구현은 빠른데 배포가 늦어지는 이유는? ourly의 상류 공정 가시화 및 프로젝트 프로세스 타임 개선 사례

AI 활용이 보편화되면서 개발 프로세스의 병목은 기존의 구현 단계에서 요구사항 정의, 설계와 같은 상류 공정(Upstream process)으로 이동하고 있습니다. ourly 주식회사는 PR 리드타임 15시간 안팎 유지, 일일 배포(Day-to-day deployment) 실현 등 구현 단계의 개선을 이미 마친 후, 가치 전달 속도를 한층 더 높이기 위해 '프로젝트 전체의 리드타임'에 주목하기 시작했습니다.

반면 요구사항 정의나 설계 같은 상류 공정은 모호해지기 쉽고, 어느 부분에서 시간이 소요되는지 파악하기 어렵다는 과제가 있었습니다. 이에 동사는 Findy Team+의 '프로젝트 프로세스 타임 분석' 기능을 활용하여 프로세스 전체를 가시화하는 작업에 착수했습니다.

본 아티클에서는 ourly 주식회사 CTO 아이자와 님과 엔지니어링 매니저 카미모토 님의 인터뷰를 통해, 해당 기능을 도입하게 된 배경부터 상류 공정을 가시화하기 위해 어떠한 실천을 이어왔는지, 그리고 가시화를 통해 어떠한 인사이트를 얻었는지 밝힙니다.

프로필

아이자와 코스케 (相澤 宏亮) 2017년 주식회사 PLAN-B 신입으로 입사. 비전공자로 출발해 자사 서비스 개발 및 SES 등을 경험. 이후 주식회사 BIT A로 이직하여 ourly 사업 Launch를 주도. 분사하여 ourly 주식회사가 된 후 EM 역할을 거쳐, 2024년 7월 집행임원 CTO로 취임. 개발, 채용/육성, 개발 생산성 향상 등 다방면을 총괄하며 활약 중.

카미모토 나오토 (神本 直人) 신입으로 SUBARU에 입사하여 6년간 하드웨어 엔지니어로 근무. 이후 실무 미경험 상태에서 Web 엔지니어로 전향해 ourly 주식회사에 합류. 2025년 4월부터 EM 직책을 수행. 신규 기능 개발 업무와 더불어 개발 생산성 향상 추진 멤버로 활동 중.

배포가 늘지 않는 이유 ── 구현 단계 이외에 남은 과제

아이자와: Findy Team+를 도입했던 2년 반 전에는 풀 리퀘스트(이하 PR)의 리드타임이나 배포 빈도에 과제가 있어, 우선 구현 단계의 개선에 집중했습니다. 현재는 PR 리드타임이 15시간 안팎으로 안정되었고, 배포 빈도도 매일 수행할 수 있는 수준까지 끌어올렸습니다.

하지만 배포가 늘어나도 배포 빈도의 증가폭은 완만했고, 기대했던 만큼 가치 전달 속도가 올라가지 않는 상황이 이어졌습니다. 저희는 코드 변경 사항을 반영하는 '배포'와 고객이 실제 가치를 체감하는 '배포'를 구분해서 보고 있는데, 배포만 빨라져서는 의미가 없기 때문입니다.

요구사항 정의나 설계 같은 상류 공정이 '어영부영 진행되는' 상태로 남아 있었고, 이 부분을 제대로 단축하지 않으면 프로젝트 전체의 리드타임을 줄일 수 없다고 느끼게 되었습니다. 제품 전략을 재검토하는 시점에서도 배포 빈도를 높이는 것이 중요하다는 결론이 나왔고, 상류 공정을 가시화할 필요성을 강하게 느끼게 되었습니다.

"PR 리드타임과 배포 빈도를 극한으로 줄인 끝에는 무엇이 있을까?"라는 의문은 팀원들도 은연중에 느끼고 있었을 것입니다. 구현 단계의 과제가 개선되면서, 배포 빈도를 높이기 위해 무엇을 해야 할지 고민할 여유가 팀 내에 생겨났습니다. 제품을 어떻게 대할 것인가, 시간을 어디에 투자해야 하는가와 같은 고민이 점점 늘어난 느낌입니다.

