노머스 Tech팀의 AI 도입 파일럿 프로젝트 회고

프로젝트의 시작

무더운 8월의 어느 여름날, CTO님으로부터 DM 하나가 왔습니다.

“상아님 시간 날때 읽어보세요”

저는 여느때처럼 네~~ 하고 대답하고는 링크를 열었습니다. 스크롤을 내리며 ‘이걸 왜 읽으라고 하시지?’ 잠시 고민했지만 곧 대수롭지 않게 넘겼습니다.

그리고 다음날, CTO님이 다시 부르셨죠.

“읽으셨나요?”

“네.. 아마..도..요..?”

“자 그럼 (이러저러해서) AI 업무 툴 도입 파일럿을 진행해보려고 합니다. (..중략) 상아님이 책임자입니다.”

그 당시 저는 Claude Code를 포함한 AI 코딩 에이전트를 본격적으로 사용해본 경험이 거의 없었습니다. AI 도구에 특별히 관심이 많지도 않고 필요하면 찾아보고 써보는 정도였던 터라 사실 제가 이 프로젝트를 진행한다는 것이 막막했습니다. 그렇게 예상하지 못하게 AI 도입 파일럿 프로젝트를 맡게 되었고, 하나씩 부딪히며 방향을 잡아갔습니다. 이 글에서는 그 과정에서 무엇을 시도했고, 어떤 시행착오를 거쳤으며 그 결과로 무엇을 얻었는지를 공유해보고자 합니다.

프로젝트의 목적

왜 파일럿 프로젝트였나

AI 도구를 Tech팀 전체에 도입하기에 앞서, 저희는 먼저 실제 개발 업무에서의 활용 가능성과 효과를 확인해보고자 했습니다. 단순히 도구 사용만을 권장하는 방식이 아니라, 어떤 방식으로 사용할 때 도움이 되는지, 어떤 점을 주의해야 하는지를 정리할 필요가 있다고 판단했기 때문입니다.

또한 각 팀원이 일상적인 개발 과정에서 AI 도구를 사용하며 어떤 변화가 발생하는지를 관찰하고 기록하는 데 집중했습니다. 코드 생성 속도나 품질 변화, 반복 업무 자동화 가능성 등을 정량·정성적으로 수집하고, 기대에 미치지 못했던 경우까지 포함해 정리했습니다.

중요한 점은, 이번 파일럿의 목적이 당장의 생산성 향상이나 업무 시간 단축을 증명하는 데 있지 않았다는 것입니다. 사용 결과가 기대와 다르더라도, 그 자체로 이후 판단에 참고할 수 있는 데이터라고 보았습니다. 성과를 만들기보다는, 의사결정에 필요한 근거를 확보하는 것이 우선이었습니다.

이렇게 축적된 결과는 이후 전체 도입 여부를 검토하고 이후 Tech팀 전체에 도입하기 위한 중요한 기반이 되도록 정리했습니다.

파일럿 성공 시 최종 목표

파일럿 프로젝트가 의미 있는 결과를 낸다면, 그 다음 단계는 비교적 분명했습니다. Tech팀 전체 업무에 AI를 도입하고, 이를 하나의 업무 문화로 정착시켜 효율을 향상시키는 것이었습니다.

이 과정에서 CTO님이 공유해주신 GitHub의 내부 플레이북은 저희의 방향성을 정리하는 데 도움이 되었습니다. 특히 AI 도입을 기술 문제가 아닌, 업무 방식의 변화로 바라보는 관점이 인상적이었습니다.

Their mistake is treating AI adoption as a technology problem when it is, in fact, a change management problem. Companies fail at AI adoption because they treat it like installing software when it’s actually rewiring how people work. The difference between success and failure isn’t buying licenses. It’s building the human infrastructure that turns skeptical employees into power users.
그들의 실수는 AI 도입을 기술 문제로 취급하는 것인데, 사실은 변화 관리 문제입니다. 기업들은 AI 도입을 마치 소프트웨어 설치처럼 취급하기 때문에 실패합니다. AI 도입은 실제로 사람들의 업무 방식을 바꾸는 작업입니다. 성공과 실패의 차이는 라이선스 구매가 아닙니다. 회의적인 직원을 파워 유저로 전환하는 인적 인프라 구축에 있습니다.

