Findy Korea Media

SEI 플랫폼이 개발 조직에 필요한 5가지 이유: 생산성부터 데이터 기반 의사결정까지 | Findy Team+

Findy Team+ — Sat, 07 Nov 2026 07:41:20 GMT

개발 조직의 규모가 커지고 개발 프로세스가 복잡해질수록 한 가지 질문이 중요해집니다.

“우리 개발 조직은 실제로 얼마나 효율적으로 일하고 있으며, 어떤 가치를 만들어내고 있을까?”

개발 조직에서는 매일 수많은 데이터가 발생합니다. GitHub의 Pull Request와 코드 리뷰, Jira의 이슈와 프로젝트 진행 상황, CI/CD의 배포 기록 등이 대표적입니다.

하지만 이러한 데이터가 여러 도구에 분산되어 있다면 개발 조직의 전체적인 상태를 파악하기 어렵습니다.

특정 프로젝트가 지연되고 있다는 사실은 알 수 있어도 어디에서 병목이 발생했는지, 개발 프로세스를 개선한 이후 실제로 성과가 달라졌는지 확인하기는 쉽지 않습니다.

이러한 문제를 해결하기 위한 접근법 중 하나가 SEI(Software Engineering Intelligence) 플랫폼입니다.

SEI 플랫폼은 개발 과정에서 발생하는 데이터를 통합하고 분석해 개발 조직의 상태를 가시화하고, 데이터 기반의 의사결정과 지속적인 개선을 지원합니다.

그렇다면 SEI 플랫폼을 도입하면 개발 조직에 어떤 변화가 생길 수 있을까요?

이번 글에서는 개발 생산성 향상, 데이터 기반 의사결정, 협업 개선, 코드 품질과 안정성, 지속적인 조직 개선이라는 다섯 가지 관점에서 살펴보겠습니다.

SEI(Software Engineering Intelligence) 플랫폼이란 무엇인가요?

SEI 플랫폼은 소프트웨어 개발 과정에서 발생하는 데이터를 수집·분석해 개발 조직의 생산성과 업무 흐름을 이해하고 개선할 수 있도록 지원하는 도구입니다.

일반적으로 GitHub와 같은 코드 관리 도구, Jira와 같은 프로젝트 관리 도구, CI/CD 시스템 등에서 발생하는 데이터를 연결해 활용합니다.

이를 통해 개발 조직은 다음과 같은 질문에 답할 수 있습니다.

개발 과정에서 가장 많은 시간이 소요되는 단계는 어디인가?
Pull Request가 생성된 이후 리뷰와 병합까지 얼마나 걸리는가?
팀별 업무량과 프로젝트 진행 상황은 어떻게 변화하고 있는가?
개발 프로세스를 개선한 이후 실제로 성과가 달라졌는가?

중요한 것은 단순히 데이터를 많이 수집하는 것이 아닙니다.

데이터를 통해 현재 상태를 이해하고, 개선이 필요한 영역을 발견하며, 실제 변화로 연결할 수 있어야 한다는 것입니다.

SEI 플랫폼은 이러한 과정을 지원하는 분석 환경이라고 볼 수 있습니다.

개발 조직에 SEI 플랫폼이 필요한 5가지 이유

1. 개발 생산성과 업무 효율성을 개선할 수 있습니다

SEI 플랫폼의 첫 번째 가치는 개발 과정에서 발생하는 비효율과 병목을 데이터로 발견할 수 있다는 것입니다.

소프트웨어 개발에는 코드 작성뿐 아니라 리뷰, 테스트, 배포, 이슈 관리 등 여러 단계가 포함됩니다.

각 단계가 서로 연결되어 있기 때문에 특정 과정에서 지연이 발생하면 전체 개발 일정에도 영향을 줄 수 있습니다.

SEI 플랫폼은 이러한 개발 활동을 통합적으로 가시화해 어느 단계에서 시간이 소요되고 있는지 파악하도록 돕습니다.

개발 프로세스의 병목을 발견할 수 있습니다

예를 들어 Pull Request가 생성된 이후 실제 병합까지 지나치게 오랜 시간이 걸린다고 가정해 보겠습니다.

단순히 전체 리드 타임만 확인한다면 어디에서 문제가 발생했는지 알기 어렵습니다.

하지만 코드 리뷰 대기 시간, 리뷰 이후 수정 시간, 병합까지 걸리는 시간 등을 함께 살펴보면 어느 단계에서 지연이 발생하는지 보다 구체적으로 파악할 수 있습니다.

이러한 데이터를 기반으로 리뷰 담당자 배정이나 승인 프로세스를 개선하는 등의 활동을 검토할 수 있습니다.

업무와 리소스의 분배 상태를 이해할 수 있습니다

개발 조직에서는 특정 팀이나 구성원에게 업무가 집중되는 경우가 발생할 수 있습니다.

SEI 플랫폼은 업무량과 개발 활동의 분포를 가시화해 팀별 부담이나 업무 흐름을 파악하는 데 도움을 줍니다.

예를 들어 특정 개발자에게 코드 리뷰 요청이 집중되어 있다면 리뷰 대기 시간이 길어지는 원인이 될 수 있습니다.

이러한 상황을 발견하면 리뷰 담당자를 분산하거나 업무 배분 방식을 조정하는 등의 개선을 검토할 수 있습니다.

다만 개발 활동량이 많다는 사실이 반드시 높은 생산성을 의미하는 것은 아닙니다. 데이터는 업무 맥락과 함께 해석해야 합니다.

데이터 수집과 리포팅을 자동화할 수 있습니다

개발 조직의 상태를 파악하기 위해 매번 GitHub와 Jira에서 데이터를 내려받아 수동으로 정리한다면 상당한 시간이 필요합니다.

SEI 플랫폼은 이러한 데이터 수집과 리포트 작성 과정을 자동화해 반복적인 관리 업무를 줄이는 데 도움을 줍니다.

그 결과 개발 조직의 리더는 데이터를 취합하는 작업보다 문제를 해석하고 개선 방향을 결정하는 데 더 많은 시간을 사용할 수 있습니다.

2. 데이터 기반의 의사결정을 지원합니다

개발 조직의 의사결정은 경험과 직관에만 의존해서는 안 됩니다.

물론 경험은 중요하지만, 실제 개발 과정에서 발생하는 데이터를 함께 활용하면 문제를 보다 객관적으로 이해할 수 있습니다.

SEI 플랫폼은 개발 조직의 상태와 변화에 관한 데이터를 제공해 의사결정의 근거를 마련하는 데 도움을 줍니다.

개선이 필요한 영역을 객관적으로 파악할 수 있습니다

예를 들어 최근 개발 속도가 느려졌다고 느끼는 상황을 생각해 보겠습니다.

단순히 개발자의 업무량이 늘었기 때문이라고 판단할 수도 있지만 실제 원인은 다를 수 있습니다.

코드 리뷰 대기 시간이 길어졌거나, 특정 프로젝트에서 반복적인 수정이 발생하거나, 배포 과정에서 지연이 발생했을 수도 있습니다.

SEI 플랫폼을 통해 관련 지표의 추세를 살펴보면 문제를 보다 구체적으로 정의할 수 있습니다.

이렇게 하면 막연한 인상보다 실제 데이터를 기반으로 개선의 우선순위를 결정하기 쉬워집니다.

프로젝트 일정과 진행 상황을 예측하는 데 도움을 줍니다

과거의 개발 데이터를 활용하면 프로젝트 계획을 수립할 때도 참고할 수 있습니다.

예를 들어 유사한 작업의 평균 처리 시간이나 개발 과정에서 반복적으로 발생하는 지연을 확인하면 향후 일정에 영향을 줄 수 있는 요소를 미리 고려할 수 있습니다.

물론 과거 데이터만으로 프로젝트 완료 시점을 정확하게 예측할 수 있는 것은 아닙니다.

새로운 기술적 난이도나 요구사항 변경 등 데이터로 설명하기 어려운 변수도 존재하기 때문입니다.

따라서 예측 데이터는 확정적인 일정이 아니라 보다 현실적인 계획을 수립하기 위한 참고 정보로 활용하는 것이 적절합니다.

프로젝트의 위험 요소를 조기에 발견할 수 있습니다

개발 일정이 지연되기 전에 관련 지표에서 이상 징후가 나타나는 경우도 있습니다.

예를 들어 특정 팀의 업무가 지속적으로 증가하거나 Pull Request 병합 시간이 길어지고 있다면 향후 일정에 영향을 줄 가능성이 있습니다.

이러한 변화를 조기에 확인하면 리소스 조정이나 업무 우선순위 변경 등 필요한 대응을 검토할 수 있습니다.

즉 SEI 플랫폼은 문제가 발생한 이후 결과를 확인하는 것뿐 아니라 문제가 커지기 전에 관련 징후를 발견하는 데도 활용할 수 있습니다.

3. 개발 조직의 협업과 커뮤니케이션을 개선할 수 있습니다

소프트웨어 개발은 여러 구성원이 함께 진행하는 작업입니다.

개발자뿐 아니라 Engineering Manager, CTO, 프로젝트 관리자 등 다양한 역할의 구성원이 서로 다른 정보를 필요로 합니다.

SEI 플랫폼은 분산된 개발 데이터를 공통의 정보로 연결해 조직 내 협업과 커뮤니케이션을 지원할 수 있습니다.

개발 현황을 하나의 기준으로 공유할 수 있습니다

팀마다 서로 다른 방식으로 프로젝트 진행 상황을 보고한다면 동일한 상황을 두고도 서로 다른 해석이 발생할 수 있습니다.

SEI 플랫폼을 통해 주요 데이터를 하나의 화면에서 확인하면 개발 조직의 상태를 보다 일관된 기준으로 공유할 수 있습니다.

특히 여러 팀이 함께 프로젝트를 진행하거나 원격으로 협업하는 조직에서는 이러한 가시성이 중요합니다.

업무 진행 상황과 지연 요소를 함께 확인하면 불필요한 커뮤니케이션을 줄이고 필요한 논의에 집중하기 쉬워집니다.

역할에 따라 필요한 정보를 제공할 수 있습니다

개발 조직의 모든 구성원이 동일한 데이터를 필요로 하는 것은 아닙니다.

예를 들어 CTO는 조직 전체의 개발 생산성과 프로젝트 진행 상황을 확인하고 싶을 수 있습니다.

Engineering Manager는 팀별 업무 흐름이나 코드 리뷰 병목을 살펴보는 데 더 관심이 있을 수 있습니다.

개발자는 자신이 참여하는 작업의 진행 상황과 리뷰 상태를 확인하는 것이 중요할 수 있습니다.

역할별로 필요한 데이터를 구분해 제공하면 각 구성원이 자신의 업무와 의사결정에 필요한 정보를 보다 효율적으로 활용할 수 있습니다.

개발자의 경험과 피드백을 함께 살펴볼 수 있습니다

개발 조직의 상태는 정량적인 데이터만으로 모두 설명할 수 없습니다.

같은 성과를 내는 팀이라도 한 팀은 원활한 협업을 통해 안정적으로 일하고 있는 반면, 다른 팀은 일부 구성원의 과도한 업무에 의존하고 있을 수도 있습니다.

일부 SEI 플랫폼은 설문조사나 피드백 기능을 통해 개발자의 만족도와 업무 경험을 함께 확인할 수 있도록 지원합니다.

이러한 정성적인 정보는 개발 활동 데이터와 함께 활용할 때 조직의 문제를 보다 다양한 관점에서 이해하는 데 도움이 됩니다.

4. 코드 품질과 소프트웨어 안정성을 개선하는 데 도움을 줍니다

개발 속도가 빠르다고 해서 반드시 좋은 개발 조직이라고 할 수는 없습니다.

빠른 개발 과정에서도 코드 품질과 소프트웨어 안정성을 유지할 수 있어야 합니다.

SEI 플랫폼은 코드 리뷰와 개발 프로세스에서 발생하는 데이터를 분석해 품질과 안정성에 영향을 줄 수 있는 문제를 발견하도록 지원합니다.

코드 리뷰 프로세스를 개선할 수 있습니다

코드 리뷰는 소프트웨어 품질을 유지하기 위한 중요한 과정입니다.

하지만 리뷰가 지나치게 지연되거나 특정 인원에게 집중된다면 전체 개발 흐름에 영향을 줄 수 있습니다.

SEI 플랫폼을 활용하면 리뷰 대기 시간, 수정 횟수, 승인 과정 등의 데이터를 살펴볼 수 있습니다. 이를 통해 리뷰 과정에서 발생하는 병목을 발견하고 개선 방향을 검토할 수 있습니다.

다만 리뷰 시간이 짧아졌다는 사실만으로 코드 품질이 향상되었다고 단정할 수는 없습니다.

리뷰 속도뿐 아니라 실제 결함이나 장애와 관련된 지표도 함께 살펴보는 것이 중요합니다.

품질과 관련된 위험 요소를 발견할 수 있습니다

특정 유형의 버그가 반복적으로 발생하거나 일부 영역에서 수정과 재작업이 빈번하게 이루어진다면 품질 관리 관점에서 추가적인 확인이 필요할 수 있습니다. 관련 데이터가 연동되어 있다면 SEI 플랫폼을 통해 이러한 패턴을 파악하는 데 도움을 받을 수 있습니다.

예를 들어 특정 모듈에서 반복적인 수정이 발생한다면 해당 영역의 테스트나 코드 리뷰 방식을 다시 검토할 수 있습니다.

다만 모든 SEI 플랫폼이 코드의 취약점이나 결함을 직접 탐지하는 것은 아닙니다. 이러한 분석에는 별도의 코드 품질 관리 및 보안 도구와의 연동이 필요할 수 있습니다.

지속적인 피드백을 통해 품질 개선을 지원합니다

소프트웨어 품질은 한 번의 점검으로 완성되지 않습니다. 개발 과정에서 발생하는 문제를 지속적으로 확인하고 개선하는 과정이 필요합니다.

SEI 플랫폼을 통해 관련 지표의 변화를 추적하면 개선 활동 이후 실제로 어떤 변화가 있었는지 확인할 수 있습니다.

이러한 피드백이 반복되면 개발 조직은 문제가 발생할 때마다 대응하는 방식에서 벗어나 지속적으로 개발 프로세스를 개선하는 방식으로 발전할 수 있습니다.

5. 지속적인 개선과 조직의 성장을 지원합니다

개발 생산성 개선은 한 번의 프로젝트로 끝나는 작업이 아닙니다.

조직의 규모와 개발 환경, 제품의 요구사항이 변화하면 개선해야 할 문제도 달라질 수 있습니다. SEI 플랫폼의 다섯 번째 가치는 개발 조직이 현재 상태를 측정하고 개선 활동을 반복할 수 있는 기반을 제공한다는 것입니다.

데이터를 활용한 회고를 진행할 수 있습니다

일반적인 회고에서는 구성원의 경험과 의견을 중심으로 문제를 논의하는 경우가 많습니다. 여기에 실제 개발 데이터를 함께 활용하면 논의의 근거를 보다 구체적으로 만들 수 있습니다.

예를 들어 지난 한 달 동안 코드 리뷰 프로세스를 개선했다면 리뷰 대기 시간이나 병합 리드 타임이 실제로 어떻게 변화했는지 확인할 수 있습니다. 개선 효과가 나타나지 않았다면 다른 원인을 검토하거나 새로운 가설을 세울 수도 있습니다.

중요한 것은 데이터가 구성원의 의견을 대체하는 것이 아니라 회고를 더 구체적으로 만드는 근거로 활용되어야 한다는 것입니다.

팀과 구성원의 성장에 필요한 정보를 얻을 수 있습니다

개발 활동 데이터는 팀의 업무 구조와 협업 방식, 특정 영역에 집중되는 업무 등을 이해하는 데 도움을 줄 수 있습니다.

예를 들어 특정 개발자에게 리뷰 요청이 집중되어 있다면 해당 구성원이 팀의 중요한 지식과 경험을 보유하고 있을 가능성이 있습니다. 이 경우 단순히 활동량을 평가하기보다 지식 공유나 리뷰 담당자 분산 등을 검토할 수 있습니다.

다만 개인별 커밋 수나 Pull Request 수를 개발자의 생산성과 직접 연결하는 것은 주의해야 합니다. 개발자의 기여에는 설계, 문제 해결, 협업, 리뷰 등 단순한 활동량으로 측정하기 어려운 요소도 포함되기 때문입니다.

따라서 개인별 데이터는 성과 순위를 매기는 용도보다 업무 환경과 성장에 필요한 지원을 이해하는 데 신중하게 활용하는 것이 좋습니다.

목표 설정과 개선 효과를 측정할 수 있습니다

개발 조직이 개선 목표를 설정했다면 실제로 목표에 가까워지고 있는지 확인해야 합니다. SEI 플랫폼은 주요 지표의 변화를 지속적으로 추적하고 과거 데이터와 비교하는 데 활용할 수 있습니다.

필요하다면 외부 벤치마크도 참고할 수 있지만 조직마다 제품과 개발 환경이 다르기 때문에 단순한 숫자 비교에는 주의해야 합니다. 중요한 것은 다른 조직보다 높은 수치를 만드는 것이 아니라 우리 조직이 해결하려는 문제를 얼마나 개선했는지 확인하는 것입니다.

이러한 측정과 개선이 반복될 때 데이터는 일회성 리포트가 아니라 조직의 지속적인 성장을 지원하는 수단이 됩니다.

SEI 플랫폼 도입으로 기대할 수 있는 효과는 무엇인가요?

앞서 살펴본 다섯 가지 가치를 정리하면 다음과 같습니다.

도입 효과	주요 활용 방법	기대할 수 있는 변화
개발 생산성 및 효율성	리드 타임, 리뷰, 업무 흐름 분석	병목 발견 및 반복 업무 감소
데이터 기반 의사결정	개발 지표 분석, 일정 추세 확인	객관적인 문제 정의 및 계획 수립
협업과 커뮤니케이션	개발 현황 공유, 역할별 대시보드	정보의 투명성 및 협업 효율 개선
코드 품질과 안정성	리뷰 과정 및 품질 관련 데이터 분석	품질 위험 요소 발견 및 개선
지속적인 개선과 성장	데이터 기반 회고, 목표 관리	개선 효과 측정 및 지속적인 조직 학습

