🍋

일에 책임지는 자신감에 대하여 - 레몬베이스 Crew Interview

레몬베이스 Engineering Team이 일하는 방식을 널리 알리기 위해 진행한 인터뷰입니다. 김안나(Head of People Science)가 묻고, 박경준(Software Engineer)이 답변했습니다. 그리고 추가영(Content Manager)이 이 과정을 지켜보고 기록했습니다. - Software Engineer는 무슨 일을 하고, 어떤 고민이 있는지 - 난이도가 높은 문제를 해결하면서 보람을 느끼는 엔지니어는 어떻게 성장하고 있는지 - 실수를 관리하는 엔지니어링 팀의 문화는 어떻게 구축되고 있는지 궁금하시다면 가볍게 읽어보세요.

이 인터뷰는 2021.05 진행된 인터뷰로, 시일이 지남에 따라 조직 구성이나 일하는 방식 등 일부 out-dated 된 내용이 있을 수 있습니다. 과거 기록 또한 팀이 거쳐온 소중한 성장 과정이기에 업데이트하지 않고 남겨두고 있으며, 최신화된 내용이 궁금하신 분들은 레몬베이스 엔지니어링 그룹 페이지를 확인해주세요 

Q. 자기 소개 부탁드려요.

안녕하세요, 레몬베이스에서 소프트웨어 엔지니어로 일하고 있는 박경준입니다. 팀에서 사용하는 닉네임은 라이언(Ryan)이고요. 레몬베이스에 합류하기 전엔 병역특례로 SI(시스템통합) 업체에서 일한 것을 시작으로, 4년여 동안 리디북스(현 리디)에서 일했어요. 현재 레몬베이스 최고기술책임자(CTO)인 대니(Danny)와는 리디에서도 같은 팀에서 일한 인연이 이어지고 있네요.

Q. 레몬베이스에서 엔지니어는 어떤 일을 하나요? 라이언이 최근 일주일 동안 시간을 가장 많이 쓴 일을 중심으로 설명해 주세요.

제가 회사에서 가장 많은 시간을 쓰고 있는 건, 유료화 프로젝트입니다. 결제 시스템을 구축하는 유료화 프로젝트에 쓰는 시간이 전체의 80~90%에 달합니다. 입사하고 나서 한 달 정도 온보딩을 거친 뒤 지금까지 5~6개월간 이 프로젝트를 진행하고 있어요. 전 직장인 리디에선 주로 신규 서비스를 만드는 일을 해서 결제와 관련된 업무를 맡아본 적이 없었기 때문에 처음엔 마냥 설레었죠. 그런데 결제라는 게 워낙 민감한 정보를 처리하는 과정이다보니, '정말 복잡하다'고 피부로 느끼고 있어요. 레몬베이스는 단건으로만 결제를 하는 게 아니라, '구독'을 위해 정기 결제를 할 수 있어야 하기 때문에 복잡하죠.

나머지 10%의 시간은 개발 방법론이나 다른 팀과의 커뮤니케이션을 원활히 하기 위한 프로토콜을 만들기 위해서 애자일 방법론을 공부하는 등에 쓰고 있어요.

Q. 결제시스템 개발이 '정말 복잡하다'고 느꼈던 이유와, 복잡한 문제를 해결한 과정을 좀 더 구체적으로 듣고 싶어요.

같은 구독 서비스 정기 결제라도, 예를 들어, 넷플릭스는 동일한 멤버십 요금제를 유지하면 매달 똑같은 금액을 결제하면 되죠. 그런데 레몬베이스는 B2B(기업간거래) SaaS(Software as a Service, 서비스형 소프트웨어)기 때문에 사용하는 인원 수에 따라 과금합니다. 결제하려는 시점에 회사에서 구성원 몇 명이 레몬베이스 서비스를 쓰고 있는지에 따라 결제 금액이 바뀌게 되죠. 매달 정기 결제를 한다면, 한 달 안에도 인원 수가 수시로 바뀔 수 있는 부분을 어떻게 처리할 지가 관건이었습니다. 월간/연간 플랜 등 다양한 옵션이 있는 데다, 입사나 퇴사 등으로 추가/삭제되는 인원의 사용 일수에 따라 요금을 부과하거나 환불해야 하다보니 결제 금액 계산이 복잡할 수밖에 없죠.

