AI가 이토록 널리, 당연하게 사용되게 되면서 우리의 개발 프로젝트에도 깊숙이 들어왔습니다. 그 결과, 프로젝트의 성격――특히 「어디가 병목 현상(Bottleneck, 제약 조건)이 되는가」가 기존과는 크게 달라지고 있다고 느낍니다.

말할 필요도 없이, 병목 현상은 프로젝트를 진행하는 데 있어 결정적으로 중요합니다. 제약 이론 (Theory of Constraints)이 말하듯, 시스템 전체의 처리량 (Throughput)은 가장 가는 부분, 즉 병목 현상에 의해 결정됩니다1. 아무리 AI로 개별 작업이 빨라지더라도, 병목 현상이 해소되지 않는 한 프로젝트 전체의 생산성은 올라가지 않습니다. 반대로 말하면, 그 부분이 막히면 프로젝트 전체가 지연되는 리스크의 소재이기도 합니다.

그래서 오늘은, AI 시대의 개발 프로젝트에서 병목 현상이 되고 있는 것은 무엇인가, 그리고 그것을 해소하기 위해 어떤 방법이 있을 수 있는가에 대해 이야기하고자 합니다.

처음에 미리 말씀드려 두자면, 이것은 「실제로 성공했다」는 성공담이 아닙니다. 저 자신도 아직 생각하는 과정에 있으며, 어디까지나 사고 실험이자 이상론입니다. 앞으로 AI 시대의 개발에 우리가 적응해 나가는 과정에서 직면할 문제를 고민하는, 그 논의의 계기가 되기를 바라는 마음으로 이야기하겠습니다. 제가 하는 말에는 오류나 착각도 많이 포함되어 있을 수 있습니다. 그것까지 포함하여 하나의 초안(たたき台)으로 받아들여 주시면 감사하겠습니다.

서두의 질문――AI 시대의 개발 프로젝트에서 병목 현상은 무엇인가――에 대한 저의 결론은, 「인간의 판단」 입니다.

인간의 판단이 필요해지는 지점은 SDLC(Software Development Life Cycle)――소프트웨어를 만드는 공정――의 내부에서 보자면, 크게 **요구사항 정의 (Requirements Definition)**와 리뷰 (Review) 두 곳이라고 생각합니다.

이만큼 AI가 똑똑해지고 설계, 구현, 테스트와 같은 작업이 극적으로 효율화·고속화되어도, 요구사항 정의나 리뷰에서 인간이 판단하는 부분은 역시 계속 남을 것입니다. 그리고 그 부분이 병목 현상이 된다――이것은 후술할 대기행렬 (Queue) 구조로부터 이론적으로도 도출할 수 있으며, AI 주도 개발 (AI-driven development)을 현장에서 수행하고 계신 분들의 체감과도 일치할 것이라 생각합니다2.

그렇다면 왜 인간이 병목 현상이 되는 것일까요? 언뜻 당연한 이야기처럼 보이지만, 여기서 한 번 멈춰서 정리해 두겠습니다.

이유는 AI의 비용과 병렬성에 있습니다. 이제 AI의 추론 비용은 크게 낮아졌으며, 많은 상황에서 개발자 한 명의 인건비보다 에이전트(Agent)를 구동하는 비용이 더 저렴합니다3. 그리고 무엇보다, 돈을 아끼지 않는다면 얼마든지 병렬로 늘릴 수 있습니다. 따라서 AI가 담당하는 설계나 구현 작업은 점점 병렬화되어 빠르게 진행될 수 있습니다 (물론 모델의 선택이나 태스크의 성격, 사용법에 따라 비용은 크게 달라집니다. 여기서 핵심은 「싸다」는 것보다 오히려 「병렬로 늘릴 수 있다」는 점입니다).

반면, 리뷰――특히 최종적인 품질 판단의 책임――은 인간에게 남습니다. AI에게 1차 리뷰를 시키는 것 자체는 가능하지만, 그 결과를 받아들여 「이것으로 좋다」고 승인하는 판단은 현재로서는 인간에게 남아 있습니다. 그렇게 되면 고속으로 양산되어 오는 성과물에 대해, 인간이라는 한정된 창구 앞에 **대기행렬 (Queue)**이 발생합니다. 대기행렬 이론 (Queueing Theory)이 가르치듯, 빠른 생산자가 단일한 느린 처리 창구에 계속해서 일을 흘려보내면 대기 시간은 급증합니다 (처리 창구의 가동률이 상한에 가까워질수록 대기 시간은 급격히 늘어납니다)4. 이것이 병목 현상의 정체입니다.

