코딩 에이전트 시대에도 코드 리뷰가 필요할까요?

AI 요약

코딩 에이전트는 기능을 구현하고 테스트를 실행하며 실패를 고친 뒤 PR까지 준비합니다. 이때 코드를 직접 작성한 사람과 PR을 여는 사람이 달라질 수 있습니다. 글쓴이는 코드 리뷰가 필요 없어진 게 아니라, 리뷰를 승인 횟수로 판단하던 관행을 바꿔야 한다고 주장합니다. 중요한 질문은 몇 명이 승인했느냐가 아니라, 변경 사항을 얼마나 신뢰할 만하게 검증했느냐입니다.

에이전트가 만든 코드를 누가 소유하나요?

전통적인 절차에서는 한 개발자가 코드를 작성하고 다른 개발자가 검토합니다. 에이전트가 구현을 맡으면, 개발자는 결과를 살펴보고 책임질 준비가 됐을 때 PR을 엽니다. 이 과정에서 개발자가 구현을 충분히 검토하고 소유권을 진다면, PR 이후에 또 한 명이 일반적인 리뷰를 해야 하는 이유가 무엇인지 물을 수 있습니다. PR을 열었다는 사실만으로 코드의 신뢰도가 높아지지는 않습니다. 신뢰에 중요한 순간은 담당 엔지니어가 결과를 이해하고 책임지겠다고 판단한 때입니다.

그렇다고 모든 변경에 같은 검토 절차를 적용하자는 뜻은 아닙니다. 과거에 리뷰 한 번을 요구했다면, 담당자가 철저히 검토한 에이전트 생성 코드에는 별도의 일반 리뷰가 필요하지 않을 수도 있습니다. 두 번의 리뷰를 요구하는 팀이라면 담당자의 검토에 PR 이후 리뷰를 더할 수 있습니다. 데이터베이스 마이그레이션, 인증, 금융 거래처럼 위험이 큰 변경은 작은 UI 수정과 다른 검증을 받아야 합니다. 책임을 맡긴다고 말하면서 모든 결정을 다른 사람이 다시 승인하게 하면, 책임과 권한이 어긋납니다.

사람의 검토량을 늘리는 대신 오류를 막습니다

에이전트는 코드 생산 비용을 크게 낮춥니다. 반면 코드가 늘어나는 속도가 사람이 검토할 수 있는 양보다 빨라지면, 리뷰어를 추가하는 것만으로 문제를 풀기 어렵습니다. 사람에게 열 배 많은 코드를 직접 읽게 하면 병목이 작성에서 검증으로 옮겨갈 뿐입니다. 글쓴이는 사람이 모든 줄을 확인하기보다, 잘못된 구현을 만들기 어렵게 설계하자고 제안합니다.

데이터베이스 제약으로 값의 조건을 강제하고, 업무 상태를 임의의 문자열 대신 유한 상태 머신(Finite State Machine)으로 표현하면 허용되지 않는 전이를 막을 수 있습니다. 타입, 계약, API 경계, 검증 로직, 생성 코드, 정적 분석과 자동 테스트도 같은 방향의 도구입니다. 개발자에게 더 주의하라고 요구하는 대신, 특정 종류의 실수를 표현할 수 없게 만듭니다. 그러면 사람은 자동으로 확인할 수 있는 조건보다 설계와 업무 판단에 주의를 쓸 수 있습니다.

위험도에 맞춰 검증을 조합합니다

글이 제시하는 검증 체계는 여러 층으로 구성됩니다. 먼저 아키텍처와 제약이 잘못된 구현을 제한합니다. 그다음 타입 검사, 테스트, 정적 분석, 보안 검사, 계약 테스트, 데이터베이스 제약과 CI가 자동으로 확인합니다. 엔지니어는 변경을 검토하고 소유권을 집니다. 더 높은 확신이 필요한 경우에는 보안, 성능, 신뢰성, 하위 호환성, API 설계, 접근성, 아키텍처나 테스트를 전문으로 보는 적대적 에이전트를 추가합니다.