저희 역시 팀원들이 AI를 자연스럽게 활용하고 각자의 경험을 공유하며 점진적으로 활용 수준을 높여가는 환경을 만드는 것을 최종 목표로 삼았습니다.

프로젝트 참여자들과 역할

이러한 목표를 달성하기 위해 프로젝트를 진행하기에 앞서 각 참여자들의 역할과 주요 책임을 명확히 정의했습니다. 이 역시 GitHub의 플레이북을 참고해 저희 팀 상황에 맞게 재구성했습니다.

역할	담당자	핵심 책임
경영진 스폰서	CTO	전략적 지원, 예산 확보, 비전 메시지 전파
중앙 책임자 (DRI)	본인	전략 수립, 진행 모니터링, 데이터 수집 및 분석
AI Advocates	각 팀 1명 (4명)	실제 업무 활용 및 검증, 팀 내 전파 및 교육
보안 정책 설계자	인프라 담당자	보안 리스크 식별, 가드레일 정책 수립
참가자 도우미	각 팀장	Advocates 활동 지원, 진행 상황 모니터링

이 중에서도 가장 중요한 역할은 AI Advocates였습니다. GitHub의 정의를 빌리자면, 이들은 “동료 간의 영향력과 피드백을 통해 도입 규모를 확대하는 내부 옹호자들의 네트워크”에 해당합니다.

각 팀에서 1명씩 선발된 AI Advocates는 실제 업무에 AI를 적용하며 문제를 겪고, 활용 방법을 실험하고, 그 과정에서 얻은 인사이트를 동료들에게 공유하는 역할을 맡았습니다. 이 구조의 핵심은 실무자 중심이라는 점이었습니다. 실제로 코드를 작성하고 문제를 해결하는 과정에서 나온 경험과 피드백이 프로젝트의 방향을 결정하기도 했습니다.

프로젝트의 진행

9월: 자유로운 탐색과 데이터 수집

프로젝트 초반에는 팀원들 간 AI 도구 활용에 있어 숙련도 차이가 컸습니다. 이미 업무에 적극 활용하고 있는 팀원도 있었고, 처음 접하는 팀원도 있었습니다. 그래서 첫 달에는 엄격한 규칙을 세우기보다 각자가 자유롭게 활용해 보고 주간 모임을 통해 서로의 노하우를 공유하며 자연스러운 학습을 진행했습니다.

동시에 데이터 수집을 위한 기반을 마련하였습니다. 모든 팀원들은 PR 템플릿에 AI 활용으로 절감된 시간과 체감 효과 등을 기록했고, 이 데이터들은 실시간 대시보드에 쌓이도록 하였습니다.

10월: 효과 검증 및 온보딩 체계 마련

10월에는 엔지니어의 체감 효과를 중심으로 한 정성 데이터의 한계를 보완하기 위해 A/B 테스트를 진행하였습니다. 유사한 작업 환경에서 AI 사용 여부에 따른 차이를 비교하여 AI 의 실질적인 효용성을 정량적으로 분석했습니다.

또한, 새롭게 참여할 Advocates들이 빠르게 적응할 수 있도록 팀별 가이드와 CLAUDE.md 등 기본 문서를 정리하여 온보딩 체계를 마련했습니다.

11월: 코드 리뷰 프로세스에 적용 및 조직 내 확산