다만 SEI 플랫폼을 도입하는 것만으로 이러한 효과가 자동으로 발생하는 것은 아닙니다.

어떤 문제를 해결할 것인지 정의하고, 필요한 데이터를 선택한 뒤, 실제 개선 활동으로 연결해야 합니다. 따라서 도입 자체보다 도입 이후 데이터를 어떻게 활용하는지가 더 중요합니다.

SEI 플랫폼은 어떤 개발 조직에 필요할까요?

SEI 플랫폼은 개발 과정에서 발생하는 데이터를 통합적으로 이해하고, 이를 지속적인 개선에 활용하려는 조직에 유용합니다.

특히 다음과 같은 상황에서 도입을 검토할 수 있습니다.

여러 개발 도구에 데이터가 분산되어 있어 전체 현황을 파악하기 어려운 경우
개발 조직의 규모가 커지면서 팀별 업무 흐름과 병목을 이해하기 어려워진 경우
개발 생산성 개선 활동의 효과를 객관적으로 확인하고 싶은 경우
경영진과 개발 조직 사이에서 프로젝트 진행 상황과 성과를 공유할 공통의 기준이 필요한 경우
수동으로 작성하는 개발 리포트와 데이터 취합 업무를 줄이고 싶은 경우

반면 개발 조직이 작고 현재 사용하는 도구만으로 필요한 정보를 충분히 확인할 수 있다면 별도의 SEI 플랫폼 도입이 반드시 필요한 것은 아닙니다.

먼저 현재 어떤 데이터가 부족하고, 그로 인해 어떤 의사결정이 어려운지 확인하는 것이 좋습니다.

SEI 플랫폼에 대해 자주 묻는 질문

SEI 플랫폼을 도입하면 개발 생산성이 바로 향상되나요?

반드시 그렇지는 않습니다. SEI 플랫폼은 개발 과정의 데이터를 수집하고 분석해 병목과 개선 기회를 발견하도록 지원합니다. 실제 생산성 향상은 데이터를 바탕으로 업무 프로세스를 개선하고 그 효과를 지속적으로 확인하는 과정에서 나타날 수 있습니다.

SEI 플랫폼은 개발자의 성과를 평가하는 도구인가요?

SEI 플랫폼은 개발 활동에 관한 데이터를 제공할 수 있지만, 커밋 수나 Pull Request 수만으로 개발자의 성과를 정확하게 판단하기는 어렵습니다. 개발 조직의 업무 흐름과 협업 환경을 이해하고 개선하는 목적으로 활용하는 것이 바람직합니다.

SEI 플랫폼과 일반적인 프로젝트 관리 도구는 무엇이 다른가요?

Jira와 같은 프로젝트 관리 도구는 주로 업무와 이슈의 계획 및 진행 상황을 관리합니다. SEI 플랫폼은 코드 관리, 프로젝트 관리, CI/CD 등 여러 도구에서 발생하는 데이터를 통합해 개발 프로세스와 생산성을 분석하는 데 초점을 맞춥니다. 두 도구는 서로 대체하기보다 함께 활용할 수 있습니다.

SEI 플랫폼으로 코드 품질도 측정할 수 있나요?

코드 리뷰 시간, 수정 패턴, 변경 실패와 관련된 지표 등 품질과 관련된 데이터를 분석하는 데 활용할 수 있습니다. 다만 코드의 실제 결함이나 보안 취약점을 직접 탐지하는 기능은 제품마다 다르며 별도의 분석 도구가 필요할 수 있습니다.

SEI 플랫폼은 CTO와 Engineering Manager에게 어떤 도움이 되나요?

CTO는 조직 전체의 개발 현황과 주요 지표를 파악하고, Engineering Manager는 팀별 업무 흐름과 병목을 이해하는 데 활용할 수 있습니다. 이를 통해 개선 과제의 우선순위를 결정하고 개선 활동의 효과를 확인하는 데 도움을 받을 수 있습니다.

SEI 플랫폼을 도입하기 전에 무엇을 준비해야 하나요?

먼저 조직에서 해결하려는 문제를 정의해야 합니다. 이후 필요한 지표와 현재 사용하는 개발 도구를 정리하고, 실제 데이터를 연동할 수 있는지 확인하는 것이 좋습니다. 도입 후에는 정기적인 리뷰와 개선 활동을 운영할 수 있는 체계도 필요합니다.

SEI 플랫폼의 핵심 가치는 '측정'이 아니라 '개선'에 있습니다

개발 조직에서는 매일 다양한 데이터가 발생합니다.

하지만 데이터가 존재한다는 것과 이를 실제 의사결정에 활용하고 있다는 것은 다른 문제입니다. SEI 플랫폼은 분산된 개발 데이터를 통합하고 분석해 개발 생산성, 업무 효율성, 협업, 품질, 조직의 성장과 관련된 문제를 이해할 수 있는 환경을 제공합니다.

그리고 여기에서 한 단계 더 나아가야 합니다.

측정 → 문제 발견 → 원인에 대한 가설 → 개선 → 재측정

이 과정이 반복되어야 데이터가 실제 개발 조직의 변화로 이어질 수 있습니다.

Findy Team+는 GitHub, Jira 등 개발 과정에서 발생하는 데이터를 기반으로 개발 조직의 상태를 가시화하고, 데이터 기반의 의사결정과 지속적인 생산성 개선을 지원합니다.

결국 중요한 질문은 “우리 개발 조직에서 얼마나 많은 데이터가 발생하고 있는가?”가 아니라 “이 데이터를 통해 무엇을 이해하고, 무엇을 개선할 수 있는가?”입니다.

개발 조직이 성장할수록 데이터를 수집하는 것만큼 이를 올바르게 해석하고 활용하는 능력도 중요해집니다.

SEI 플랫폼은 이러한 데이터 기반의 개선 문화를 구축하는 데 도움이 되는 도구입니다.

AI 도입만으로는 가치 제공 속도가 빨라지지 않는다 - LegalOn Technologies가 가시화를 통해 확인한 아웃컴으로 이어지는 기반과 프로세스 재구축의 포인트 | Findy Team+

Findy Team+ — Thu, 29 Oct 2026 02:47:30 GMT

20~30개의 개발팀이 동시에 운영되고 있는 LegalOn Technologies에서는 생성형 AI의 발전이 업무 방식에도 큰 변화를 가져오기 시작했습니다. 개별 엔지니어가 AI 도구를 능숙하게 활용하는 것만으로는 조직 전체의 개발 속도를 높이기 어렵습니다. 여러 팀이 협력해 가치를 전달하는 조직에서는 이제 ‘AI를 어떻게 활용할 것인가’를 넘어, ‘AI를 전제로 가치 제공 프로세스를 어떻게 재설계할 것인가’가 중요한 과제로 떠오르고 있습니다.

이러한 배경에서 LegalOn Technologies는 2025년 AID CoE(AI-powered Development Center of Excellence)를 출범시켰습니다. AI 활용 확산과 프로세스 개선, 조직 내 노하우 공유를 부서와 팀의 경계를 넘어 추진하고 있습니다. 또한 Findy Team+를 활용해 AI 도입 전후의 생산성 변화와 개발 프로세스의 병목 구간을 정량적으로 파악하고, 이를 바탕으로 조직 차원의 개선 사이클을 만들어가고 있습니다.

이번 기사에서는 AID CoE가 출범하게 된 배경과 AI 도입 이후 나타난 변화, 그리고 Findy Team+를 활용해 조직 개선을 어떻게 추진하고 있는지에 대해 CTO 오피스 책임자로서 개발 조직 전반의 이네이블먼트를 담당하고 있는 도키타케 유타 님에게 이야기를 들었습니다.

프로필

도키타케 유타(時武佑太)
CTO 오피스 책임자

2017년 주식회사 LegalForce(현 LegalOn Technologies)에 첫 번째 EM으로 입사했으며, 같은 해 10월 CTO에 취임했다. 2019년에는 ‘TechCrunch Tokyo CTO Night 2019’ 피치 콘테스트에서 우승하며 ‘CTO of the Year’를 수상했다.

2022년 CTO에서 물러난 이후 엔지니어로서 첫 번째 프로덕트를 비롯해 현재 글로벌 시장에서도 활용되고 있는 법무 AI ‘LegalOn’ 개발에 참여했다.

2025년 4월부터 CTO 오피스 책임자를 맡고 있다. LLM을 활용해 개발 프로세스를 체계화·자동화하고 개발 조직의 생산성을 10배까지 끌어올리는 것을 목표로, 조직의 경계를 넘어 다양한 팀과 협업하며 관련 활동을 추진하고 있다.

생성형 AI의 발전에 대응하기 위해──AID CoE 출범과 조직을 넘어선 협업의 필요성

도키타케: AID CoE를 출범시킨 이유는 생성형 AI의 발전 속도를 개발 조직이 충분히 따라가지 못하고 있다는 위기감이 있었기 때문입니다. ChatGPT가 등장한 이후 AI를 활용한 도구와 방법은 계속 늘어났지만, 초기에는 정확도가 불안정해 “대단하긴 하지만 실제 업무에서 사용하기는 어렵다”는 수준이었습니다.

하지만 2024년에 들어서면서 상황이 크게 달라졌습니다. 정확도가 높아지면서 실제 업무에서도 충분히 활용할 수 있는 단계에 접어들었다고 느꼈습니다. 한편 새로운 기술에 관심이 많은 사람들은 스스로 다양한 도구를 시험해보지만, 매일 개발 업무에 쫓기는 구성원들은 새로운 기술을 살펴볼 여유가 부족할 수밖에 없습니다. 개발 조직이 150~200명 규모가 되면 개인의 자율에만 맡겨서는 조직 전체의 AI 활용 수준에 편차가 생기게 됩니다.

이대로라면 AI의 흐름에 뒤처질 수 있다는 위기감이 있었습니다. 원래는 CTO 오피스에서 AI 도구 도입을 추진하고 있었지만, AI 에이전트가 단순한 구현 단계를 넘어 개발 프로세스 전후에까지 영향을 미치기 시작하면서 여러 조직을 아우르며 지원할 수 있는 조직이 필요하다고 생각하게 됐습니다.

그래서 AI 활용에 특화된 조직인 AID CoE를 출범시켰습니다. 처음에는 CTO와 저, 두 명으로 시작했는데, 2024년 말부터 업계 전반의 AI 활용이 급격히 가속화되면서 더 본격적으로 추진해야 하는 상황이 됐습니다.

AI를 활용하려면 보안과 법무 측면의 검토가 반드시 필요합니다. 다행히 이 부분은 데이터 부문과 법무 부문에서 먼저 가이드라인을 정비해두었습니다. “어느 수준의 데이터까지 LLM에 입력할 수 있는가”와 같은 기준이 마련되어 있었기 때문에, 저희는 ‘어떻게 조직 전체로 확산할 것인가’에 집중할 수 있는 상태에서 시작할 수 있었습니다.

AID CoE는 ‘AI 활용과 관련해 어려움이 생겼을 때 가장 먼저 찾아오는 곳’과 같은 역할을 지향하고 있습니다. 팀마다 겪는 문제는 다릅니다. 실제로 특정 팀에 직접 들어가 구성원들과 함께 과제를 해결하기도 했고, 핸즈온 세션을 진행한 적도 있습니다. 관련 지식과 노하우를 문서화해 구성원들이 스스로 필요한 정보를 찾아볼 수 있도록 한 경우도 있습니다. 팀의 상황에 따라 지원 방식을 다르게 가져가고 있습니다.

AI 활용 수준의 편차를 줄이고, 조직 전체가 AI의 발전에 대응할 수 있도록 만드는 것. 그것이 AID CoE를 출범시킨 이유입니다.

AI를 전제로 한 개발 프로세스로──가치 제공까지의 ‘전체 최적화’를 위한 노력

도키타케: AID CoE가 처음 내세운 방향은 AI를 활용한 개발의 베스트 프랙티스를 사내에 정착시키고, AI-native 시대에도 경쟁력을 유지할 수 있는 개발 조직으로 진화하는 것이었습니다. 이를 ‘AI 주도 개발’이라고 표현하기도 하는데요. 단순히 AI라는 도구를 도입하는 것이 아니라 개발 프로세스와 업무 방식 자체를 AI를 전제로 재구성해, 가치 제공의 속도와 품질에서 기존 방식으로는 만들기 어려운 수준의 성장을 이루고 싶다는 의미입니다.

하지만 약 반년 동안 추진해보니, 처음 예상했던 것보다 훨씬 더 ‘기반’이 중요하다는 사실을 깨닫게 됐습니다. AI를 도입하고 모두가 능숙하게 사용할 수 있게 되면 목표에 도달할 수 있을 것 같았지만, 실제로는 그렇지 않았습니다.

개발 조직에는 그 기반이 되는 문화와 프로세스, 매니지먼트 방식이 있고 그 위에 AI가 더해집니다. 저희 조직도 어느 정도 기반이 갖춰져 있다고 생각했지만, AI를 최대한 활용한다는 관점에서 보면 아직 개선할 수 있는 부분이 많다는 것이 솔직한 생각입니다.

실제로 Cursor 도입을 추진했던 3월경에는 업무에서 AI 에이전트를 사용하는 구성원이 10%도 되지 않았습니다. 최근에는 95%를 넘어섰습니다. 확산이라는 측면에서는 지난 반년 동안 분명한 성과가 있었고, 실제 사용하는 엔지니어들에게 물어보면 거의 모두가 “생산성이 높아졌다”고 이야기합니다. 하지만 프로덕트 출시 수나 매출에 얼마나 연결됐는지를 보면 기대했던 만큼의 변화가 나타나지는 않았다는 느낌이 있었습니다.

처음에는 적어도 ‘2배’ 정도의 성장을 목표로 하고 싶었습니다. 예를 들어 1년에 100개를 출시하던 조직이 AI를 활용하면 200개를 출시할 수 있는 모습을 생각했습니다. 하지만 현재로서는 아직 그 수준까지 도달하지 못했습니다.

원인을 살펴보니 AI 덕분에 코딩 속도는 분명 빨라졌지만, 그 전후의 커뮤니케이션이나 요구사항 구체화, 리뷰 과정에서 추가적인 시간이 발생하면서 결과적으로 출시까지 걸리는 시간은 기대만큼 줄어들지 않았습니다. 애초에 전체 개발 프로세스에서 구현이 차지하는 비중은 약 20%에 불과합니다. 나머지 80%에 해당하는 기획, 요구사항 정리, 의사결정, 리뷰, 검증, 릴리스 조율이 병목이 된다면 전체 프로세스가 빨라질 수는 없습니다.

AI 도입 초기부터 블로그에서도 이야기했지만, “AI를 통해 효율을 높이고 싶다면 구현 단계만 개선해서는 안 되고, 개발 전 과정으로 개선 범위를 넓혀야 한다”고 생각했습니다. 반년 동안 실제로 추진해보면서 그 가설이 맞았다는 것을 실감하고 있습니다.

지금은 AI 도입을 추진하는 동시에 문화와 매니지먼트 방식, 팀 구조 등 조직의 ‘기반’을 탄탄하게 정비해야 한다는 필요성을 강하게 느끼고 있습니다. 엔지니어가 “내 코딩이 편해졌으니 생산성이 높아졌다”고 느끼는 수준에 머물러서는 조직 전체의 성과로 이어지지 않습니다. 가치 제공 속도를 높이려면 더 넓은 관점에서 프로세스 전체를 바라보고, 어디에 병목이 있으며 무엇을 개선해야 하는지를 고민해야 합니다.

여기에는 팀을 구성하는 방식이나 커뮤니케이션 방식, 리뷰 규칙, 경우에 따라서는 조직 구조를 다시 설계하는 일까지 포함될 수 있습니다. AI만으로 해결할 수 있는 문제가 아니기 때문에 문화와 매니지먼트 측면에서도 함께 접근하지 않으면 AI의 효과를 최대한 끌어내기 어렵다고 생각합니다.

AI 시대에는 애자일 개발 사이클을 지금보다 훨씬 빠르게, 그리고 여러 곳에서 동시에 돌릴 수 있게 될 것입니다. 하지만 현재는 그 사이클을 제대로 소화할 수 있는 조직적 준비가 아직 충분하지 않습니다. 그렇기 때문에 단순히 도구를 도입하거나 AI 활용을 확대하는 데 그치지 않고, 개발 조직 전체를 어떻게 최적화할 것인지까지 함께 고민하며 조직을 만들어가고자 합니다.

코드 생성부터 SDD, 이노베이터 제도까지──AI 활용을 조직 문화로 정착시키기 위한 실천

도키타케: AI 활용을 조직 전체로 확산하기 위해 AID CoE에서는 여러 가지 활동을 진행하고 있습니다.

프로세스 개선 측면에서는 프론트엔드 영역에서 사내 디자인 시스템을 AI가 제대로 이해할 수 있도록 컨텍스트를 구성하고, Figma 디자인을 바탕으로 거의 그대로 프론트엔드 코드를 생성하는 방식을 마련했습니다. 디자이너가 만든 페이지를 AI에 입력하면 약 90~95% 수준으로 디자인을 재현한 코드가 생성됩니다. 상당히 높은 수준으로 구현됩니다. 다만 이를 일상적으로 활용하는 사람과 아직 충분히 활용하지 못하는 사람으로 나뉘고 있기 때문에, 앞으로는 이 방식을 더 널리 정착시키고 싶습니다.