인간이 담당하는 것은 앞서 말씀드린 대로 크게 두 가지입니다. 하나는 무엇을 만들 것인가 (의도·요건)를 결정하는 것 (요구사항 정의)――인간이 기점이 되는 발안입니다. 다른 하나는 그 의도에 비추어 AI가 생성한 것 (설계·구현·테스트, 그리고 설계 판단 그 자체)이 올바른지를 판정하는 것 (리뷰)――AI의 출력을 승인하거나 반려하는 평가입니다.

오늘은 이 중 요구사항 정의는 일단 제쳐두고, 리뷰에 초점을 맞추겠습니다. 리뷰의 병목 현상을 어떻게 해소하면 좋을지, 그 부분을 중심으로 이야기하겠습니다.

리뷰의 병목 현상을 해소하는 방법은 크게 세 가지가 있다고 생각합니다.

• 인간 리뷰어의 수를 늘린다
• 1인당 리뷰를 빠르게 처리할 수 있도록 한다 (리뷰 부하를 낮추거나 / 리뷰 능력을 높임)
• 애초에 리뷰해야 할 범위를 좁힌다 (다른 방법으로 해결함)

**첫 번째 「리뷰어의 수를 늘린다」**는 가장 알기 쉬운 해결책입니다. 대기행렬은 창구를 늘리면 빠르게 처리할 수 있다는 것은 상식적인 대응일 것입니다.

**두 번째 「1인당 리뷰 처리 속도를 높인다」**에는 두 가지 방향이 있습니다. 하나는 개개인의 리뷰 능력 그 자체를 높이는 것입니다. 다른 하나는 리뷰 부하를 줄이는 방안을 마련하는 것입니다. 후자의 예로는 리뷰하기 쉬운 대시보드를 준비하거나, 혹은 AI의 출력이 인간이 읽기에 어렵다면 이를 읽기 쉬운 형태로 변환하는 메커니즘을 만드는 방식 등을 생각할 수 있습니다.

다만, 방법 1과 2에는 공통된 한계가 있습니다. 둘 다 「희소한 인간의 리뷰 능력」을 늘리거나 연마하는 방향이며, 효과는 인간이라는 자원의 양에 대해 선형적으로만 증가합니다. 인간은 희소 자원이기에, 인원수를 계속 늘리는 것도, 한 사람의 처리 속도를 계속 높이는 것도 결국 한계에 부딪히게 됩니다.

이와 대조적으로 **세 번째 「리뷰해야 할 범위를 좁힌다」**는 성격이 다릅니다. 이는 인간의 능력을 늘리는 것이 아니라, 애초에 인간이 리뷰해야 하는 대상을 줄이는 것――대기행렬에 쌓이는 작업량 그 자체를 구조적으로 깎아내는 방향입니다. 그래서 저는 이 세 가지 중 이것이 가장 비용 대비 효과(Cost-effectiveness)가 높지 않을까 생각합니다. 어디까지나 제 견해입니다만, 인간이라는 제약에 대해 선형적으로만 작용하는 방법 1·2보다, 제약에 걸리는 부하 자체를 줄이는 방법 3의 효과가 더 클 것이라고 보고 있습니다.

구체적으로는, 정적 분석(Static Analysis)이나 자동 테스트(Automated Test) 등 기계적·결정론적(Deterministic) 프로그램으로 처리할 수 있는 부분은 그쪽에서 처리한다는 뜻입니다.

즉, 이런 발상입니다――사양(Specification)이나 테스트 케이스(Test Case)가 올바른지는 인간이 리뷰한다. 그 테스트를 통과하는 형태로 구현이 되어 있다면, 구현 내용을 한 줄씩 인간이 읽어야 할 필요는 크게 줄어든다. 이렇게 리뷰 대상을 압축하는 것입니다.

