Backend Software Engineer

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

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

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

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

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

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

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

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

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

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

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

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

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

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