AI 활용 수준이 높아짐에 따라, 개별적으로 업무에 활용하는 것을 넘어 팀 프로세스에 AI 를 도입하는 시도를 하였습니다. 팀 프로세스에서 반복적으로 언급되던 문제 중 하나인 코드 리뷰로 인한 병목을 개선하기 위해 Claude Code를 활용한 사전 리뷰 단계를 도입했습니다. 사람의 리뷰를 대체하기보다는, 리뷰 이전 단계에서 기본적인 개선 포인트를 걸러내 전체적인 개발 속도가 개선될 수 있는지를 실험했습니다.

동시에 각 팀별로 신규 Advocates를 추가로 선발하여 팀 내 확산 속도를 높였으며, 기존 멤버들이 이들을 이끄는 멘토링 시스템을 통해 조직 전반의 AI 활용 역량을 강화했습니다.

12월: 성과 분석 및 가이드라인 정립

4개월간의 여정을 마무리하며 그간 축적된 데이터를 종합 분석했습니다. 이를 통해 AI 도입이 실제 업무에 어떤 영향을 주었는지를 객관적으로 정리하고 이는 AI 도입의 타당성을 입증하는 근거가 되었습니다.

또한 개별 팀원들의 노하우와 AI 사용시 반드시 지켜야 할 보안 기준을 정리하여, 각 팀별로 ‘AI 활용 가이드라인’을 만들었습니다.

가이드라인의 핵심은 단순히 기능 사용법을 나열하는 것이 아니라 이를 개발 프로세스의 각 단계별 활용법으로 구조화한 점이었습니다. 기획, 코드 작성, 리뷰, 테스트 등 각 단계에서 AI를 어떻게 활용하면 효과적인지, 반대로 어떤 경우에는 기대만큼의 효과를 얻기 어려운지, 그리고 결과물을 어떻게 검증해야 하는지를 중심으로 정리했습니다. 이를 통해 신규 팀원도 AI 활용법을 빠르게 습득하고 이미 검증된 프롬프트 템플릿과 주의사항을 공유함으로써 불필요한 시행착오와 실수를 줄일 수 있도록 했습니다.

이 가이드라인은 팀 단위 확산 시 시행착오를 최소화하고 “우리 조직에서는 이렇게 사용한다”를 설명하는 기준 자료로 활용될 예정입니다.

주요 성과 및 인사이트

이렇게 4개월 동안 실제 업무 환경에서 AI 도구를 사용하며 다양한 시도와 실험을 진행했고, 그 과정과 결과를 꾸준히 기록해왔습니다. 이렇게 축적된 기록을 바탕으로, 단순히 “AI가 도움이 되었는가”가 아니라 어떤 작업에서, 어떤 조건일 때, 어느 정도의 효과가 있었는지를 종합적으로 분석할 수 있었습니다. 다음으로는 이 활동들을 종합해, 파일럿 프로젝트를 통해 확인한 주요 성과와 인사이트를 정리해보고자 합니다.

생산성 증가

파일럿 기간 동안 확인한 평균 개발 시간 단축률은 33.2%로, 단순 계산으로 약 1.5배의 생산성 증가 효과였습니다. 특히 엔지니어들이 체감하는 개발 속도 향상은 70%로 가장 높게 나타났습니다. 숫자뿐 아니라, 실제로 “일이 빨라졌다”는 인식이 분명히 형성됐다는 점이 인상적이었습니다.

A/B 테스트를 통한 작업 유형별 차이는 더 뚜렷했습니다. 반복적인 패턴이 있는 작업에서는 50~78% 수준의 시간 단축 효과가 나타났습니다. 예를 들어 Android UI 테스트 코드 작성은 약 55분이 절감됐고, 백엔드 CRUD API 개발은 2.5시간 걸리던 작업이 50분으로 줄어들며 66.7%의 단축 효과를 보였습니다. 인프라와 자동화 작업 역시 비슷한 수준의 효율 개선이 있었고, Figma MCP와 AI를 함께 활용한 UI 작업도 약 56%의 시간 절감 효과를 확인할 수 있었습니다. 반면 마이그레이션 작업은 약 12% 수준으로 상대적으로 효과가 제한적이었습니다.