――단, 제약 이론(Theory of Constraints)이 가르쳐주듯, 병목 현상(Bottleneck)은 해소된다고 해서 사라지는 것이 아니라, 다음으로 느린 공정으로 이동합니다1. 리뷰 범위를 테스트로 좁히더라도, 이번에는 「그 테스트나 사양 자체가 올바른가」를 인간이 리뷰해야 할 필요가 남습니다. 즉 병목은 사라지지 않습니다. 변하는 것은 리뷰의 "대상"입니다―― 「AI가 양산한 모든 구현」에서, 「인간의 의도를 나타내는 더 작고 안정적인 면」으로 옮겨가는 것입니다. 목표는 병목을 없애는 것이 아니라, AI에게 위임할 수 있는 영역을 넓혀 인간의 책무보다 작은 면으로 옮기는 것에 있습니다. 그렇다면 그 「작은 면」을 어떻게 만들 것인가. 그것이 다음 이야기입니다.

인간이 하지 않으면 어쩔 수 없는 부분은, 반복해서 말씀드리지만, 무엇을 만들지 결정하는 것과, 기계적으로는 판정할 수 없는 올바름――예를 들어 설계 판단의 좋고 나쁨――을 판별하는 것입니다. 역으로 말하면, 요건이나 사양에 관한 판단이 개입되는 테스트를 자동화할 수 있다면, 인간이 리뷰해야 할 범위를 상당히 좁힐 수 있을 것입니다.

이하, 그 관점에서 3가지 종류의 테스트를 차례대로 살펴보겠습니다. 이것들은 「인간의 의도가 어디에 깃들어 있는가」에 따라 나눈 세 가지 면――시나리오·보편 조건·설계 판단――에 대응합니다.

가장 먼저 하고 싶어지는 것이 **시나리오 테스트(Scenario Test)**입니다. 이른바 종합 테스트나 인수 테스트(Acceptance Test)에 해당합니다.

최종적으로 사용자가 실제 업무에서 시스템을 사용하는 상황을 상정하고, 그 시나리오 안에서 시스템이 자신의 의도대로 동작하는지, 현실에서 제대로 도움이 되는 형태로 기능하는지를 확인하는 것――그것이 시나리오 테스트입니다. 이를 작성함으로써 필요한 요건의 누락이 없는지를 확인할 수 있고, 동시에 요건대로 시스템이 동작하는지도 검증할 수 있습니다.

여기서 구체적인 예를 하나 들겠습니다. 제가 개인적으로 만들고 있는 Moira(모이라)라는 프로젝트 관리 시스템5에서는, 인수 시나리오를 다음과 같은 「행위(When / Then)」와 「화면의 변화(Before → After)」의 형태로 작성하고 있습니다.

예를 들어 "진행 중인 태스크를 '더 이상 필요 없음'으로 판단하여, 솔직하게 취소한다 (달성률 100%로 위장하여 종료하지 않는다)"라는 시나리오는 다음과 같이 작성합니다.

행위 (When / Then)

When 개발자가 진행 중인 태스크 T를 "더 이상 필요 없음"이라고 판단하고, 이유를 첨부하여 취소한다
Then T는 활성 목록(작업 큐·리뷰 큐·미할당 백로그)에서 사라진다
And T는 "취소됨(수행 불필요·이유 포함)"임을 화면에서 명확히 알 수 있고,
...

화면의 변화 (Before → After)

포인트는 역할 분담입니다. 인간은 이 「동작」과 「화면의 변화」를 리뷰하기만 하면 됩니다. "음, 취소하면 이렇게 동작했으면 좋겠어"라고 의도대로인지 확인합니다. 그리고 이를 실제 E2E 자동 테스트로 작성하고, 실행하여 그린(Green)이 되는지 확인하는 작업은 AI에게 맡긴다――이러한 역할 분담이 가능하지 않을까 하는 이야기입니다. 이를 통해 인간이 리뷰해야 할 범위는 확실히 좁아집니다.

여기서 한 가지, "시나리오는 인간이 리뷰하여 의도대로임을 확인했다고 치더라도, AI가 그 시나리오를 정확히 반영한 자동 테스트를 작성할 수 있을까? 정말 신뢰할 수 있을까?"라는 의문을 갖는 분도 계실 것입니다. 이는 매우 타당한 의문입니다.

제 견해는 이렇습니다. 시나리오를 생각하는 작업은 현실의 업무와 시스템을 잇는 「가교」이며, 시스템의 동작이 타당한지 판단하는 작업입니다. 이 부분은 인간만이 할 수 있습니다. 반면, 일단 확정된 시나리오를 테스트 코드(Test Code)로 옮기는 작업은 자연어의 의도를 실행 가능한 형태로 옮겨 적는 작업으로, 비교적 AI가 실력을 발휘하기 쉬운 영역입니다.

