생성형 AI를 팀의 전력으로 만드는 「skills·rules」 설계. Sansan Contract One이 도전하는 LLM 활용 표준화와 자동화의 최전선

“개발이 병목이다.”——이렇게 느끼는 엔지니어 조직은 적지 않다.

하지만 Sansan 주식회사의 Contract One Engineering Unit은 이제 정반대의 고민을 안고 있다. 한때 백로그에 수두룩하게 쌓여 있던 태스크는 거의 소진되었고, 팀은 “이제 다음에 할 일을 찾아야 하는 것 아니냐”라는 질문을 받는 단계에 도달했다.

도대체 무엇이 달라졌을까.

속도를 조직의 최우선 가치로 두고, 1인 1에픽 체제를 도입했으며, 생성형 AI를 적극적으로 활용하고, Findy Team+를 통해 메트릭을 정량적으로 관리했다. 여러 시도를 다각도로 결합한 결과, 릴리스 노트 건수는 14배나 늘어났다. 하지만 오시마 다케노리 부장과 다카하시 나오야 테크 리드가 바라보는 곳은 그 다음 단계다. 생성형 AI 시대에 엔지니어 조직은 어디를 향해 가야 할까. Contract One의 도전은 그 질문에 대한 하나의 답을 보여준다.

“멈추지 않는” 조직을 만든다——속도에 대한 신념은 어디에서 시작됐는가

—— 먼저 Contract One이라는 프로덕트에 대해 소개해 주세요.

오시마(大島): Contract One은 계약서를 데이터베이스로 구축해 활용할 수 있게 돕는 제품입니다. 기업이 체결하는 계약서에는 만기, 금액, 조건 등 중요한 정보가 대량으로 들어있지만, 정작 많은 기업에서 이를 충분히 활용하지 못하고 있습니다.

Contract One은 이 정보들을 정돈하고 구조화하여, 계약 데이터를 경영 판단과 업무 효율화에 바로 활용할 수 있게 해줍니다. Sansan이 명함 데이터를 출발점으로 비즈니스의 가능성을 넓혀온 것처럼, Contract One은 계약 데이터를 시작으로 기업의 새로운 가치를 창출하는 것을 목표로 하고 있습니다.

—— 두 분이 지금 이 업무에 임하게 된 계기가 무엇인지 말씀해 주세요.

오시마: 자율주행 개발에 참여하던 시절, 머신러닝으로 알고리즘을 고도화하는 것보다 결국 데이터의 품질이 결과를 좌우한다는 점을 깨달았습니다. 좋은 데이터가 있어야 좋은 기능도 나오는 법입니다. Contract One에서 계약서를 데이터베이스화해 활용한다는 미션은 저에게 하나의 흐름으로 자연스럽게 이어졌습니다.

다카하시(高橋): 인턴 시절에 “품질은 팀이 보완할 수 있다. 그보다 속도를 먼저 의식하라”라는 말을 들은 뒤 생각이 완전히 바뀌었습니다. 가치 전달이 늦어지면 아무리 품질이 뛰어나도 제품은 성장하지 못합니다. 그 사고방식은 지금도 제 일의 기준이 되고 있습니다.

—— Contract One Engineering Unit이라는 조직에서 가장 중요하게 생각하는 것은 무엇인가요?

오시마: 명문적으로 정해둔 것은 아니지만, 바로 ‘속도’입니다. 제품의 성장을 위해 개발이 멈춰서는 안 된다——이것이 팀원 모두가 공유하는 공통 인식입니다. 여기에 더해 단순히 요청을 받아 만드는 데 그치지 않고, 우리가 직접 문제를 정의하고 개발을 주도하는 ‘진정한 제품 개발 조직’을 만들어가고 싶습니다. 이 두 가지가 저희의 근본에 있습니다.

다카하시: 누군가 시키기 전에 “이 문제는 우리가 직접 찾아서 해결하자”라고 먼저 움직이는 문화가 자연스럽게 자리 잡혀 있습니다. 그것이 저희 팀의 가장 큰 강점이라고 생각합니다.