인원 수에 따라 요금을 일할 계산하는 과정이 너무 복잡해져서 개발이 어느 정도 진행된 상태에서 기획 자체를 크게 바꾸는 일도 있었습니다. (편집자 주: "개발자가 이해하기도 어려운 수준까지 복잡해져서 고객을 이해시키기는 불가능할 정도였다고 판단했다"는 것이 CTO인 대니의 설명입니다.) 고객 입장에서 결제 과정을 더 쉽게 이해할 수 있는 방향으로 기획을 변경하자고 대니가 제안했고, 일주일간 팀 내 논의를 거쳐 결정했습니다. 원래 기획대로 진행되었다면, 유료화 프로젝트를 조금 더 일찍 끝낼 수 있었겠지만 유료화 후 관리에 골머리를 앓았을 거라고 생각해요. 게다가 누구나, 언제든지 이런 제안을 해서 더 나은 방향으로 계획을 바로바로 바꾸는 것이 가능하다고 모두가 깨닫는 계기가 되었고요.

개발 일정과 업무로드에 영향을 미치더라도 더 나은 방향을 제시할 수 있는 팀 문화 이 대목에서 벤 호로위츠의 <하드씽>에 등장하는 다음의 질문이 떠올랐습니다.

이런 상황을 가정해보자. 당신 회사의 소프트웨어 엔지니어가 제품 아키텍처에서 앞으로 더 발전된 제품으로 진화하는 데 심각한 걸림돌이 될 문제점을 발견한다. 엔지니어 판단으로는 그 문제점을 해결하려면 제품 출시 일정이 3개월 늦어지는 차질이 빚어진다. 다른 팀원들이 문제해결을 위해 3개월이 지연되는 것은 용인할 수 있는 수준이라고 입을 모은다. 그런데 엔지니어가 막상 작업을 시작한 후 실제로는 9개월이 지연됐다. 하지만 그가 발견한 것은 꼭 해결해야만 했던 정말로 중요한 문제였다. 당신이라면 창의성과 용기를 발휘한 그 엔지니어를 포상하겠는가, 아니면 그에게 일정 차질에 대한 책임을 묻겠는가? - 벤 호로위츠 저, 안진환 역 <하드씽> p.357

Q. 레몬베이스 엔지니어링 팀 고유의 일하는 방식 혹은 문화 측면에서 라이언이 강조하고 싶은 것이 있나요? 과거에 다녔던 회사들과 비교해주셔도 좋아요.

팀의 문화에 대해서 미리 생각해보면서 적어봤는데, 크게 네 가지 특징을 찾았어요. 첫 번째는 (이전 질문의 답변에서도 드러났지만) 고객 관점에서 생각한다는 것이예요. 서비스를 만들 때 최대한 고객을 이해하고 고객의 니즈가 뭔지 파악하고, 그 니즈를 해소하려고 해요. 서비스를 기획하는 PO(프로덕트오너), PD(프로덕트디자이너)만이 아니라, 엔지니어도 고객의 관점에서 생각하려고 하는 게 저희 문화 중 하나인 것 같아요.

두 번째는 엔지니어링 팀뿐만 아니라 레몬베이스 전체의 문화인 것 같은데, 무엇이든 공유합니다. 일단 공유할 수 있는 슬랙 채널이 많죠. 팀 엔지니어링 채널도 있고. 좋은 블로그 글이나 영상이 있으면 서로 공유하고, 꼭 알아야 할 내용은 일일이 당사자를 멘션해서(지목해서) 알려주기도 해요. 그리고 매주 월요일 팀 미팅의 마지막 어젠다 자체가 '쉐어링(공유)'입니다. 누구나 자유롭게 5분 정도 한 주간 자기가 경험한 것을 나눠요. 이렇게 공유가 생활이 되다보니 제가 알고 있는 범위를 벗어나 다양한 정보와 지식을 얻을 수 있는 경로가 많아졌어요.