또 하나 여러 팀에서 시도하고 있는 것이 Spec-Driven Development(SDD)입니다. 저희 프로덕트는 업무 도메인이 복잡해 실제 업무를 경험하지 않으면 이해하기 어려운 경우가 많습니다. AI가 이러한 도메인 지식을 충분히 이해한 상태에서 코드를 생성할 수 있도록 개발 프로세스를 정리하는 프레임워크로 SDD를 활용하고 있습니다. 실제로 적용해보니 품질을 유지하면서도 높은 재현성을 확보할 수 있게 됐고, “확실히 정확도가 높아진다”는 점도 체감하고 있습니다.

다만 SDD는 프로세스 자체가 상당히 무겁기 때문에 이를 조직 전체로 한 번에 확대하는 것은 쉽지 않습니다. 잘 운영되고 있는 팀도 있지만, 모든 팀에 적용하기에는 난도가 높다는 인상도 있습니다. 그렇지만 ‘LegalOn’처럼 복잡한 도메인을 다루는 프로덕트와는 상당히 잘 맞는 부분이 있기 때문에, 어떤 요소를 적용했을 때 가장 효과적인지는 계속 검증해 나갈 계획입니다.

조직 문화를 만들기 위한 활동으로는 ‘AID Innovators’라는 제도를 운영하고 있습니다. AI 활용을 적극적으로 추진하는 구성원들을 사내에서 ‘이노베이터’로 선정하고, 이들이 정기적으로 모일 수 있는 자리를 마련하고 있습니다. 이노베이터들이 속한 팀에서 어떤 변화가 일어나고 있는지, 새롭게 시도해 잘된 것은 무엇인지, 반대로 잘되지 않았던 것은 무엇인지 공유받고, 이를 AID CoE에서 정리해 조직 전체에 공유합니다. 이노베이터들에게 “직접 조직 전체로 확산해달라”고 요구하기보다는, “일상 업무에서 AI 활용 방법을 계속 탐구해달라. 그 과정에서 나온 지식과 경험은 조직 차원에서 모아 확산하겠다”는 역할을 기대하고 있습니다.

일부 팀이나 일부 구성원만 AI를 잘 활용해서는 조직 전체의 성과로 이어지기 어렵습니다. 이러한 활동을 통해 AI 활용이 일회성 시도로 끝나는 것이 아니라 조직 문화로 자리 잡도록 만드는 것을 목표로 하고 있습니다.

체감이 아닌 데이터로 판단한다──Findy Team+로 확인한 변화와 프로세스 개선의 실마리

도키타케: AI 활용을 확대하는 데 있어 효과 측정은 반드시 필요하다고 생각합니다. AI 활용은 ‘실제로 얼마나 성과가 나타났는가’를 판단하기가 매우 어려운 영역입니다. 체감에만 의존하면 평가가 모호해질 수밖에 없습니다. 특히 AID CoE처럼 조직의 변화를 지원하는 이네이블먼트 조직은 성과가 수치로 드러나지 않으면 과소평가되기 쉬운 측면도 있습니다. 올해는 AI 활용에 집중한 여러 활동을 추진하고 있기 때문에, 시간의 흐름에 따라 효과를 정량적으로 측정할 수 있는 기반이 반드시 필요하다고 판단했습니다.

개발 조직 전체의 관점에서도 우리 개발 프로세스가 얼마나 효율적으로 운영되고 있는지, 어디에 병목이 있는지를 확인할 수 있는 기반이 필요했습니다. AI 활용에 투자하는 이상, 그 투자가 실제로 어느 정도 효과를 내고 있는지를 객관적으로 설명할 수 있는 근거가 없다면 조직 차원에서도 투자 여부를 판단하기 어려워집니다.

Findy Team+를 도입한 것도 같은 이유에서였습니다. AI 활용의 효과를 제대로 확인하려면 우선 어떤 방식으로든 개발 생산성을 수치로 파악해야 한다고 생각했습니다. 이전에 트라이얼로 사용해본 경험이 있어 어떤 데이터를 확인할 수 있는지, 어떻게 활용할 수 있는지 이미 어느 정도 알고 있었기 때문에 가장 먼저 도입 후보로 떠올랐습니다.

사용하기도 편했습니다. GitHub 연동이 간단했고, 화면에 표시되는 데이터도 보기 쉬워 수치의 변화와 흐름을 파악하기 좋았습니다. 그전까지 사내에는 개발 활동을 체계적으로 파악할 수 있는 시스템이 없었기 때문에 ‘커밋부터 PR 오픈까지 걸리는 시간’, ‘PR 생성 수’, ‘리드타임’과 같은 세부 데이터를 확인할 수 있게 된 것은 큰 변화였습니다.

실제로 사용하기 시작하면서 여러 가지 사실을 발견할 수 있었습니다. AI 도입 이후 PR 생성 수가 눈에 띄게 증가한 팀이 있었지만, 동시에 리뷰 리드타임이 길어지는 경향도 나타났습니다. 이전에도 “리뷰에 시간이 오래 걸린다”는 이야기는 있었지만, 체감만으로는 놓치기 쉬웠던 두 지표의 관계가 데이터로 명확하게 드러나면서 다음 개선 가설을 세우기가 훨씬 쉬워졌습니다.

AI 활용도가 높은 구성원은 실제 데이터에서도 차이가 나타났습니다. PR 수가 많으면서도 리뷰 대응 속도까지 빠른 구성원들이 있었고, 이들을 롤모델로 삼아 다른 팀과 구성원에게도 업무 방식을 공유하자는 방향으로 이어졌습니다.

특히 Findy Team+의 사이클 타임 분석을 자주 활용하고 있습니다. AI 도입 전후에 어떤 변화가 있었는지뿐 아니라 특정 팀이 아닌 조직 전체에서 어느 단계가 병목이 되고 있는지를 확인할 수 있기 때문에 개선 활동의 우선순위를 정하는 데도 도움이 됩니다. 경영진에게 현황을 보고하는 데 활용할 수 있다는 점에서도 큰 도움이 되고 있습니다.

AI는 단순히 도입하기만 한다고 성과가 나타나는 영역이 아닙니다. 개발 프로세스 안에 존재하는 문제를 찾아내고 하나씩 해결해 나가야 합니다. 그런 의미에서 Findy Team+의 데이터는 AID CoE의 활동을 뒷받침하는 중요한 ‘기반’이 되고 있습니다.

AI 활용이 확대되면서 토큰 사용량이나 이용료가 늘어나기 때문에 자연스럽게 비용에 대한 이야기도 나오게 됩니다. 이때 중요한 것은 “그만큼의 투자를 통해 실제로 얼마나 많은 결과물을 만들어냈는가”를 설명할 수 있느냐입니다. Findy Team+를 통해 이를 객관적으로 설명할 수 있게 된다는 것은 상당히 큰 의미가 있다고 생각합니다.

AI-native 시대에 경쟁할 수 있는 조직으로──문화·기반·매니지먼트의 변화와 Findy Team+의 역할

도키타케: 앞으로는 AI-native 시대에 최대한의 가치를 만들어낼 수 있는 조직을 만드는 데 더욱 힘을 쏟고 싶습니다. 단순히 도구나 시스템을 도입하는 것만으로는 충분하지 않습니다. 개발의 기반이 되는 문화와 마인드셋은 물론, CI/CD 인프라와 같은 기술적 기반까지 포함해 조직 전반의 변화를 만들어가야 한다고 생각합니다.

문화적인 측면에서는 각 팀의 현재 상황을 파악하고 구성원별로 추가적인 지원이 필요한지를 판단하는 것도 중요합니다. 구성원들이 AI를 어떻게 활용해야 하는지를 충분히 이해할 수 있도록 하고, 이를 바탕으로 개발 조직 전체에 긍정적인 흐름을 만들어가고 싶습니다.

Findy Team+의 데이터는 이러한 활동을 추진하는 데 중요한 기준이 될 수 있다고 생각합니다. 우리가 현재 나아가고 있는 방향이 맞는지, 최근 추진한 활동이 실제 수치의 개선으로 이어지고 있는지를 확인하는 데 도움이 됩니다. 특히 사이클 타임 분석은 어떤 부분부터 개선해야 할지를 판단하는 데 효과적입니다.

또한 배지 기능처럼 우리 조직의 수준이 상대적으로 어느 정도인지 객관적으로 확인할 수 있다는 점도 좋다고 생각합니다. 업계 전체와 비교했을 때 우리 회사의 개발 방식과 프랙티스가 어느 정도 수준까지 발전해 있는지를 확인하는 용도로도 활용할 수 있을 것입니다.

이러한 조직 개선의 기반으로 Findy Team+를 앞으로도 계속 활용해 나가고 싶습니다.

AI를 자연스럽게 활용하는 문화를 만든다

도키타케: 앞으로는 엔지니어뿐 아니라 개발 조직 전체가 AI를 자연스럽게 활용하고, AI를 전제로 한 개발 프로세스가 하나의 문화로 자리 잡은 상태를 만들어가고 싶습니다.

LegalOn Technologies의 흥미로운 점은 AID CoE뿐만 아니라 각 팀 안에도 AI 활용에 적극적인 구성원이 많다는 점입니다. 조직 곳곳에서 동시에 AI 활용이 진행되고 있습니다. 규모가 큰 조직이기 때문에 어려움도 있지만, 다양한 전문성을 가진 구성원들과 논의하면서 자신의 판단과 재량으로 새로운 시도를 추진할 수 있습니다.

이런 환경에서 새로운 방식에 대해 처음부터 거리를 두기보다는 기존에 익숙했던 방식을 과감하게 내려놓고 새롭게 배울 수 있는 사람과 함께 일하고 싶습니다. AI 시대의 개발에서는 기술 역량뿐 아니라 커뮤니케이션 방식이나 주변 사람들을 자연스럽게 참여시키는 역량도 중요해집니다. 팀 안팎의 구성원들과 협력하며 일을 추진할 수 있는 사람이라면 특히 강점을 발휘하기 좋은 환경이라고 생각합니다.

기술 역량은 물론, 이러한 소프트 스킬에 자신이 있거나 새로운 방식에 도전해보고 싶은 분이라면 꼭 한번 이야기를 나눠보셨으면 합니다.

팀 자율성을 유지하며 리드타임을 1/3로 단축한 Sansan의 개발 생산성 가시화 실천법 | Findy Team+

Findy Team+ — Thu, 29 Oct 2026 02:43:54 GMT

본문 요약

도입 전: 해결하고자 했던 과제

프로덕트와 엔지니어링 조직이 함께 우상향하며 성장하고 있었지만, 개발 생산성을 정량적으로 파악하지는 못했습니다. 'Bill One Engineering Unit(BOEU)'을 시작으로 타 유닛에서도 동일한 문제를 겪고 있었습니다.

Findy Team+를 도입한 이유

사내 지원자들이 개발 생산성을 가시화하는 자체 도구를 개발해 출시했으나, 기능 업데이트에 리소스를 투입하는 전담 부서가 없어 사용자 피드백 반영이 더뎠고 사내 정착이 어려웠습니다. Google이나 DORA 라이브러리 도입도 검토했지만 비용 효율성이 맞지 않아 포기하고 Findy Team+를 도입했습니다.

도입 결정 계기

우수한 UI/UX 디자인만으로는 설득력이 부족했기 때문에 자체 개발 도구와의 차이점을 ROI로 제시하고 현장 설문조사를 진행했습니다. 트라이얼 기간 동안 단기간에 성과를 입증한 점이 도입의 결정적 계기가 되었습니다.

도입 후: 주요 성과

Findy Team+ 도입 후 팀의 퍼포먼스를 명확한 언어로 정의할 수 있게 되었습니다. 병목 구간이 가시화되면서 매니저로서 집중해야 할 지점이 분명해졌고, 도출된 인사이트를 바탕으로 다음 액션을 실행하기 쉬워졌습니다. 도입 전후를 비교했을 때 병합된 풀 리퀘스트(PR) 수는 약 1.3배 증가했고, 리드타임은 약 1/3로 단축되었습니다.

프로젝트 소개

'Bill One Engineering Unit(BOEU)'은 모든 청구서를 온라인으로 수령하고 데이터화하는 인보이스 관리 서비스 'Bill One'을 담당합니다. 기업의 청구서 수령부터 월차 결산까지의 과정을 가속하기 위해 조직력 강화뿐만 아니라 기능 개발 및 타사 서비스와의 연동에 집중하고 있습니다. 고객의 핵심 경영 과제 중 하나인 '디지털 기술을 통한 효율화'를 실현하며 부가가치 높은 서비스를 확대해 나가고 있습니다.

프로필

카와모토 켄지 (川元謙治) Sansan 주식회사 기술본부 Bill One Engineering Unit (BOEU) Core Business AP 그룹 엔지니어링 매니저. SIer 및 패키지 개발사 경험을 거쳐 2022년 Sansan 주식회사에 경력직으로 입사했습니다. Web 애플리케이션 개발 엔지니어로 커리어를 시작해, 현재는 'Bill One'의 청구서 수령 개발을 담당하는 그룹의 엔지니어링 매니저로서 Bill One 전체의 개발 생산성 향상을 이끌고 있습니다.

팀 자율성을 유지하며 리드타임을 1/3로 단축한 Sansan의 개발 생산성 가시화 실천법

"만남에서 이노베이션을 창출한다"라는 미션을 바탕으로 일하는 방식을 바꾸는 DX 서비스를 제공하는 Sansan 주식회사. Sansan은 엔지니어링 조직의 개인 퍼포먼스 회고와 조직 과제 발굴에 엔지니어링 조직 지원 클라우드 'Findy Team+'를 활용하고 있습니다.

이번 인터뷰에서는 Sansan 주식회사 기술본부 Bill One Engineering Unit(이하 BOEU) Core Business AP 그룹의 엔지니어링 매니저 카와모토 켄지 님을 만났습니다. 개발 생산성 측정을 위해 Findy Team+를 도입한 이유와 운영 방식, 도입 후 나타난 변화에 대해 이야기를 나누었습니다.

글로벌 테크 컴퍼니를 지향하는 Sansan

――Sansan의 조직 규모와 기술본부 체제에 대해 소개 부탁드립니다.

카와모토: 기술본부는 약 500명 규모입니다. 'Sansan Engineering Unit'과 'Bill One Engineering Unit(BOEU)'을 포함해 프로덕트 기준으로 여러 유닛이 나누어져 있습니다.

――현재 속해 계신 유닛은 어떤 역할을 하나요?

카와모토: 저는 인보이스 관리 서비스 'Bill One' 개발을 담당하는 BOEU에서 엔지니어링 매니저를 맡고 있습니다. Bill One은 우편이나 이메일로 수령하는 청구서를 디지털화하여 클라우드에서 일괄 관리할 수 있는 서비스입니다. 일본의 인보이스 제도와 전자장부보존법에 대응하며, 월차 결산 업무를 효율화해 기업 경영진의 의사결정 속도를 높여줍니다.

――기술본부가 가진 핵심 미션은 무엇인가요?

카와모토: Sansan은 글로벌 테크 컴퍼니를 목표로 하고 있습니다. Bill One 역시 싱가포르와 태국을 시작으로 글로벌 진출을 추진 중입니다. 지난 기수(17기) OKR 목표 중 하나가 '생산량 2배 달성'이었을 만큼, 이는 현재 기술본부의 가장 중요한 미션입니다.

개발 생산성 가시화를 위한 노력

――전사 차원에서 개발 생산성 측정을 시작하게 된 배경은 무엇인가요?

카와모토: 프로덕트와 엔지니어링 조직이 우상향하며 성장하고 있었지만, 개발 생산성을 정량적으로 파악하지 못해 성장세에 재현성이 있는지 확신할 수 없었습니다. 퍼포먼스를 시각화하고자 사내 지원자들을 중심으로 자체 도구를 개발하기 시작했습니다.

――자체 도구를 사용하던 중 Findy Team+에 관심을 갖게 된 계기가 있었나요?

카와모토: 자체 개발 도구의 기능을 지속해서 업데이트할 전담 부서가 없다 보니 사이드 프로젝트 수준의 개발에는 한계가 있었습니다. 현장 사용자의 피드백이 신속하게 반영되지 않아 사내 확산이 어려웠죠. Google이나 DORA 관련 라이브러리 활용도 검토했지만, 비용 대비 효율이 맞지 않아 일찍이 단념했습니다.

대안을 찾던 중 개발 생산성을 정량적으로 측정할 수 있는 Findy Team+를 선택하게 되었습니다. 우수한 UI/UX 디자인과 팀 및 구성원 간 비교 기능이 매력적이었습니다.

――Findy Team+ 도입 과정에서 사내 설득에 어려움은 없었나요?

카와모토: UI/UX가 뛰어나고 사용하기 편하다는 점이 큰 매력이었지만, 감성적인 이유만으로는 설득력이 부족했습니다. 사내 합의를 도출하려면 "개발 생산성을 얼마나 추구해야 ROI(투자 대비 효율)를 맞출 수 있는가"를 정량적으로 제시해야 했습니다.

자체 도구와의 차별점과 이점을 명확한 언어로 다듬어 ROI를 설명해야 했기에 시간이 다소 걸렸습니다. 이를 위해 자체 도구와 Findy Team+의 기능을 대조한 비교표를 작성하고, 현장 개발자 대상 설문조사 결과를 함께 제출했습니다. 트라이얼 기간 동안 조직 내 정착 가능성을 보여준 것은 물론, 리드타임을 약 1/3로 줄인 성과를 정량 수치로 증명한 것이 결정적이었습니다.

품질과 생산성을 타협하지 않는다

――Findy Team+ 도입 후 정한 측정 목표나 지향점은 무엇이었나요?

카와모토: 무리하게 수치 목표를 세우고 달성 여부에만 연연하지는 않았습니다. 목표치만 채우려는 '수치 왜곡(Goal Hacking)' 현상을 방지하기 위해서였습니다. 대신 "리뷰 시간이 지연되고 있지는 않은가?", "팀 내에서 특정인에게 리뷰 부하가 쏠리지 않는가?"처럼 퍼포먼스를 가시화하고 조직의 건강도를 점검하는 용도로 먼저 활용했습니다.

――BOEU는 바텀업(Bottom-up) 문화가 강한 조직으로 알려져 있습니다.

