테크 리드 진경 님을 만나다

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

Q. 진경 님은 이전 직장에서 서광열 대표님(이하 ‘광열 님’)과 함께 일해보신 경험을 바탕으로, 코드박스에도 합류하셨다고 들었어요.

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

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

Q. 소프트웨어 엔지니어 그룹은 코드박스에서 가장 큰 조직인데요. 테크 리드로서 뭘 가장 고민하시나요?

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

Q. 코드박스 소프트웨어 엔지니어 그룹의 기본적인 개발 환경을 한번 정리해 주시겠어요?

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

Q. Python Django는 계속 사용할 예정인가요? 새로 들어오는 개발자들이 이 프레임워크에 얼마나 능숙해야 하는지 궁금합니다.

Python Django를 유지하고 있는 건 저희 팀 모두 똑같이 생각할 것 같은데요. 레거시 코드나 프로토타입을 버리고 새로 작성해도 혁신적인 제품이 나오지 않을 것이라는 생각이 있어요. 그래서 기존 코드를 점진적으로 개선하고 있습니다. Django 경험이 없는 소프트웨어 엔지니어라고 해도 기본기가 탄탄하다면 금방 적응할 수 있는 수준이고요. 실제 면접에도, Django 자체에 대한 것보다는 데이터베이스와 웹 기술에 대해 얼마나 이해하고 있는지를 더 중요하게 봅니다.

프레임워크에 종속적으로 코드를 작성하지 않고 있기 때문에 필요하면 다른 프레임워크로 전환할 수 있고요. 하지만 현재로서는 그렇게 중요한 아젠다가 아니기 때문에 유지되고 있어요. 지금은 웹 프레임워크보다 세금 계산이나 문서 생성이 정확한지 등 구현된 기능이 정확한 검증하는 것에 초점을 맞추고 있습니다.

Q. Python Django가 필수적인 요소가 아니라 지금 굳이 모두 전환할 정도로 우선순위가 높지 않기 때문에 유지하고 있는 거네요.

네, 우선순위가 높은 것부터 작업하고 있습니다. 예를 들면 제품 개발 초기에는 클라이언트가 모두 자바스크립트로 작성되어 있었는데 모두 타입스크립트로 바꿨고요. 최근에는 Python 코드를 mypy라는 툴로 타입 에러를 잡을 수 있도록 타입을 붙이고 있습니다. ‘엔지니어 한 명당 하루에 파일 5개씩 작업하기’ 같은 루틴을 만들어서 점진적으로 바꾸는 방식을 취하고 있어요. 만약 웹 프레임워크를 바꿔야 한다고 해도 비슷한 방식으로 바꿀 수 있다고 생각합니다.

Q. 개발팀을 뽑을 때 코딩 테스트는 어느 정도 고려하시나요? 

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

Q. 전화 면접 시 컴퓨터공학 기초 내용에 대해 많이 물어보시는 걸로 아는데, 소프트웨어 엔지니어로서 이러한 지식을 갖추는 것이 왜 중요한지 궁금합니다.

전화 면접에서 이런 기초적인 질문을 던지는 이유는 소프트웨어 엔지니어가 어려운 문제를 해결할 능력이 있는지 평가하기 위해서입니다. 자료구조나 알고리즘, 데이터베이스 이론 등 기초 지식은 쉬운 것도 있고, 어려운 것도 있어요. 그런데 현업을 하다 보면 풀기 어려운 문제에 부딪힐 때가 있어요. 이떄 문제 해결을 위해 난이도가 높은 기초 지식을 활용하기도 하는데요.

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

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

Q. ZUZU에서는 프로덕트 디자이너들이 CSS 등 웹 퍼블리싱을 담당하고 있는데요. 개발자 입장에서 어떤 장점이 있을까요?

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

Q. 저희 서비스가 다루는 분야가 넓다 보니, 업무 분장이 기능 단위로 이뤄지고 있잖아요. 관련해서 한번 설명 부탁드려요.

저희 제품은 많은 도메인 지식이 필요해서 신규 입사자들이 초반 업무에 익숙해지는데 어려울 수 있어요. 그래서 저희 팀에서는 기능별로 오너를 정해 업무를 진행하고 있습니다. 업무 분장과 지식 공유를 통해 팀 전체의 역량을 향상시키기 위해서 인데요. 예를 들어 스톡옵션은 A님이, 개인투자조합은 B님이 맡는 식으로요. 물론 엄격한 구분은 아니고, 다른 사람들도 언제든 해당 기능에 대해 논의할 수 있어요. 필요한 경우 개발에 참여할 수도 있고요. 

그리고 코드 리뷰를 통해 서로 작업물을 검토합니다. 제품 출시할 때 관련된 코드를 최소한 두 명 이상이 완전히 파악하고 있어야 해요. 이 과정에서 작업자는 본인이 짠 코드를 다른 소프트웨어 엔지니어에게 잘 이해시켜야 하니, 자연스럽게 팀 내에 지식을 공유하고 지속적으로 발전시킬 수 있습니다.

Q. 코드 리뷰는 어떤 프로세스로 하고 계신가요?

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

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

Q. 새로운 기능을 만들게 될 때, 업무 프로세스가 어떻게 되나요?

고정된 프로세스는 없지만 대략적인 과정을 말씀드리면, 요구 사항은 다양한 경로로 전달돼요. 예를 들어 외부 협업의 경우 API 문서나 화면 명세 등을 전달받습니다. 그러면 프로덕트 디자이너와 CPO가 함께 필요한 기능을 정리하고 구현 범위를 결정합니다. 큰 기능의 경우, 프로덕트 디자이너가 스케치를 한번 먼저 그리는데요. 상세한 스케치는 아니고, 때에 따라 칠판에 대략 그리기도 해요. 이런 화면이 있고, 여기서 어디로 넘어가겠다, 정도의 수준에서 논의하죠.

논의가 정리되면 소프트웨어 엔지니어 그룹은 모델링, 프로덕트 디자이너 그룹은 스케치를 좀 더 구체화 합니다. 모델링과 스케치를 통해 대략적인 큰 그림을 결정하고 나면 세세한 부분은 담당 프로덕트 디자이너와 소프트웨어 엔지니어가 채워나가며 기능을 완성해 갑니다.

Q. 좋은 소프트웨어 엔지니어가 되려면 기본적으로 커뮤니케이션 스킬이 좋아야 한다고 많이 얘기하던데요. ZUZU의 소프트웨어 엔지니어 그룹에서 특히 강조하는 커뮤니케이션 스킬이나 관련 마인드 셋이 있다면 뭘까요?

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

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

Q. 요청을 무조건 수행하는 게 아니라 이 요청이 얘기하는 문제가 뭔지 한 번 더 생각하는 게 중요하다는 거죠. 소프트웨어 엔지니어 그룹에서 좋은 퍼포먼스를 내기 위해서는 이런 걸 빨리 파악하는 것도 중요하겠네요.

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

Q. 진경 님이 생각하시는 소프트웨어 엔지니어 그룹의 인재상은 무엇인가요?

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

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

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

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

Q. 마지막 질문드릴게요. 진경 님이 소프트웨어 엔지니어 그룹과 이루고 싶은, 최종적인 목표가 있다면?

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