2026년 10월 기준, Tanomu의 AI를 중심으로 한 팀 개발
저희 회사에서도 AI를 주축으로 하는 개발을 시작한 지 꽤 시간이 흘렀기 때문에, 일단 비망록처럼 현재 상황을 정리하고 싶다는 것이 이 글의 목적입니다.
반년 후, 1년 후에는 더욱 자동화 및 효율화가 진행될 것이라고 생각하기 때문에, 잊지 않도록 기록하는 것입니다.
자, Tanomu에서는 PR(Pull Request) 리뷰나 지적 사항 수정 역시 AI에 맡기는 것을 전제로 하고 있습니다.
PR이 올라온 시점부터 병합되기까지
- Author가 구현하고, AI로 셀프 리뷰하여 수정합니다.
- PR을 올리면, CI에서 AI 리뷰가 실행됩니다.
- 리뷰어가 자동으로 할당되고, 각자 자신의 AI로 리뷰를 진행합니다.
- 판단이 필요한 부분은 사람이 읽습니다.
- 지적 사항에 대한 수정이나 재요청 역시 AI의 도움을 받아 Approve가 붙으면 병합(Merge)합니다.
셀프 리뷰의 한계
PR을 올리기 전에 Author도 자신의 AI로 셀프 리뷰를 합니다.
하지만, 셀프 리뷰만으로는 누락이 발생하기 때문에 팀 내에서 서로 꼼꼼하게 리뷰하는 과정을 거치고 있습니다.
우선, AI가 보는 관점은 사람마다 다릅니다.
AI에 전달되는 Context File(컨텍스트 파일) 역시 팀 차원에서 완전히 통일되어 있지 않고, 각자 오버라이드(override)하고 있습니다.
같은 PR이라도 누구의 AI가 보느냐에 따라 지적 사항이 달라지기 때문에, 이로 인해 많은 추가적인 지적이 발생합니다.
또한, AI 리뷰는 같은 Context라 하더라도 실행할 때마다 결과가 다릅니다.
1회차에는 나오지 않았던 지적이 3회차에서 나오는 경우가 자주 있습니다.
따라서 자신의 AI를 여러 번 돌리는 것보다 다른 사람의 AI로 검토받는 것이 더 많은 지적 사항을 얻을 수 있다고 생각합니다.
리뷰에 관해서는, 토큰(token)을 모아서 서로 리뷰하는 느낌입니다.
CI의 AI 리뷰
PR을 올렸을 때 CI에서도 AI 리뷰가 실행되도록 하고 있습니다.
원래는 각자의 토큰은 개발에 전념하고, CI만으로 리뷰가 완결되면 좋을 텐데, 구독(Subscription)과 동일한 정밀도의 API를 이용하면 비용이 상당히 높기 때문에, 현재는 각 팀 멤버의 리뷰에 의존하는 상황입니다.
CI AI 리뷰 메커니즘은 '발견', '검증', '통합'의 3단계로 나누어 실행되도록 되어 있습니다.
'발견' 단계에서는 관점별로 AI를 분리하여 각각 독립적으로 리뷰하도록 합니다.
관점은 다음 6가지입니다.
- 정확성 및 데이터 무결성 (Accuracy and Data Integrity)
- 보안 (Security)
- 성능 (Performance)
- 프로젝트 규약 (Project Convention)
- 하위 호환성 (Backward Compatibility)
- 적대적 리뷰 (Adversarial Review)
AI는 오탐지(False Positive)도 꽤 많이 하기 때문에, '검증' 단계에서 지적이 정말 올바른 것인지 별도로 확인합니다.
남은 지적 사항들을 '통합' 단계에서 중요도별로 정리하여 PR에 코멘트합니다.
이는 각자의 AI 리뷰 결과에도 해당되는 내용인데, 어느 정도의 오탐지나 잘못된 지적이 나오는 것은 허용하고 있습니다.
그 지적을 수용할지 여부는 Author가 가장 잘 알고 있기 때문에, 지적하는 쪽에서는 다소 임의적으로 지적해도 좋다는 합의를 하고 있습니다.
lint
작성 방식에 대한 지적도 엄청나게 늘어나기 때문에, 결정론적으로 정할 수 있는 것은 lint로 막고 있습니다.
백엔드와 프론트엔드 모두 각종 linter를 활용하여 팀의 규약을 나타내는 독자적인 규칙을 많이 만들고, 코딩 규칙을 기계적으로 보호하고 있습니다.
더불어 lint로 검증하는 항목은 AI의 Context에서 제외하여 업무 경감화(Streamlining)를 하고 있습니다.
AI에게는 기계로는 보장하기 어려운 문제 등에 집중하도록 합니다.
생각보다 지혜를 짜내면 다양한 커스텀 규칙을 표현할 수 있기 때문에, 앞으로도 이곳은 지속적으로 충실하게 만들어가고 싶다고 생각합니다.
리뷰어 할당
리뷰어는 PR마다 CI에서 자동으로 결정되도록 하고 있습니다.
중요한 PR의 경우에는 수동으로 더 많이 할당하기도 합니다.
할당된 사람은 기본적으로 AI로 자동 검토를 진행합니다.
그 위에서, 중요한 항목이나 중요한 PR에 대해서는 사람의 리뷰도 추가합니다.
기본적으로 사전에 설계 문서를 사람이 리뷰하거나, PR의 단위를 세분화하는 등 AI 리뷰가 원활하게 돌아가도록 여러 가지 노력을 시도하고 있는 상황입니다.
많은 경우 자동으로 AI 리뷰가 처리되기 때문에, 요청부터 첫 번째 리뷰가 붙을 때까지는 대부분의 PR에서 2시간 이내입니다.
이로 인해 지적이 발생한 후 수정하여 재요청하는 루프(loop) 또한 고속화되고 있습니다.
또한, 수정할 때마다 같은 PR에 대해 같은 사람에게 여러 번 리뷰를 요청하게 되므로, 재요청했을 때는 그 리뷰어가 이전에 붙였던 Approve를 자동으로 취소하는 메커니즘을 넣어, 리뷰 요청에 대한 인지도가 낮다는 문제를 해결했습니다.
로컬 오케스트라를 만들고 있다
개인적인 시도이지만, 저의 PR이나 제가 리뷰어로 지정된 PR에 대한 대응은 로컬 PC에서 구동되는 오케스트라 도구를 통해 대부분의 작업을 자동화하고 있습니다.
내가 Author인 PR
- 제가 PR을 'ready for review' 상태로 설정하면 AI가 착수합니다. - AI가 셀프 리뷰를 수행하며 지적 사항을 수정합니다.
- 테스트를 거쳐 커밋(commit)합니다 (2단계와 3단계를 문제가 없을 때까지 반복).
- 푸시(push)합니다.
- 제가 리뷰 요청을 해도 되는지 확인합니다.
- 리뷰어에게 요청합니다 (여러 사람이 자동으로 배정됩니다).
- 지적 사항이 생기면, 분류, 수정, 검증, 푸시, 답변, 재요청까지의 과정을 AI가 진행합니다.
- 설계 판단이 필요하거나 마이그레이션(migration)과 같은 무거운 변경은 AI에게 결정하게 하지 않고 저에게 돌아옵니다.
내가 Reviewer인 PR
다른 사람의 PR은 전용 작업 디렉터리에서 AI가 코드를 읽게 하여 리뷰 코멘트 초안을 만들도록 합니다.
어느 경우든, 중요한 지적이나 판단이 갈리는 부분은 AI로 결정하지 않고 저에게 가져옵니다.
자동화할 수 있는 사소한 영역과 인간의 개입이 필요한 경계를 짓는 것이 어려워 운영하면서 개선을 계속하고 있습니다.
과제 (Challenges)
사람에 의한 체크가 필수적이며, 아직 완전한 자동화와는 거리가 멀기 때문에, 이곳의 자동화를 팀 목표로 설정하여 진행하고 있습니다.
물론 완전한 자동화는 어렵지만, 100%가 아니더라도 90%라면 목표할 수 있을 것이라 생각하며, 조금씩이라도 모든 사람의 작업 대부분이 자동화될 수 있도록 개선을 진행하고 있습니다.
그 과정에서 느끼고 있는 과제들을 정리해 보겠습니다.
AI 수정 방향이 이상하게 흘러감
AI 리뷰를 통해 나온 지적 사항의 분류와 수정까지 AI에게 맡기고 있습니다.
그 때문에 가끔 '왜 이렇게 되었을까?' 싶은 방향으로 수정이 진행됩니다.
lint로 걸리는 것은 막고 있지만, 근본적인 방침 자체가 벗어나는 것은 막을 수 없습니다.
AI가 판단한 배경은 모두 로컬에 로그로 남겨두고 나중에 그 판단이 타당했는지 평가하고 있지만, 체감상 PR의 1할 정도는 '왜 이렇게 되었을까?' 하는 경우입니다.
따라서 이 부분이 해결되지 않으면 '머지 전 인간 체크'를 빼기는 어렵다는 인상을 받습니다.
사람에게 판단을 요구하는 경우가 많음
판단이 필요하면, 먼저 여러 AI 모델에 각각 의견을 내게 하여 결론이 자동으로 나오도록 합니다.
그 위에서 결론이 나지 않는 것만 사람에게 전달하도록 하고 있습니다.
하지만 결과적으로 인간의 판단이 필요한 건수가 아직 많습니다.
'왜 그렇게 판단했어?'라고 묻고 싶을 만한 경우와 별개로, '왜 이게 판단할 수 없는 거야?'라는 경우가 자주 발생합니다.
AI끼리 주고받는 과정에서 AI만이 이해하는 언어로 설명해 오는 경우도 있습니다.
이런 때는 그 단어에 대한 해설을 만드는 것부터 시작하고, 그다음 판단한다는 과정을 빈번하게 거치고 있습니다.
사소한 경계 짓기
모든 PR을 사람이 확인하면 상당히 힘들고 머리도 피로해집니다.
그래서 사소한 PR은 자동으로 머지(merge)하고, 사람은 그렇지 않은 PR의 판단에 집중하는 형태로 하고 싶습니다.
다만, 무엇을 근거로 '사소하다'라고 할 수 있는지가 어려워 결정을 내리지 못하고 있는 것이 솔직한 심정입니다.
변경 행 수가 적다고 해서 안전한 것은 아닙니다.
생산성 향상을 위한 도구라면, 망가져도 큰일이 없는 수준이라면 어느 정도는 자동 머지로 괜찮지 않을까 생각합니다.
UI/UX 리뷰가 취약함
서버 사이드와 같이 로직 기반으로 결정되는 처리는 AI가 고정밀도로 리뷰해주기 때문에 많은 결함을 탐지하고 수정할 수 있습니다.
다만, 화면 측면에서는 아직 리뷰어로서 AI를 충분히 활용하지 못하고 있어, Author의 주관에 의존하여 개발이 진행되고, PdM이나 QA 엔지니어의 테스트 시점에 과제가 발견되는 경우가 여전히 많습니다.
이 부분을 효율화하면 더 높은 정밀도와 속도가 나올 것이라 느끼고 있어, 여러 가지를 정비하고 싶다고 생각합니다.
모두가 동일하게 처리하지 못함
이러한 과제들은 제가 항상 30~50개의 PR을 병렬로 진행하는 과정에서 발생한 것들로, 팀원 전체가 이 정도의 병렬 작업량으로 일하고 있는 것은 아닙니다.
'병렬로 대량의 태스크를 처리한다'는 시스템 자체가 아직 성숙하지 못했다는 것이 과제라고 느끼고 있어, 이곳을 보다 범용적인 구조물로 만들어 팀 내에 전개함으로써 생산성 향상을 도모하고 싶습니다.
과제의 해결을 향하여
시스템으로 해결할 수 있는 부분은 아직 많아 보여서, lint 추가나 플로우 정비, 규칙 재검토 등 하나씩 손을 대고 있습니다.
그 목적을 위해 금요일 오후는 팀원 전체가 개발 효율 개선에 전념하기로 결정했습니다.
AI 관련이든 CI(지속적 통합) 관련이든, 무엇에 손을 댈지는 각자의 판단에 맡기고 있습니다.
지금은 개발 환경 정비에 여러 가지를 도전해보고 싶은 시기라고 생각하기 때문에, 주제는 좁히지 않았습니다.
이 이후에 10배, 100배의 생산성 향상이 있을 수 있다고 느낍니다.
논의 (Discussion)