카미모토: 저 자신은 이전부터 고민해 오던 부분이었지만, 최근에는 팀 전체가 아웃컴에 의식을 둘 수 있게 되었습니다. 개발 생산성 컨퍼런스나 외부 이벤트에서도 아웃컴에 대한 이야기가 많아졌고, 구현 단계 개선을 넘어 팀원 모두가 가치 전달에 직접 직면할 수 있게 되었다고 느낍니다.

아이자와: AI 기술이 발전하면서 PR 리드타임을 단축하거나 배포 빈도를 높이는 식의 난이도 자체가 낮아지고 있다는 실감이 듭니다. 이에 따라 우리가 풀어야 할 과제도 자연스럽게 바뀌고 있습니다. X(옛 트위터)나 Qiita를 봐도 제품 전체의 가치 전달이나 아웃컴에 대한 논의가 늘어났습니다. 구현 속도만 개선해서는 미래가 없다는 느낌이 들었고, 그 위에서 우리가 에너지를 어디에 집중 투자해야 할지 재고해야 할 시점이라고 봅니다.

Why(왜 만드는가)를 파악하기 위한 데이터 기반 구축

카미모토: 전후 공정의 병목을 개선하고 싶었던 것이 가장 큰 이유입니다. 지난 2년 정도에 걸쳐 설계부터 구현, 테스트까지, 이른바 프로그래밍의 전문성이 필요한 영역은 상당 부분 개선을 이루어냈습니다. 최근에는 LLM 활용 덕분에 이 프로세스가 더욱 빨라지고 있습니다.

그렇게 되자 가치 전달 속도를 지금보다 몇 배나 높이려 할 때, '설계 이전'과 '테스트 이후' 공정을 개선하지 않으면 한계에 다다를 것이라 느꼈습니다. 설계~테스트 구간은 고속화되었지만, '무엇을 만들 것인가', '왜 만드는가'라는 What·Why 영역이 모호한 상태로 남는다면 제품 차원의 가치 전달로 직접 연결하기 어렵기 때문입니다.

Jira나 스프레드시트에서도 티켓의 예실(예상 공수와 실제 공수)까지는 측정하고 있었지만, 공정별 상세 내역까지는 파악하지 못했습니다. 설계보다 상류 공정의 티켓은 일부만 발행되었고, 설계부터 배포 운영까지를 하나의 티켓으로 묶은 뒤 3가지 분류만 적용하고 있었습니다.

• 공(攻): 신규 기능 개발이나 개선 등 새로운 가치 창출로 이어지는 타스크

• 수(守): 버그 수정이나 보수 운영 등 기존 제공 가치의 유지로 이어지는 타스크

• 주(走): 스터디나 리팩터링 등 공·수 양면의 강화로 이어지는 타스크 (※ CTO인 아이자와 님이 야구를 좋아해서 3가지 분류에 '주공수'라는 표현을 사용했습니다. 웃음)

같은 '신규 개발' 안에서도 이것이 설계 단계인지 테스트 단계인지와 같은 공정별 차이는 보이지 않는 상태였습니다.

게다가 단일 티켓이 전체적으로 얼마만큼의 시간을 사용했는지에 대한 실제 공수나 작업 착수 전의 예상 공수는 파악하고 있었지만, 이는 거대한 마크로(Macro) 지표에 불과했습니다. 결과적으로 "어디부터 손을 대야 하는가"가 모호하게 남아버리는 과제가 존재했습니다.

아이자와: 당시에는 스프린트의 예실을 보며 회고를 진행했지만, 차이가 발생해도 "휴일이 있었다", "시간을 내지 못했다"와 같은 외부적인 이유로 결론이 나곤 해서 본질적인 개선으로 이어지지 못했습니다. 차이가 나더라도 프로젝트에 치명적인 문제가 발생하는 것은 아니었기 때문입니다. 개선 포인트를 찾지 못해 손을 댈 수가 없었던 상황이었습니다.