세 번째는 '포스트 모템(post-mortem, 사후분석)'이예요. 실수를 예방하는 것도 물론 중요하지만 불가피하게 발생한 실수를 관리하는 방식이 엔지니어링 팀 문화로 자리 잡았어요. 장애가 일어나면 누군가를 탓하는 게 아니라 장애의 원인을 파악하고 해결하는 데 초점을 맞추는 겁니다. 그리고 같은 장애가 다시 발생하지 않도록 하기 위해선 어떻게 시스템을 정비해야할지에 대해 팀 회의를 통해 함께 고민하고, 다른 팀에도 공유하는 문화가 있어요.

포스트 모템은 이렇게 합니다. "코로나19로 인해 재택 근무를 하는 날이 많아서 온라인으로 주로 커뮤니케이션이 이뤄지다보니, (1) 장애 발생 즉시 화상 회의를 열어 누가 당장 장애 복구에 참여할 수 있는지부터 확인한 뒤 신속하게 1차 대응을 합니다. 서비스에 문제가 생기면 일차적으로 Slack에 센트리(Sentry) 알람이 오는데, 팀원 전부가 알람을 보고 즉각 반응하면 좋겠지만 다수가 본다고 생각하면 은연중에 누군가 처리하겠지 하고 넘길 수 있습니다. 그래서 엔지니어링 팀에선 매일매일 센티넬(Sentinel)과 부 센티넬을 정해 센트리를 먼저 확인하도록 하는, 일종의 '당번제'를 운영하고 있어요. (2) 장애를 제일 먼저 발견한 사람이나 담당자를 정해 장애 원인을 파악하고, 이를 문서로 정리해 팀 내에 공유합니다. 시각별로 어떤 조치가 이뤄졌는지도 기록합니다. (3) 팀 내 모든 크루들은 이 문서를 읽고 난 뒤 같은 장애를 또 겪지 않으려면 우리가 어떻게 해야 할지 개선 아이디어를 문서에 남깁니다. (4) 해당 장애가 발생한 다음 주 월요일 팀 회의에서 다시 한 번 장애 복구 시나리오와 발생 원인을 공유합니다. 미리 크루들이 적어놓은 개선안을 다 같이 보면서 실행 시기를 결정합니다. 당장 일주일 안에 개선할 수 있는 실행 방안도 있고, 분기에 걸쳐서 개선해 나가야 하는 사항도 있기 때문입니다. 액션 아이템을 정하고, 각각 담당자를 두어 실행해 나가기로 합니다."

마지막은 이런 문화를 만드는 주체에 관한 것인데, 엔지니어링 팀 내에선 일하는 방식이나 방법론을 CTO인 대니만 이끌어 가는 게 아니라, 다 같이 만들어가고 있다는 점을 강조하고 싶습니다. 이게 예전에 일한 조직과 많이 다른 부분인데요. 당시엔 팀장 혼자 많은 고민을 한 뒤 '우리 이렇게 하자'고 하면 나머지 팀원들이 그대로 따라 가는 경우가 많았거든요. 대니도 물론 제안을 많이 하긴 하지만 대니 뿐만 아니라 다른 엔지니어링 팀 크루들도 일하는 방식의 변화를 이끌고 있어요. 예를 들어, 최근엔 소프트웨어 엔지니어인 제임스(James)의 제안으로 <클린 애자일>이란 책으로 함께 스터디하고 있죠. '내가 성장하면서 회사도 같이 성장하면 좋겠다'는 주인 의식이 있기 때문에 팀장이 이끄는대로 끌려가는 게 아니라, 한 사람 한 사람이 주도적으로 일할 수 있는 것이라고 생각합니다.

Q. 제품을 만드는 메이커로서, 라이언이 중요하게 생각하는 가치가 있나요? 있다면 무엇인가요?

이 질문에 대한 답도 두 가지로 생각해왔어요. 첫번째는 신뢰입니다. 제품에 대한 신뢰도 사람 간의 신뢰와 비슷해서 신뢰를 쌓는 데는 오랜 시간이 걸리는데, 잃는 건 한 순간이죠. 더군다나 레몬베이스는 인사 정보를 다루는 B2B SaaS를 만드니까 신뢰가 더욱 중요하다고 생각해요.