수치로 조직을 움직인다——릴리스 생산량 2배를 요구받은 조직이 선택한 해답은 무엇이었나

—— Contract One은 현재 어떤 단계에 있나요?

오시마: 2023년에 출시되어 PMF(제품-시장 적합성)를 달성한 지 이제 2년 남짓 된 젊은 제품입니다. 시장을 개척해 나가는 과정에서 조직 전체에 “릴리스 생산량을 2배로 늘려달라”는 요구가 있었습니다. 이를 실현하지 못하면 제품 자체가 성장할 수 없었기에 상당한 압박감이 있었습니다.

—— 당시 개발 현장은 실제로 어떤 상태였나요?

다카하시: 백로그는 계속 쌓이는데 이를 소화해내지 못하는 상황이 이어졌습니다. 한 팀이 하나의 프로젝트를 전담하는 구조였기 때문에, 어느 한곳에서 정체가 생기면 전체 흐름이 멈춰버렸습니다. “빨리 해야 한다”는 조바심은 큰데, 정작 어디서 왜 늦어지는지 수치로 확인이 되지 않는 점이 가장 답답했습니다.

오시마: 자체적으로 지표를 집계해보려 했으나 구체적인 수치를 얻기가 어려웠습니다. 릴리스 노트 건수가 늘어나고 있다는 건 감지할 수 있었지만, 정확히 어떤 시도가 어느 정도의 효과를 내고 있는지는 보이지 않았습니다. 결국 감으로 판단할 수밖에 없다 보니 의사결정에 확신을 갖기 힘들었습니다.

—— 그래서 Findy Team+를 도입하게 된 것이군요. 결정적인 이유는 무엇이었나요?

오시마: 솔직히 말해 의사결정을 객관적인 수치에 기반해 내리고 싶었습니다. 자체적으로는 파악하기 힘들었던 세부 메트릭을 확보할 수 있는 데다, 즉시 도입해 사용할 수 있다는 점만으로도 도입 이유는 충분했습니다. 개발 리소스를 지표 시스템 정비에 빼앗기지 않아도 된다는 점 역시 속도를 중시하는 저희 조직에 큰 이점이었습니다.

다카하시: 저는 리뷰 리드 타임을 지속적으로 추적하고 싶었으나, 자체 개발로는 한계가 있었습니다. Findy Team+를 도입하니 PR 리뷰의 흐름을 세밀하게 들여다볼 수 있게 되었습니다. 어디에서 작업이 지연되고 있고, 누구나 어느 단계가 병목이 되는지 명확히 짚어낼 수 있게 된 점은 기대 이상의 성과였습니다.

—— 도입 후 조직에 가장 큰 변화를 가져온 것은 무엇이었나요?

다카하시: “전원이 동일한 지표를 바라보게 되었다”는 경험이 생긴 점입니다. 이전에는 설계 문서 리뷰가 특정 인원 단계에서 멈춰 있어도 이를 문제로 인식하기가 어려웠습니다. 하지만 Findy Team+를 통해 시각화되면서 병목 지점이 한눈에 드러났습니다. “지금 이 부분에서 정체가 발생하고 있다”고 데이터로 제시할 수 있게 되면서 의사결정 속도가 획기적으로 빨라졌습니다.

—— Findy Team+의 커스터마이징 기능도 높이 평가하고 있다고 들었습니다.

다카하시: 팀 모니터링 설정 기능을 보고 솔직히 감탄했습니다. 저희 팀은 인턴과 정규직이 함께 섞여 있다 보니 각각의 지표를 구분해서 추적해야 할 때가 있습니다. Findy Team+에서는 이런 단위까지 모니터링을 유연하게 설정할 수 있어 목적에 맞게 세밀하게 활용할 수 있습니다. 예전에 이를 직접 구축해 보려 했던 경험이 있어 이 작업이 얼마나 난이도 높은지 잘 알고 있습니다. 그렇다 보니 이 커스터마이징 기능이 더욱 유용하게 느껴집니다.