이를 통해 패턴이 명확할수록 AI의 효율은 높아진다는 점을 확인할 수 있었습니다. CRUD 개발, 테스트 코드 작성, 문서화, 반복 작업 자동화처럼 구조가 분명한 영역부터 AI를 도입하는 것이 빠른 성과로 이어질 가능성이 높다는 시사점을 얻었습니다.

품질 유지

AI 도입을 논의할 때 가장 큰 우려는 코드 품질이었습니다. 실제로 AI가 생성한 코드가 품질 저하로 이어지지는 않을지 확인이 필요했습니다.

분석 결과, 버그 발생률은 AI 사용 여부와 무관하게 프로젝트당 평균 5개로 동일했습니다. 오히려 엔지니어들이 체감하는 코드 품질은 36.7% 개선됐다는 응답이 나왔습니다.

다만, AI가 생성한 결과물을 그대로 신뢰하지 않고 반드시 검증하는 과정은 꼭 필요했습니다. 이 원칙은 이후 가이드라인에서도 핵심 기준으로 정리되었습니다.

또한 AI를 활용한 PR과 그렇지 않은 PR의 머지 시간을 비교해, 코드 품질이 유지되고 있는지를 간접적으로 살펴보고자 했습니다. 머지 시간은 품질을 직접적으로 나타내는 지표는 아니지만, 리뷰 과정에서 발생하는 수정과 논의의 양을 가늠할 수 있는 참고 지표라고 판단했습니다.

일반적으로 리뷰 코멘트가 많을수록 왕복 커뮤니케이션이 늘어나고, 수정 커밋이 반복될수록 머지까지의 시간이 길어집니다. 또한 논쟁이 발생하거나 설계 재검토가 필요한 경우에도 머지 일정은 자연스럽게 지연됩니다. 이런 맥락에서 머지 시간은 리뷰 과정에서 품질 이슈나 논의가 얼마나 발생했는지를 보여주는 하나의 신호로 볼 수 있다고 생각했습니다.

이 전제를 바탕으로 데이터를 살펴본 결과, AI를 활용한 PR의 머지 시간이 오히려 더 길게 나타났습니다. 표면적으로는 다소 역설적인 결과처럼 보였지만, 이후 변경 라인 수와 작업 성격을 함께 분석하면서 그 이유를 이해할 수 있었습니다.

AI-assisted PR의 평균 변경 라인 수는 Non-AI PR 대비 2.24배에 달했습니다. AI는 단순한 수정이 아니라, 더 복잡하고 규모가 큰 작업에 주로 사용되었습니다. 리뷰 병목을 제외하고 비교했을 때, 머지 시간 차이는 약 7.2%, 시간으로는 4.5시간 정도에 불과했습니다.

즉, 작업의 복잡도를 함께 고려하면 AI를 활용한 PR이 오히려 더 효율적으로 처리되고 있었고, 품질 역시 안정적으로 유지되고 있었다고 볼 수 있었습니다.

예상치 못한 효과들

정량 지표 외에도, 숫자로 측정하기 어려운 변화들이 분명히 존재했습니다. 엔지니어들의 업무 영역이 자연스럽게 확장됐고, 기술 스택이나 언어의 경계를 넘어 다양한 시도가 이루어졌습니다. 그 결과 팀에 필요한 인프라 도구, 자동화 스크립트, 운영용 대시보드 등이 자발적으로 만들어졌습니다. 라이브 모니터링 대시보드, iOS CI/CD 환경 개선, 백오피스 어드민 프론트 개발 등이 그 사례였습니다.

조직 안정성 측면에서도 긍정적인 효과가 있었습니다. 조직 개편 상황에서도 레거시 코드 이해와 인수인계가 훨씬 수월해졌고, 새로운 환경에 빠르게 적응할 수 있었습니다. 장애 대응 과정에서도 복잡한 에러 로그와 시스템 흐름을 빠르게 파악할 수 있어, 문제 원인 분석과 대응 시간이 단축된 사례도 있었습니다.

