구름은 한 달에 한 번 수요일에 기술, 개발, 성장, 조직 문화 등에 관한 이야기를 나누는 COMMIT 세미나를 진행하고 있습니다. COMMIT은 COMMUNICATION과 IT의 합성어로 개발자가 소스 코드를 커밋하듯 IT 업계를 이루는 분들의 역량을 COMMIT하고 있어요.
2024년 2월 주제는 ‘시야가 넓은 개발자가 되는 방법’입니다. 스타트업 CTO를 거쳐 LINE 기술임원이자 일본 No.1 배달서비스 데마에칸 CPO로서 크고 작은 팀을 리드한 김영재 님은 뛰어난 성과를 내는 개발자의 조건으로 ‘넓은 시야’를 꼽았어요. 개발자가 시야를 넓혀야 하는 이유는 무엇일까요? 2월 COMMIT 발표자 김영재 님과 나눈 이야기를 전해드립니다.
🎤 김영재 Youngjae Kim
Executive Fellow at LINE Corp, CPO of Demae-can
관리자를 강요받은 개발자로 5번의 창업과 2번의 엑싯(Exit)을 경험했습니다. 스타트업 CTO로 5년, 엑싯 후 네이버의 매니저, 지금은 LINE의 기술임원이자 일본에 상장된 자회사의 CPO이고요. 10년 동안 3명부터 400명에 이르는 프로덕트 조직을 이끌며, 팀을 민첩하게 만들기 위한 다양한 노력을 했습니다.
영재 님은 5번의 창업을 경험하셨고, 스타트업 CTO 5년, 엑싯 후 네이버 매니저를 거쳐 지금은 LINE 기술임원을 맡고 계시죠. 다양한 역할과 경험이 영재 님께서 좋은 프로덕트를 만드는 데 어떤 영향을 주었나요?
경력은 다양하지만 계속 프로덕트 메이커로 일해왔어요. 어디에서든 유저에게 의미 있는 프로덕트를 만들겠다는 마음은 지금도 변함 없습니다. 지금까지의 경력과 앞으로의 경력 모두 이를 위한 도전일 거예요.
다양한 분야의 프로덕트를 만들면서 느낀 건 결국 ‘유저와의 공감’이 가장 중요하다는 것이었어요. 동료에게도 자주 하는 이야기고요.
유저와 공감하는 능력이 필요하다는 데 공감합니다. 영재 님은 프로덕트 유저와 어떻게 가까워지셨나요?
가장 공들이는 건 유저의 피드백을 살펴보는 거예요. 그래서 제 나름대로 유저의 이야기를 들을 수 있는 더듬이를 만들었죠.
유저와 공감하는 게 중요하다고 이야기하면 보통 소프트 스킬 쪽을 강조하는데, 저는 하드웨어적으로도 장치가 필요하다고 생각했습니다. 그래서 유저 피드백을 잘 수집하는 프로덕트를 직접 만들었어요.
‘ABC User Feedback’이라는 팀 오픈 소스를 릴리즈해 개선하고 있습니다. 기능이 전사적으로 적용되기까지는 굉장히 오래 걸렸어요. 그래도 포기하지 않았습니다. 유저 피드백에서 출발하는 프로덕트 개선이 필요하다고 꾸준히 팀을 설득했어요. 지금은 유저가 접하는 모든 프로덕트에 해당 기능이 적용되어 있습니다.
최근 5년 동안 3명부터 400명까지의 프로덕트 조직을 이끄셨는데, 영재 님이 생각하는 좋은 프로덕트 팀도 궁금합니다.
규모가 커져도 소수로 일할 때의 감각을 놓치지 않는 게 중요한 것 같아요. 규모에 상관없이 손발이 잘 맞는 팀은 인원이 늘어도 작은 팀일 때와 다르지 않았습니다. 반대로 민첩하지 않은 팀을 안정화시켜 손발을 맞추기까지는 최소 1년 반에서 2년 정도 걸리더라고요.
기술임원이자 CPO로서 중요하게 생각하는 개발 철학도 있나요?
팀에서는 오픈 소스로 전환할 수 있다는 가정 하에 소프트웨어를 설계하고 있습니다. 공개를 안할지라도 말이죠. 다시 말해 오픈 소스를 개발할 때의 마인드셋이 설계 철학입니다. 프로덕트를 오픈 소스로 공개한다고 하면 시작부터 보안과 코드 등을 꼼꼼히 신경쓸 수 밖에 없거든요.
저는 아키텍처를 중요하게 생각합니다. 좋은 아키텍처 위에 좋은 코드, 좋은 코드 위에 좋은 프로덕트라고 말해요. 그런데 좋은 아키텍처를 만들려면 프로세스를 개선해야 하는 경우가 많더라고요. 새로운 프로세스를 만들어야 할 수도 있고요. 좋은 프로덕트를 만들려면 프로세스도 꾸준히 개선해야 한다는걸 깨달았습니다.
프로세스를 직접 개선한 사례도 있을까요?
직접 버전 규칙을 만들었던 적이 있어요. 업무 메신저를 보는데, 이번에 릴리즈한 게 몇 번째 버전인지, 지난 버전은 언제 릴리즈한 건지를 물어보는 질문이 2번 이상 보이더라고요. 왜 똑같은 질문이 계속 나오는지 프로세스를 살펴보게 됐죠. 버전 숫자에 의미가 없다 보니 발생한 문제더라고요.
그래서 ‘HeadVer’라는 버저닝 규칙을 만들었습니다.예를 들어 3.2345.79 버전이라면 ‘3’은 세 번째 릴리즈라는 뜻이고, ‘2345’는 2023년 45주 차에 릴리즈했다는 의미예요. 1년이 52주이니 대략 겨울에 릴리즈한 거죠. 마지막 ‘79’는 빌드 넘버입니다.
지금까지 70여 개의 프로덕트에 적용했는데 혼란이 많이 줄었어요. 이를테면 CS가 들어온 릴리즈 버전이 ‘3.2345.79’라면 릴리즈 시기를 파악하거나, 정확한 바이너리를 찾는 커뮤니케이션은 생략할 수 있죠. 여러분도 회사를 면밀히 관찰하면 분명 개선할 점을 찾을 수 있을 거예요.
2월 COMMIT에서는 어떤 이야기를 들려주실 예정인가요?
함께 일하고 싶은 프로그래머가 되는 게 중요하다는 이야기를 자주 해요. 협업할 때 편하고, 함께할수록 풍성한 결과가 기대되는 동료가 되는 거죠.
유지보수하기 쉽고 깔끔한 코드를 쓰는 건 기본이고, 주변을 돌아보며 프로세스를 개선하는 것도 필요합니다. 나와 일했을 때 팀의 효율이 좋아진다는 걸 경험하면 그 자체로 본인과 팀에 엄청난 힘이 되거든요. 개발자도 시야를 넓혀야 한다는 점을 강조드리고 싶어요.
2월 COMMIT에서는 Interface, Process, Capacity 측면에서 시야를 넓히는 방법을 공유하려고 해요. Interface는 프로덕트 유저 뿐만 아니라, 코드의 유저까지 생각하며 개발하는 것, Process는 내가 오늘 코딩하는 토픽은 어디에서 어떻게 왔고 어떻게 운영되고 있는지 살펴보는 것, 끝으로 Capacity는 긴 호흡으로 지치지 않고 넓게 협업하며 개발하는 법에 대해 이야기할 예정입니다.
개발 역량도 중요하지만, 장기적으로는 넓은 시야에서 팀과 동료, 비즈니스까지 고려할 수 있어야 합니다. 제 이야기가 정답은 아니지만, 이번 COMMIT에서 영감을 얻으시면 좋겠어요.
더 자세한 이야기는 2월 14일 수요일 오후 7시에 열리는 COMMIT에서 들을 수 있습니다.
Edit Sunny Design Lil