오시마: 자체적으로 구축하려 하면 아무래도 개발 시간이 오래 걸리고, 그 자체로 또 다른 병목이 되어버립니다. Findy Team+는 즉시 도입해 사용할 수 있으면서도 상세 설정까지 가능합니다. 개발 리소스를 지표 구축에 쓰지 않고 제품 개발 자체에 집중할 수 있다는 것은 조직 차원에서도 매우 큰 장점입니다.

—— 꾸준한 개선을 이어온 결과는 어떻게 달라졌나요?

다카하시: 사실 과정 자체는 매우 꾸준하고 직관적인 개선의 반복이었습니다. 매주 리뷰 리드 타임을 점검하며 지연되는 부분을 하나씩 해결해 나간 것이 전부입니다. 하지만 그 결과 쌓여 있던 백로그 태스크를 거의 다 소화해 내는 수준에 이르렀습니다. 지금은 “이제 다음에 할 일을 찾아야 하는 것 아니냐”라는 이야기가 나올 정도의 단계가 되었습니다.

오시마: 릴리스 노트 건수는 무려 14배나 증가했습니다. 예전에는 개발 부문이 병목이었지만, 지금은 단순히 수치 이상으로 실질적인 임팩트가 나타나고 있음을 체감합니다. 다만 이것이 끝이 아니라, 오히려 이제부터가 진짜 시작이라고 생각합니다.

생성형 AI×자동화——‘완전 자동화’를 내다본 skills·rules 설계의 최전선

—— 생성형 AI 활용은 어떻게 시작됐나요.

다카하시: 처음에는 ‘LLM week’라는 기획을 진행했습니다. 일정 기간 동안 팀원 전체가 LLM 활용법을 다각도로 시도해보고 트래킹하는 방식이었습니다. 하지만 솔직히 초기에는 잘 활용하지 못했습니다. “편리하긴 한데 실제 업무 어디에 적용해야 할지 모르겠다”는 상태가 이어졌고, 개인별 활용 수준의 격차도 컸습니다.

오시마: 모든 작업을 AI에 무작정 맡기려는 분위기가 형성되면서 오히려 결과물의 품질이 떨어지는 부작용도 있었습니다. ‘AI를 사용하는 것’ 자체가 목적이 되어버린 셈이죠. 그래서 진행을 잠시 멈추고 “우리가 왜 AI를 사용하는가”에 대해 목적을 다시 정립했습니다. 그 과정에서 정의하게 된 것이 바로 skills와 rules 개념입니다.

—— skills·rules란 구체적으로 어떤 것인가요.

다카하시: rules는 AI와 맺는 ‘규칙’입니다. 코드 스타일이나 설계 방침 등 팀 차원에서 반드시 준수해야 할 기준을 정의합니다. skills는 ‘PR 리뷰 요청문 작성’, ‘테스트 코드 생성’처럼 반복되는 작업들을 AI에게 위임하기 위한 템플릿 역할을 합니다. 이 두 가지를 체계화하면 개인별 활용 격차를 줄이고 팀 전체의 구현 역량을 평준화하여 끌어올릴 수 있습니다.

—— skills·rules 정비를 시작하게 된 계기는 무엇이었나요.

다카하시: AI를 각자 방식대로 자율적으로 사용하다 보니 결과물의 품질이 들쑥날쑥해졌습니다. “특정 팀원의 코드는 AI가 작성한 티가 난다”, “리뷰 공수가 오히려 늘었다”는 지적도 나오기 시작했습니다. 팀 차원의 구현 품질을 유지하면서 개발 속도를 올리려면, AI 활용 방식 자체를 표준화해야 한다는 점을 깨달았습니다.

오시마: 그러면서 떠오른 과제가 “표준화가 제대로 이루어지고 있는지 어떻게 검증할 것인가”였습니다. skills나 rules를 정비하더라도, 이것이 실제 개발 속도나 품질 향상으로 이어지고 있는지가 데이터로 확인되지 않았습니다. 단지 감각적으로 “좋아진 것 같다”는 수준으로는 조직 차원의 의사결정을 내릴 수 없기 때문입니다.

