테스트를 건네주면, AI는 빨간색을 보고 수정합니다

이것은 이제 누구나 알고 있는 사실이라고 생각합니다. 테스트를 먼저 준비하고 AI에게 구현하게 하면, 실패를 읽고 스스로 수정합니다. 특별한 일은 일어나지 않았습니다.

그렇다면, 그 상태에서 자리를 비울 수 있을까요?

똑같은 일을, 아무도 보지 않는 상태에서 끝까지 해낼 수 있을까요. 여기서 손이 멈춘다면, 그것은 AI의 능력만의 문제가 아닙니다. 앉아 있는 동안 자신이 무엇을 하고 있는지를 우리는 의외로 파악하지 못하고 있습니다.

한번 실제로 자리를 비워보았습니다. 돌아온 67건의 리뷰 지적이 생각보다 훨씬 솔직한 답이었습니다.

24시간, 맡겨보았다

Jira 티켓을 집어 들고, 수락 조건(Acceptance Criteria)을 읽게 하고, TDD 기반으로 구현하여 PR을 만드는 것까지 무인으로 돌렸습니다. 인간은 보고 있지 않습니다.

한 가지, 나중에 중요해지므로 미리 써둡니다. 테스트는 제가 작성하지 않았습니다. 수락 조건으로부터 AI가 테스트를 생성하고, 그대로 스스로 구현했습니다. 테스트 취급에 대한 제약이나 지시도 두지 않았습니다.

24시간 동안 15개의 PR이 만들어졌고, 그것을 제가 혼자서 평소와 같은 기준으로 리뷰했습니다. 통계적인 조사가 아니라, 제 현장에서의 1회분 케이스 스터디입니다.

자율 주행은 성립했으나, 검증은 자기 채점이었습니다

아침이 되어 보니 PR이 나열되어 있었습니다. 멈춰야 할 곳에서 멈춰 있었고, 무한 루프에 빠지는 일도 없었으며, 테스트는 초록색(Pass)입니다. 무인으로 돌린다는 부분에 대해서는 성립되었습니다.

다만, 초록색으로 확인할 수 있는 것은 "수락 조건을 만족했다"는 것이 아닙니다. "AI가 수락 조건을 해석하여 테스트로 표현한 범위를, AI 자신의 구현이 만족했다"는 것입니다. 해석, 테스트로의 사상(Mapping), 구현이라는 3단계가 있으며, 초록색이 직접 확인하고 있는 것은 3단계인 구현이 2단계인 테스트에 적합하다는 것뿐입니다.

테스트 변조 방지만으로는 이 문제를 막을 수 없습니다. 나중에 완화하는 것을 금지하더라도, 최초의 해석이 틀렸다면 틀린 테스트가 그대로 고정됩니다. 제약을 두는 위치가 상류로 옮겨져 있는데, 그곳에 해석을 외부에서 검증하는 메커니즘이 없었습니다.

자율 주행은 성립했으나, 판정의 독립성은 성립하지 않았다. 이 상태에서 무슨 일이 일어났는지가 다음의 67건입니다.

리뷰는 끝나지 않았습니다

테스트가 통과하고 있는데도 지적할 사항이 차례차례 나왔습니다. 15개 PR에 총 67건. 여러 논점에 걸쳐 있는 것도 있지만, 주된 원인을 하나로 정해 분류했습니다.

자율 주행에는 성공했지만, 리뷰를 불필요하게 만들 수 있는 상태는 아니었습니다. 부하가 늘었는지 줄었는지는 통상적인 개발 시의 PR당 지적 수와 비교하지 않았기에 말할 수 없습니다. 다음부터는 측정하겠습니다.

67건은 같은 이유로 나온 것이 아닙니다

한 건씩 읽어 내려가니 유래가 세 가지로 나뉘었습니다.

노출된 것

사양에 적혀 있지 않았기에 AI가 결정했다. 테스트는 통과한다. 하지만 의도한 것이 아니다. 목록 필터링을 앱 측에서 할지 DB 측에서 할지, 정형 처리(Formatting)를 어느 계층에 둘지, 에러 메시지에 어디까지 정보를 포함할지——모두 수락 조건에는 적혀 있지 않았고, 적혀 있지 않은 이상 AI는 무언가를 결정할 수밖에 없습니다.