다만――이 점이 중요합니다만――「신뢰해도 좋다」는 것이 「검증을 버려도 좋다」는 의미는 아닙니다.

먼저, 「신뢰해도 좋다」는 이유는 E2E 테스트에는 기계적인 제동 장치가 있기 때문입니다. AI가 작성한 테스트는 실제 시스템에 대해 실제로 실행되며, 그린(Green)/레드(Red) 결과가 나옵니다. 번역을 실수했다면 대부분의 경우 테스트가 실패하여 알아챌 수 있습니다. 이 「실행하여 확인할 수 있다」는 점이, AI의 추론이 개입하는 대조 작업보다 신뢰를 두기 쉬운 이유입니다.

한편, 「검증을 버려도 좋다」가 될 수 없는 이유는, 그럼에도 테스트가 그린(Green)이라 하더라도 틀릴 수 있기 때문입니다. 헛도는(아무것도 검증하지 않는) 어서션(Assertion)을 작성해 버리거나, 애초에 사양의 일부를 테스트하는 것을 잊어버리는 등――이러한 누락은 발생합니다. 테스트는 버그의 존재는 보여줄 수 있어도, 부재를 증명할 수는 없습니다6. 따라서 실무에서는 AI가 작성한 테스트나 프로퍼티(Property) 자체를 다른 에이전트의 적대적 리뷰(Adversarial Review)나 인간의 리뷰에 맡깁니다. 이것이 현실적인 타협점이라고 생각합니다.

그렇다면 E2E 테스트를 작성하면 그것으로 충분하냐고 묻는다면, 아직 불충분합니다.

E2E 테스트는 결국 구체적인 시나리오의 모음입니다. 구체적인 예를 유한하게 나열하는 접근 방식인 이상, 입력의 조합을 모두 망라할 수는 없습니다.

그렇다면 시나리오 테스트만으로는 어떤 케이스를 놓치게 될까요? 그것은 시스템이 가져야 할 보편적인 조건――어떤 시나리오에서도 반드시 성립해야 하는 전제 조건 같은 것――입니다. 이는 E2E 테스트로는 다 확인할 수 없습니다.

예를 들어 Moira에는 다음과 같은 보편적 조건이 있습니다5.

• 「달성률 (EV%)은 반드시 0~100% 범위 내에 있어야 한다.」
• 「이벤트 기록 순서를 바꾸더라도 도출되는 결과는 완전히 동일해야 한다」 (동일한 시각·동일한 ID의 순서를 유지하는 한).

이러한 성질은 특정 시나리오를 아무리 쌓아 올려도 다 확인할 수 없습니다. 시나리오 테스트는 "태스크를 취소하면 달성률이 올라간다"와 같은 하나의 구체적인 예를 검증하는 것이지만, "어떤 입력 조합이라도 달성률이 100%를 넘지 않는다"거나 "기록 순서에 관계없이 결과가 유일하게 결정된다"는 것은 그 방어 범위 밖에 있습니다. 그래서 놓치게 됩니다.

이 문제에 대한 해결책이 바로 프로퍼티 기반 테스트 (Property-based Testing) 입니다.

지금까지 우리가 친숙하게 접해온 기능 테스트는 기본적으로 엑샘플 (Example, 구체적 예시) 기반 테스트입니다. 양자의 차이는 다음과 같습니다.

엑샘플 기반 테스트는 결국 엔지니어가 상상할 수 있는 범위 내에서만 검증할 수 있습니다. 이와 대조적으로 프로퍼티 기반 테스트는 인간이 놓치기 쉬운 입력의 조합까지 자동으로 찔러줍니다. 그렇기에 시나리오 테스트의 빈틈을 메울 수 있는 것입니다.

강조하고 싶은 점은, **E2E 테스트와 PBT는 어느 한쪽만으로 충분한 것이 아니라 상보적(Complementary)**이라는 사실입니다. E2E는 "특정 현실 시나리오에서 타당한가"를, PBT는 "모든 경우에 보편적 조건이 깨지지 않는가"를 봅니다. 커버리지가 다르기 때문에 둘 다 필요합니다.