이 에이전트들은 코드를 승인하거나 무조건 “LGTM”이라고 말하는 역할이 아닙니다. 보안 에이전트는 권한 우회나 인젝션 가능성을 찾고, 성능 에이전트는 비싼 쿼리나 불필요한 할당, N+1 접근을 살핍니다. 이들도 결함이 있는 동료처럼 다뤄야 합니다. 보안 에이전트의 검토가 시스템의 안전을 증명하지는 않지만, 독립적으로 문제를 찾는 시도는 검증을 보탭니다. 문서 변경에는 성능 검토가 필요하지 않을 수 있고, 데이터베이스 변경에는 더 많은 검증이 필요할 수 있습니다. 변경 위험에 따라 검증 단계를 조합하는 방식입니다.

사람의 판단이 필요한 곳에 집중합니다

사람은 이 변경이 실제 문제를 해결하는지, 적절한 추상화인지, 아키텍처에 맞는지, 사업상 타당한지, 팀이 운영할 만한지 판단합니다. 반면 데이터베이스 열의 NULL 허용 여부나 API 계약의 하위 호환성, 상태 전이의 유효성은 제약이나 자동 검사로 옮길 수 있습니다. 이런 검증을 시스템으로 옮길수록 사람은 자동화하기 어려운 판단에 집중할 수 있습니다.

글쓴이는 코드 리뷰가 사라지기보다 의미가 바뀐다고 봅니다. 에이전트가 구현을 작성하는 환경에서 엔지니어는 타이핑한 사람이 아니라, 결과를 이해하고 검증하며 책임지는 사람이 됩니다. 목표는 속도를 위해 검증을 줄이는 것이 아닙니다. 아키텍처, 자동화, 전문 에이전트와 엔지니어의 판단을 조합해 검증을 늘리면서 사람의 검토 부담을 줄이는 것입니다.

dev.to 반응

• @kentkandiforge — 제가 겪은 일과 같습니다. 에이전트가 저장소 20곳에서 수백만 줄을 만들었을 때, 저도 말씀하신 대로 확장되지 않는 방법부터 썼습니다. 리뷰어와 테스터를 사람과 에이전트 모두 늘렸습니다. 제게 남은 교훈은 양만큼이나 시점도 중요하다는 점입니다. 테스터가 에이전트로 테스트를 작성했지만, 대부분 코드가 통합된 뒤에 실행했습니다. 테스트가 문제를 잡았을 때는 변경 사항이 이미 들어간 뒤였습니다. 검증 관문이 잘못된 위치에 있었습니다. 실수를 표현할 수 없게 제약을 두는 계층형 모델에 공감합니다. 각 계층을 언제 실행하느냐도 어떤 계층을 두느냐만큼 중요하다고 덧붙이고 싶습니다. 통합 후에 실행하는 강력한 적대적 에이전트도 여전히 문제를 늦게 잡습니다. 전문 에이전트는 엔지니어가 소유권을 맡기 전에 실행하나요, 아니면 그 뒤에 실행하나요?
  • @remojansen — 에이전트 리뷰는 병합 전에 합니다. 병합하면 그 변경을 소유하게 되니, 소유권을 맡기기 전에 진행합니다.