제품을 만드는 메이커로서 두 번째로 중요하게 생각하는 가치는, 제가 미리 적어온대로 읽어보면 '사용자가 좀 더 게을러질 수 있는 제품 만들기'입니다. 모든 소프트웨어는 사람을 편하게 해주기 위한 도구기 때문에 UX(사용자환경)가 좀 더 편해질 수 있도록 노력을 기울여야 한다고 생각합니다.

Q. '사용자가 좀 더 게을러 질 수 있는 제품'이라는 표현이 재밌습니다. 이런 관점에서 현재 레몬베이스 제품은 10점 만점에 몇 점 짜리인가요?

3점입니다. 사실 제 기준이 매우 높기 때문에 높은 점수를 주지 못했습니다. 어떤 서비스를 써도 '이래서 불편하다' '왜 이렇게 만들었어'라고 투덜거린다는 점을 감안해서 받아들여주세요. 제가 평소에도 깐깐하단 평가를 많이 듣습니다. 그러다보니 아무래도 UX적으로 사소한 것이라도 개선해 나가려고 노력을 기울이게 되죠. 예를 들어, 지난 3월엔 1:1 미팅 보드에서 마우스로 '추가' 버튼을 클릭해야지만 어젠다를 생성할 수 있다는 것이 불편하다고 느꼈고, 단축키(Ctrl+Enter)로도 어젠다를 추가할 수 있도록 개선하기도 했고요.

라이언의 문제 제기로, 1:1 미팅 어젠다를 기록하는 입력창에서 줄바꿈 기능을 개선하기 위한 논의가 슬랙에서 활발히 이뤄졌다. 슬랙 캡처

(이야기를 듣다보니, 문득 궁금하네요. 라이언의 기준으로 10점 만점을 줄 수 있는 서비스는 무엇인가요?)

넘사벽이긴 한데, 유튜브와 넷플릭스를 꼽을 수 있습니다. 모바일 화면 우측을 두 번 탭하면 10초 빨리감기(패스트포워드), 좌측을 탭하면 되감기(리와인드)를 할 수 있는 기능처럼 유튜브의 UX는 매우 직관적이죠. 넷플릭스는 일부러 장애를 일으켜서 대응 시스템을 강화하는 '카오스 몽키'란 제도를 둬서 시청자의 불편을 최소화할 수 있는 아키텍처를 구축하고 있다는 점에서 높은 점수를 줄 수 있습니다.

Q. 언제 일의 재미와 보람을 느끼나요?

대니의 답변과도 비슷한데, (이쯤에서 대니의 인터뷰도 읽고 싶다면 성장하는 엔지니어링 팀은 어떻게 일하는가) 어려운 문제를 해결했을 때 가장 큰 보람을 느낍니다. 최근에 보람을 느꼈던 일 중에선 배포 환경을 바꾼 일이 가장 먼저 떠오르네요. 유료화 프로젝트를 진행하면서 배포 환경을 빈스토크(Beanstalk)에서 AWS의 ECS(Elastic Container Service)로 바꿔야 했어요. 사용하고 있는 인프라도 손봐야 했고 기존에 어떻게 구축되어 있는지도 전체적으로 파악해야 했기 때문에 배포 환경을 바꾼다는 것 자체도 큰일이었는데, 입사한지 1~2개월 밖에 안되었던 시점에 해냈기 때문에 더 크게 보람을 느꼈어요. 빈스토크라는 서비스도 사용해본 적이 없었고, 레몬베이스에서 작성된 코드를 이해하는 일도 병행해야 했기 때문에 난이도가 높았죠.

Q. 반대로 언제 일이 어렵고 힘든가요

제품을 만들었는데 아무런 피드백이 없을 때. 매출이 올랐는지 내렸는지 시장의 반응을 알 수 있어야 하는데 제품에 대한 호불호조차 파악할 수 없으면 '난 뭘 한 거지'란 생각이 들면서 힘이 빠지더라고요.

단순 반복 작업도 힘들어요. 어떤 일이 주어지면 '내가 이 일을 마쳤을 때 성장할까'라는 질문을 하게 되는데, 단순 반복 작업으로는 스스로 성장했다고 느끼기 쉽지 않죠.

Q. 과거에 했던 일과 비교할 때, 지금 하고 있는 일이 더 도전적인 지점이 있나요?