덧붙이자면, 프로퍼티 기반 테스트는 AI 시대에 탄생한 새로운 기법이 아니라, 20년 전부터 존재해 온 개념입니다 (PBT의 프레임워크로 널리 알려진 QuickCheck의 논문은 2000년에 발표되었습니다)7. 그렇다면 왜 지금까지 폭발적으로 보급되지 않았느냐 하면, 그 이유 중 하나가 "시스템의 보편적 조건을 인간이 추출하는 작업의 어려움" 때문이었습니다 (그 외에도 테스트 데이터 생성기 설계의 어려움 등 여러 장벽이 있습니다)8.

그 "보편적 조건의 추출"은 AI가 제안을 돕기 쉬운 작업이기도 합니다. 따라서 AI를 잘 활용한다면 기존의 장벽 중 하나를 낮출 수 있지 않을까—라고 생각합니다9. 다만, 여기서도 "신뢰하되 검증하라"는 원칙은 동일합니다. AI가 보편적 조건을 제안할 수 있는 것과, 그것이 올바른 보편적 조건인지는 별개의 문제이므로, AI가 기안한 프로퍼티는 역시 인간이 하나씩 리뷰하고 승인해야 합니다. AI에 의해 PBT가 쉬워질 것이라는 전망 자체는 아직 저에게 가설 단계이며, 앞으로 실증해 나가야 할 과제라고 생각합니다.

지금까지 프로퍼티 기반 테스트를 통해 시스템의 보편적 조건을, 시나리오 테스트를 통해 현실 업무에 접지된 유한한 시나리오를 각각 검증할 수 있었습니다. 그렇다면 이것으로 충분할까요? 안타깝게도 이것만으로는 여전히 놓치는 영역이 있습니다.

그것이 바로 **설계 판단 (Design Decision)**입니다.

기능 테스트나 시나리오 테스트로는, 예를 들어 "유지보수성이 높은 시스템을 만들기 위해 이러한 설계 방침으로 진행하자"라고 결정한 부분은 검증할 수 없습니다. 시스템은 그 설계 판단을 지키고 있든 지키지 않고 있든, 기능적으로는 동일하게 동작해 버리기 때문입니다.

Moira를 예로 들어보겠습니다5. Moira에는 "계산의 '토대'와 '계산 그 자체'를 분리한다"라는 최상위 설계 원칙이 있습니다. 토대(시스템의 핵심)는 "구조·불변 조건·메커니즘"만을 가지며, "평가·값·계산식"은 모두 하류(Downstream)로 넘긴다는 방침입니다. 이를 지키지 않으면 동일한 지표가 여러 곳에서 제각각 계산되어, 이른바 **"두 개의 진실 (Two Truths)"**이 발생하게 됩니다.

하지만—이 방침이 지켜지고 있는지 여부는 시나리오 테스트로는 알 수 없습니다. 화면에 나오는 숫자가 맞는지 틀린지는 테스트할 수 있어도, 그 숫자가 "토대에서 단 한 번 계산된 것"인지 "화면 측에서 몰래 재계산된 것"인지는 동작 테스트(Behavioral Test)만으로는 보이지 않기 때문입니다.

그리고 이 설계 판단 중에도 자동 테스트로 만들 수 있는 것과 없는 것이 있습니다.

자동 테스트로 만들 수 있는 설계 판단의 예:

• "토대는 하류의 계산에 의존해서는 안 된다" (앞서 언급한 설계 원칙). 이는 의존 관계를 기계적으로 체크하는 **아키텍처 적합성 테스트 (Architecture Fitness Function)**로 잡아낼 수 있습니다. Moira에서는 정적 분석 도구를 사용하여 "순환 의존 금지"나 "토대가 계산 측을 포함하지 않음"과 같은 의존 방향 규칙을 CI에서 실제로 실행하고 있습니다 (현재는 아직 단순한 대리 규칙 단계이며 본격적인 경계 강제는 앞으로의 과제이지만, 방향성은 이와 같습니다).
• "기록은 추가 전용이며, 과거를 수정하지 않는다 / 삭제 API를 갖지 않는다 / 이벤트의 종류는 4개뿐이다". 이 중 "삭제 API를 갖지 않는 것"과 "이벤트 종류가 4개로 고정되어 있는 것"은 **타입 테스트 (Type Test)**를 통해 기계적으로 보장할 수 있습니다. 나아가 "과거를 수정하지 않고, 동일한 기록이라면 동일한 결과가 재현된다 (추가 전용)"라는 성질은 앞서 언급한 프로퍼티 기반 테스트로 확인합니다 (기록의 순서를 바꿔도 결과가 변하지 않는다는 성질이 바로 이것입니다).