카와모토: 탑다운 방식으로 목표치를 제시하면 "왜 이 수치여야 하는가"에 대한 의문이 생겨 본질에서 벗어난 논쟁으로 흐르기 쉽습니다. 무엇보다 BOEU는 바텀업에 강점이 있는 조직이기에 팀의 자율성을 해치고 싶지 않았습니다. 개발 영역마다 맥락이 다르고 팀별로 지향하는 목표도 다릅니다. 저희는 프로덕트 개발과 사용자 가치 전달로 이어지는 흐름을 중요하게 생각하므로, 팀 간의 직접적인 비교도 가능한 한 지양했습니다.

――실천 과정에서 어려웠던 점과 이를 극복한 방법이 궁금합니다.

카와모토: OKR과의 상관관계를 정립하는 일이 쉽지 않았습니다. '레벨 1: 작업량 중심의 생산성' 향상이 '레벨 2: 기대 부가가치 생산성'으로 어떻게 이어지는지 연관성을 입증하는 것은 난제였고, 지금도 고민하는 지점입니다.

저희는 일정 기간 내에 리드타임을 줄여 빠르게 연속 연출·배포하면 산출물(Output)이 늘어날 것이라는 가설을 세웠습니다. 이에 따라 가장 작은 단위인 풀 리퀘스트(PR)와 그다음 단위인 프로덕트 백로그 아이템(PBI)에 주목했습니다.

우선 레벨 1과 레벨 2 관점에서 리드타임 단축을 추진했습니다. 이후 우리가 진짜 이루고자 하는 바를 다시 논의한 끝에 핵심은 '고객에게 전달하는 가치량의 증가'라는 점을 깨달았습니다. 자연스럽게 최종 산출물 양을 늘리는 방향으로 포커스를 전환했습니다.

――산출물 증대가 까다로운 개발 영역이나 과제에서는 어떻게 합의를 도출했나요?

카와모토: 요소들을 상충 관계(Trade-off)로 보지 않는 자세가 중요합니다. 예를 들어 품질과 개발 생산성은 서로 대립하는 것처럼 보이기 쉽습니다. 생산성 향상에만 치우치면 버그나 인시던트가 늘어나 결국 사용자 가치 전달 속도와 프로덕트 만족도를 떨어뜨립니다.

또한 미팅이 많다고 해서 무조건 없애는 것도 정답은 아닙니다. 지식과 경험의 공유는 조직 문화로서 중요한 가치를 지니므로, 동기부여와 관련된 문화적 요소는 과도하게 깎아내리지 않았습니다. 수치로 드러나지 않는 구성원의 웰빙 영역까지 고려하며 적절한 균형점을 찾고자 했습니다.

병합된 풀 리퀘스트 수 약 1.3배 증가, 리드타임은 약 1/3로 단축

――Findy Team+ 도입 이후 개선된 구체적인 성과는 무엇인가요?

카와모토: 스프린트 회고 시 팀 퍼포먼스를 명확히 점검할 수 있는 투명한 점검·피드백 사이클이 구축되었습니다. "이번 스프린트는 왜 잘 되었는가?", "지금 왜 벨로시티(개발 속도)가 떨어졌는가?"와 같은 의문에 대해 퍼포먼스를 명확한 언어로 설명할 수 있게 되었습니다.

병목 구간이 시각화되면서 매니저로서 어디에 집중해야 할지 명확해진 점도 큰 변화입니다. 이전에는 다음 액션이 모호해 막막한 느낌이 있었지만, 데이터 인사이트를 얻게 되면서 명확한 액션 플랜으로 연결하기가 훨씬 수월해졌습니다.

――앞으로 새롭게 시도하고 싶은 부분이 있다면 무엇인가요?

카와모토: 풀 리퀘스트 생성에 대한 가이드라인을 수립했는데, 지속해서 준수하지 않으면 형해화되기 쉽습니다. 따라서 이 부분이 잘 지켜지고 있는지 꾸준히 모니터링할 계획입니다.

――개발 생산성 가시화를 거치며 조직과 구성원의 의식, 행동에는 어떤 변화가 있었나요?

카와모토: 전에는 정성적인 문장으로만 비포&애프터를 설명하곤 했습니다. 하지만 Findy Team+를 도입한 후에는 성과에 대해 자연스럽게 정량 데이터를 기반으로 대화하는 문화가 정착되었습니다.

예를 들어 구성원들은 '바텀업+탑다운' 관점에서 성과를 명확히 정의하거나 목표를 설정할 때 Findy Team+를 활용하며, "변화 결과를 정량적으로 측정할 수 있다"라는 대화가 자연스럽게 오고 갑니다. 개인의 성과가 팀에 어떻게 기여하는지 눈으로 확인되면서 BOEU 내부에서도 깊이 정착되었습니다.

――지표 측면에서는 어떤 변화가 있었나요?

카와모토: 프로젝트를 추진한 결과, 개발 생산성 레벨 2에 해당하는 PBI 처리량이 1년 만에 2배로 증가했습니다. Findy Team+ 데이터에서도 PBI 증가에 따라 병합된 PR 수가 약 1.3배 증가했고, 리드타임은 약 1/3 수준으로 단축되었습니다.

자율적으로 일하는 팀이 만드는 강한 조직

――향후 개발 생산성 측정 및 Findy Team+ 활용에 대한 비전이 궁금합니다.

카와모토: 조직 내 팀 개편이 유연하게 이루어지는 편이라, 새로운 팀이 빌딩될 때 드는 초기 비용을 줄이고 그동안 퍼포먼스 분석이 어려웠던 해외 개발 팀의 생산성 가시화도 추진할 계획입니다. 또한 퍼포먼스 분석과 연동해 "충분한 개발 시간이 확보되어 있는가"를 정량적으로 검증할 수 있는 미팅 분석 기능도 적극 활용하고자 합니다. 다만 개발 중심인 해외 팀의 경우 미팅이 병목이 되는 경우는 거의 없을 것으로 보고 있습니다.

――마지막으로 Sansan 개발 조직의 매력을 소개해 주세요.

카와모토: Sansan은 Findy Team+뿐만 아니라 ROI를 입증할 수 있고 개발자 경험(DX)을 높여주는 도구라면 언제든 적극적으로 도입할 수 있는 환경을 갖추고 있습니다. Copilot, ChatGPT 등도 신청하면 즉시 계정을 제공합니다. 큰 틀의 방향성은 탑다운으로 제시되지만, 팀의 자율성을 존중하는 바텀업 문화를 매우 중요하게 여깁니다. 이러한 문화가 Findy Team+를 통한 성공적인 개선으로 이어졌다고 생각합니다.

"자율적으로 일하는 팀이 퍼포먼스도 높으며, 그 합이 모여 강한 조직을 만든다"라는 신념을 앞으로도 지켜나가고 싶습니다. 이를 위해 채용과 육성에 끊임없이 공을 들이고 있습니다. 팀의 높은 자율성을 바탕으로 주도적으로 일하는 문화에 공감하는 분들에게 Sansan은 매우 매력적인 터전이 될 것입니다. 관심 있는 분들의 많은 지원을 기다립니다.

신입 개발자가 자율적으로 성장하는 환경의 구축 | Findy Team+

Findy Team+ — Thu, 29 Oct 2026 02:43:46 GMT

아사히신문사에서는 개발 생산성 시각화를 통한 조직 개선을 추진하고 있습니다. AI 전략 지원 SaaS 'Findy Team+'를 활용해 개인 성장을 가시화하고, 팀 내 회고와 대화 문화를 조성하고 있습니다.

이번 인터뷰에서는 아사히신문사에 신입 엔지니어로 입사해 디지털판 뉴스 개발을 담당하고 있는 에나미 준스케 님, 카토 카즈키 님을 모시고 Findy Team+ 활용 사례와 시각화를 통해 얻은 인사이트, 향후 전망에 대한 이야기를 들어보았습니다.

다양한 직군이 협업하는 스크럼 체계와 신입부터 성과를 내는 커리어 패스

── 담당 조직과 팀에 대해 소개 부탁드립니다.

에나미: 제가 속한 팀은 총 7명으로, PdM 2명과 엔지니어 5명으로 구성되어 있습니다. 매일 데일리 스크럼을 진행하며 개발을 추진하고 있어요. 주로 디지털판 뉴스기사를 송고하는 'Plasma'라는 시스템을 담당하며, 결제 관련 기능의 안정적인 운영과 성능 개선, 사용자 경험 향상을 목표로 작업하고 있습니다.

── 카토 님의 팀은 어떻게 구성되어 있나요?

카토: 제가 속한 조직은 아사히신문 디지털 앱 리뉴얼을 담당하는 팀으로, 전체 인원은 약 25명 규모입니다. 제 팀은 그중 하나로 10여 명 정도예요. PdM, 디자이너, 프론트엔드, 백엔드, 인프라, 클라이언트 엔지니어 등 다양한 역할의 팀원들이 협업하며 프로젝트를 진행하고 있습니다.

── 두 분의 커리어에 대해서도 말씀해 주세요.

에나미: 컴퓨터공학을 전공하고 신입으로 입사해 현재 3년 차입니다. 구직 활동 당시 사람들과의 합을 중요하게 생각했는데, 아사히신문사 면접 과정에서 "이 사람들과 함께 일하고 싶다"는 확신이 들어 입사를 결정했습니다. 지금은 엔지니어로서 주로 PdM이 정의한 요구사항에 맞춰 구현을 담당하고 있습니다.

카토: 물리학을 전공하며 양자역학 등을 연구했기 때문에, 입사 당시 기술 경험은 거의 Zero에 가까웠습니다. 입사 후 첫 6개월 동안은 프론트엔드를 담당했고, 이후에는 PdM에 가까운 역할로 소규모 프로젝트를 진행했습니다. 현재는 백엔드와 인프라 업무를 중심으로 다루고 있으며, 향후 제품 전체에 책임감을 갖고 기여하는 '프로덕트 엔지니어'로 성장하는 것이 목표입니다.

지표와 마주하는 것이 성장의 출발점: 선배와의 차이를 파악하고 행동을 바꾼 신입 엔지니어의 변화

── 개발 생산성을 측정하게 된 계기는 무엇인가요?

에나미: 입사 후 제 성장을 객관적으로 확인하고 싶어 개발 생산성을 KPI로 설정했습니다. 다만 당시에는 스스로 무엇이 부족한지 감으로만 느낄 뿐이었기에, 선배 엔지니어들과의 차이를 정량적으로 파악해보고 싶었던 것이 가장 큰 계기였습니다.

── Findy Team+ 도입 이후 업무에 어떤 변화가 있었나요?

에나미: 먼저 제 작업 방식에 큰 변화가 생겼습니다. Findy Team+로 가시화된 수치를 통해 제 개발 프로세스를 객관적으로 돌아보기 시작했죠.

처음 데이터를 확인했을 때는 솔직히 '외면하고 싶다'는 생각이 들었습니다. 특히 롤모델로 삼던 선배의 지표와 비교했을 때, 같은 시간을 근무하더라도 아웃풋의 양과 질에서 현격한 차이가 났거든요.

예를 들어 어떤 주에는 제가 40건 가까이 커밋을 올린 반면, 선배는 10건 안팎에 불과했습니다. 그럼에도 선배가 작성한 PR의 품질이 훨씬 높았고, 훨씬 안정적으로 배포하고 있었습니다.

에나미: 이를 확인한 뒤부터는 코드에 손을 대기 전에 구현 방침을 철저히 정립하는 습관을 들였습니다. 착오로 인한 불필요한 커밋이 줄어들면서 PR 1개당 커밋 수가 약 3분의 1 수준으로 줄었습니다. 업무에도 차츰 여유가 생겼고, 리뷰 참여 빈도도 높아졌습니다.

── 카토 님의 팀에서는 어떤 변화를 체감하셨나요?

카토: 저희 팀은 이터레이션마다 진행하는 레트로스펙티브(회고)에서 Findy Team+를 활용하고 있습니다. 주로 다음 세 가지 관점을 모니터링합니다.

DevOps 분석: 지속적이고 안정적으로 리리스가 이루어지는가
팀 요약: PR 병목 구간 파악
리뷰 산점도: 차이(Diff) 크기 및 PR 편중 현상 시각화

한 스프린트에서는 2,000줄이 넘는 PR이 특정 에픽에 집중된 것을 발견했습니다. "스토리 분할이 미흡했던 것은 아닐까?"라는 가설을 세웠고, 다음 스프린트에서 바로 개선 조치를 취했습니다.

지표는 '평가'가 아닌 '대화의 물꼬': 개인과 팀의 긍정적 변화를 만든 시각화 활용법

── 팀 내에 지표를 공유할 때 반발이나 부담감은 없었나요?

카토: 전혀 걱정할 필요가 없었습니다. 처음 데이터를 공유할 때 "어떤 지표를 참고하고, 어떤 지표는 과도하게 해석하지 않을 것인가"에 대해 팀원들과 충분히 이야기를 나누었거든요. 예컨대 개인별 리드타임 같은 지표는 무리하게 추적하지 말자는 공감대가 자연스럽게 형성되었습니다.

개인을 평가하기 위한 목적이 아니라, 팀 전체의 개선 포인트를 찾기 위한 힌트로 활용한다는 전제가 확립되어 있었기에 대화도 건설적인 방향으로 흐를 수 있었습니다.

── 지표에 지나치게 매여 오히려 업무가 경직될 우려는 없었나요?

카토: 그 부분은 항상 경계하고 있습니다. '개발 생산성 콘퍼런스(開発生産性Conference)'에서 넷플릭스 관계자분이 언급했던 "지표를 과대평가하지 않는다"는 관점이 매우 인상 깊었습니다.

Findy Team+에서 측정되는 지표는 어디까지나 '아웃풋(Output)'이므로, 이것이 실제 '아웃컴(Outcome)'으로 이어지고 있는지 지속적으로 점검합니다. 단순히 수치를 열거하는 것에 그치지 않고, 그 데이터에서 무엇을 배울 수 있는가에 집중하고 있습니다.

── Findy Team+ 데이터를 접하면서 마인드나 행동에 또 어떤 변화가 있었나요?

에나미: 매우 큰 변화가 있었습니다. 특히 입사 초기에는 주변 선배들과 비교해 '내 생산성은 과연 괜찮은 걸까?' 하는 막연한 불안감이 있었습니다. Team+에서 선배들의 수치를 실제로 확인했을 때는 다소 충격을 받기도 했습니다. 동일한 시간을 투입하는데도 아웃풋의 양과 질이 판이하게 달랐으니까요.

하지만 이를 계기로 "무엇이 이 차이를 만드는가?"에 대한 깊은 내성이 시작되었습니다. 선배들은 커밋 수가 적지만 PR의 완성도가 높아 단번에 머지되는 반면, 저는 시착오가 많아 불필요한 커밋을 남기고 있었습니다. 작업에 착수하기 전 단계에서의 설계력과 방향성의 정교함이 달랐던 것이죠.

── 이후 구체적으로 어떤 방식을 도입하셨나요?

에나미: 우선 구현을 시작하기 전, 작업 방향을 글이나 메모로 구체화해 정리하는 과정을 거쳤습니다. 이 간단한 과정만으로도 불필요한 커밋이 대폭 감소했습니다.

또한 리뷰 과정에서 지적받기 쉬운 포인트를 미리 고민해 보게 되면서 리뷰 프로세스 자체도 한결 매끄러워졌습니다. 현재는 PR당 커밋 수가 확연히 줄었고, 머지까지 걸리는 시간도 크게 단축되었습니다.

선배를 벤치마킹하며 나만의 스타일 구축하기: 데이터와 대화를 기반으로 성장을 가속한 실천 사례

── 선배 엔지니어들로부터 노하우를 배우는 과정은 어떻게 이루어졌나요?

에나미: 처음에는 타 팀 선배들에게 찾아가 질문하는 것조차 큰 용기가 필요했습니다.하지만 용기를 내어 다가가 보니 "오히려 먼저 물어봐 주어서 고맙다"는 친절한 반응이 돌아왔습니다. 정말 감사한 일이었죠.

그 이후로는 정기적으로 조언을 구하며, "이분은 어떻게 아웃풋을 일정하게 유지할 수 있을까?"를 모니터링하고 벤치마킹했습니다. 내성과 관찰, 그리고 모방을 반복하는 과정에서 자연스럽게 저만의 작업 방식이 자리 잡게 되었습니다.

카토: 저의 경우 Findy Team+ 데이터를 개인적 차원에 머무르게 하지 않고, 팀 전체와 공유하며 회고하는 프로세스를 구축했습니다. 특히 레트로스펙티브 시점에는 "PR이 지연된 원인은 무엇인가", "리리스가 특정 시점에 몰린 이유는 무엇인가"와 같이 현상의 원인을 분석하고 개선안(Try)을 함께 도출하는 문화를 형성하고자 노력했습니다.

── 그 과정에서 특별히 유의했던 점이 있다면 무엇인가요?

카토: 가장 중요한 점은 '지표를 위한 지표로 취급하지 않는 것'이었습니다. 지표에 과도하게 매몰되면 자칫 개인을 압박하는 분위기가 조성될 수 있습니다. 따라서 데이터를 어디까지나 "변화의 징후를 감지하는 힌트"로 활용하고자 했습니다.

예를 들어 특정 에픽에서 PR 차이가 비정상적으로 커진 경우, "스토리 분할 단위가 적절하지 않았을 수 있겠네요." "이 시점에 요구사항이 변경되어 일정이 지연된 것 같습니다." 와 같이 지표 배경에 있는 실질적인 원인을 팀 전체가 함께 고민하도록 유도하고 있습니다.

── 데이터에 직면하는 과정에서 불안감은 없었나요?

카토: 최초 도입 단계에서 "어떤 지표를 중점적으로 보고, 어떤 지표는 과도하게 의미 부여하지 않을 것인가"에 대한 팀 내 합의를 미리 마쳤던 점이 큰 힘이 되었습니다. 덕분에 불안감 없이 지표를 수용할 수 있었고, 조직을 다듬어가는 긍정적인 도구로 활용하고 있습니다.