B2B SaaS를 만드는 것 자체가 도전적인 일이라고 생각합니다. 지난 분기에 내부적으로 멀티 태넌트(multi-tenent) 분리를 위해서 스터디를 많이 했는데, 한국어로 된 자료가 거의 없더라고요. B2B SaaS 개발 경험이 풍부한 개발자가 국내엔 많이 없다는 반증일 거란 생각이 들었습니다. 그래서 B2B SaaS를 잘 만드는 개발자가 된다면, 적어도 한국에선 인정 받는 개발자가 될 수 있겠죠.

초기 스타트업이니까, 애자일 방법론, 타 팀과의 커뮤니케이션 방식 등 모두 제로에서부터 맞춰가야 하는 것도 도전적인 일이라고 생각합니다.

Q. 레몬베이스에서 일한 지난 반년간 개인적으로 가장 성장한 부분은 무엇인가요?

미리 인터뷰 질문지를 받고 이 부분에서 고민을 많이 했어요. 고민을 하면서 떠오른대로 말하자면, 저는 '자신감'인 것 같아요. 입사 초기엔 자신감이 없어서 어떤 일이 주어지면 '내가 이걸 할 수 있을까' '내가 제대로 해내지 못하면 어쩌지' 이런 걱정부터 했다면, 지금은 어떤 일이 주어지든 새로운 도전을 즐기게 된 것 같아요. 그 일을 마쳤을 때 어떤 결과가 있든지 스스로 책임지면 되지, 하기도 전에 미리 걱정할 필요 없다는 마인드로 많이 변했어요. 이렇게 자신감을 가지니까 스스로 도전적인 일을 찾아서 하려고 하게 되더라고요.

Q. 자신감을 갖게 된 계기가 있나요?

엔지니어링 팀은 한 달에 한 번, 대니와 1:1 미팅을 하는데(앞으로는 격주에 한번씩 한다고 합니다.) 주기적으로 1:1을 하면서 대니가 봤을 때 제가 개선했으면 하는 점에 대해서 물어봤어요. 또 3개월 수습 기간 중 한 달이 지나면 동료들의 평가를 받게 되는데 다른 크루들도 그만(Stop)했으면 하는 점으로 '자신감을 가졌으면 좋겠다'는 피드백을 남겼고요. 같은 시기에 대니와 1:1 미팅을 하면서 제가 어떤 상태인지, 스스로를 낮게 평가하다보니 고민이 많다는 얘기를 쏟아내게 됐어요. 그때 대니가 저에게 해준 조언이 큰 도움이 되었습니다. '그런 고민할 시간에 일단 도전하고 책임을 지면 된다'는 대니의 조언을 듣고, 바로 다음날부터 마음가짐이 바뀌었어요. 스스로 돌아봐도 그런 고민을 한 시간이 아깝게 느껴지더라고요. 그 시간에 내가 어떻게 더 성장할 수 있을지를 고민했으면 좋았을텐데. 그렇게 거짓말처럼 1:1 미팅을 한 뒤 하루 만에 고민이 근본적으로 해결됐습니다.

(라이언의 자신감 회복에 대니가 상당히 공을 들였더군요. 유재석의 2020 MBC 연예대상 수상소감 관련 기사를 공유하기도 했다고 합니다. 그 수상소감의 일부를 아래에 공유합니다.)

저는 항상 어떤 프로그램을 할 때 '자신 있다', '해낼 수 있다' 이런 생각으로 프로그램을 해본 적은 한 번도 없는 거 같습니다.
그러나 늘상 제가 프로그램을 시작할 때 속으로 되뇌는 얘기가 있어요. '아.. 어떤 결과가 됐든 받아들이고 내가 그거에 대한 책임을 지겠다' 그런 생각으로 '놀면 뭐하니?'도 시작을 했고 이렇게 많은 시청자 여러분의 도움으로 이렇게 '놀면 뭐하니?'로 이런 큰 상을 받게 되었습니다.
-'2020 MBC 방송연예대상'에서 대상을 수상한 유재석이 남긴 소감 중

Q. 라이언은 어떻게 성장하고 싶나요? 더 잘하고 싶은 것, 혹은 나아지기 위해 노력하는 것이 있다면, 무엇인가요?