이러한 것들은 이상적으로 말하자면 모두 자동 테스트로 만들어야 한다고 생각합니다.

자동 테스트로 만들기 어려운 설계 판단의 예:

• 「사람의 기술이나 숙련도를 모델화하지 않는다 (누가 어떤 태스크를 수행할지는 시스템이 자동으로 매칭하지 않고, 인간이 외부에서 결정한다)".

이것은 의도적으로 '하지 않는 것'에 대한 판단입니다. 이러한 "부재(absence)"를 기존의 테스트로 확인하는 것은 어렵지만, AI에게 대조하게 할 수는 있습니다. "코드 안에 정말로 기술(skill) 항목이 없는가", "할당을 자동으로 산출해 버리는 경로가 없는가"를 AI가 코드베이스를 읽어 확인하는 것입니다 ("없다는 것"을 확인하므로 **부의 대조 (negative matching)**라고 부릅니다).

다만, 이 부분은 E2E 때보다 더욱 신중해야 합니다. "있는 것을 확인하는 것"은 하나만 찾아내면 끝나지만, "없는 것을 확인하는 것"은 코드베이스 전체를 보고 나서야 비로소 말할 수 있습니다. 만약 AI가 동의어인 구현(예: skill을 proficiency라고 쓰는 등)을 놓친다면, 찾지 못하고 "없음 (ALIGNED)"이라고 오판할 수 있습니다. "없다는 것을 확인하는 것"은 본질적으로 어렵습니다. 게다가 E2E 테스트와 달리 실행을 통한 기계적인 제동 장치가 없습니다 (실행해서 그린/레드가 되는 방식이 아닙니다). 따라서 이것은 어디까지나 "어느 정도"의 신뢰입니다.

정리하면 다음과 같습니다.

• 설계 판단 자체가 옳은가 (Yes / No) ―― 이것은 인간이 하나하나 리뷰합니다.
• 그 판단이 실제로 코드베이스에 반영되었는가 ―― 자동 테스트 (fitness 함수, 타입 테스트, PBT)로 잡아낼 수 있는 것은 잡아냅니다. 어려운 것은 AI에게 대조하게 합니다. 그럼에도 완전히 신뢰할 수 없는 부분은 인간이 눈으로 직접 확인합니다.

참고로, 설계 판단 중에는 애초에 테스트 대상이 정의상 존재하지 않는 것도 있습니다. 예를 들어 "작업을 어디까지 세밀하게 분해할 것인지, 그 입도(granularity)를 규칙으로 묶지 않고 인간의 판단에 맡긴다"와 같은 판단입니다. 이런 것들은 자동 테스트에도 AI 대조에도 적합하지 않으며, 순수하게 인간이 리뷰할 수밖에 없습니다.

마지막으로 요약입니다.

지금까지 AI 시대의 병목 현상(Bottleneck)은 인간의 리뷰(최종 판단)라는 점, 그리고 이를 해소하려면 "인간이 리뷰해야 할 범위를 좁히는 것"이 가장 레버리지가 크다는 점을 말씀드렸습니다. 그리고 그것은 병목을 없애는 것이 아니라, 인간이 서 있는 위치를 더 작고 안정적인 면으로 옮기는 것이라고도 말씀드렸습니다.

이를 위해서는 결정론적인 프로그램으로 품질을 기계적으로 뒷받침하고, 인간의 리뷰 대상을 깎아 나간다는 사고방식이 축이 됩니다. 정적 분석이나 린트(Lint)도 그 일부이지만, 가장 큰 영역은 역시 자동 테스트입니다. 그중에서도 핵심은 인간의 의도가 테스트에 제대로 반영되는 것입니다. 그렇기에 그것을 ①E2E 테스트, ②프로퍼티 기반 테스트 (Property-based Testing), ③설계 판단의 검증이라는 형태로 구체화해 나가는 것이 중요하다는 이야기였습니다 (이 세 가지는 인간이 리뷰해야 할 "의도가 깃든 면"으로 구분한 것입니다).

그렇다면, 이를 바탕으로 개발 흐름은 어떻게 될까요? 마지막으로 그 전체상을 Moira에서의 실제 방식을 예로 들어 말씀드리겠습니다5.