시선은 '나'에서 '팀'으로: 지표를 바탕으로 조직 전체 개선에 도전하는 차세대 엔지니어의 인식 변화

── 향후 도전하고 싶은 목표가 있다면 말씀해 주세요.

에나미: 팀의 리드타임과 생산성 스코어를 지속적으로 트래킹하며, 조직의 개선을 선도하는 리더로 성장하고 싶습니다.

최근 업무에 여유가 생기면서 개인의 생산성을 넘어 팀 전체의 역량에 눈을 돌리게 되었습니다. 후배들도 새로 입사한 만큼, 그동안 축적한 경험과 시행착오를 팀에 효과적으로 공유하고 싶습니다.

── 개인 기여자(Player)에서 팀 전체를 이끄는 역할로 시야가 확장된 셈이군요.

에나미: 그렇습니다. 초기에는 눈앞의 코드를 작성하는 것만으로도 여력이 없었지만, Findy Team+를 통해 주요 지표를 시각적으로 확인하게 되면서 제 행동이 팀 전체에 미치는 영향을 고찰하게 되었습니다.
그렇기에 앞으로는 팀 단위의 퍼포먼스 향상에 적극적으로 기여해 보고 싶습니다.

카토: 현재 가장 집중하고 있는 과제는 '팀 전체 관점에서 건강하고 효율적인 리뷰 프로세스를 정립하는 것'입니다. 현재는 제 코드 리뷰가 특정 선배 엔지니어 1명에게 편중되어 있어 병목 및 속인화 위험이 존재하는 상황입니다. 해당 구성원이 휴가를 가거나 자리를 비울 때 리뷰가 적체되는 현상이 발생하곤 하죠.

'누구나 부담 없이 리뷰할 수 있는' 조직으로: 문화와 시스템 양날개로 유연한 팀을 만들고자 하는 바람과 동료에 대한 기대

── 어떤 방향으로 개선을 추진하고자 하시나요?

카토: SES(외주 개발) 파트너분들이나 타 팀 멤버들에게도 리뷰 담당 범위를 확장하고자 합니다. 누구나 리뷰에 참여할 수 있도록 하려면 지식 공유와 가이드라인 정립이 선행되어야 하겠지만, 장기적으로는 '누구나 부담 없이 리뷰에 참여할 수 있는 환경'을 조성하는 것이 조직의 유연성을 확보하는 지름길이라고 생각합니다.

── 두 분이 생각하는 '함께 일하고 싶은 엔지니어'의 모습은 무엇인가요?

에나미: 기술적 역량도 중요하지만, 그보다 '함께 일할 때 소통이 원활하고 편안한 사람'이면 좋겠습니다. 저희 팀은 분위기가 매우 좋고, 질문이나 상의를 주저 없이 할 수 있는 따뜻한 동료들로 구성되어 있습니다. 그렇기에 기술력 이상으로 팀 문화에 잘융화될 수 있는 인성을 중요한 요소로 봅니다.

카토: 저 역시 비슷한 의견입니다. 특히 '겸손함'과 '상대방을 존중하는 태도'를 갖춘 분과 함께 일하고 싶습니다.

회사 내에 존경할 만한 선배 엔지니어분들이 많이 계신데, 실력이 뛰어날수록 동료들을 대할 때 더욱 정중하고 배려심 깊은 모습을 보여주십니다. 이러한 인품과 태도가 팀 전체에 긍정적인 에너지를 공급한다고 믿습니다.

── 마지막으로 이 글을 읽고 계신 분들께 한 말씀 부탁드립니다.

카토: Findy Team+를 활용하면 객관적인 지표를 통해 팀과 개인의 현주소를 정확히 파악하고, 개선을 위한 실질적인 힌트를 얻을 수 있습니다. 이러한 데이터를 팀 내에서 건설적이고 긍정적으로 소화할 수 있는 문화가 조성되어 있다는 점이 저희 아사히신문사 개발 조직의 큰 강점입니다.

에나미: 신입 시절부터 개발 생산성이라는 쉽지 않은 주제를 다뤄왔지만, Findy Team+ 덕분에 제 성장의 궤적을 객관적으로 관찰할 수 있었습니다. 도입을 고민 중인 조직이나 엔지니어가 있다면, 개인의 회고와 성장에 큰 도움이 되는 도구라고 꼭 추천해 드리고 싶습니다.

문화가 지표를 움직인다: ‘인성’ 중심 채용으로 시작된 Recustomer의 고생산성 조직 구축법 | Findy Team+

Findy Team+ — Thu, 29 Oct 2026 02:43:36 GMT

「배포 빈도 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)이나 단축키에 대한 대화가 일상적으로 오갈 정도로 전반적인 작업 효율의 평균치가 높습니다. 엔지니어 간의 소통이 매우 활발하고, 기술 콘퍼런스 발표나 대외 발신도 당연하게 여기는 분위기입니다. 덕분에 새로 합류하는 멤버들도 자연스럽게 이러한 조직 문화에 스며들 수 있는 최적의 환경이 조성되어 있다고 자부합니다.

빠른 실험과 학습으로 가설 검증 속도를 높이다 - Skill note | Findy Team+

Findy Team+ — Thu, 29 Oct 2026 02:42:41 GMT

기사 내용 요약

도입 전: 해결하고자 했던 과제

개발 속도와 품질을 모두 충족시키면서 업무의 사람 의존성과 지표 부재를 해소하고, 경영진에게 설명할 수 있는 정량적 데이터를 확보하고자 했다.

Findy Team+를 도입한 이유

수작업 집계의 한계에 도달했고 GitHub 연동만으로 Four Keys가 자동으로 시각화되며, 팀에서도 즉시 활용할 수 있었기 때문이다.

도입을 결정한 이유

설정은 몇 번의 클릭으로 가능하고 UI는 직관적이며 비용은 최소 수준. 그럼에도 불구하고 개발자·매니저·경영진이 동일한 화면을 보며 대화할 수 있는 실용성이 결정적인 요인이었다.

도입 후: 성과

회고의 질이 향상되고 팀의 자율 운영이 실현되었으며, 리뷰 리드 타임이 단축되고 ‘하루 1PR’ 문화가 정착되었다.

경영 판단에도 기여하는 개발 생산성의 가시화. Skillnote의 실천 사례는?

제조업을 위한 인재 육성 및 스킬 관리의 DX(디지털 전환)를 지원하는 클라우드 서비스 ‘Skillnote’를 제공하는 주식회사 Skillnote. 동사는 개발 생산성의 가시화 및 개선을 목적으로 ‘Findy Team+’를 도입하였으며, 팀의 인식 변화와 리드 타임 단축 등 정성적·정량적 측면 모두에서 성과를 내고 있습니다.

이번에는 VPoE인 안도 다이스케(安藤大輔)님에게 Findy Team+ 도입 배경과 현장의 활용 방법, 그리고 ‘자율적인 조직 만들기’를 향한 비전에 대해 이야기를 들었습니다.

제조업 현장의 과제에 밀착한 SaaS ‘Skillnote’를 전개

─ 우선 귀사의 사업과 개발 조직에 대해 소개해 주세요.

Ando：주식회사 Skillnote는 ‘만드는 사람이 주체가 되는 세상으로’라는 비전을 바탕으로, 제조업을 위한 스킬 관리 및 교육 클라우드 ‘Skillnote’를 개발·제공하고 있습니다. 제조 현장에서 요구되는 스킬을 ‘가시화’하고, 육성 계획 책정부터 실천까지 지원함으로써 업무 품질 향상과 조직 역량 강화를 지원하고 있습니다.

─ 제조업 인재 육성에 초점을 맞춘 SaaS라는 점이 인상적이네요.

Ando：감사합니다. 제조업 현장에서는 숙련 기술이나 지식의 계승이 개인 의존적인 경우가 많고, 특히 베테랑 퇴직이나 신입 직원의 이탈 문제가 큰 과제로 여겨지고 있습니다. Skillnote는 ‘누가 어떤 스킬을 갖고 있는가’, ‘다음에 어떤 스킬을 습득해야 하는가’ 등의 정보를 일원화하여 관리하고, 체계적으로 육성을 진행할 수 있도록 돕고 있습니다.

─ 개발 조직에 대해서도 말씀해 주시겠어요?

Ando：PdM, 엔지니어, 디자이너, QA 등 다양한 역할의 멤버가 소속되어 있습니다. 전원이 하이브리드 또는 풀리모트로 근무하고 있으며, Slack, Notion, GitHub 등을 활용하여 일상적인 커뮤니케이션과 협업을 진행하고 있습니다.

─ 온라인 중심의 개발 체제군요. 조직 문화 측면에서 중요하게 생각하시는 점은 무엇인가요?

Ando：속도감과 유연성은 물론이고 지식 공유와 회고의 문화도 매우 중요하게 생각하고 있습니다. 회고에서는 업무의 개선점을 팀 전체가 함께 도출할 뿐 아니라, 서로에게 감사를 전하는 시간도 마련하고 있습니다. 자율적인 멤버들이 서로를 존중하며 일할 수 있는 환경을 추구하고 있습니다.

수작업 집계에서 탈각. Four Keys 가시화의 결정타는 '사용 편의성’

─ 개발 생산성 가시화에 착수하게 된 배경과 Findy Team+를 도입하게 된 이유를 알려주세요.

Ando：Skillnote는 사회 인프라에 가까운 현장에서 사용되는 제품입니다. 그렇기 때문에 ‘멈추지 않도록’, ‘망가지지 않도록’ 하는 것이 매우 중요합니다. 품질과 안정적인 운영 확보는 필수적이지만, 동시에 속도감 있는 개발도 요구되고 있습니다.

─ 품질과 속도의 양립은 쉽지 않죠.

Ando：정말 그렇습니다. 그래서 저희 스스로도 “우리는 어느 정도의 속도로, 얼마나 안정적으로 개발하고 있는가?”라는 질문에 대해 정량적으로 답할 수 있어야겠다고 생각하게 되었습니다. 이것이 바로 개발 생산성 가시화에 착수하게 된 계기였습니다.

─ 처음부터 툴 도입을 고려하셨던 건가요?

Ando：아니요, 처음에는 스프레드시트를 사용해서 GitHub 데이터를 수작업으로 집계하고 있었습니다. 그러나 운영의 수고가 너무 커서 지속적으로 데이터를 확인하기가 어려웠습니다. 그래서 업계 표준 지표인 ‘Four Keys’를 기반으로 데이터를 자동 시각화할 수 있는 시스템이 필요하다고 느꼈습니다.

─ 그런 가운데 Findy Team+에 주목하신 이유는 무엇이었나요?

Ando：결정적인 이유는 개발 팀을 위해 최적화되어 있었고, 도입 장벽이 낮았다는 점입니다. GitHub와 연동만 하면 Four Keys가 자동으로 가시화되는 기능은 정말 편리했습니다. 또한, 개발 팀 누구나 “이건 써보고 싶다”라고 느낄 만큼 UI가 직관적이라는 점도 크게 작용했습니다.

─ 개발 팀이 자율적으로 활용할 수 있는 도구라는 점도 포인트였군요.

Ando：맞습니다. 개발 생산성의 가시화는 ‘보는 것’이 목적이 아니라, 그것을 ‘어떻게 활용할 것인가’가 핵심이라고 생각합니다. 그래서 개발 멤버들이 자연스럽게 일상 활동 속에 녹여낼 수 있는 툴인지 여부를 가장 중요하게 보았습니다.

Findy Team+로 변화한 회고 문화. 자율적으로 움직이는 팀을 만드는 법

─ Findy Team+를 도입한 이후, 구체적으로 어떻게 활용되어 왔나요?

Ando：가장 먼저 절감한 것은 “수치를 보는 것만으로는 행동이 바뀌지 않는다”는 사실이었습니다. 툴을 도입해도 ‘아무도 보지 않는다’, ‘아무도 사용하지 않는다’면 의미가 없습니다. 그래서 우선 저 자신이 매일 대시보드를 꼼꼼히 살펴보면서 어떤 지표가 어떻게 변화하는지, 릴리스와 어떤 상관관계가 있는지를 꾸준히 관찰했습니다.

─ 정량적인 변화나 툴 활용 방식에 어떤 확장이 있었나요?

Ando：지금은 대시보드가 일상적으로 활용되고 있습니다. 개인 활동뿐 아니라 팀 전체의 상태, 스프린트별 리뷰 리드 타임이나 PR 수의 변화까지 시각화되어 회고 시 중요한 자료로 자리 잡았습니다.

또한 Four Keys의 변화뿐만 아니라, SPACE, SLO(서비스 수준 목표), 견적 오차 등의 데이터도 비즈니스 측이나 경영진에게 설명할 때 적극 활용하고 있습니다.

도입 전에는 “진행이 늦어지는 이유”를 정성적으로밖에 설명할 수 없었지만, 이제는 “이 시기에 리뷰가 지연되었다”, “여기서 머지가 집중되었다”는 식의 구체적인 근거를 바탕으로 설명할 수 있게 되었습니다.

─ 팀이 ‘가시화’를 스스로의 무기로 삼은 인상이네요.

Ando：정확히 그런 느낌입니다. 지금은 팀 내에서 ‘과제를 발견하고 가설을 세워 개선한다’는 사이클이 정착되어 매니저에게 의존하지 않고 멤버 스스로가 움직이는 문화가 자리잡고 있습니다. 이제야 자신들의 수치에 자연스럽게 관심을 갖고, 회고하고, 개선을 고민하는—그런 ‘자율적인 조직’으로 변화하고 있다는 걸 실감하고 있습니다. 이것은 Findy Team+를 통해 얻은 매우 큰 성과라고 생각합니다.

숫자를 ‘지적’에 사용하지 않는다. 신뢰와 자율을 키우는 정착 접근법

─ 도입부터 정착까지 순조로워 보이는데, 어려움을 느끼신 순간도 있었나요?

Ando：네, 물론 있었습니다. 역시 첫 번째 장벽은 “보이게 되었다고 해서, 반드시 보게 되는 것은 아니다”라는 점이었습니다. 툴에 수치가 표시되어 있어도 일상 업무에 치이다 보면 자연스럽게 관심이 멀어지게 됩니다. 초기에는 “이건 내가 먼저 제대로 써보는 수밖에 없다”라고 결심하고, 저 스스로가 Four Keys 데이터를 읽고, 관찰하고, 가설을 세우고 행동으로 옮기려 노력했습니다.

── 멤버를 어떻게 참여시켜 나가셨나요?

Ando：단순히 숫자를 보며 지적하는 것이 아니라, “이 PR, 요즘 리뷰에 조금 시간이 걸리는 것 같던데 혹시 신경 쓰이는 부분 있어요?”처럼, 일상적인 PR이나 대화 흐름 속에서 자연스럽게 질문을 던졌습니다. 정성적인 정보와 수치를 함께 바라보며 듣는 방식을 중요하게 생각했고, “이 수치가 나쁘니까 고쳐달라”는 식의 전달은 절대 하지 않았습니다.

─ 그런 접근 방식에 대한 멤버의 반응은 어땠나요?

Ando：솔직히 처음부터 긍정적이었습니다. Skillnote의 엔지니어들은 원래부터 “어떻게 하면 더 나아질 수 있을까”를 늘 고민하는 사람들입니다. 그래서 수치를 계기로 가설 검증 사이클이 돌아가기 시작하자, “이렇게 해보면 어떨까?”라는 제안이 자연스럽게 나오기 시작했습니다. 예를 들어, EM이 자발적으로 ‘하루 1PR’ 문화를 추진해 준 것도 그런 흐름의 일부였습니다.

─ 조직 전체적으로도 수치에 대한 거부감은 없었나요?

Ando：그 점도 저희가 신경 쓴 포인트입니다. 수치를 평가 지표로 삼지 않고, 어디까지나 회고와 개선을 위한 ‘힌트’로 활용한다는 태도를 철저히 유지했습니다. 그래서 “누가 지켜보고 있다”는 느낌이 아니라, “우리를 위해 우리가 본다”는 문화가 뿌리내렸다고 생각합니다. 정량 데이터에 지나치게 의존하지 않고, 정성적인 대화를 중심에 둔 정착 방식이 오히려 잘 맞았다고 느낍니다.

─ 각자가 납득하면서 참여할 수 있는 방식을 모색하신 거군요.

Ando：맞습니다. 그 결과, 정기적인 회고 자리에서도 Four Keys 대시보드를 자연스럽게 참고하게 되었고, “지난 스프린트보다 PR 수가 늘었네” 같은 대화가 팀 내에서 일상적으로 오가는 분위기가 생겨났습니다. 이러한 흐름이 지금의 ‘스스로 움직이는 팀’의 기반이 되었다고 생각합니다.

건강한 조직의 열쇠는 ‘가시화’와 ‘납득감’. 개선 문화를 넘어 그다음으로

─ 앞으로의 전망에 대해 말씀해 주세요.

Ando：앞으로는 지금보다 더 ‘자율적인 개선 사이클’을 스스로 돌릴 수 있는 팀을 만드는 데 속도를 내고 싶습니다. 이미 팀 내에서는 “다음엔 이 부분을 개선해보면 좋겠다”는 주제가 자연스럽게 생겨나는 분위기가 조성되고 있습니다. Findy Team+를 통해 얻은 데이터를 기반으로, 각자가 가설을 세우고 행동하며 회고하는 문화를 더 깊이 뿌리내리게 하고 싶습니다.

─ 자율적인 팀 문화 구축을 위한 시도가 차근차근 성과를 내고 있는 것 같습니다.

Ando：감사합니다. 만약 이런 시도를 하지 않았다면, 아마도 로드맵 지연이나 개인 의존적인 병목에 계속 시달리고 있었을 겁니다. “왜 일정이 늦어졌는가”, “어디에 과제가 있는가”라는 설명조차 하지 못한 채, 엔지니어 조직 전체가 소모되는 상태였을지도 모릅니다.