—— 그래서 다시 Findy Team+가 필요해지는군요.

다카하시: skills와 rules를 정비한 후 실제로 리뷰 리드 타임이 단축되었는지, 배포 주기가 빨라졌는지를 Findy Team+를 통해 직관적으로 확인할 수 있게 되었습니다. AI 활용이 실제 생산성 향상으로 이어지는지를 정량적으로 검증할 수 있게 된 점이 매우 컸습니다. 시책의 효과가 데이터로 보이지 않으면 다음에 무엇을 개선해야 할지 방향을 잡을 수 없습니다.

오시마: AI로 생산성을 극대화하려는 조직일수록 객관적인 메트릭이 필수적이라고 봅니다. AI 도입의 실제 효과는 눈으로 쉽게 확인하기 어렵습니다. 단순히 “속도가 빨라진 느낌이다” 정도로는 조직을 움직일 수 없습니다. Findy Team+가 있기에 AI 활용에 대한 투자가 올바른 방향으로 실행되고 있는지 명확히 판단할 수 있게 되었습니다.

다카하시: 수치로 현황을 정확히 파악하고, AI를 활용해 개선을 실행합니다. 이 두 가지가 긴밀하게 맞물려야 비로소 지속 가능한 속도 향상이 가능해집니다. 어느 한쪽만으로는 한계가 있기에 이 두 축의 결합이 매우 중요한 의미를 갖습니다.

—— skills·rules 정비는 지금도 계속되고 있나요.

다카하시: 그렇습니다. 끊임없이 업데이트하고 있습니다. 한 번 구축해 두고 방치하는 것이 아니라, 제품이 진화함에 따라 계속 수정해 나가야 합니다. 지침이 오래되면 오히려 생산성에 방해가 되기도 합니다. Findy Team+ 지표를 모니터링하다가 “이 부분의 속도가 떨어지고 있다”는 점이 발견되면, 그에 맞춰 관련 skills나 rules를 즉시 재검토합니다. 이 선순환 사이클을 지속적으로 돌리는 것이 현재 테크 리드로서 제 가장 핵심적인 역할입니다.

—— 그 연장선상에 ‘완전 자동화’가 있는 것이군요.

오시마: 목표하는 수준에 도달하려면 결국 사람의 손이 들어가는 공정을 자동화해 나갈 수밖에 없습니다. 엔지니어가 본질적인 의사결정과 판단에만 전념할 수 있도록 오퍼레이션 전체를 E2E로 자동화하는 구조를 설계하고 있습니다.

다카하시: 완전 자동화라고 하면 다소 거창하게 들릴 수 있지만, 핵심은 “사람의 주관적 판단이 꼭 필요한 구간을 제외한 나머지 공정을 자동으로 흐르게 만드는 것”입니다. AI와 자동화로 불필요한 공정을 줄이고, Findy Team+로 그 효과를 검증합니다. 이 사이클이 계속 작동하는 한 개발 속도는 지속적으로 상승할 것입니다.

다음 프런티어는 ‘과제 발견’——엔지니어가 영업 전략을 움직이는 날

—— 개발 병목이 해소된 이후에는 무엇이 보이기 시작했나요.

오시마: 다음 단계로 추진하고자 하는 것은 문제 정의 및 ‘과제 발굴’ 영역까지 개발 부문의 역할을 확장하는 것입니다. 백로그가 거의 소진되면서 비로소 이러한 고차원적 고민을 할 수 있는 여력이 생겼습니다. 이는 결승점이 아니라 새로운 출발선입니다.

