Backend Software Engineer

레몬베이스 Engineering Team이 하는 일을 좀 더 널리 알리기 위해 진행한 인터뷰입니다. 김안나(Head of People Science)가 묻고, 김현철(CTO)이 답변했습니다. - CTO는 무슨 일을 하고, 어떤 고민이 있는지 - 건강한 문화를 지키기 위해 노력하는 엔지니어링 팀은 어떻게 일하는지 - 레몬베이스 엔지니어링 팀의 Bases of Conduct는 무엇인지 궁금하시다면 가볍게 읽어보세요.

엔지니어로서 일한 제 모든 경험을 토대로, 지금은 레몬베이스에서 회사와 구성원들의 문제 해결에 도움을 주는 서비스를 만들고 있고요. 고객이 겪고 있는 문제를 가장 잘 해결할 수 있는 제품, 나아가 최고의 고객 경험을 줄 수 있는 제품을 만들기 위해 팀 내 다른 엔지니어 분들과 함께 노력하고 있습니다.

최근 몇 주 동안은 레몬베이스 제품을 유료화하기 위한 개발 작업에 시간을 가장 많이 썼고요. 상반기 런칭을 준비 중인 목표 관리 제품의 기반 기술을 검토하고, 제품의 기준을 세팅하기 위한 고민도 하고 있습니다.

저희 엔지니어링 팀은 어떤 문제를 해결하기 위해 사용하는 기술적인 환경이나 개발 방법에 열려있는 편인데요. 제품 관련 해결해야하는 문제가 있을 때, 그 문제를 해결하는 엔지니어들이 스스로 모든 것들을 주도적으로 판단하고 결정할 수 있으려면 팀의 리더로서 제가 기술 혹은 제품의 기준을 정하는 일에 시간을 많이 써야 한다고 생각합니다 아직까지는 제가 엔지니어링 실무를 담당하고 있는 일들도 많아서 여력이 부족할 때도 있지만, 가능한 깊이 고민해서 좀 더 나은 기준을 팀이 세팅하는데 도움이 되는 것이 제 역할인거죠.

리디북스 때부터 지금까지 꽤 긴 시간 동안 엔지니어링 팀을 이끌었지만, 부족함이 많은 리더라고 생각하고요. 다만 더 좋은 팀을 만들기 위한 고민은 멈춘 적이 없었습니다. 레몬베이스라는 제품을 만드는 것은 어찌보면 그 기나긴 여정의 연장선이기도 합니다. 저희 팀에서 일하는 엔지니어 분들이 더 몰입하고, 더 성장하며, 개발의 과정과 결과에서 오는 즐거움을 느낄 수 있도록 만드는 것이 저의 역할이라고 생각하고 열심히 하고 있습니다. (웃음)

더불어 Data Visualization 과 관련한 일들은 전사적으로 중요한 주제라, 틈틈이 챙기고 있습니다. 레몬베이스는 현재 4개의 가치를 기반으로 일하는 방식을 만들어가고 있는데요. 그중 하나인 'Win by Data'라는 가치를 크루 모두가 실제 행동으로 옮기기 쉽도록 좀 더 다양한 데이터들을 쉽게 추출하고, 시각화하여 크루들에게 공유할 수 있는 시스템을 Retool과 Redash라는 도구를 활용하여 만들고 있습니다.

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

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

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

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

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

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

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

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

레몬베이스 Engineering Team이 일하는 방식을 좀 더 널리 알리기 위해 진행한 인터뷰입니다. 추가영(Content Manager)이 묻고, 이진만(Software Engineer)이 답변했습니다. - 도전적인 업무를 선뜻 맡을 수 있는 심리적 안전감은 어디서 오는지 - 문제의 핵심을 파악하는 커뮤니케이션 능력을 키우기 위해선 어떤 노력이 필요한지 - 자신뿐 아니라 팀 전체의 '건강한 성장'을 위해 노력하는 엔지니어는 어떻게 일하는지 궁금하시다면 가볍게 읽어보세요.

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