지금은 수치로 상황을 명확하게 설명할 수 있게 되었고, 모두가 납득하고 판단·개선에 참여할 수 있는 환경이 마련되었습니다. 그 결과, 스트레스에 강한 사람만 살아남는 조직이 아니라, 건강하게 성장할 수 있는 팀이 만들어지고 있다고 실감하고 있습니다.

생성형 AI도 아군으로. 현장 수준에서 진행되는 ‘자율적인 생산성 향상’

─ 개발 생산성의 가시화에 더해 생성형 AI의 활용도 진행 중이라고 들었습니다.

Ando：네, 생산성 향상의 또 다른 축으로 생성형 AI의 활용에도 적극적으로 임하고 있습니다. 처음 도입한 것은 GitHub Copilot이었고, 개인용으로 출시되었을 당시 제가 먼저 사용해 보며 “이건 어마어마한 생산성 향상을 가져오겠다”는 직감을 받았습니다. Organization 계정에서도 사용 가능해진 그날 바로 모든 엔지니어에게 도입을 전개했습니다.

─ 도입을 결정하게 된 핵심 요인은 무엇이었나요?

Ando：“먼저 도입하지 않으면 타사에 뒤처진다”는 강한 위기감이 있었습니다. 그동안 코딩 중에 고민하면서 검색하고 작성했던 작업들이 부드럽게 진행되면서, 엄청난 패러다임 전환이 느껴졌습니다.

─ 현재는 어떤 툴들을 활용하고 계신가요?

Ando：Devin, JetBrains AI Assistant(Junie) 같은 개발 보조 툴부터, Lovable, Dify 같은 노코드 툴까지 용도에 따라 다양한 생성형 AI를 검증하고 활용 중입니다. 그 외에도 ChatGPT Team plan, tl;dv, Atlassian Premium 등 개발 이외의 업무에도 생성형 AI를 도입하여 효율화를 진행하고 있습니다.

─ 현장에서의 활용 사례에 대해 말씀해 주세요.

Ando：현재는 주로 소규모 코딩 태스크, 테스트 설계, 인시던트 포스트모템, 신규 프로덕트의 프로토타이핑 등에 활용하고 있습니다. 생성된 코드도 리뷰만 거치면 바로 반영 가능한 수준인 경우도 많아 굉장히 큰 공수 절감 효과를 내고 있습니다.

─ 정성적인 성과는 이미 체감하고 계신가요?

Ando：네. 이른바 “레벨 1”의 생산성—현장 실감 기반의 효율 향상은 명확하게 느끼고 있습니다. 앞으로는 Findy Team+에서 가시화하고 있는 Four Keys 지표와 결합하여, AI 활용의 효과를 정량적으로도 검증해 보고자 합니다.

─ 향후 주목하고 계신 AI 기술이 있다면 알려 주세요.

Ando：Claude Code의 퍼포먼스가 매우 뛰어나서 현재 PoC 및 도입을 검토 중입니다. 생성형 AI는 나날이 진화하고 있기 때문에 도입 기술도 지속적으로 재검토하면서 ‘아웃컴의 변화’까지를 내다본 PDCA 사이클을 운영할 수 있도록 하고자 합니다.

기술로 제조업의 미래를 바꾼다. Skillnote가 그리는 도전과 동료에 대한 마음

─ Findy Team+의 추천 포인트를 알려주세요.

Ando：가장 큰 매력은 “생산성을 가시화함으로써 조직 내 대화의 질이 높아진다”는 점입니다. 수치가 보이게 되면 감각이나 인상에만 의존하지 않고 공통의 지표를 바탕으로 건설적인 논의가 가능해집니다.

예를 들어 “왜 개선이 필요한가?”, “어디에 과제가 있는가?”와 같은 논의를 감정적으로 흐르지 않게 진행할 수 있고, 다음 액션으로 자연스럽게 이어지기 쉬워집니다. 특히 소규모 팀에서는 한 사람 한 사람의 영향이 크기 때문에 판단이 정성적으로 흐르기 쉬운데, Four Keys 같은 정량적 데이터가 있으면 ‘어떻게 할 것인가’에 집중하는 전향적 논의가 가능해집니다.

─ 마지막으로, Skillnote의 매력과 함께 일하고 싶은 엔지니어상에 대해 알려주세요.

Ando：Skillnote는 “만드는 사람이 주체가 되는 세상으로”라는 비전을 바탕으로, 제조업이라는 거대한 산업의 변혁에 도전하고 있는 스타트업입니다. 겉보기에는 ‘화려함’이 없는 영역일 수도 있지만 사회적으로 큰 의미를 지닌 테마에 기술과 프로덕트로 정면으로 마주할 수 있는 환경입니다.

현장에서 실제로 사용되는 제품이기 때문에 사용 편의성과 신뢰성에도 강한 집착을 갖고 있습니다. 그런 현장의 과제에 공감하고 사용자에게 진심으로 마주하면서

“좋은 프로덕트를 만드는 것이 누군가의 삶을 더 좋게 만드는 일”이라고 믿고 행동할 수 있는 엔지니어와 함께 일하고 싶습니다.

Findy Team+를 활용한 지속적인 성장 문화 도입으로 리드타임 200% 단축 - SBINFT | Findy Team+

Findy Team+ — Thu, 29 Oct 2026 02:42:24 GMT

이 기사 내용 요약

도입 전: 해결하고자 했던 과제

애자일 개발의 회고와 KPT 등을 통해서는 조직 전체의 개선으로 이어지지 않았고, 릴리스 지연이나 개발 생산성의 가시화가 어려웠던 점이 과제였다.

Findy Team+를 도입한 이유

개발 활동을 직관적이고 정량적으로 시각화하고 엔지니어가 스스로 개선할 수 있는 환경을 만들기 위해, 간단하게 운영 가능한 Findy Team+에 매력을 느꼈기 때문이다.

도입을 결정한 계기

GitHub 및 Jira의 데이터를 직관적으로 시각화하고 1~3개의 화면만으로 상황을 파악할 수 있다는 점. 국산 도구로서 데이터 관리 측면에서도 안심할 수 있었던 점이 결정적이었다.

도입 후: 성과

PR 오픈부터 머지까지의 시간이 200% 감소되고, 변경 리드 타임도 200% 단축되었다. 공통 대시보드를 활용해 자율적인 자기 개선 문화가 조직에 정착되었다.

‘자기 개선’ 문화를 정착시켜 리드 타임을 200% 단축. SBINFT가 실천하는 데이터 기반 조직 구축법은?

블록체인 기술을 활용한 NFT 사업을 전개하는 SBINFT 주식회사는 엔지니어 조직 내에서 개발 생산성의 가시화와 멤버의 자기 개선을 추진하기 위해 엔지니어 조직 지원 클라우드 ‘Findy Team+’를 활용하고 있습니다. 본 기사에서는 도입 후 불과 수개월 만에 PR 오픈부터 머지까지 걸리는 시간을 200% 단축하고, 변경 리드 타임 역시 200% 단축한 실례에 대해 개발부장 히와타리(Hiwatari)님을 인터뷰했습니다. 엔지니어 조직의 개선에 고민 중인 분들을 위한 실천적인 힌트가 가득 담긴 내용입니다.

─ 귀사에 대해 소개해 주세요.

SBINFT 주식회사는 블록체인 기술을 활용하여 NFT(Non-Fungible Token)를 중심으로 한 디지털 자산 거래 플랫폼을 제공하고 있습니다. NFT 시장의 성장에 발맞추어 개인이나 기업이 안심하고 이용할 수 있는 거래 환경을 정비함으로써 디지털 콘텐츠의 새로운 가치 창출을 목표로 하고 있습니다. 개발부는 ‘SBINFT Market’이나 ‘SBINFT Mits’ 등의 제품 개발을 담당하고 있으며, 스마트 컨트랙트 개발과 기술 선정, 시스템 아키텍처 검토까지 폭넓게 대응하고 있습니다. 개발 부문 책임자로서 저는 COO와 협력하여 기술적 의사결정을 주도하고 있습니다. 영업 부서와 개발 부서 간의 거리가 가깝고, 엔지니어가 영업 회의에 참여하는 등, 사업과 개발이 긴밀하게 연계되는 문화가 정착되어 있는 것이 특징입니다.

─ 개발 조직에서는 어떤 미션을 내세우고 있나요?

저희 개발 조직이 내세우는 미션은 “실측값에 기반하여 수치를 개선할 수 있는 수단을 SBINFT에 제공하는 것”입니다. 이를 실현하기 위해 특히 중시하는 것은 예측 가능한 견적 산정과 개발의 실천입니다. 기존에는 데이터에 기반한 개발 정확도에 과제가 있었으며, 올바른 현황 파악을 통해 개선을 진행해 왔습니다. 개발부에서는 “릴리스 빈도가 높고 생산 능력이 높은 팀”을 목표로 하고 있습니다. 이를 위해 멤버가 자기 개선을 하기 쉬운 환경을 갖추고, 일상적인 개발 활동이 어떻게 조직의 성장으로 이어지는지를 가시화하는 데 주력하고 있습니다. 자율적으로 개선을 반복할 수 있는 문화를 정착시키고, 작은 변화를 쌓아가며 지속적인 성장을 실현하는 것이 목표입니다.

─ 개발 생산성 측정을 추진하고 도구를 도입하려고 한 계기는 무엇이었나요?

개발 생산성 측정을 시작하게 된 계기는 COO와의 대화 중 “좋은 엔지니어란 무엇인가?”라는 논의가 있었기 때문입니다. 엔지니어 평가 기준을 명확히 할 필요성을 느꼈고, 최종적으로 “릴리스를 많이 할 수 있는 엔지니어”를 평가 기준으로 설정하게 되었습니다. 이전에는 스토리 포인트나 티켓 소화 수로 확인하고 있었지만 이는 직관에 반하는 경우가 많았고, 엔지니어 본인도 납득하기 어려운 방식이었습니다. 그때 “내가 낸 아웃풋이 팀에 어떤 영향을 주었는가”를 가시화할 수 있는 지표가 필요하다고 강하게 느꼈습니다. 또한 회고나 KPT에서는 개인 수준의 개선에 그쳐 조직 전체의 성장으로 이어지기 어려운 과제도 있었습니다. 여러 개발이 병행되는 가운데, 모든 구성원이 아웃풋을 균등하게 측정하고 자율적으로 목표를 세워 개선할 수 있는 환경을 만들고 싶었습니다.

진행 정체의 원인을 특정, 정성적인 개선으로

─ Findy Team+ 도입 전의 과제는 무엇이었나요?

도입 전 가장 큰 과제는 개발 생산성을 객관적으로 가시화할 수 없었다는 점입니다. 애자일 개발의 회고나 KPT를 시행하고는 있었지만 개선이 개인 단위에 그쳐 팀 전체의 성장으로 이어지지 못했습니다. 또한 여러 개발 과제가 병행되는 경우, 진행 상황이나 병목의 위치가 파악되기 어려워 “어디서 작업이 정체되고 있는가”, “무엇이 지연의 원인인가”를 알기 힘든 상황이었습니다. 회고 시에도 과제가 추상적으로 흐르기 쉬워 실효성이 부족하다는 고민이 있었습니다. 더불어 엔지니어 평가에 있어서도 “무엇을 기준으로 좋은 엔지니어로 판단할 것인가”가 모호했고 정성적 평가에 의존하는 경우가 많아 현장과 경영진 사이에서 공통된 인식을 형성하기 어려웠던 것도 도입 전의 주요 과제 중 하나였습니다.

─ 그 과제를 어떻게 특정하셨나요?

과제를 특정하기 위해 먼저 Jira에서 티켓의 Open부터 Close까지 걸리는 시간을 측정하고, 각 멤버들이 어느 공정에서 막히고 있는지를 분석했습니다. 그러나 확인을 진행하는 가운데, 티켓이 완료되지 않는 이유가 단순한 지연만은 아니라는 점이 드러났습니다. 예를 들어, 어떤 멤버는 PR을 올리는 데 시간이 오래 걸렸고, 또 다른 멤버는 리뷰 지적이 많은 경향이 있었습니다. 더 나아가 “태스크의 목표가 불명확하다”, “리뷰 대기로 정체된다”, “PR 작성을 시작하지 못한다” 등 멤버마다 다른 요인이 있었고, 이것이 릴리스 지연의 원인이라는 사실이 밝혀졌습니다. 처음에는 Confluence나 Jira로 Try 항목을 관리했지만 실효성이 낮았고, 결과적으로 일상적인 업무 개선으로 이어지지 않았습니다. 1:1이나 회고 미팅을 거듭한 결과, 팀 차원에서 릴리스 지연의 병목을 특정하지 못하는 것이 최대의 과제임을 확인하게 되었습니다. 이후 “어느 단계에서 어느 정도 시간이 걸리고 있는가”를 한눈에 파악할 수 있는 도구의 필요성이 커졌고, 그 결과 Findy Team+ 도입으로 이어졌습니다. 수치로 경향을 파악할 수 있게 되면서 멤버 전원이 자신의 과제를 인식하고 개선을 위한 구체적인 행동으로 연결할 수 있게 되었습니다.

개인 개선에서 팀 전체의 성장으로. 리드 타임도 200% 단축

─ Findy Team+ 도입 이후의 변화에 대해 알려주세요.

Findy Team+ 도입 이후, 개발 생산성의 가시화가 크게 진전되었고 팀 전체의 인식과 행동에도 변화가 나타났습니다. 그동안은 모호했던 각자의 개발 활동을 수치로 확인할 수 있게 되어 멤버들이 자신의 퍼포먼스를 객관적으로 되돌아보는 습관이 자리 잡았습니다. 특히 효과를 실감한 부분은 1on1이나 팀 미팅에서 수치를 기반으로 구체적인 개선점을 논의할 수 있게 된 점입니다. 예를 들어 “왜 PR 머지까지 시간이 길어졌는가”, “무엇이 변경 코드 라인 수에 영향을 주었는가”와 같은 회고가 가능해져 행동과 결과가 연결되면서 구성원이 납득할 수 있게 되었습니다. 또한 PR 오픈부터 머지까지의 시간은 도입 전과 비교해 200% 감소했으며, 변경 리드 타임도 동일하게 200% 단축되었습니다. 이를 통해 릴리스 빈도가 증가하고 개발 사이클의 고속화에 성공하고 있습니다.

─ 왜 멤버/팀으로서 함께 대응할 필요가 있었는가요?

회고나 KPT를 도입하고는 있었지만, 개인 수준의 개선에 그쳐 팀 전체의 성장으로 이어지지 않는 점이 과제였습니다. 복수의 개발이 병행되면 서로의 상황을 파악하기 어려워지고, 회고도 개인 반성에 그치며 “○○을 못했다”는 과제가 남의 일처럼 받아들여지는 경향이 있었습니다. 또한 애자일 개발을 운영함에 있어 팀 목표가 모호하고 완료되지 못하는 상황이 계속되면, “회고에 시간 쓰느니 코드를 더 작성하는 게 낫지 않나?”라고 생각하는 멤버도 생겨났습니다. 이 상황을 개선하기 위해서는 정량 데이터를 기반으로 모두가 현황을 공유 인식하고, 팀 전체가 과제에 맞서야 할 필요가 있었습니다. 멤버로부터 “자기 개선을 하고 싶다”는 목소리는 있었지만, 그 실행을 가속화할 수 있는 구조가 부족했습니다. 정성적 논의만으로는 한계가 있었고, 수치 기반의 목표가 있다면 멤버 스스로 자율적인 개선이 가능할 것이라고 판단했습니다.

─ 개발 생산성의 가시화를 통해 조직·구성원의 인식 및 행동에 어떤 변화가 있었나요?

도입 초기에는 “도구를 쓰면 어떻게든 되겠지”라는 수동적인 자세도 보였습니다. 그러나 지금은 “내 수치가 올라간 이유, 혹은 떨어진 이유를 생각해보자”는 적극적인 인식으로 변화하고 있습니다. 1on1에서 수치를 확인하고 “왜 수치가 올랐다고 생각해?”, “개선을 위해 어떤 점을 의식했어?”라고 질문함으로써, 멤버들이 스스로 원인 분석을 하게 되었습니다. 이 프로세스가 정착되면서 자기 자신을 디버깅하는 감각이 길러졌고, 그 결과 “어떻게 하면 팀 전체의 생산성을 높일 수 있을까”를 고민하게 된 점은 매우 큰 변화입니다. 또한 예전에는 회고 시 “나는 이번에 뭐가 잘됐고, 뭐가 안 됐는가”와 같은 개인적인 회고가 중심이었지만 지금은 “팀으로서 어디를 개선해야 할까. 어떤 접근이 효과적일까”를 모두가 의식하게 되었습니다. 이러한 인식 변화는 멤버 간의 상호 지원이나 리뷰 개선으로도 이어지고 있으며, 조직으로서의 일체감이 높아졌다고 느끼고 있습니다.

─ 이 활동에서 가장 어려웠던 점은 무엇이었나요?

가장 어려웠던 점은 수치에 대한 멤버의 수용 태도와 활용 방식의 정착이었습니다. 도입 초기에는 “수치로 평가되는 것이 아닐까?”라는 불안이나 “도구가 보여주는 결과를 어떻게 해석해야 할지 모르겠다”는 목소리가 많았습니다. 특히 PR 수나 변경 라인 수 같은 지표는 멤버 간에 온도차가 존재하여 모두가 납득할 수 있기까지 시간이 걸렸습니다. 또한 리뷰 체계의 과제도 큰 장벽이었습니다. 리뷰 담당자의 리소스가 부족해 PR 머지까지 시간이 소요되었고, 이것이 생산성 향상의 병목이 되었습니다. 더불어 UI 디자이너나 비코드 업무를 담당하는 멤버에 대해서는 측정 결과를 어떻게 활용할지 고민하는 장면도 많았습니다. 과제 해결을 위해 1on1이나 팀 미팅에서 “수치는 자기 개선을 위한 도구”라는 점을 반복적으로 전달하고, 도구를 활용한 회고의 중요성을 공유했습니다. 아울러 멤버 한 사람 한 사람과 함께 수치를 보면서 “왜 수치가 올랐는가”, “어떤 시도가 성과로 이어졌는가”를 구체적으로 논의함으로써, 점차적으로 거부감이 줄어들었습니다.