엔지니어 개인과 팀, 두 가지 관점에서 생각해봤어요. 우선, 엔지니어 관점에선 B2B SaaS 제품을 잘 만드는 개발자가 되고 싶습니다. 그래서 기회가 된다면 AWS Summit에서 '레몬베이스는 B2B SaaS를 이렇게 만들고 있다'고 자신감 있게 발표할 수 있는, 그런 사람으로 성장하고 싶어요.

또, 코드로 인프라 환경을 관리하는 일에도 앞장 서려고 합니다. 코드로 인프라를 관리하면, 자동화를 통해 테스트 환경과 프로덕션 환경을 동일하게 관리할 수 있고, 현재의 인프라 구조를 비교적 쉽게 파악할 수 있는 장점이 있죠. 다만 장애 복구 때문에 급해서 혹은 인프라를 관리하는 코드를 신뢰하지 못해서 코드를 수정하지 않고 인프라 환경을 직접 변경하면 코드와 인프라의 불일치가 발생할 수 있어요. 이런 우를 범하지 않도록 팀내 가이드나 문화도 잘 구축해 나가려고 해요.

팀의 관점에선, (레몬베이스에 아직 스쿼드는 없지만) 하나의 스쿼드나 팀을 이끌 수 있는 사람이 되고 싶습니다. 리더는 단순히 개발을 잘 한다고 될 수 있는 건 아니라고 생각해요. 또 강연을 듣거나 책을 읽는다고 해서 좋은 리더가 될 수 있는 것도 아니죠. 그래서 조금씩 스스로를 성장시켜서 리더의 역할을 맡을 수 있는 사람이 되었으면 좋겠습니다.

Q. 앞으로 엔지니어링 팀에 어떤 분이 동료로 함께 하길 기대하나요?

세 가지인데, 첫째, 어떤 영역이든 특정 하나의 영역에서라도 남을 가르칠 수 있거나 팀을 이끌 수 있는 사람이었으면 좋겠습니다. 둘째, 자신의 성장만을 위해서 일하는 게 아니라 회사의 성장도 균형 있게 생각할 수 있는 사람이었으면 하고요. 세번째로는 어떤 문제의 해결책에 대해서 다른 사람의 의견을 무조건 수긍하는 게 아니라, 자신만의 답을 내놓을 수 있는 사람이길 바랍니다.

Q. 라이언이 생각하는 건강한 성장은 무엇인가요? 지금 건강하게 성장하고 있나요?

방금 한 답변과 같은 맥락인데, 개인의 성장과 회사의 성장이 균형을 이루는 것이 '건강한 성장'이라고 생각합니다. 주변에 있는 동료와 회사 전체를 챙기면서 같이 성장할 수 있기 때문이죠. 개인적으로는 6개월 전의 나보다 지금의 내가 조금이라도 나은 부분이 있다면, 건강한 성장을 하고 있다고 볼 수 있지 않을까요? 6개월 전의 저는 자신감이 없는 사람이었지만 지금은 '뭐든 할 수 있다'는 마음을 가지고 있기 때문에 건강한 성장을 하고 있다고 스스로 평가합니다.

구체적인 상상의 힘을 믿습니다. 패티 맥코드 전 넷플릭스 최고인재책임자(CTO)는 그의 저서 <파워풀>에서 6개월 후의 회사 곳곳을 걸어 다니는 모습을 상상하라고 제안합니다. 그리고나서 말하죠. "당신이 지금 상상하는 변화가 일어나려면, 구성원들이 어떻게 해야 할까요? 당신이 알아야 할 것은 무엇일까요?" 스쿼드를 이끄는 리더로 성장한 라이언과 각자가 특정 분야에서 팀을 이끌 수 있는 역량을 갖춘 엔지니어링 팀을 함께 상상할 수 있는 기회를 주어 고맙습니다.

(끝)

레몬베이스에서 라이언과 함께 일하고 싶다면?

레몬베이스 팀을 소개합니다 를 살펴보시면 됩니다. 이 글과 관련하여 무엇이든 궁금한 점이 생기셨다면, start@lemonbase.com으로 편히 연락주세요!