공통점은 결정된 내용이 아니라, 결정했다는 사실이 어디에도 기록되어 있지 않다는 것입니다. 대화를 하고 있다면 AI는 모호한 부분에서 "어느 쪽으로 할까요?"라고 물어올 것이고, 묻지 않더라도 구현을 쫓는 과정에서 알아챌 수 있습니다. 모호함은 대화가 흡수하고 있으며, 비용으로서 표면화되지 않습니다. 자리를 비우면 흡수할 주체가 없어지며, 모호함은 그대로 구현으로서 확정됩니다. 아무도 확정된 사실을 깨닫지 못한 채 리뷰까지 오게 됩니다.

그래서 순서는 이렇습니다. 흔히 말하는 "무인화를 하려면 명확한 사양이 필요하다"가 아니라, 무인화를 하려고 하면 명확성을 요구받는다. 전제 조건이 아니라 결과로서 직면하게 되는 것입니다.

검출할 수 없었던 것

사양 정합성이 23건으로 돌출된 것은 요건이 모호했기 때문만은 아니라고 생각합니다. 요건을 해석하는 자와 해석의 올바름을 판정하는 자가 동일했기 때문입니다. 잘못 읽더라도 그 읽기에 따른 테스트가 작성되어 초록색이 됩니다. 테스트 7건도 같은 뿌리이며, 자기 채점으로는 이러한 취약점을 검출할 수 없습니다.

23건 중 어디까지가 요건의 모호함이고 어디까지가 해석의 검출 누락인지는 구분할 수 없습니다. 양쪽 모두 작용하고 있으며, 합쳐서 30건, 전체의 45%가 이 영역입니다.

무인화 고유라고 생각하기 어려운 것

규약·nits 11건과 명명·용어 6건은 무인화 그 자체가 원인이라기보다, 프로젝트의 규칙이 자동 검사(Automated Inspection)되지 않았던 점이 드러난 것이라고 생각합니다. 구현 버그 2건과 반려(rejection) 3건도 무인화와는 별개의 계통입니다.

앉아 있는 동안, 무엇을 제공하고 있었는가

앉아 있을 때 우리는 의식하지 못한 채 여러 역할을 수행하고 있습니다. 절차서 어디에도 적혀 있지 않습니다. 앉아만 있으면 무료로 제공되기 때문입니다.

작동한 것은 상위 3개뿐입니다. 하위 3개 중 2개는 자리를 떠났기 때문에 어려웠던 것이 아니라, 검증 방식의 문제였습니다.

그리고 AI가 알아서 결정한 것들은, 외부화되지 않았던 판단의 목록 그 자체였습니다. 계층의 책임(Responsibility)도, 권한 처리 방식도, 테스트의 입도(Granularity)도 모두 제 머릿속에 있었습니다. 단지 어디에도 적혀 있지 않았을 뿐입니다.

67건은 외부화할 곳을 가리키는 지도로 읽을 수 있습니다

동일한 67건을 이번에는 "어디로 외부화하면 방지할 수 있는가"를 기준으로 다시 분류합니다.

17건은 AI인지 여부와 상관없이, 자동 검사나 규칙화로 내리기 쉬운 지적 사항이었습니다. 일단 검증기(Verifier)로 옮겨두면, 리뷰에서 반복적으로 지적하는 비용은 거의 사라집니다.

28건은 다시 기록(Write-back)하면 줄어듭니다. 여기서 한 가지 방법이 있습니다. 구현을 시키는 것이 아니라, 판단이 필요한 부분만 보고하게 하여 무인으로 돌리는 방식입니다. 돌아오는 것은 구현 코드가 아니라 사양(Specification)의 빈틈 목록이며, 인간이 이에 답하고 요구사항에 다시 기록한 뒤 구현을 시작합니다. 이번 23건의 상당수는 이 방식이었다면 구현 전에 표면화될 수 있었을 가능성이 있습니다. 반대로 말하면, 대화로 결정한 판단은 다시 기록하지 않는 한 코드베이스의 지식으로 남지 않습니다. 대화 로그가 남는 환경이라 하더라도, 다음 세션의 AI가 그것을 읽는 것은 아니기 때문입니다.