아쉬웠던 점

하지만 이번 파일럿 프로젝트를 진행하며 아쉬운 점도 있었습니다.

첫 번째는 데이터 측정의 한계였습니다. 엔지니어의 생산성을 정량적으로 측정하는 일은 글로벌 대기업들도 여전히 고민하고 있는 어려운 문제입니다. 특히 AI 도구 도입 효과를 정확히 비교하려면, 비교 기준이 되는 기존 생산성 지표가 선행되어야 합니다. 하지만 이번 파일럿에서는 프로젝트를 진행하는 동시에 측정 체계를 설계해야 했기 때문에, 초기 데이터의 정교함이 충분하지 못했습니다. 만약 프로젝트 시작 전에 측정 방법과 기준을 더 명확히 정의했다면, AI 도입 전후의 차이를 보다 정확하게 비교할 수 있었을 것이라는 아쉬움이 남습니다.

두 번째는 실험 범위의 제약입니다. 파일럿 프로젝트의 성격상 기존 프로젝트 진행에 영향을 주지 않는 선에서 운영해야 했고, 그로 인해 AI를 보다 넓은 범위에서 실험해볼 기회는 제한적이었습니다. 예를 들어 개발 프로세스 전반을 재설계하거나, 새로운 워크플로우를 과감하게 시도하는 수준까지는 나아가지 못했습니다. 가능성을 더 탐색하지 못했다는 점에서는 아쉬움으로 남습니다.

세 번째는 코드 리뷰 영역에서 기대 대비 효과가 충분하지 못했다는 점입니다. Claude Code를 활용한 사전 코드 리뷰는 코드 스타일 개선이나 가독성 향상, 단순한 성능 개선, 기본적인 알고리즘 검토에서는 일정 부분 도움이 되었지만, 복잡한 비즈니스 로직을 다루는 영역에서는 기대만큼의 효과를 보지 못했습니다. 실제로 여러 팀원들로부터 “도메인 이해가 깊게 필요한 로직에서는 큰 도움이 되지 않았다”는 의견이 나왔습니다. 이를 통해 AI 코드 리뷰는 보조 수단일 뿐이라는 한계를 인식하게 되었습니다.

마치며

이번 파일럿 프로젝트를 통해, 노머스 Tech팀은 AI 도구를 실제 개발 업무에 어떻게 적용할 수 있는지에 대해 구체적인 기준을 마련할 수 있었습니다. 이 경험을 바탕으로, 2026년에는 전체 엔지니어를 대상으로 AI 도구를 단계적으로 확대 도입하고, 활용 문화까지 정착시키는 것을 목표로 하고 있습니다.

저희가 이번 프로젝트를 통해 얻은 가장 큰 배움은 ‘엔지니어 중심의 변화’가 중요하다는 점입니다. 검증 없이 도구 도입을 강행하거나 위에서 정한 지침을 일방적으로 전달하기보다, 실제 코드를 작성하는 엔지니어들이 중심이 되어 경험을 공유했기에 변화를 자연스럽게 받아들일 수 있었습니다.

AI 도입을 고민하는 다른 조직이 있다면, 처음부터 큰 변화를 목표로 삼기보다 실제 업무 환경 안에서 작은 실험을 반복하며 검증해 나가는 방식을 권하고 싶습니다. 결국 AI 도입은 단순한 도구의 교체가 아니라, 우리가 일하는 방식을 더 나은 방향으로 재설계하는 과정이기 때문입니다.

노머스 Tech팀의 이번 사례가 AI와 함께 성장하고자 하는 다른 조직에게도 도움이 되기를 바랍니다.

감사합니다.

참고

https://resources.github.com/enterprise/ai-powered-workforce-playbook/ (영문)

https://news.hada.io/topic?id=22581 (한글요약)