카미모토: 왜 유명무실해졌냐 하면, 당시의 저희가 마크로 차원의 최종 지표만 바라보고 있었기 때문이라고 생각합니다. 지행 지표이다 보니 개선을 하더라도 영향이 나타나기까지 시간이 걸립니다. 미크로 차원의 사이클 타임이나 PR 수 등을 중점적으로 개선해 나간 끝에, 비로소 의미 있는 지표로서 마크로 지표를 바라볼 수 있게 된 느낌입니다.

아이자와: 동시에 당시의 저희가 '개선해야 할 레이어'를 착각했던 측면도 있었다고 봅니다. PR 리드타임이나 리뷰 체계 같은 당장의 실행 영역 개선이 아직 충분하지 않은 단계에서 프로세스 전체의 최적화를 다루려다 보니, 다루는 단위가 지나치게 커서 어디부터 개선해야 할지 보이지 않았습니다.

Findy Team+를 처음 도입했을 때도 돌이켜보면 동일한 함정에 빠져 있었습니다. 예전에 외부 이벤트에서 "생산성 수치를 전부 개선하려다 아무것도 개선하지 못한 이야기"라는 주제로 발표한 적이 있는데, 그때는 베로시티나 배포 빈도와 같은 레이어에서 리드타임도 함께 개선하려고 했습니다.

선행 지표와 지행 지표를 정리하지 않은 채 한꺼번에 다루다 보니, 결과적으로 어느 것 하나 개선되지 않는 상태가 되었습니다. 그 경험 이후 먼저 리드타임 하나에만 집중하는 방침으로 전환했습니다. 구현 단계의 기반이 정비되고 나서야 비로소 프로세스 전체로 시선을 돌릴 수 있는 상태가 되었다고 느낍니다.

Jira 운영 재검토와 프로세스를 팀에 정착시키기 위한 노하우

Jira 운영 쇄신으로 프로세스를 '가시화'

아이자와: 원래의 Jira 운영 방식은 지금과 완전히 달랐습니다. 배포 빈도가 주 1회 또는 2주 1회였던 시절에는, 스프린트 중의 변경 사항을 리뷰 환경에 올리고 스프린트 리뷰에서 PO와 확인하여 배포 OK/NG를 받는 흐름이었습니다. OK가 떨어지면 쌓아두었던 PR을 한 번에 배포하는 방식이었습니다.

라벨 활용도 거의 없었고 에픽 단위로만 관리하는 수준이었습니다. 공수 입력도 각자에게 맡겨두다 보니 결국 스프린트 마지막 날에 일괄 입력하는 경우가 많았습니다. 티켓 분류 역시 '공·수·주' 3가지에 불과해 공정별 차이는 전혀 보이지 않았습니다.

카미모토: 이번에 프로젝트 프로세스 타임 분석 기능을 활용하면서 우선 이러한 운영 구조를 대대적으로 재검토했습니다. Findy Team+에서 권장하는 사용법을 기본으로 삼아, 스토리를 기점으로 삼고 여기에 서브 타스크를 발행하는 방식으로 전환했습니다.

그 위에서 서브 타스크에는 반드시 4가지 라벨을 각각 1개씩 부여하도록 했습니다.

• 00: 아웃컴 (아웃컴 분석용)

  개발을 통해 어떤 아웃컴을 제공할 수 있는가

• 01: 개발 종류 (투자 분석용)

  신규 기능 개발 / 기능 개선

• 02: 개발 공정 (프로세스 타임용)

  구현 / 설계 / 요구사항 정의 / 테스트

• 03: 개발 영역

  태스크가 어떤 직능 영역에 속하는가

이 4가지 항목 중 하나라도 누락되면 프로세스 전체의 가시화가 불가능해지기 때문에 필수 규칙으로 정했습니다.

'티켓 입력 담당자'가 뒷받침하는 운영 정착