공통 대시보드를 통한 팀원 간 상호 개선

─ 개발 생산성 측정을 통해 얻은 베네핏(효과)에 대해 알려주세요.

가장 큰 효과는 공통 대시보드를 통해 멤버 전원이 각자의 노력과 그 결과를 직관적으로 확인할 수 있게 되었다는 점입니다. 이를 통해 각자의 과제가 명확해지고, 회고가 보다 구체적이고 실효성 있는 것으로 바뀌었습니다.

또한 PR 오픈부터 머지까지 걸리는 시간이 200% 감소하고 변경 리드 타임도 마찬가지로 200% 단축된 것은 수치적으로 보아도 매우 큰 성과였습니다. 이 개선으로 인해 릴리스 빈도가 높아지고 개발 속도도 향상되었습니다.

게다가 하루의 활동 상황을 실시간으로 확인할 수 있는 대시보드는 멤버 간 커뮤니케이션의 계기가 되었습니다. 자신과 다른 멤버의 수치를 비교하며 “왜 저 사람은 더 빠를까?”와 같은 대화가 자연스럽게 생기고, 긍정적인 자극으로 이어지고 있습니다. 이것이 결과적으로 멤버 간 상호 개선을 촉진하는 문화 형성으로 이어지고 있습니다.

── Findy Team+의 추천 포인트를 알려주세요.

Findy Team+의 가장 큰 매력은 직관적으로 이해할 수 있는 대시보드를 통해 개발 활동을 시각화할 수 있다는 점입니다. GitHub나 Jira의 데이터를 기반으로 멤버 개개인의 활동 상황과 팀 전체의 경향을 한눈에 확인할 수 있는 점은 매우 편리합니다. 특히 변경 라인 수, PR 수, 리뷰 수 등 엔지니어에게 익숙한 지표로 확인할 수 있는 점이 일상의 회고와 개선 활동에 직결된다고 느낍니다.

또한 온보딩 리포트 기능도 활용하고 있습니다. 새롭게 입사한 멤버가 어느 정도 개발에 참여하고 있는지를 수치로 확인할 수 있어 조기에 과제를 발견하고 지원 체계를 마련하기 쉬워졌습니다. 이처럼 개인의 성장을 촉진함과 동시에 팀 전체의 퍼포먼스 향상에 기여하는 점이 큰 매력입니다.

더 나아가, “자신을 디버깅할 수 있는 감각”이 몸에 밴다는 점도 추천 포인트입니다. 자신의 활동을 수치로 되돌아보며 “왜 이런 결과가 나왔을까?”를 스스로 생각하는 습관이 자리 잡게 되면, 엔지니어의 자기 개선 의식이 자연스럽게 높아집니다. 이런 문화 형성을 지원해주는 도구로서 Findy Team+는 매우 유용하다고 느끼고 있습니다.

─ 마지막으로, 앞으로 함께 일하고 싶은 엔지니어상에 대해 알려주세요.

저희는 팀으로서 함께 과제를 해결하고 사업을 성장시키는 데서 기쁨을 느끼는 엔지니어를 찾고 있습니다. 블록체인이나 NFT 분야는 아직 새로운 영역으로 기술적 도전과 불확실성도 많지만, 그만큼 기술을 통해 사업에 직접 기여할 수 있는 재미가 있습니다.

특히 중요하게 생각하는 것은 “자신만 성과를 내는 것”이 아니라 “팀 전체의 성과를 생각하는 자세”입니다. 혼자서 앞서가는 것이 아니라 “지금 팀이 어려운 상황이니 내가 도와야겠다”, “어떻게 하면 모두가 원활하게 나아갈 수 있을까?”를 함께 고민할 수 있는 분과 일하고 싶습니다.

또한 새로운 기술에 호기심을 가지고 변화를 두려워하지 않고 도전할 수 있는 분이라면 저희 회사 환경에 잘 맞을 것입니다. 블록체인과 NFT는 계속 진화 중이며, 때로는 기존 상식을 뒤엎는 일도 있습니다. 스스로 성장하고 싶은 분, 도전을 즐길 수 있는 분들의 많은 지원을 기다리고 있습니다.

개발 조직의 건강 진단, SmartHR은 어떻게 시작했을까? 개발 생산성 도구 도입 배경부터 구성원의 공감을 이끌어낸 독서회 문화까지 | Findy Team+

Findy Team+ — Thu, 29 Oct 2026 02:42:11 GMT

클라우드 인사노무 소프트웨어 'SmartHR'을 개발하는 주식회사 SmartHR에서는, 엔지니어 조직의 개인 회고 및 조직의 과제 발굴을 위해 엔지니어 조직 지원 클라우드 'Findy Team+'를 활용하고 있습니다.

이번에는 SmartHR에서 다이렉터(본부장)를 맡고 있는 Sugawara 님과 매니저인 Kozuki 님을 인터뷰했습니다. 개발 생산성 측정을 시작하게 된 배경과 'Findy Team+' 도입을 결정한 계기, 그리고 팀 차원에서 이러한 시도를 추진하기 위한 노하우 등에 대해 이야기를 나누었습니다.

더 나은 피드백과 개선을 위해 개발 생산성 측정을 시작

—— 먼저 두 분의 주요 경력과 현재 맡고 계신 역할에 대해 소개해 주세요.

Sugawara: 첫 직장인 SIer에서 5년 정도 근무한 후, B2C 서비스 기업으로 이직해 서비스 출시부터 운영까지 10년가량 참여했습니다. 그 후 SmartHR에 입사했고요. 역할 변화를 말씀드리면, 'Findy Team+' 도입을 처음 검토할 당시에는 치프(Chief)였고, 실제 도입했을 때는 매니저를 거쳐 현재는 다이렉터(본부장) 직책을 맡고 있습니다.

Kozuki: 저도 처음에는 SIer에서 10년 정도 근무했고, 이후 이커머스 D2C 모델을 운영하는 사업회사에서 5년간 일했습니다. 그 뒤에 SmartHR에 입사해 지금까지 이어오고 있습니다. 'Findy Team+' 도입 검토 초기에는 팀원이었고, 도입 시점에는 치프를 맡았으며, 현재는 매니저로 일하고 있습니다.

개발 조직의 규모 및 생산성 측정 배경

—— 개발 조직의 규모와 체계는 어떻게 구성되어 있나요?

Sugawara: 엔지니어 조직 전체는 약 130명 규모입니다. 그 안에 30~40명 정도로 구성된 기본 기능 팀이 있고, 그 외에 옵션 기능 팀 등 10여 개 팀이 더 있습니다. 'Findy Team+' 도입을 가장 먼저 고려했던 곳은 기본 기능 팀이었습니다. (※인원수는 2024년 5월 기준) 아울러 옵션 기능 팀 중에서도 사용해 보고 싶다는 팀들이 있어 함께 도입을 진행했습니다.

—— 어떤 배경에서 개발 생산성 측정을 시작하게 되셨는지 궁금합니다.

Sugawara: 저희는 평소 스크럼 방식으로 개발하며 피드백 등을 통해 개선을 이어왔습니다. 반면 정량적으로 측정된 데이터는 그리 많지 않았고, 필요할 때마다 수작업으로 취합하는 경우가 많았습니다. 그래서 정량적으로 확인 가능하면서도 자동으로 집계되는 시스템이 있다면, 훨씬 효과적인 피드백과 개선이 이루어질 수 있겠다고 생각했습니다.

또한 업계 전반의 평균 수준은 어느 정도인지, 그리고 그와 비교했을 때 우리 팀의 위치는 어디쯤인지를 파악하고 싶었습니다. 더 강한 개발 조직 Py와 팀을 만들어 가기 위해 더 많은 지표와 재료가 필요하다는 점도 동기부여가 되었습니다.

고객에게 더 빠르게 가치를 제공하기 위해 개선할 점이 무엇인지 고민할 때, 물론 평소의 피드백이나 스크럼의 각 이벤트도 중요하지만 실제로 코드를 작성하는 과정 역시 핵심적인 부분입니다. 따라서 그 영역까지 포함해 정량적으로 살펴보는 것이 좋겠다는 판단이 있었습니다.

정확성과 유연성이 'Findy Team+' 도입의 핵심 결정 요인

—— SmartHR에서는 'Findy Team+'를 한 차례 검토하신 후, 재검토 과정을 거쳐 최종 도입하셨습니다. 결국 어떤 점이 가장 큰 결정 요인이 되었나요?

Sugawara: 처음 검토했을 당시에는 풀 리퀘스트(PR)에 라벨이 부여된 대상을 측정할 수는 있었지만, 특정 라벨이 붙은 대상을 제외하는 기능은 없었습니다. 저희는 특정 라벨을 제외할 수 있는 시스템이 있으면 매우 유용하겠다고 생각했는데, 당시 "곧 개발될 예정"이라는 안내를 받았습니다. 그리고 재검토를 진행한 시점에는 이미 그 기능을 사용할 수 있게 되어 있었습니다.

이 기능이 지원되면서 저희 스크럼 개발 프로세스에서 1스프린트 동안 어떤 일이 일어났는지 정밀하게 데이터를 추출할 수 있게 되었습니다. 이러한 높은 정확성과 유연성이 'Findy Team+' 도입을 결정한 큰 요인 중 하나였습니다.

또한 영업 및 고객 성공(Customer Success) 담당자분들이 사전에 기대치를 세심하게 조율해 주시며, 앞으로 함께 잘 협업해 나갈 수 있겠다는 신뢰를 주신 점도 크게 작용했습니다.

—— 현장에서 직접 사용하는 관점에서, Kozuki 님이 트라이얼 버전을 검토하셨을 때는 어떤 느낌을 받으셨나요?

Kozuki: 저는 이전 직장에서 'Findy Team+'를 이미 사용해 본 경험이 있어 어떤 솔루션인지 잘 알고 있었습니다. 전 직장에서는 경영진 보고가 주요 도입 배경이었기에 지금과는 상황이 조금 다르지만, 현재 저희 회사는 조직이 급성장하는 단계인 만큼 도입하는 것이 맞다고 판단했습니다.

팀원이 급격히 늘어나는 상황에서 조직의 퍼포먼스를 유지하거나 더 향상시킬 수 있을지 상시 모니터링하고 싶었습니다. 조직이 확대되더라도 퍼포먼스를 유지하고 개선을 지속할 수 있는 역량(Capability)을 확보하는 데 있어, 이 솔루션이 좋은 수단이 될 것이라 생각했습니다.

애플리케이션 모니터링 영역에서 말하는 '관측 가능성(Observability)'처럼, 개발 현황을 명확히 볼 수 있는 상태를 만들어 두고 상황이 악화되면 바로 조치를 취할 수 있도록 대비하자는 취지였습니다.

—— 'Findy Team+' 도입을 통해 궁극적으로 어떤 점을 실현하고자 하셨나요?

Kozuki: 기본적인 바이탈 체크 용도는 당연히 전제되어 있었고, 사실 도입 초기부터 지표 자체는 꽤 좋은 편이었습니다. 다만 개선할 수 있는 여지가 여전히 남아 있다고 느꼈고, 그 성장 가능성을 수치상의 차이(Delta)로 확인할 수 있다면 우리 조직은 충분히 그 과제를 해결해 나갈 수 있다고 믿었습니다.

말만 앞세우기보다는 정량적으로 함께 확인할 수 있는 기준이 있어야 설명하기가 훨씬 수월해집니다. 따라서 이러한 데이터를 명확히 보여줌으로써 개선 활동에 대한 추진력(Momentum)을 불어넣고 싶었습니다.

Sugawara: 저도 같은 생각입니다. 특히 공동으로 확인할 수 있는 지표가 있으면 각 팀이 서로의 사례를 참고하기 쉬워집니다. 또한 비슷한 과제를 해결하더라도 팀마다 접근 방식이 다른 경우가 많은데, 데이터를 기반으로 이에 대해 활발히 이야기를 나눌 수 있는 환경이 조성된다는 점이 매력적이었습니다.

팀의 이해를 도와 'Findy Team+' 도입과 추진으로 연계

—— 'Findy Team+' 도입 이후, 팀원들의 이해와 공감은 어떻게 이끌어내셨나요?

Sugawara: 처음 검토했을 때 도입을 보류했던 큰 이유 중 하나가 바로 팀의 이해를 얻지 못하면 성공하기 어렵다고 판단했기 때문입니다. 단순히 숫자 자체에만 매몰되면 지표를 왜곡하는 구조(Hack)가 발생하기 쉽고, 그렇게 달성한 수치에는 아무런 의미가 없기 때문입니다.

그래서 사내에서 《Lean과 DevOps의 과학(Accelerate)》이라는 책으로 독서회를 개최했습니다. Four Keys 지표가 어떤 의미를 지니는지, 그리고 그 숫자가 우리 엔지니어들에게 어떤 영향을 미치는지에 대한 개념을 먼저 정립(Install)해 나갔습니다. 현재는 당시 독서회에 참여했던 멤버들이 중심이 되어 'Findy Team+' 도입과 활용을 적극적으로 추진해 주고 있습니다.

—— 'Findy Team+'의 활용을 조직 내에 안정적으로 정착시키기 위해 어떤 노력을 기울이고 계시나요?

Sugawara: 기본 기능 팀과 옵션 기능 팀 내부에서 'Findy Team+' 활용을 주도하는 멤버들이 모이는 격주 미팅을 운영하고 있습니다. 일종의 느슨한 사내 커뮤니티 같은 형태입니다. 그곳에서 서로의 팀이 시도하고 있는 활동이나 안고 있는 고민을 나누며 서로의 인사이트를 공유합니다.

Findy Team+를 정착시키는 과정은 팀 내에서 어느 한 사람의 힘만으로는 매끄럽게 굴러가기 어렵습니다. 그렇기 때문에 어떻게 방향을 잡고 나아갈지 논의하거나, 팀 내에 관심 있는 인원이 있다면 함께 참여하도록 독려하는 등 프로젝트 추진을 위한 전반적인 소통 창구로 활용하고 있습니다.

—— Kozuki 님께서 팀 차원의 활동을 추진하실 때 특별히 신경 쓰신 점이 있다면 무엇인가요?

Kozuki: 팀의 현재 상황에 맞춰 메시지를 전달하는 데 집중했습니다. 저희 팀은 몹 프로그래밍(Mob Programming) 중심으로 일하고 있으며, 주 1회 진행되는 팀 레트로(피드백 시간)에서 'Findy Team+' 그래프를 함께 확인합니다. 이때 무작정 "이 지표를 개선합시다"라고 압박하기보다는, "이번 주는 이런 활동이 지표에 긍정적인 영향을 주었네요"라며 자연스럽게 짚어줍니다.

이처럼 팀의 상황에 녹아들도록 정보를 자연스럽게 스며들게 하는(Subliminal) 소통 방식을 의식했습니다. 아울러 이러한 활동에 관심을 가진 새로운 멤버가 합류하면서, 그 멤버와 함께 추진력에 더욱 박차를 가할 수 있었습니다.

—— 구성원분들 중에서 숫자로 지표를 확인하는 것에 대해 부정적인 반응은 없었나요?

Kozuki: 특별히 없었습니다. 저희는 몹 프로그래밍 방식으로 업무를 진행하고 있어서 기존에도 사이클 타임을 중심으로 살펴보고 있었는데, 지표가 High나 Elite 수준에 가깝게 나오고 있어서 다들 "나쁘지 않네"라며 긍정적인 분위기로 받아들였습니다.

—— 최근에는 OKR이나 KPI 같은 정량적인 수치 목표도 설정하셨다고 들었습니다.

Kozuki: 프로덕트 엔지니어의 핵심 슬로건으로 '보다 빠른 딜리버리(배포)'를 내걸고 있으며, 전사적인 슬로건 역시 이와 궤를 같이하고 있습니다. 그래서 이번 분기에는 프로덕트 OKR에도 딜리버리 관련 목표를 반영하기로 했습니다.

기존에는 주로 PdM을 중심으로 OKR을 운영해 왔으나, 이번에 엔지니어들도 함께 참여해 딜리버리 목표를 공유하면서 프로세스가 빠르게 추진되었습니다. 스스로의 개인 미션에 이를 적극적으로 반영하는 팀원도 늘고 있습니다.

협력 체계를 구축해 활동의 사례화 및 체계화 도모

—— 개발 생산성 측정과 관련하여 향후 시도하고자 하는 도전 과제가 있다면 무엇인가요?

Kozuki: 이번에 OKR의 핵심 결과(Key Result)로 정량적인 수치를 설정했습니다. 원래도 지표가 나쁜 편은 아니었기에 대폭 상향된 Elite 등급을 목표로 잡았습니다. 하지만 단순히 지표 달성 자체를 목적으로 삼기보다는, 저희가 시도하는 활동들을 사례화하고 체계화하는 데 초점을 맞추고 있습니다.

현재 4개 팀이 공동 OKR을 공유하고 있으며, 이들 팀 간에 서로의 활동을 공유하는 협력 체계를 구축해 나가는 중입니다. 이러한 문화가 조직에 뿌리내린다면 수치는 자연스럽게 따라올 것이라 믿습니다. 사내의 소중한 자산이 될 수 있도록 이와 같은 활동에 큰 비중을 두고자 합니다.

Sugawara: 개발 생산성을 어떻게 바라보아야 하는지, 그 관점의 기반이 되는 메시지를 지속적으로 발신할 필요가 있다고 생각합니다. 예를 들어 듀얼 트랙 애자일(Dual-Track Agile)을 실천할 때는 디스커버리(발견)나 딜리버리(배포) 중 어느 한쪽만 빨라서는 의미가 없으며, 두 영역이 모두 신속하게 움직여야 합니다.