Moira에서는 먼저 인간과 AI가 대화하며 요구사항 정의서에 해당하는 것을 "기점"으로 삼아 만들어가는 것에서 모든 것이 시작됩니다 ("옆에 둔다"라고 말했던 요구사항 정의도 흐름 속에서는 여기서 등장합니다). 다만, 이 기점이 되는 문서는 상당히 추상적이며, 개선을 거듭할수록 인간이 직접 읽고 이해하기 어려운 것이 되어갑니다.

그래서 이를 인간이 리뷰하기 쉬운 3가지 면으로 분할하고 있습니다.

• 시나리오 (수락 시나리오 집합 = 외적 타당성: 만들어야 할 것을 제대로 만들고 있는가)
• 프로퍼티 목록 (보편 조건의 목록 = 내적 일관성: 어떤 상황에서도 깨지지 않는 전제가 지켜지고 있는가)
• 설계 판단 목록 (설계 판단의 목록 = 구조적 건전성: 유지보수성 등의 판단이 논리적으로 일관되는가)

그리고 인간은 "이 시나리오는 내 의도대로인가", "이 프로퍼티나 설계 판단은 Yes인가 No인가"를 자신의 눈으로 하나하나 리뷰합니다. 이것이 인간이 소유하는 영역, 즉 앞서 말한 "인간이 서 있는, 작고 안정적인 면"입니다.

그 다음 단계―― 이것들을 바탕으로 테스트를 작성하는 작업은 AI가 수행하며, 그 테스트의 합격 여부는 결정론적으로 확인됩니다. 그렇기에 여기서 품질은 어느 정도까지 기계적으로 뒷받침됩니다. 물론 테스트를 통과한다는 것이 결함의 부재를 증명하는 것은 아닙6. 그럼에도 인간이 한 줄씩 구현을 쫓는 대신, 의도 그 자체를 리뷰하는 곳에 설 수 있게 한다―― 이것이 제가 생각하는 하나의 이상적인 개발 흐름입니다.

반복해서 말씀드리지만, 이것은 어디까지나 하나의 이상론이며 현재 제가 개인적으로 생각하고 있는 것에 불과합니다. "아니, 이 부분은 다르지 않은가", "이 부분은 아직 해결되지 않은 것이 아닌가"―― 그러한 논의의 계기가 된다면 기쁘겠습니다. 이 글을 읽고 무언가 생각하신 점, 의견, 소감이 있다면 꼭 보내주시기 바랍니다. 감사합니다.

본고의 사실 주장 중, Moira에 관한 구체적인 예시는 모두 내부 확정 문서(설계·사양 문서)에 근거하고 있습니다5. 일반적인 이론에 대한 참조는 널리 확립된 1차 문헌을 인용했습니다. 일반 이론 이외의 세 가지 점――AI의 추론 비용(Inference Cost) 수준 / AI 시대의 PBT / "리뷰가 병목(Bottleneck)이 된다"는 실증――은 추후 웹 검색을 통해 사실 확인을 거쳐 출처를 각주에 보충했습니다. 결과적으로, 추론 비용의 대폭적인 하락은 권위 있는 통계로 뒷받침되는 한편, "AI가 인건비보다 저렴하다"는 현시점 및 많은 케이스에서의 경향에 머물러 있으며 반대 방향의 예측(Gartner)도 존재하기 때문에 단정은 피했습니다(3). AI에 의한 PBT 지원은 연구의 급증과 선도 기업의 실운용까지는 사실로 확인되었으나, "주류화 = 조류"라고 단정 지을 수는 없습니다(9). **"리뷰가 병목이 된다"**는 인과관계를 분리한 동료 검토(Peer Review) 연구는 부족하지만, 개발 텔레메트리(Telemetry)에서 동일한 패턴이 직접 관찰되고 있으며, 본고는 〈이론적 추론 + 실데이터〉로서 이를 위치시키고 있습니다(2).

제약 이론 (Theory of Constraints). E. M. Goldratt & J. Cox,