카미모토: 운영 규칙을 문서화한 뒤, 매일 10분 정도 진행하는 회의에서 팀원 전체가 "오늘의 티켓을 전건 입력하는" 시간을 만들었습니다. "각자 알아서 하세요"라고 하면 형식적으로 흐르기 쉽기 때문에, 처음에는 동기적으로 다 함께 진행하는 자리를 의도적으로 마련했습니다. 이 시간 동안 논의를 거치며 정의에 대한 이해도를 맞춰나갔습니다.

아이자와: 주니어 멤버에게 '티켓 입력 담당자' 역할을 맡겨 석회 때 챙기는 업무를 담당하도록 했습니다. 주니어 멤버가 역할을 가짐으로써 당사자 의식이 생기고, 팀 전체적으로 운영이 정착되기 쉬워졌다고 느낍니다.

이러한 위임 방식은 원래 저희 팀에 존재하던 문화이기도 합니다. 석회에 제가 참석하지 못할 때도 있으므로, 단순한 알림이나 확인 역할이라면 주니어 멤버도 충분히 해낼 수 있습니다. OJT 단계에서 이러한 역할을 경험하게 함으로써 본인들의 동기 부여로도 연결된다고 봅니다. 성과를 내기 시작한 멤버에게는 카미모토 님처럼 차츰 책임 범위를 넓혀주고 있습니다.

카미모토: 석회 때의 입력 작업은 지금도 이어지고 있지만, 최근에는 각자 자투리 시간에 자발적으로 입력하는 모습이 늘었습니다. 석회 자체에 소요되는 시간도 점차 짧아지고 있습니다.

아이자와: 운영을 정착시키는 과정에서 중요했던 것은 "왜 지금 이것을 해야 하는가"를 공유하는 것이었습니다. 기존에 거쳐온 프로세스가 존재하기 때문에, 최종적으로 생산성이 높은 팀(단순한 코드량이 아닌 제품의 가치를 높일 수 있는 팀)을 목표로 삼기 위해 우선 PR 리드타임 등 당장의 실행 영역 개선을 완료해 왔습니다. 그 맥락을 바탕으로 "다음은 상류 공정을 마주할 타이밍이다"라고 설명하니 멤버들도 자연스럽게 받아들여 주었습니다.

최근에는 AI 네이티브 방식의 요구사항 정의나 설계에 대해 팀과 논의하는 자리도 있었는데, "왜 지금 해야 하는가?"라는 의구심은 딱히 나오지 않았습니다. 구현 단계를 개선하고, 그 앞뒤 공정을 정비함으로써 배포 빈도를 끌어올릴 수 있다는 흐름을 팀 전체가 자연스럽게 이해하고 있었기 때문이라고 생각합니다.

'Why'를 전달하고 상류 공정 참여 유도

아이자와: 한편, 상류 공정은 아직 충분히 티켓화되지 못한 부분이 있습니다. 요구사항 정의나 디자인 공정은 대표인 사카모토 님이 PO로서 외부 디자이너와 소통하며 진행하고 있는데, 여기에 시간이 얼마나 소요되는지, 어떤 프로세스로 결정되는지가 블랙박스화되어 있었습니다. 이 부분을 가시화하지 않는 한 프로젝트 전체의 리드타임을 파악할 수 없고 향후의 병목이 될 것이므로, 지속적으로 소통해 나갈 계획입니다.

상류 공정을 참여시키는 데 있어 핵심은 "왜 가시화하는가", "이 작업을 하면 무엇이 개선되는가"를 정성껏 전달하는 것입니다. 동시에 어떻게 효율화하고 싶은지, 팀으로서 어떤 이상적인 모습을 그리고 있는지도 함께 공유해야 합니다.

최근에는 Figma로 프로토타입을 제작하는 흐름을 팀 내에서 시도하고 있습니다. DX가 앞서 있는 기업 중에는 PO가 실제로 프로토타입을 구동해 보며 요구사항을 구체화하는 수순을 도입한 사례도 있는데, 이러한 일하는 방식을 참고하면서 역할과 프로세스 재검토로 이어가고자 합니다.