레몬베이스의 리뷰 제품을 집중적으로 만드는 스쿼드에 소속돼 있는 엔지니어, 이진만입니다. 레몬베이스에선 제이미(Jamie)라고 부릅니다. '리뷰 스쿼드'는 레몬베이스의 리뷰 제품을 '어떻게 하면 고객들이 더 잘 쓸 수 있을지, 더 많은 고객들이 제품에 만족할 수 있을지'를 고민하면서 짧은 주기로 제품을 개선해나가고, 이 과정을 통해 학습하는 사이클을 빠르게 반복(iteration)하는 목적 조직입니다.

20171029_154826.jpg

지난 6월 목표 제품 출시와 함께 유료화 후 스쿼드가 구성되면서 팀을 새롭게 빌딩(구축)하는 과도기를 지나고 있습니다. 그래서 엔지니어지만 구성원의 심리적 안전감을 높이기 위한 활동을 기획하고, 회고를 진행하는 등의 일에 시간을 많이 썼네요. 내부적으로 팀 빌딩을 하는 동안에도 고객들은 제품을 이용하고 있기 때문에 고객들의 요청에 대응하거나 기능을 개선하는 일도 병행하고 있고요.

spotify.jpg

또, 스쿼드가 아닌 프론트엔드/벡엔드 챕터(기능 조직)에서도 '더 빨리 달리기 위해선 무엇을 해야 할지'를 고민하고 있어요. 예를 들어, 다중 테스트 환경을 구축하거나 보다 나은 인프라 모니터링 환경을 만들기 위한 방안 등을 논의합니다. 통상적으로는 새로운 기능을 개발하거나 고객의 불편사항에 대한 대응 등 '고객의 문제를 해결하기 위한 개발 업무'에 일주일 중 60% 정도의 시간을, 기획/플래닝을 포함한 설계에 30%, 엔지니어링 팀이나 리뷰 스쿼드가 아닌, 다른 팀에서 하고 있는 업무를 파악해 각각의 영역에서 축적된 지식을 소화하는 등 레몬베이스가 하나의 팀으로 유지되기 위해 필요한 활동에 10% 정도의 시간을 씁니다.

다른 팀에서 하는 업무에 관심을 갖는 데는 개인적인 호기심도 작용합니다. 모든 업무에 똑같은 관심을 기울일 수는 없고, HR 분야의 지식(domain knowledge), Customer Success, 데이터, 콘텐츠 등과 관련된 업무 내용을 좀 더 관심 있게 지켜보고 있어요. 그리고 업무의 과정이나 결과에서 제가 느낀 점이나 의견을 내면 업무 자체에 도움을 줄 수도 있지 않을까 기대하는 것도 있고요. 퇴근길에 30분 혹은 휴식을 취할 때 슬랙에서 읽지 않은 메시지를 보면서 다른 팀의 업무 진행 상황을 파악하는 등 루틴을 만들어가고 있어요.

두 가지는 꼭 강조하고 싶네요. 첫 번째는 오류가 발생하거나 장애가 났을 때 원인 제공자가 누구인지(who)를 찾기보다 문제 해결을 위해 무엇(what)을 해야 할지에 집중하는 것이 팀의 문화로 자리잡혀 있습니다. 누구든 문제 상황을 겪을 수 있다고 생각하고, 다 같이 자기 일인 마냥 도와주기 때문에 심리적으로 안정되고, 문제가 생기면 도움을 받을 수 있다는 믿음이 깔려있기 때문에 엔지니어로서 도전적인 업무를 맡는 데도 주저함이 없는 것 같아요. 두 번째는 이런 문화를 바탕으로 꼭 오류에 대응하는 상황이 아니라, 어떤 일을 할 때 의견과 조언, 도움이 필요할 때면 언제든지 요청할 수 있고 또 요청을 받으면 도움을 주려고 하는 문화가 형성되어 있다는 점도 알리고 싶습니다. 한마디로, 문제를 같이 풀어나가는 문화라고 할 수 있겠네요.

Q. '문제를 같이 풀어나가는 문화'를 바탕으로 제이미가 맡았던 혹은 앞으로 기꺼이 맡고 싶은 '도전적인 업무'엔 어떤 것이 있나요?