「배포 빈도 5배 증가, 리드타임 1/6 단축」. 이 수치만 본다면 특별한 기술적 해결책을 도입했을 것이라 생각하기 쉽습니다. 하지만 Recustomer 주식회사가 이러한 개선을 이뤄낸 배경에는 툴이나 방법론의 쇄신만으로는 설명할 수 없는, 채용과 조직 문화에 대한 끈기 있는 투자가 있었습니다.
반품 및 교환 경험을 지원하는 SaaS를 운영하는 이 회사의 개발 조직은 프로덕트 팀 13명이라는 소수 정예 체제입니다. 2년 연속 'Findy Team+ Award'를 수상할 만큼 높은 생산성을 실현한 이들이 가장 먼저 착수한 것은 ‘인성을 최우선으로 하는 채용 방침’의 확립이었습니다. 기술력이나 실적보다 인성을 우선시한다. 언뜻 생산성 향상과 직결되지 않아 보이는 이 선택이 데모 주도 개발과 DevOps 문화의 정착, 그리고 비즈니스 부문을 포함한 전사적인 Claude Code 도입을 거쳐 결국 극적인 수치 개선으로 이어졌습니다.
본 기사에서는 CTO 마나베 씨와 EM·스크럼 마스터를 겸임하고 있는 사토 씨를 모시고, 채용 철학의 배경부터 구체적인 생산성 개선 시책, Findy Team+ 활용법까지 그 전체상을 들어보았습니다.
프로필
-
마나베 슈고 (眞鍋 秀悟) / CTO
교토대학교 이학부를 수석으로 합격하고 동 대학원을 거쳐 엔지니어의 길로 들어섰다. 신입으로 입사한 Fixstars에서 Executive Engineer로서 개발을 리드하며 상장을 경험했다. 이후 Mujin에서 아키텍트를 역임하고, Preferred Networks의 EM을 거쳐 Hacobu에서 CTO실 실장 및 연구개발부 부장을 지냈다. 2024년 5월 Recustomer CTO로 취임했다. ‘Startup CTO of the Year 2025’에서 오디언스 상을 수상했다.
-
사토 이츠키 (佐藤 樹) / 엔지니어링 매니저(EM) & 스크럼 마스터
고등전문학교에서 전기전자 공학을 전공하고 SIer에서 커리어를 시작했다. 2022년 Recustomer에 풀스택 엔지니어로 합격해 프런트엔드와 백엔드 개발을 담당했으며, 2024년 EM으로 취임했다. 신규 기능 개발 팀 매니징과 더불어 직접 코드를 작성하는 플레잉 매니저로 활동 중이다.
「인성」 채용이 만드는 「호응하는 조직」 —— AI 시대 강한 팀의 토대는 기술력보다 먼저 구축되었다
마나베: 엔지니어 조직의 채용 방침에서 ‘인성’을 중시하게 된 데에는 몇 가지 배경이 있지만, 웹 서비스 기업이라는 점이 큽니다. 프런트엔드, 백엔드, 인프라 등 모든 영역을 한 사람이 완벽히 파악하기란 매우 드뭅니다. CTO급이라 해도 모든 분야를 깊게 이해하기는 어려울 정도로 광범위하죠. 따라서 웹 개발에서는 ‘집단지성’을 통해 서로의 약점을 보완하며 제품을 만드는 것이 중요하며, 소통 없이는 업무가 원활히 진행될 수 없기에 인성이 핵심이 됩니다.
비즈니스 관점에서도 지식을 독점하는 것이 아니라, 그 지식을 전파하고 함께 추진하려는 멤버가 소중합니다. 특정 기술이 대단하다고 해서 그것을 당연하게 여기기보다, 가치 있는 것을 팀 내에 전파하려는 사람이 프로덕트를 진심으로 생각하는 엔지니어라고 믿습니다.
면접에서는 반드시 ‘팀 활동에서의 성공과 실패 경험’, 그리고 ‘상사나 동료의 객관적인 평가에 대한 본인의 생각’을 묻습니다. 긍정적인 이야기만 하는 분은 자기 객관화가 부족할 가능성이 큽니다. 저희는 기술 시험 대신 20분 정도 구술 면접을 진행하는데, 정답을 맞히는 것보다 모르는 것을 솔직하게 인정하는 태도를 중요하게 봅니다. 아는 척하는 멤버가 팀에 들어오면 조직 내에서 실패를 공유할 수 없게 되기 때문입니다.
같은 컬처가 스며들었음을 증명한 ‘어드벤트 캘린더’
마나베: 누군가 한 명 시작하면 모두가 자발적으로 따라오는 문화가 정말 놀랍습니다. 예를 들어, 8명이 24개의 글을 써야 하는 어드벤트 캘린더를 진행할 때, 저는 CTO로서 무리니 하지 말라고 만류했었습니다. 하지만 멤버들은 해냈고, 심지어 기술 블로그 트렌드에 오르는 양질의 콘텐츠들을 쏟아냈죠.
1on1에서도 “누구와 사이가 안 좋다” 같은 비본질적인 고민은 나오지 않습니다. 대신 “이렇게 개선하고 싶은데 어떻게 하면 좋을까”라는 생산적인 대화가 오갑니다. 온보딩 과정에서도 ‘팀 단위의 움직임’을 강조합니다. 실패를 인정하고 그 경험을 통해 팀 전체의 스킬을 업데이트하는 메커니즘이 자연스럽게 작동하고 있습니다.
패기만으로는 부족했다 —— 추진력 있는 배에 ‘항해사’가 필요했던 이유
마나베: 제가 합류하기 전에는 열정 넘치는 멤버들은 많았지만, 수개월 단위로 봤을 때 비즈니스적 진척은 더뎠습니다. 엔진은 강력한데 항해사가 없는 격이었죠. 패기는 넘치지만 비즈니스 방향성이 어긋나 결과적으로 비즈니스 가치가 낮은 상태였습니다.
저는 효율적으로 비즈니스 가치를 높이기 위해 무엇이 필요한지 강화하는 데 집중했습니다. “우리는 이번 달에 무엇을 위해 움직이는가”, “이 시책이 비즈니스적으로 어떤 가치를 창출하는가”라는 질문을 던지며, 엔지니어가 단순히 코드를 짜는 사람이 아니라 비즈니스를 움직이는 주인공이라는 인식을 심어주었습니다.
배포 빈도 5배·리드타임 1/6을 실현한 「그만둔 것」과 「바꾼 것」 —— 완벽주의를 버리고 데모 주도×DevOps×AI 활용으로
실제 작동하는 것을 보여주는 게 최우선──데모 주도 개발 도입
사토: 데모 주도 개발(Demo-Driven Development)은 실패를 겪으며 나온 시책입니다. 원래 저희는 완벽주의 성향이 강해서, 전부 다 만들고 나서야 비로소 배포하고 처음으로 사람들에게 보여주곤 했습니다. 그 결과, 결과물을 직접 봤을 때 "생각했던 것과 조금 다르다"는 피드백이 나오면서 재작업이 발생하거나, 같은 팀인데도 다른 멤버가 무엇을 하고 있는지 알 수 없는 불건전한 상태가 지속되었습니다.
현재는 '1주 1스프린트'라는 상당히 빠른 사이클로 개발을 돌리고 있으며, 스프린트 마지막에는 스프린트 리뷰의 일환으로 데모 시연회를 열고 있습니다. 우선 실제로 작동하는 모습을 보여주는 것을 최우선으로 삼고, 그 위에 태스크의 우선순위를 정합니다. "아직 완성되지는 않았지만 이런 느낌으로 작동합니다"라고 사전에 공유한 뒤, 실제로 구동되는 모습을 보여주는 방식으로 운영하고 있습니다.
도입 초기에는 거부감이나 과제도 있어서 "일주일 만에 보여줄 수 있는 결과물이 없다"는 목소리도 있었습니다. 하지만 "PR(Pull Request) 기준으로 보여줘도 괜찮다"고 하니, 생각보다 공유가 활발하게 올라오더라고요. "보여줄 게 없다"고 했던 건 반드시 완성품을 보여줘야 한다는 고정관념에서 비롯된 것이라 생각합니다.
돌이켜보면 말로만 애자일(Agile)을 외쳤지 실제로는 워터폴(Waterfall)에 가까운 개발을 하고 있었다는 사실을 깨달았고, 작게 시작해서 계속해서 시도해 나가는 이상적인 문화에 가까워질 수 있었습니다.
이러한 노력을 통해 엔지니어가 개발을 하는 의의나 배경을 더 깊이 이해하게 되었습니다. 단순히 지시받은 일을 어떻게든 완수하겠다는 생각에서 벗어나, "왜 이 일을 해야 하는가", "고객은 왜 이 기능을 요구하는가"와 같은 본질적인 부분에 눈을 돌리기 시작한 것입니다. 사내 하청처럼 수동적으로 움직이는 게 아니라, 함께 가치를 만들어가는 일원이라는 인식을 가질 수 있게 되었다고 느낍니다.
사토: 반대로 그만둔 일 중에서 가장 효과가 컸던 것은 프로덕트 오너(PO)가 모든 배포에 책임을 지던 운영 방식입니다. DevOps 문화를 도입하여 개발뿐만 아니라 유지보수와 운영까지 엔지니어가 일관되게 책임을 지는 형태로 바꿨습니다.
이를 통해 엔지니어가 개발, 검증, 릴리스, 유지보수·운영까지 자율적으로 완결 지을 수 있게 되었고, 꼭 필요할 때만 PO의 도움을 받음으로써 배포 빈도를 획기적으로 개선하는 데 큰 기여를 했다고 생각합니다.
전원이 동일한 에코시스템에 탑승하다──Claude Code 전사 확산
사토: AI 활용은 회사 차원에서 적극 권장하고 있으며, 현재 모든 멤버가 Claude Code를 사용해 개발하고 있습니다. 메인 스프린트 태스크뿐만 아니라, 각자가 느끼는 기술 부채를 해결하는 작업도 동시에 진행하고 있어 팀 내 침투율이 매우 높습니다. 최근에는 PR(Pull Request) 수도 약 5배 정도 증가했습니다.
마나베: 타사 CTO분들과 이야기를 나누다 보면 "AI를 활용하지 못하는 멤버를 어떻게 해야 할까"라는 고민을 자주 듣게 되는데, 저희는 그런 걱정이 전혀 없습니다. 기본적으로 팀 단위로 움직이기 때문에 누군가 소외되는 상황이 발생하지 않기 때문입니다. 한 사람이 좋은 메커니즘을 만들면 모두가 자연스럽게 따라 하기 때문에 개인 간의 격차가 생기지 않습니다.
페어 프로그래밍(Pair Programming)까지는 아니더라도 "지금 이런 식으로 개발하고 있어"라는 '대화'가 일상적으로 오가며 지식 공유(Knowledge Sharing)가 매우 활발하게 이루어집니다. 비즈니스 가치에 집중하면서도, 보이지 않는 곳에서 해야 할 일들을 확실히 끝내고 있는 상태가 유지되고 있습니다.
비즈니스(Biz) 조직에서도 Claude Code를 활용하기 시작했다는 점도 주목할 만한 특징입니다. 개발팀에서 Claude Code의 사전 설정을 모두 준비해 둔 덕분에, 비즈니스 직군 멤버들도 자연스럽게 사용할 수 있게 되었습니다. 비즈니스 부서에서도 소스 코드를 전부 열람할 수 있도록 하고 AI가 이를 학습하게 하니, 기술적인 질문에도 AI가 답변을 척척 해내어 엔지니어에게 들어오는 문의가 눈에 띄게 줄었습니다.
예를 들어 데이터 분석의 경우, 기존에는 비즈니스 부서에서 엔지니어에게 매번 요청해야 했던 일들을 이제는 AI에게 질문하면 SQL이 자동으로 생성되고 HTML로 시각화되는 단계까지 전 과정이 자동화되었습니다. 이러한 프로세스를 사내에 표준화해 두었기 때문에, 엔지니어들 사이에서도 '비즈니스 팀에게 따라잡힐 수도 있겠다'는 좋은 의미에서의 긴장감이 조성되고 있습니다.
수치 목표에만 매몰되었던 실패──「경향을 파악하는 지표」라는 관점으로
사토: 개선 활동을 추진하는 과정에서 시행착오도 있었습니다. 바로 구체적인 '수치 목표'를 설정했던 일입니다. 수치 목표를 세우니 어떻게든 그 숫자만 달성하려는 방향으로 생각이 쏠리면서, 본질에서 벗어난 행동들이 나타나기 시작했습니다. 숫자는 어디까지나 조직의 현재 상태와 경향을 가시화하는 도구일 뿐, 숫자를 채웠다고 해서 고객에게 새로운 가치를 제공하고 있는가는 별개의 문제입니다. 그래서 과감히 목표 설정을 폐지했습니다.
또 다른 실패는 AI를 활용해 과거의 기술 부채를 해결하는 PR을 대량으로 생성하는 시책을 밀어붙였을 때였습니다. 결과적으로 한 번의 배포(Deploy) 안에 너무 많은 내용이 뒤섞이면서 테스트가 부실해지고, 정작 중요한 검증이 방대한 양에 묻혀버리는 문제가 발생했습니다.
AI 덕분에 PR을 만드는 것은 한결 수월해졌지만, 이를 안전하게 최종 배포 단계까지 도달시키는 '책임 의식'에 대해서는 팀 전체가 다시 한번 머리를 맞대고 방향성을 일치시킬 필요가 있었습니다.
Findy Team+ 활용법──수치를 「관리」에서 「개선의 즐거움」과 「칭찬」으로 바꾸는 운영술
사토: Findy Team+를 도입하고 가장 좋았던 점은 그동안 수치화하기 어려웠던 엔지니어의 활동(Activity)이 시각화되면서, 우리 팀의 현재 상황과 정량적인 경향을 명확히 파악할 수 있게 된 것입니다.
특히 특정 멤버에게 리뷰가 쏠리면서 리뷰 및 개발 부하가 가중되고 있던 상황이 화면에 그대로 드러난 점이 유효했습니다. "특정 인원에게 부담이 치우쳐 있다"는 느낌은 팀 내부적으로도 어렴풋이 인지하고 있었지만, UI를 통해 시각적으로 확인하니 "이건 확실히 문제"라는 공통된 인식을 팀 전체가 가질 수 있었습니다. 덕분에 이를 어떻게 개선할지에 대한 구체적인 논의로 발전할 수 있었고, 결과적으로 팀 체제와 PR(Pull Request) 리뷰어 지정 방식을 재검토하여 전반적인 개발 생산성을 높이는 계기가 되었습니다.
AI 활용도를 라벨로 자동 측정하다
사토: AI 활용도를 시각화하기 위해, Claude Code로 PR을 생성하는 명령어 안에 자동으로 라벨을 부여하는 메커니즘을 심어두었습니다. 나중에 수동으로 라벨을 붙이려고 하면 누락이 발생하기 쉬우므로, 자동화를 통해 확실하게 측정할 수 있도록 했습니다.
가시화를 통해 예상치 못했던 수확은 AI 활용이 리드타임과 사이클타임에 긍정적인 영향을 미쳤다는 점입니다. 반면, AI 활용이 아웃풋(Output)이나 아웃컴(Outcome)에 폭발적인 영향을 주는 것에 그치지 않고, 오히려 '새로운 병목 구간'을 찾아내는 계기가 되기도 했습니다. PR은 늘어났지만 인간이 감당해야 할 리뷰 부하가 전체적으로 증가한 점, 배포 대상 커밋 수가 많아지면서 검증 시간이 늘어난 점 등입니다. 이러한 새로운 과제를 발견하게 된 것은 뜻밖의 소득이었습니다.
사토: Findy Team+의 데이터는 주 1회 진행하는 회고(Retrospective) 세션에서 전원이 함께 확인하고 있습니다. 엔ジニア들이 막연하게 느끼던 정성적인 답답함이 수치로 가시화되면서 명확하게 증명되는 측면이 있기 때문입니다.
예를 들어, AI 활용으로 인해 PR 수는 늘어나는 반면 변경된 코드 라인 수도 함께 증가했던 적이 있습니다. "PR을 작게 나누자", "리뷰어를 배려하는 PR을 만들자"고 다짐했었지만, 어느샌가 그러한 문화가 느슨해졌다는 사실이 수치로 드러난 것입니다. 멤버들 사이에서 "나도 그렇게 느끼고 있었다"는 공감대가 형성되면서 자연스럽게 개선을 위한 논의가 시작되었습니다.
마나베: 저희는 도전을 장려하고, 성과를 낸 직원이 있다면 모두의 앞에서 칭찬하는 문화를 의식적으로 실천하고 있습니다. 서로 협력하여 일하는 문화가 더욱 공고해진 상태에서 이것이 '스코어'라는 형태로 표현되니, 멤버들도 "나도 저런 행동을 본받아 노력해야겠다"라며 자연스럽게 긍정적인 행동을 모방하게 되었고, 이는 결국 집단 전체의 성과로 이어지고 있습니다.
사토: 실제로 수치가 좋지 않은 멤버에게 숫자를 들이밀며 압박하는 커뮤니케이션은 하지 않습니다. PR 실적이 저조하다면 먼저 그 배경이나 원인을 묻고 경청합니다. 무리하게 아웃풋을 올리라고 다그치기보다는, AI 활용 방식을 함께 점검하거나 태스크 정리를 도와주는 등 그 사람의 상황에 공감하며 함께 고민합니다.
앞서 수치 목표를 없앴다고 말씀드린 배경과 마찬가지로, 숫자는 어디까지나 상호 이해를 돕기 위한 '공통 언어'일 뿐 누군가를 질책하기 위한 도구가 아닙니다. 코드 리뷰를 예로 들면, 그저 가장 빠른 속도로 머지(Merge)만 하는 사람은 단지 'Approve 승인 능력이 높은 사람'일 뿐입니다. 단순히 Approve만 누르는 역할이라면 인간보다 AI가 더 잘합니다. 앞으로 어떤 코드를 지향할 것인지, 어떤 팀을 만들어갈 것인지와 같은 '문화에 대한 이야기'가 훨씬 중요하다고 멤버들에게 강력하게 전달하고 있습니다.
2년 연속 수상의 결정적 요인은 시책이 아닌 '문화'였다
사토: Findy Team+ Award를 2년 연속 수상할 수 있었던 것은 어떤 특정한 시책 덕분이라기보다, '문화'의 힘이 가장 컸다고 생각합니다.
일주일에 한 번 배포하기도 급급했던 상태에서 지금의 단계까지 올 수 있었던 것은 일상적인 대화와 행동, 그리고 코드 한 줄을 작성하는 과정에 이르기까지 아주 작은 것들이 정성스럽게 쌓인 결과입니다. "Recustomer로서 어떤 조직을 지향하는가"에 대한 방향성이 팀 내부적으로 정확히 일치했기에, 높은 생산성을 담보하는 문화가 자리 잡을 수 있었습니다.
대외적으로 성과를 인정받으면서 조직 구성원들의 자신감도 한층 높아졌습니다. "우리의 방향이 틀리지 않았다"는 확신은, 다음 단계의 대외 발신이나 지속적인 개선을 이끌어내는 강력한 동기부여가 되고 있습니다.
「강한 엔지니어」의 정의가 변한 시대에──Recustomer에서 일한다는 것
마나베: 예전에는 '강한 엔지니어 = 대단한 코드를 쓸 줄 아는 사람'이었다고 생각하지만, 이제는 패러다임이 변하고 있음을 체감합니다. 불확실한 상황 속에서도 본질적인 과제를 꿰뚫어 보고, 주변을 동참시키며 지속적으로 가치를 만들어낼 수 있는 사람. 독단적으로 행동하지 않고 모두와 협력하여 개발할 수 있는 사람. 그리고 다양한 영역에 대한 도전 의지가 높은 사람이 앞으로의 시대를 이끌어갈 강한 엔지니어라고 생각합니다.
AI를 활용한 개발이나 가치 창출에 관심이 있는 엔지니어에게 Recustomer는 매우 도전하기 좋은 환경입니다. 비즈니스 팀 역시 Claude Code를 다루며 업무를 자동화하는 회사이기 때문에 서로 노하우를 가르쳐줄 수 있습니다. 엔지니어의 활동이 비즈니스 팀 전체에 변화를 이끌어내는 동력으로 이어지는 조직이기도 합니다.
저희는 Claude Code Max 20x 플랜을 누구나 사용할 수 있으며, 업무 효율을 높이기 위한 키 바인딩(Key Bindings)이나 단축키에 대한 대화가 일상적으로 오갈 정도로 전반적인 작업 효율의 평균치가 높습니다. 엔지니어 간의 소통이 매우 활발하고, 기술 콘퍼런스 발표나 대외 발신도 당연하게 여기는 분위기입니다. 덕분에 새로 합류하는 멤버들도 자연스럽게 이러한 조직 문화에 스며들 수 있는 최적의 환경이 조성되어 있다고 자부합니다.