전체상 가시화를 통해 "하지 않을 일"을 명확하게

아이자와: 가시화를 시작한 지 얼마 되지 않아, 소위 '의미 있는 데이터'로서 명확하게 읽어낼 수 있는 부분은 솔직히 아직 많지 않습니다. 하지만 가시화를 시도하는 과정 자체에서 알게 된 점이 많습니다.

첫째로, Jira를 포함한 데이터를 바르게 남겨두지 않으면 애초에 가시화의 출발선에조차 설 수 없다는 사실입니다. 이 점을 이른 단계에서 깨달을 수 있었던 것은 큰 성과였습니다.

둘째로, 가시화를 시도함으로써 기존 플로우의 어느 지점이 병목이 되고 있는지가 비로소 수면 위로 드러난다는 점입니다. 예를 들어 디자인 영역의 경우 PO가 외부 디자이너와 주고받으며 진행하고 있는데, 그 시간이 얼마나 걸리는지, 어떤 공정을 거치는지 전혀 보이지 않았습니다. 가시화하고 싶다고 생각한 순간에 가시화에 필요한 상태가 구축되어 있지 않으면 아무것도 볼 수 없다는 점, 이는 개선을 추진하는 데 있어 매우 중요한 깨달음이었습니다.

카미모토: 전체를 넓게 바라볼 수 있게 됨으로써 '개선해도 효과가 크지 않은 영역'이 명확히 보일 것이라는 기대가 있습니다. 회고를 진행하다 보면 가성비가 낮은 개선안에 논의가 집중되는 경우가 자주 있습니다. 하지만 전체상이 파악되면, 개선하더라도 전체에 수 % 정도밖에 영향을 주지 못하는 영역에 시간을 낭비하지 않아도 됩니다. 즉, '하지 않을 일'에 대한 의사결정이 쉬워진다는 의미입니다.

재현성을 만드는 프로젝트 표준 프레임 구축

아이자와: 프로젝트 전체 지표는 PR 리드타임이나 사이클 타임처럼 매일 추적하는 성격의 지표는 아니라고 생각합니다. 분기에 한 번, 혹은 월 1회 정도의 주기적 호흡으로 프로젝트 진행 양상을 조망하며 확인하는 방식이 적합합니다. 사이클 타임이 짧았던 프로젝트와 그렇지 않았던 프로젝트의 차이를 복기하고, 구현 이외의 공정에 어떤 차이점이 있었는지를 명확히 함으로써 개선해야 할 포인트를 보다 빠르게 특정할 수 있을 것입니다.

배포 빈도가 더욱 올라간다면 2주 단위 등 프로젝트의 실태에 맞춘 주기로 평가하는 것도 가능해 보입니다.

또한, 프로젝트 프로세스 타임 분석을 활용해 프로젝트의 '표준 프레임(型)'을 만들어가고자 합니다. 예컨대 요구사항 정의라면 "이 정도 기간 내에 수렴하는 것이 건전하다", 설계라면 "이 사이클에 맞추려면 여기까지 마쳐두어야 한다"와 같은 기준값입니다. 이러한 표준 프레임이 잡히면 멤버들이 프로젝트 전체 진행을 판단하기 쉬워지고 매니지먼트 부담도 줄어들 것입니다. 최종적으로는 누가 프로젝트를 담당하더라도 일정 수준의 재현성을 가지고 진행할 수 있는 상태를 만들어, 개인의 경험에 의존하지 않고 가치 전달까지의 속도를 끌어올릴 수 있는 조직을 목표로 하고 있습니다.

카미모토: 현시점에서는 측정의 기반이 이제 막 갖춰진 단계이지만, 이제부터 본격적으로 활용하는 페이즈에 들어갑니다. 6개월 뒤에는 성과를 공유해 드릴 수 있을 것으로 기대하니 많은 관심 부탁드립니다.