The Goal(North River Press, 1984). "시스템의 처리량(Throughput)은 제약(Bottleneck)이 결정한다", "제약을 해결하면 다음 제약이 나타난다" (Five Focusing Steps)라는 개념. ↩ ↩2 -
"AI 개발에서 리뷰(인간의 최종 품질 판단)가 병목이 된다"는 것을 RCT(무작위 대조 시험) 등으로 인과적으로 분리한 동료 검토 연구는 제가 아는 한 아직 부족합니다. 반면, 개발 텔레메트리에서는 이 패턴이 직접 관찰되고 있습니다. Faros AI(1,255개 팀, 1만 명 이상의 실측, 2025)에 따르면, AI 채택률이 높은 팀은 완료된 태스크 +21%, 머지(Merge)된 PR +98%로 생성 측면은 증가하는 반면, PR 리뷰 시간은 +91% 증가하였고, 기업 수준의 처리량(Throughput), DORA 지표, 품질에는 유의미한 개선이 보이지 않아 "하류의 병목이 AI의 증가분을 흡수한다"고 보고되었습니다 ("The AI Productivity Paradox," 2025). 이는 Google의 DORA 보고서와도 일치합니다 (Accelerate State of DevOps 2024: AI 채택이 약 25% 증가하면 딜리버리 안정성이 약 7.2% 저하 / State of AI-assisted Software Development 2025: AI는 조직의 강점과 약점을 증폭시키며, PR을 비대하게 만들어 리뷰를 압박한다). 또한, 경험이 풍부한 개발자를 대상으로 한 RCT에서는 AI 이용으로 인해 오히려 작업 시간이 19% 증가한 사례도 있어 (J. Becker, N. Rush, E. Barnes, D. Rein, "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity," METR, arXiv:2507.09089, 2025), "AI = 즉각적인 고속화"라는 전제 자체에도 유보가 필요합니다. 본고의 주장은 이러한 실데이터와 대기행렬 이론(Queueing Theory) / 제약 이론으로부터의 구조적 추론에 기반한 위치로 읽어주시길 바랍니다. ↩ ↩2 -
추론 비용의 하락. Stanford HAI,

2025 AI Index Report, 제1장(2025)에 따르면, MMLU에서 GPT-3.5 수준(점수 64.8)을 내는 모델의 추론 가격은 2022년 11월의 $20.00/100만 토큰에서 2024년 10월의 $0.07/100만 토큰(Gemini-1.5-Flash-8B)으로, 약 18개월 만에 '280배 이상' 하락했다. 하락률은 태스크(Task)나 성능 수준에 따라 크게 다르다(성능이 일정하다고 가정할 때 연간 9~900배): B. Cottier 외 (Epoch AI), "LLM inference prices have fallen rapidly but unequally across tasks" (2025). 다만 "개발자의 인건비보다 AI가 더 저렴하다"는 점은 지역, 이용량, 모델 선택에 강하게 의존하며, 이를 직접 비교한 피어 리뷰(Peer-reviewed) 연구는 확인되지 않는다. 오히려 Gartner는 토큰 소비의 급증을 배경으로, 2028년까지 AI 코딩 비용이 평균적인 개발자의 급여를 상회할 수 있다고 예측하고 있다 ("Gartner Predicts AI Coding Costs Will Surpass Average Developer's Salary by 2028 as Token Consumption Surges," 보도자료, 2026-06-24). ↩ ↩2 -
대기 행렬 이론 (Queuing Theory). J. D. C. Little, "A Proof for the Queuing Formula: L = λW,"

Operations Research(1961). 및 처리 창구의 가동률이 상한에 가까워질수록 대기 시간이 급증하는 성질 (J. F. C. Kingman의 근사식, 1961). ↩ -
본고의 Moira 사례는 모두 Moira 자체의 내부 설계 문서에 기반한다 (본 기사 작성 시점에서는 미공개된 개인 프로젝트). 구체적으로는, 취소(Cancel) 시나리오는 수락 시나리오 집합에, 속성(Property)(달성률 0~100% = PR-EVPCT-RANGE / 기록 순서 불변 = PM-ORDER-INV)은 속성 목록에, 설계 결정(토대와 계산의 분리 = D-4 / 추가 전용 4개 이벤트 = D-3 / 착수 가능 여부 = D-2 / 스킬 비모델화 = D-34)은 설계 결정 카탈로그에, 3면 리뷰 체계는 프로젝트의 스티어링(Steering) 문서에, fitness 함수는 의존성 체크 도구(dependency-cruiser)에 의한 구성으로서 각각 관리하고 있다. ↩ ↩

2↩3↩4↩5 -
E. W. Dijkstra, "Notes on Structured Programming" (1970) 외. "테스트는 버그의 존재를 보여주기 위해 사용할 수 있지만, 버그의 부재를 보여주기 위해 결코 사용할 수 없다". ↩ ↩

2 -
K. Claessen & J. Hughes, "QuickCheck: A Lightweight Tool for Random Testing of Haskell Programs,"