다카하시: 지난 연휴 기간에 제품 개발 관련 서적들을 다시 읽었는데, 과거와는 내용을 받아들이는 깊이가 완전히 달랐습니다. 예전에는 개발 정체를 해결하는 데 급급해 그 부분에만 매몰되어 있었습니다. 하지만 이제는 그 다음 차원의 이야기를 실질적으로 고민하며 읽을 수 있게 되었습니다. 팀이 이 정도 수준까지 성장했다는 점에 큰 보람을 느낍니다.

—— 지금까지 과제 발견은 PdM이 담당해 왔습니다. 엔지니어가 여기에 참여하면 무엇이 달라지나요.

오시마: “무엇을 만들 것인가”를 결정하는 기획 초기 단계부터 엔지니어가 함께 논의할 수 있게 됩니다. 이는 제품의 완성도와 개발 속도를 동시에 끌어올리는 결과를 낳습니다. 엔지니어가 PdM과 한 팀으로 과제 발굴을 함께 진행하면, 기획과 검증 사이를 오가는 소통 공수가 획기적으로 줄어듭니다. 그로 인한 생산성 임팩트는 단순 기능 개발 속도를 올리는 것과는 비교할 수 없을 정도로 큽니다.

다카하시: 엔지니어가 과제 발굴에 직접 참여하면 기술적 실현 가능성을 현장에서 즉시 판단하며 논의를 진행할 수 있습니다. “이 방식은 바로 구현 가능하다”, “이 접근은 기술적으로 난이도가 높다”는 피드백을 즉각 제공할 수 있어 기획 검증의 정확도와 속도가 비약적으로 올라갑니다. PdM과 엔지니어 간의 불필요한 왕복 소통만 줄어들어 전체 리드 타임이 대폭 단축됩니다.

—— 구체적으로 어떤 목표를 그리고 있나요.

오시마: 과제 발굴부터 실제 릴리스까지의 전 과정을 1개월 이내에 완료하는 구조를 목표로 하고 있습니다. 이것이 실현되면 개발이 영업 전략까지 강력하게 견인할 수 있게 됩니다. “이 기능을 신속히 공급하면 이번 계약을 성사시킬 수 있다”는 선순환을 월 단위로 돌릴 수 있게 되면, 제품이 시장에 가치를 전달하는 속도 자체가 차원 다르게 변할 것입니다.

다카하시: 엔지니어가 영업 전략에 직접적인 영향을 미치는 구조는 예전에는 상상하기 어려웠습니다.하지만 이제는 충분히 실현 가능한 영역 안으로 들어왔습니다. 조직이 한 단계 높은 차원으로 진화했음을 실감하고 있습니다.

—— 마지막으로 Contract One이라는 조직의 매력과 함께 일하고 싶은 엔지니어상에 대해 말씀해 주세요.

오시마: AI 시대에 엔지니어가 어떻게 자신만의 가치를 증명할 것인가에 대해 하나의 명확한 이정표를 제시하는 조직이라고 자부합니다. Contract One은 Sansan의 차세대 핵심 사업으로 기대를 모으고 있는 제품이며, 현재 가파르게 성장하는 단계에 있습니다. 조직의 진화와 제품의 성장을 동시 경험할 수 있는 환경은 흔치 않습니다. 저희는 스스로 한계를 두지 않고 최종 성과(Outcome)에 집착할 수 있는 분과 함께하고 싶습니다. 단순 기술뿐만 아니라 제품과 비즈니스 전반에 넓은 관심을 두고, 실질적인 성과를 만들어내기 위해 주도적으로 움직이는 분을 기다리고 있습니다.

다카하시: 실행력이 압도적으로 빠르고, 시도해보고 싶은 아이디어를 유연하게 도전해볼 수 있는 조직입니다. “이것을 시도해보고 싶다”는 주도성만 있다면 얼마든지 시행착오를 거치며 성장할 수 있는 문화가 갖춰져 있습니다. 앞으로 비즈니스 부문과의 협업이 더욱 확대될 예정인 만큼, 기술과 제품 양쪽 모두에 흥미를 느끼고 폭넓게 기여하고 싶은 분이라면 마음껏 역량을 발휘하실 수 있을 것입니다.