• @contentclips_st — 담당 엔지니어의 승인을 검증으로 간주하는 부분에는 한 가지 경고를 덧붙이고 싶습니다. 그 엔지니어는 의도를 정한 사람이어서, 검토가 구현보다 의도를 확인하는 쪽으로 기울 수 있습니다. 맥락을 가장 잘 아는 유일한 리뷰어에게 사각지대가 옮겨가는 셈입니다. 승인 단추를 늘리지 않고 그 한 번의 검토를 탄탄하게 만드는 방법 두 가지가 있습니다. 에이전트가 작업을 시작하기 전에 명세와 테스트를 동결하고, PR 검토는 동결된 명세에서 시작합니다. 변경 사항이 실행 중에 바뀐 의도가 아니라 동결된 내용을 구현했는지 확인합니다. 그리고 diff 크기가 아니라 영향 범위에 따라 리뷰를 정합니다. 기계적인 리팩터링 4천 줄은 타입, 계약, 커버리지 변화로 쉽게 확인할 수 있습니다. 사람은 이런 검사가 닿지 않는 위험 영역만 읽으면 됩니다. 승인 횟수는 소유권을 확인하는 의식이 되고, 검증은 검색 가능한 기록물이 됩니다.
• @kaydenilands — 무언가를 공개하기 전에 동료 검토 절차를 거칩니다. 그 과정을 통해 리뷰의 목적을 달리 생각하게 됐습니다. 사람 편집자가 초안 전체를 읽고, 저는 이름이 붙은 수정 사항을 반영합니다. 이번 달에는 잘못된 사람에게 인용을 돌린 문장, 최신 합계 옆에 놓인 1년 지난 통계, 하이픈으로 이어진 단어 중간을 잘라 버린 자막 엔진을 잡았습니다. 단순한 문체 문제가 아닙니다. 셋 다 오류로 공개됐을 내용입니다. 에이전트가 리뷰를 없앤다고 생각하지 않습니다. 리뷰어의 역할을 오타 찾기에서 자신감 있게 들리는 오답 찾기로 바꿉니다. 그 일은 더 어렵고 시간도 더 듭니다.
• @_firelinks — 소유권과 승인은 서로 관련은 있지만 같은 개념은 아닙니다. 엔지니어가 에이전트 생성 변경을 소유하더라도, 승인은 검토한 정확한 리비전과 입력, 상태에 묶여야 합니다. 그중 하나라도 검토 뒤에 바뀌면 기존 승인은 더는 적용되지 않아야 합니다. 그렇게 하면 엔지니어에게 권한을 주면서도 티켓 번호나 승인 횟수를 검증의 대용으로 삼지 않을 수 있습니다. 계층형 모델에서 제약과 검사가 각자 확인할 것을 확인하고, 담당자는 해결되지 않은 문제를 판단합니다.
• @beusebiu — 제가 지키고 싶은 부분은 아무도 측정하지 않는 것입니다. 리뷰어는 변경 사항을 머릿속에 담고 이 코드베이스에 들어맞는지 판단해야 합니다. 에이전트는 작동한다고 말할 수 있지만, 이 코드베이스에 그 변경이 있어야 하는지는 다른 문제입니다. 그 질문은 diff 안에 들어 있지 않습니다.
• @respect17 — 적대적 에이전트 아이디어가 가장 기억에 남습니다. diff를 의심하는 게 전부인 보안 에이전트는 그저 “LGTM”이라고 말하는 에이전트와 다릅니다. 승인 대상을 정확한 리비전에 묶어야 한다는 Mike의 의견도 중요해 보입니다. 병합 전에 누군가 후속 커밋을 올리면 소유권 주장이 낡은 근거가 될 수 있으니, 계층형 파이프라인에도 그 방식이 필요합니다.
• @syntaxwanderer_26 — “결함이 있는 동료”라는 비유가 마음에 듭니다. 에이전트가 작성한 코드에서는 리뷰 질문의 초점이 “이 줄이 맞나?”에서 “이 변경이 다른 어디에 영향을 줬나?”로 옮겨간다고 덧붙이고 싶습니다. 에이전트는 국소적인 변경을 깔끔하게 보이게 만드는 데는 능숙하지만, 영향 범위를 파악하는 데는 훨씬 약합니다. diff만 보여주지 말고 변경된 요소에 의존하는 클래스와 경로를 보여주는 영향 분석 화면을 리뷰어에게 제공하는 것이 제 작업 흐름에서 가장 큰 개선이었습니다.
• @innokentyb — 전문 에이전트를 병합 전에 실행하면 검증 관문을 올바른 위치에 둘 수 있습니다. 남은 질문은 에이전트가 검토하는 대상을 누가 검증하느냐입니다. 지시하는 엔지니어가 명세를 만들고 에이전트들이 그와 같은 해석에서 테스트를 생성한다면, 리뷰 과정 전체가 같은 실수에 동의할 수 있습니다. 동결된 요구사항과 테스트 기준 사이에는 구현 과정에서 나오지 않은 독립적인 확인을 하나 이상 두고 싶습니다. 반례, 뮤테이션 테스트, 독립적인 인수 시나리오가 그 예입니다.

원문: dev.to / 번역·요약: Trawling