ZUZU 고객분들로부터 가장 많이 듣는 칭찬이 ‘너무 쉽고 편하다’인데요. ZUZU가 고객에게 쉽게 다가갈 수 있는 서비스가 될 수 있었던 건 소프트웨어 엔지니어 구성원(이하 'SE 구성원')이 끊임없이 고민하고 노력한 덕분이기도 해요. ZUZU 서비스 핵심 가치를 만들어 내고 지속적으로 성장시키는 SE 구성원에 어떤 사람들이, 어떻게 일하고 있을까요? 개발그룹의 한 축인 테크 리드 정진경 님을 만나 이야기를 들어보았어요.

광열 님이 CTO로 있을 때 처음 인연을 맺었는데요. 팀원 케어와 목표 설정, 팀 이끌기 등 광열 님에게 소프트웨어 엔지니어로서, 그리고 상사로서 배울 점이 많다고 생각했어요. 그래서 제가 병역 특례가 끝나고 학교로 돌아갔을 때 광열 님이 저를 불러서 ‘이런 걸 준비하고 있는데 개발할 소프트웨어 엔지니어가 필요하다’고 하셨을 때 같이 해야겠다고 생각했습니다.

사실 당시에 저도 스타트업을 가고 싶었지만, 생존할 수 있는지에 대한 의문이 있었어요. 제가 이전에 병역 특례로 근무했던 곳이 근무 끝나고 얼마 안 되어 폐업했거든요. 하지만 광열 님은 믿을 수 있다고 생각해서 코드박스에 조인했어요. 

최근에는 조직의 체계를 좀 더 잡아야겠다고 생각하고 있어요. 기능이 예전보다 훨씬 많아지면서 새로운 소프트웨어 엔지니어들이 조직에 적응하는 데 시간이 오래 걸리더라고요. 새로운 개발자가 들어와도 조직이 지속적으로 유지되고 제품이 발전할 수 있도록 문화와 시스템을 어떻게 개선할지에 대한 고민을 하고 있습니다. 특히, 새로운 SE 구성원들의 온보딩 과정을 어떻게 향상시킬 수 있는지 고민하고 있어요. 

서버 개발은 Python Django, 클라이언트 개발은 React 코드를 TypeScript로 작성하고 있습니다. 서버 클라이언트 통신은 대부분 GraphQL을 사용하고 일부에서만 REST API를 쓰고 있습니다. GraphQL은 소프트웨어 엔지니어들이 처음 접할 수도 있는 기술이지만, 복잡하지 않아 적응하기 어렵지 않습니다. 

Python Django를 유지하고 있는 건 저희 SE 구성원들이 모두 똑같이 생각할 것 같은데요. 레거시 코드나 프로토타입을 버리고 새로 작성해도 혁신적인 제품이 나오지 않을 것이라는 생각이 있어요. 그래서 기존 코드를 점진적으로 개선하고 있습니다. 

Django 경험이 없는 소프트웨어 엔지니어라고 해도 기본기가 탄탄하다면 금방 적응할 수 있는 수준이고요. 실제 면접에도, Django 자체에 대한 것보다는 데이터베이스와 웹 기술에 대해 얼마나 이해하고 있는지를 더 중요하게 봅니다.

프레임워크에 종속적으로 코드를 작성하지 않고 있기 때문에 필요하면 다른 프레임워크로 전환할 수 있고요. 하지만 현재로서는 그렇게 중요한 아젠다가 아니기 때문에 유지되고 있어요. 

지금은 웹 프레임워크보다 세금 계산이나 문서 생성이 정확한지 등 구현된 기능이 정확한 검증하는 것에 초점을 맞추고 있습니다.

네, 우선순위가 높은 것부터 작업하고 있습니다. 