2건이 가장 위험하고 가장 쓰기 어려운 것이었습니다. 권한 처리나 입력 검증은 아무도 적지 않지만 모두가 전제로 삼고 있으며, 심지어 테스트도 통과합니다. 무인화의 범위를 넓힐 때 가장 먼저 명문화해야 할 곳은 바로 여기라고 생각합니다.

8건은 적어도 일부를 설계 제약(Design Constraint)으로 외부화할 수 있습니다. 의존 방향은 테스트로 작성할 수 있고, 계층의 책임은 아키텍처 규칙이 됩니다. 이미 코드로서 일관되게 존재하는 패턴은 쓰지 않아도 효과가 있습니다. AI가 그 형태에 끌려가기 때문입니다. 8건이 나왔다는 것은 그 부분이 아직 제대로 갖춰지지 않았다는 진단이기도 합니다. 한편으로는 규모를 확인하기 전에는 결정할 수 없는 성능상의 판단처럼, 사전에 적을 수 없는 것들도 섞여 있습니다.

다만, 모두 적으려고 하면 결국 설계 판단 그 자체를 적는 단계까지 가게 됩니다. 거기까지 적으면 무인으로 돌릴 수 있겠지만, 적는 시점에 인간이 거의 전부를 결정하게 됩니다. 무인화의 정도와 사전에 결정해야 하는 양은 트레이드오프(Trade-off) 관계이며, 어느 한쪽으로 치우친다고 해서 편해지는 종류의 문제가 아닙니다.

다음에 시도할 것

이번의 약점은 검증이 자기 채점(Self-grading) 방식이었다는 점이었습니다. 단순히 "테스트를 작성하는 세션과 구현하는 세션을 나누면 독립될 것이다"라고 단정할 수는 없습니다. 동일한 수락 조건(Acceptance Criteria)을 동일한 모델이 유사한 컨텍스트에서 읽는다면, 해석의 오류는 상관관계(Correlation)를 가진 채 남게 됩니다. "X라는 의미다"라고 오독하면, 테스트 측도 X로 작성하고 구현 측도 X로 구현하여 테스트가 통과(Green)되어 버립니다.

세션 분리는 자기 채점에서 한 단계 멀어지는 것일 뿐, 독립성을 획득하는 것은 아닙니다. 그럼에도 다음에는 이 방법을 시도해 보려 합니다. 두 가지 가설이 서기 때문입니다.

• 테스트 7건의 주된 원인이 자기 채점이라면 건수가 줄어들 것이다. 줄어들지 않는다면 분리만으로는 검증기의 품질이 올라가지 않는다.
• 사양 정합성 23건이 줄어든다면 자기 채점이 검출 누락을 증폭시키고 있었던 것이다. 줄어들지 않는다면 문제의 중심은 요구사항 측에 있다.

다만 다음 시도는 별도의 티켓(Ticket)이 될 것이므로, 건수가 변하더라도 티켓의 난이도 자체가 다를 수 있습니다. 이 관찰만으로 인과관계를 단정할 수는 없습니다. 엄밀히 구분하려면 본래 동일한 티켓을 다른 구성으로 재실행하여 67건이라는 베이스라인과 비교해야 합니다.

참고로 규약 17건과 설계 8건은 검증을 분리해도 줄어들지 않습니다. 독립성의 문제가 아니므로 다른 방법이 필요합니다.

마치며

앉아 있는 동안, 나는 무엇을 무료로 제공하고 있었는가.

저의 경우, 그 답은 67건의 리뷰 지적이라는 형태로 돌아왔습니다. 그중 7할에 대해서는 검증기, 요구사항, 안전 규칙이라는 외부화할 대상을 특정할 수 있었습니다.

그렇다면 남은 3할은 정말로 인간의 업무일까요? 그 부분 또한 알 수 없습니다. 설계 판단의 일부는 규칙화할 수 있을 것 같고, 테스트 관련 7건은 다음번에 개선하려고 합니다. 구현 버그(Implementation bug) 또한 검증기(Verifier)를 보강하면 줄어들지도 모릅니다. 인간의 업무라고 생각하고 있는 것도, 아직 외부화(Externalization)하지 못했을 뿐인지도 모릅니다.

다음에 파악해야 할 것은 바로 그 3할입니다.

Discussion