이를 실현하기 위해 어떤 부분이 'Findy Team+'로 관측 가능하고, 어떤 부분이 다른 도구로 확인되는지, 혹은 이러한 활동의 결과가 'Findy Team+'에 어떤 숫자로 반영되는지 등에 대해 전사적인 공감대를 형성해 나가고자 합니다.

—— 다시 한번 'Findy Team+'에서 가장 추천하고 싶은 강점이 있다면 말씀해 주세요.

Sugawara: 몇 가지가 있습니다만, 우선 간편하게 측정할 수 있다는 점입니다. 또 다른 하나는 현재 필요한 기능이 없더라도 향후 개발될 것이라는 기대감을 준다는 점입니다. 앞서 말씀드린 라벨 제외 기능도 그렇고, 최근에는 주말을 통계에서 제외하는 기능도 추가되었습니다.

이러한 기능들은 없으면 없는 대로 유저가 감수해야 한다고 생각하기 쉽지만, 막상 반영되면 업무 효율이 크게 올라가기 때문에 실제 구현해 주셨을 때 정말 감사했습니다. 게다가 고객 성공(Customer Success) 담당자분들이 다방면으로 꼼꼼히 지원해 주신 덕분에 프로젝트를 차질 없이 이끌어올 수 있었던 점도 큰 도움이 되었습니다.

Kozuki: 저 역시 간편한 측정 편의성을 꼽고 싶습니다. 자체적으로 시스템을 구축해 측정하려면 손이 많이 가지만, 'Findy Team+'는 도입 과정에 번거로움이 거의 없고 데이터가 즉시 가시화된다는 점이 큰 장점입니다.

또한 최근 업데이트된 기능을 포함해 팀의 프로세스 개선을 돕는 기능들이 매우 충실합니다. 리뷰 분석 등도 마찬가지인데, 단순히 수치를 측정하는 것에 그치지 않고 이를 피드백하는 프로세스 전체를 아우르는 프로덕트로 진화하고 있다고 느껴져 앞으로도 기대가 큽니다.

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

Findy Team+ — Wed, 21 Oct 2026 15:30:00 GMT

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개월 뒤에는 성과를 공유해 드릴 수 있을 것으로 기대하니 많은 관심 부탁드립니다.

AI 투자 성과의 축적을 가시화하는 Findy Team+, ‘개발 자본 스코어(베타 버전)’ 출시 | Findy Team+

Findy Team+ — Wed, 07 Oct 2026 16:00:00 GMT

(원문 : PR TIMES 「AI投資の「積み上がり」を可視化。Findy Team+「開発資本スコア（β版）」を提供開始」)

하네스 구축 수준·AI 비용 안정성 등 AI 시대에 필요한 지표 제공. 개발 자본을 중심으로 조직과 팀을 분석할 수 있도록 UI 전면 개편

Findy 주식회사(일본 도쿄도 시나가와구, 대표이사: 야마다 유이치로, 이하 ‘당사’)는 경영과 개발 현장을 연결하는 AI 시대의 개발 자본 플랫폼 ‘Findy Team+’에서 AI 시대의 개발 역량을 가시화하는 신규 기능 ‘개발 자본 스코어’의 베타 버전을 출시했습니다.

개발 자본 스코어는 Speed·Quality·Control의 세 가지 축으로 개발 조직의 현재 상태를 스코어화해, 조직의 강점과 개선 과제를 보여줍니다. 이를 통해 경영진과 개발 현장이 같은 근거를 바탕으로 투자 효과와 조직의 상태를 논의할 수 있도록 합니다.

또한, ‘Speed’, ‘Quality’, ‘Control’이라는 세 가지 축을 기반으로, ‘하네스 구축 수준’, ‘AI 비용 안정성’, ‘리뷰 수정 발생률’, ‘리뷰 완료 풀 리퀘스트 비율’, ‘풀 리퀘스트 템플릿·CODEOWNERS 설정률’ 등 5개 지표를 제공합니다.

이 지표들은 AI가 자율적으로 작업할 수 있는 기반의 구축 현황, AI 사용 비용의 안정성, 리뷰의 품질과 통제 현황을 가시화합니다. 이를 통해 AI 활용 기반을 마련하기 위한 투자가 일회성 대응에 그쳤는지, 조직의 ‘개발 자본’으로 축적되었는지를 조직과 팀별로 수치로 파악할 수 있습니다.

뿐만 아니라, 축적 현황을 바탕으로 기반이 갖춰진 팀부터 AI 활용을 확대하는 등 조직과 팀별로 다음 실행 방안을 결정할 수 있습니다. 이와 함께 개발 자본을 중심으로 분석할 수 있도록 UI를 전면 개편했습니다.

배경: 경영진과 개발 현장의 간극을 좁히는 ‘공통 언어’의 필요성

최근 생성형 AI와 AI 에이전트가 확산되면서 요구사항 정의부터 구현, 리뷰, 검증에 이르기까지 개발 전 과정에서 AI 도입이 가속화되고, 산출물의 양도 크게 늘고 있습니다. 반면 경영진과 개발 현장에서는 다음과 같은 과제가 드러나고 있습니다.

경영상의 과제

AI에 지속적으로 투자하고 있지만, 투자에 따른 성과는 명확하지 않습니다. 조직의 실제 상황을 파악하기 어려워 AI에 대한 추가 투자나 활용 확대를 위한 적절한 의사결정에도 어려움을 겪고 있습니다.
개발 현장의 과제

개발 프로세스를 개선하고 있지만, 그 성과가 조직 역량 향상으로 얼마나 축적되고 있는지 보여주기 어렵습니다. 또한 개선의 우선순위가 주관적인 판단에 의존하고 있어, 경영진에게 투자의 타당성을 설명할 객관적인 근거가 부족합니다.

당사는 이러한 과제를 해결하기 위해 2026년 5월, 개발 생산성을 기업의 경쟁력과 직결되는 경영 자산으로 재정의하는 ‘AI 시대의 개발 자본’ 정립 프로젝트를 시작했습니다. 이러한 문제를 해결하기 위한 기능인 ‘개발 자본 스코어’는 ‘Speed’, ‘Quality’, ‘Control’이라는 세 가지 관점에서 조직의 상태를 정량적으로 가시화합니다. 이는 경영진과 개발 현장이 동일한 지표를 바탕으로 소통하고 신속하게 의사결정을 내리기 위한 ‘공통 언어’로 활용할 수 있습니다.

AI 에이전트 활용이 본격화되면서 확인해야 할 사항도 늘어나고 있습니다

AI 에이전트 활용이 더욱 본격화되면서 경영진이 확인해야 할 사항도 늘어나고 있습니다.

AI에 맡길 수 있는 범위는 기반의 구축 수준에 따라 달라집니다. 테스트, CI, 규칙, 문서가 갖춰지지 않은 조직에서는 AI 에이전트가 안전하게 자율적으로 작업하도록 할 수 없습니다.
AI 사용 비용이 예산 계획을 세우기 어려운 규모로 커지고 있습니다. 월별 사용 비용의 변동이 커지면서 예산 증액의 타당성을 설명할 근거가 필요해지고 있습니다.
병목이 리뷰와 의사결정 단계로 이동하고 있습니다. AI가 생성하는 산출물이 늘어나면서 리뷰 상태가 조직 전체의 개발 속도와 품질을 좌우하게 되었습니다.

이들은 모두 AI 투자가 일회성 성과에 그칠지, 조직의 역량으로 축적될지를 좌우하는 중요한 사항입니다.

AI 시대의 개발 자본을 구성하는 세 가지 관점

관점	확인해야 할 사항	세부 분석 항목
Speed	빠르게 만들고, 배포하고, 학습하고 있는가. 구현뿐 아니라 리뷰, CI, 배포, 결과 관측까지 포함한 변경과 학습 주기의 속도를 파악합니다.	만드는 속도 / 배포하는 속도 / 학습하는 속도
Quality	재작업 없이 개발을 진행하고 있는가. 재작업이나 반려, 장애, 유지보수성 저하를 줄이고 지속적으로 가치를 제공하고 있는지 파악합니다.	재작업의 적음 / 운영 환경에서의 품질 / 지속적인 유지보수성
Control	변경을 예측하고 통제할 수 있는가. 변경의 영향 범위, 검증, 승인, 롤백, 복잡성을 조직 차원에서 관리하고 있는지 파악합니다.	구조의 통제 / 프로세스의 통제 / 복잡성의 통제

개발 자본 개념 정립에 협력한 기업

‘개발 자본’의 개념 정립에는 AI 활용을 선도적으로 추진하는 일본 기업인 KDDI 주식회사, 주식회사 SmartHR, 합동회사 DMM.com, 퍼솔커리어 주식회사 등 4개사가 협력하고 있습니다. 이번 개발 과정에서도 각사의 경영·개발 부문 책임자와 현장 엔지니어를 대상으로 ‘개발 자본으로서 무엇을 측정해야 하는가’를 주제로 인터뷰를 진행했습니다. 현장 실무자와의 세션에서는 자사의 실제 데이터를 함께 살펴보며 의견을 수렴했고, 여기서 얻은 시사점과 지적 사항을 새로운 지표의 추가와 확충에 반영했습니다.

신규 기능 개요

개발 자본 스코어의 지표와 개편된 UI를 통해 경영진과 부서장이 개발 현장에 던지는 다음과 같은 질문에 구체적인 수치로 답할 수 있게 됩니다.

AI 도구를 도입했지만, AI가 안전하게 자율적으로 작업할 수 있는 ‘조직의 기반’은 갖춰져 있는가?
AI 사용 비용이 급격하게 변동하지 않고, 예측하고 통제할 수 있는 범위 내에서 유지되고 있는가?
산출물이 급증하면서 리뷰 적체나 품질 저하가 새로운 병목으로 작용하고 있지는 않은가?

개발 자본 스코어는 Findy Team+에서 제공해 온 DevOps 분석, 사이클 타임 분석, 프로젝트 투자 분석 등의 지표를 Speed·Quality·Control의 세 가지 축으로 분류해 보여줍니다. 조직 전체의 현황뿐 아니라 팀별 상세 현황도 확인할 수 있습니다.

표시 항목	개요
개발 자본 스코어	Speed·Quality·Control의 세 가지 축으로 구성된 스코어를 레이더 차트로 시각화해, 개발 조직의 강점과 개선 과제를 한눈에 파악할 수 있습니다.
스코어 추이 그래프	월별 변화를 추적해, AI 투자와 각종 개선 활동이 조직의 자산으로 축적되고 있는지 정량적으로 확인할 수 있습니다.
지표별 세부 항목	세 가지 축을 세부 항목별로 분석해, 개발 현장과 구체적인 과제를 중심으로 대화할 수 있는 근거를 제공합니다.
팀 모니터링 목록	각 팀의 세 가지 축별 스코어를 비교해, 자원을 우선적으로 투입해야 할 부서를 판단할 수 있도록 지원합니다.
팀별 개발 자본 스코어 및 추이 그래프	각 팀의 현재 상태와 지금까지의 변화를 가시화합니다. 조직 내 상대적인 위치를 파악하고, 우선적으로 개선해야 할 영역을 판단할 수 있습니다.
지표별 그래프	세 가지 관점별 상세 지표를 확인해, 리뷰 적체나 높은 재작업률처럼 개발 현장에서 바로 개선 활동으로 연결할 수 있는 구체적인 과제를 파악할 수 있습니다.

신규 기능 ①: 지표 확충

‘하네스 구축 수준’, ‘AI 비용 안정성’, ‘리뷰 수정 발생률’, ‘리뷰 완료 풀 리퀘스트 비율’, ‘풀 리퀘스트 템플릿·CODEOWNERS 설정률’은 AI 에이전트 활용이 본격화되면서 중요성이 높아지는 항목입니다. AI가 자율적으로 작업할 수 있는 기반의 구축 현황, AI 사용 비용의 안정성, 리뷰 상태를 측정합니다.

동일한 AI 도구를 같은 비용으로 도입하더라도 조직마다 성과가 달라지는 이유 중 하나는 이러한 기반의 차이에 있습니다. 현재 수치가 좋더라도 기반이 갖춰지지 않았다면 성과를 지속하기 어렵고, 기반이 갖춰져 있다면 향후 성장으로 이어질 가능성이 있습니다. 단기적인 결과를 넘어, AI 활용을 위한 투자가 조직의 역량으로 얼마나 축적되고 있는지 판단할 수 있도록 근거를 확충했습니다.

월별 스코어 변화를 추적하면 AI 투자와 각종 개선 활동이 조직의 자산으로 축적되고 있는지 정량적으로 확인할 수 있습니다. 또한 팀별 스코어와 추이 그래프를 통해 각 팀의 현재 상태와 지금까지의 변화를 파악할 수 있습니다.

(이미지: 개발 자본 스코어 대시보드)

지표	관점	개요
하네스 구축 수준	Control	AI에 조직의 맥락을 제공하기 위한 환경이 얼마나 갖춰져 있는지 측정합니다. AI 에이전트가 안전하게 자율적으로 작업할 수 있는 기반이 얼마나 마련되어 있는지 판단하는 근거가 됩니다.
AI 비용 안정성	Control	AI 사용 비용이 급격하게 변동하지 않고 안정적인 범위에서 유지되는지 측정합니다. AI 투자가 통제된 상태에 있는지 판단하는 근거가 됩니다.
리뷰 수정 발생률	Quality	리뷰를 한 번에 통과하지 못하는 변경이 얼마나 있는지 측정합니다. 리뷰를 요청하기 전 단계에서 품질을 얼마나 확보하고 있는지 판단할 수 있습니다.
리뷰 완료 풀 리퀘스트 비율	Control	변경이 정해진 리뷰·승인 절차를 거치는 비율을 측정합니다. 정해진 리뷰 규칙이 실제로 준수되고 있으며, 거버넌스로서 실효성이 있는지 판단할 수 있습니다.
풀 리퀘스트 템플릿·CODEOWNERS 설정률	Control	PR 템플릿과 CODEOWNERS가 설정된 리포지토리의 비율을 측정합니다. 변경 내용을 작성하는 방식과 리뷰 담당자가 정해진 절차로 체계화되어 있는지 판단할 수 있습니다.

신규 기능 ②: UI 개편

‘Findy Team+’에서 사용해야 하는 기능은 경영진, 개발 부서장, 현장 엔지니어 등 역할에 따라 다릅니다. 개발 자본 측정을 통해 경영 의사결정에도 활용할 수 있는 서비스로 발전하면서 사용자층은 더욱 넓어졌습니다. 당사는 이러한 변화를 반영해 사용자 경험 자체를 재설계했습니다.

탐색 메뉴는 먼저 조직·팀·멤버·프로젝트 중 분석할 범위를 선택하고, 다음으로 활용 사례별로 정리된 메뉴에서 분석 목적을 선택하는 구조로 변경했습니다. 경영진은 조직 전체의 개발 자본을, 개발 부서장은 팀 단위의 상태를 출발점으로 분석하는 등 각자의 역할에 따라 필요한 기능을 쉽게 찾을 수 있도록 설계했습니다. 이와 함께 개발 자본을 중심으로 조직과 팀의 상태를 심층적으로 분석할 수 있도록 하는 데 중점을 뒀습니다.

팀별 스코어와 추이 그래프를 통해 조직 내 상대적인 위치와 지금까지의 변화를 파악하고, 우선적으로 개선해야 할 영역을 확인할 수 있습니다. 또한 세 가지 관점별 상세 지표에서는 리뷰 적체나 높은 재작업률처럼 개발 현장에서 바로 개선 활동으로 연결할 수 있는 구체적인 과제를 파악할 수 있습니다.

(이미지: 새로운 탐색 메뉴 화면)

향후 계획

정확도를 더욱 높이고 더 큰 가치를 제공하기 위해 다음과 같은 계획을 추진할 예정입니다.

기능 확충: 사용자 피드백을 바탕으로 기능을 확충해 12월경 선보일 예정입니다.
지표 확충: AI 시대의 개발 조직을 파악하는 데 필요한 관점을 지속적으로 추가할 예정입니다.
벤치마크 비교 확대: 업종과 규모별 그룹 비교를 지원해 자사의 현재 수준을 더욱 정확하게 파악할 수 있도록 할 계획입니다.
‘Findy Team+ Award’에서 활용(2026년 12월 8일 개최 예정): 개발 자본과 관련한 우수한 활동을 가시화하고 시상할 예정입니다.

경영과 개발 현장을 연결하는 AI 시대의 개발 자본 플랫폼 ‘Findy Team+’ 소개

‘Findy Team+’는 경영과 개발 현장을 연결하는 AI 시대의 개발 자본 플랫폼입니다. AI 활용 기반 구축을 지원하는 컨설팅부터 개발 현황과 투자 대비 효과의 데이터화까지 포괄하며, 개발 현장의 개선부터 경영 의사결정까지 통합적으로 지원합니다.

당사는 2026년 5월부터 AI 시대의 소프트웨어 개발 역량을 경영 자산으로 보는 ‘개발 자본’이라는 개념을 제시하고 있습니다. 엔지니어의 ‘인적 자본’과 AI 투자 등의 ‘기술 자본’을 결합해, 개발 조직을 기업 성장을 뒷받침하는 ‘경영 자산’으로 강화합니다. 현재 스타트업부터 대기업까지 약 1,500개사에서 도입하고 있습니다(체험 이용 포함).

Findy Team+ 일본 공식 사이트: https://jp.findy-team.io/
Findy Team + 한국 공식 사이트: https://kr.findy-team.io/
Findy Team+ 무료 데모 신청: https://kr.findy-team.io/contact-us

Findy 주식회사 소개

회사명: Findy 주식회사 / Findy Inc.
소재지: 일본 도쿄도 시나가와구 오사키 1-2-2 아트빌리지 오사키 센트럴타워 5층
대표자: 대표이사 야마다 유이치로
기업 홈페이지: https://findy.co.jp/