예를 들면 제품 개발 초기에는 클라이언트가 모두 자바스크립트로 작성되어 있었는데 모두 타입스크립트로 바꿨고요. 최근에는 Python 코드를 mypy라는 툴로 타입 에러를 잡을 수 있도록 타입을 붙이고 있습니다. ‘엔지니어 한 명당 하루에 파일 5개씩 작업하기’ 같은 루틴을 만들어서 점진적으로 바꾸는 방식을 취하고 있어요. 

만약 웹 프레임워크를 바꿔야 한다고 해도 비슷한 방식으로 바꿀 수 있다고 생각합니다. 

채용 과정에서 알고리즘 문제를 풀어보는 것으로 코딩 테스트를 하고 있는데요. 테스트 완수까지 며칠 정도 여유 시간을 드려요. ‘이 정도는 풀 수 있어야 다음 채용 단계로 넘어갈 수 있다’고 생각되는 내용을 문제로 내고요. 그래서 코딩 테스트 문턱이 높다기보다는 스크리닝 용도로 사용하고 있습니다. 제출된 코딩 테스트 결과는 코드 작성 습관 등을 확인하는 데 참고하고, 대면 면접 준비할 때도 활용합니다. 

전화 면접에서 이런 기초적인 질문을 던지는 이유는 소프트웨어 엔지니어가 어려운 문제를 해결할 능력이 있는지 평가하기 위해서입니다. 

자료구조나 알고리즘, 데이터베이스 이론 등 기초 지식은 쉬운 것도 있고, 어려운 것도 있어요. 그런데 현업을 하다 보면 풀기 어려운 문제에 부딪힐 때가 있어요. 이때 문제 해결을 위해 난이도가 높은 기초 지식을 활용하기도 하는데요.

기본기가 약하다면 지식 습득과 문제 해결을 동시에 해야 해요. 시간이 더 오래 걸리겠죠. 많이 헤매기도 할거고요. 반대로 기본기가 탄탄한 사람들은 문제가 생겼을 때 상황 파악이 좀 더 빠르고, 금방 문제 해결을 위한 코딩을 할 수 있어요.

그래서 문제를 해결할 수 있는 기초 지식과 능력을 갖춘 소프트웨어 엔지니어인지 확인하기 위해, 면접에서 기초 지식을 질문하고 있습니다.

이 방식에는 장단점이 있지만, 장점 중 하나는 프로덕트 디자이너들이 코드를 직접 수정할 수 있다는 거예요. 

예를 들어, 애니메이션을 추가하고 싶은데 프로덕트 디자이너가 코드를 건드리지 못하고 소프트웨어 엔지니어에게 요청해야 하면 둘 다 불행해질 수 있어요. 프로덕트 디자이너가 요청한 결과물이 마음에 들지 않을 수 있는데, 그러면 소프트웨어 엔지니어에게 다시 부탁하는 과정이 반복돼요. 하지만 프로덕트 디자이너가 주도적으로 작업할 수 있다면, 이런 비효율성을 줄일 수 있습니다. 그 결과 소프트웨어 엔지니어는 자신의 업무에 더 집중할 수 있게 되고요. 

저희 제품은 많은 도메인 지식이 필요해서 신규 입사자들이 초반 업무에 익숙해지는데 어려울 수 있어요. 그래서 저희 SE 구성원은 기능별로 오너를 정해 업무를 진행하고 있습니다. 업무 분장과 지식 공유를 통해 팀 전체의 역량을 향상시키기 위해서 인데요. 

예를 들어 스톡옵션은 A님이, 개인투자조합은 B님이 맡는 식으로요. 물론 엄격한 구분은 아니고, 다른 사람들도 언제든 해당 기능에 대해 논의할 수 있어요. 필요한 경우 개발에 참여할 수도 있고요. 그리고 코드 리뷰를 통해 서로 작업물을 검토합니다. 제품 출시할 때 관련된 코드를 최소한 두 명 이상이 완전히 파악하고 있어야 해요. 이 과정에서 작업자는 본인이 짠 코드를 다른 소프트웨어 엔지니어에게 잘 이해시켜야 하니, 자연스럽게 SE 구성원내에 지식을 공유하고 지속적으로 발전시킬 수 있습니다.

크게 모든 엔지니어가 참여하는 리뷰와 1대1 리뷰로 나뉩니다. 우선 데이터 모델링하는 부분을 가장 심도있게 리뷰합니다. 주로 새 기능을 추가할 때 데이터를 어떻게 저장할 것인지에 대한 것인데, 추후 유지보수나 기능 확장에 있어서 큰 영향을 미치기 때문에 소프트웨어 엔지니어 그룹 전체가 리뷰합니다. 

이후에 서버와 API 통신, 화면 표시 등 상대적으로 중요도가 낮은 부분은 1대1로 리뷰하고요. 1대1 코드 리뷰는 보통 GitHub의 Pull Request를 통해 리뷰어를 지정하고, 대면 리뷰를 권장합니다. 1대1 코드 리뷰는 수시로 하게 되는데, 하루에 최소 3~4건 이상은 하는 것 같아요. 리뷰하는 패치 규모는 몇 줄짜리 간단한 패치부터 수백 줄짜리 패치까지 다양합니다.

요청받은 기능이 왜 필요한지 이해하고, 진짜 문제를 파악하기 위해 커뮤니케이션하려는 자세가 중요해요. ZUZU는 업무용 메신저로 슬랙을 사용하는데요. 기능 개발이나 추가 요청이 있을 때 소프트웨어 엔지니어 그룹이 직접 슬랙 멘션 되는 경우가 많아요. 프로덕트 기획자가 따로 없으니까요. 

예를 들어 파트너 로펌이나 다른 구성원에서 ‘이것이 불편하니 고쳐달라’거나, ‘이런 기능을 새로 만들어 달라’고 할 때가 있는데요. 이럴 때 아무 저항없이 ‘필요하구나’, ‘작업해야 하는구나’ 생각하는 게 아니라, 진짜 불편한 점이 무엇인지 물어보는 게 중요합니다. 정말 불편한 점이 뭔지 알고 작업을 시작하는 것과, 바로 작업에 들어가는 건 큰 차이가 있어요.

매우 중요합니다. 100개의 기능 요청 중 40개 정도는 안 해도 되는 일일 수 있어요. 이를 걸러내는 것이 좋은 퍼포먼스를 내는 데 중요한 스킬이죠. 

3가지 정도 얘기할 수 있을 것 같아요. 

첫 번째, 기술적인 호기심이 많은 사람. 이러한 사람들은 새로운 기술을 배우고 적용하는 것을 즐기세요. 그래서 어떤 문제가 발생했을 때 빠르게 솔루션까지 도달해요. 

두 번째로, 제품에 대한 애정이 넘치는 사람. 이런 분들은 개발을 숙제처럼 하기보다는, 이 제품에 어떤 기능이 더 들어가면 좋을지, 더 효율적일지 스스로 생각하는 데 어려움이 없어요. 실제로 지금 소프트웨어 엔지니어 그룹에도 이렇게 작업하시는 소프트웨어 엔지니어들이 많고요. 

세 번째로, 기술적인 것 외에 사용자 경험도 궁금해하는 사람. 예를 들어, 사용자가 이 버튼을 못 쓰게 하고 싶은데, 이때 사용자가 버튼을 누르지 못하게 하는 방식과 버튼을 숨기는 것에 어떤 차이가 있지? 이렇게 자연스럽게 궁금해하는 거죠. 의식적으로 고민하고요. 이런 특성을 가진 분이라면 ZUZU의 소프트웨어 엔지니어 그룹에 잘 맞으실 것 같고, 많은걸 성취하실 수 있을거라 생각합니다.

세상에 없던 경험이 가능한 제품을 만들어서 시장 혁신을 선도하고 싶습니다. ZUZU와 유사한 서비스들이 ZUZU 때문에 많이 긴장했음 좋겠습니다. (웃음)