요약 (TL;DR)

• 자신을 최종 책임이 있는 관리자(manager)의 위치로 설정하면, AI 기반 워크플로우에서 인간의 검토가 필요한 부분이 명확해집니다.
• 모든 라인을 같은 깊이로 읽을 필요는 없습니다. 소유권 경계(ownership boundaries), 아키텍처, 검증 전략, 라이선싱 및 보안과 같은 고위험 영역에 인간의 검토를 집중해야 합니다.
• AI 시대에는 개발자의 가치가 '모든 것을 직접 작성하는 것'에서 '품질을 책임지고 개발 시스템을 설계하는 것'으로 변화합니다.

서론

제가 계속 고민하는 질문은 AI가 구현의 큰 부분을 담당할 때 코드 리뷰는 어떻게 작동해야 하는가입니다.

이러한 사고 모델(mental model)은 저에게 유용했습니다:

• AI 구현자 (AI implementer): 코드를 작성합니다.
• AI 리뷰어 (AI reviewer): diff를 검사합니다.
• 당신: 최종 제품에 대한 책임이 있는 관리자 (manager)

이러한 틀로 보면, '여전히 코드 리뷰를 해야 하는가?'라는 질문에 대한 답은 실용적입니다.

네, 결과물(outcome)을 소유한다면 필요합니다. 하지만 아니요, 모든 것을 같은 강도로 읽을 필요는 없습니다.

관리자 스타일의 워크플로우에서 검토 목표의 변화

인간 팀에서는 관리자가 보통 모든 파일의 모든 라인을 읽지는 않습니다.

그들은 여전히 다음 사항들을 통제하기 때문에 책임을 질 수 있습니다:

• 방향성 (무엇을 만들고 무엇을 만들지 않을 것인가)
• 품질 기준 (출시되기 위해 무엇이 참이어야 하는가)
• 위험 관리 (보안, 법적, 운영 위험)
• 검증 시스템 (테스트, 모니터링, 롤백)

AI 구현자와 AI 리뷰어가 참여할 때도 마찬가지입니다.

주요 차이점은 더 빠른 구현 속도가 느린 의사 결정과 검증의 격차를 훨씬 더 눈에 띄게 만든다는 것입니다.

'모든 것을 읽기' 대신 명확한 책임 경계를 설정하라

인간이 AI가 생성한 모든 라인을 깊이 있게 검사하는 워크플로우는 보통 확장성이 없습니다.

더 나은 패턴은 책임 경계(accountability boundaries)를 명시적으로 만드는 것입니다.

1. 명세(Spec) 책임

• '완료되었다'고 정의하는 조건은 무엇인가?
• 어떤 비기능적 요구사항(성능, 가용성, 감사 가능성 등)이 중요한가?
• 기존 동작과의 호환성을 어떻게 유지할 것인가?

2. 설계 (Design) 책임

• 아키텍처 경계(Architectural boundaries)와 의존성 방향(Dependency directions)이 여전히 깔끔한가?
• API/데이터/권한(Permission) 경계가 일관적인가?
• 불필요하게 미래의 변경 비용(Change cost)을 높이고 있지는 않은가?

3. 리스크 책임 (Risk accountability)

• 이것이 보안 노출(Security exposure)을 초래하는가?
• 오픈소스(OSS) 라이선스 또는 이용 약관(Terms-of-use) 리스크가 있는가?
• 영향 범위(Blast radius)와 복구 옵션(Recovery options)을 이해하고 있는가?

4. 검증 책임 (Verification accountability)

• 이것을 안전하다고 판단하기 위해 어떤 테스트를 통과해야 하는가?
• 어떤 사용자 여정(User journeys)이 여전히 수동 점검을 필요로 하는가?
• 모니터링/로깅/알림(Monitoring/logging/alerts)이 회귀(Regressions)를 빠르게 감지할 수 있는가?

만약 인간이 이 네 가지 사항에 대한 책임을 진다면, 모든 변경 사항을 한 줄씩 읽는 작업은 더 이상 필수 사항이 아니게 됩니다.

여전히 깊이 있게 읽어야 하는 코드

"모든 것을 읽을 필요는 없다"는 말이 "아무것도 읽지 않아도 된다"는 뜻은 아닙니다.

AI 중심의 개발 환경에서도 다음과 같은 영역은 항상 주의 깊은 인간의 검토를 거쳐야 합니다:

• 인증/인가 (Authentication/authorization)
• 결제 및 가격 책정 로직 (Billing and pricing logic)
• 데이터 삭제 및 마이그레이션 흐름 (Data deletion and migration flows)
• 공개 API 규약 (Public API contracts)
• 암호화 및 키 관리 (Cryptography and key handling)
• 감사 및 컴플라이언스 경로 (Audit and compliance paths)

이 영역들은 실패 시 비용이 매우 높은 구간입니다. 인간이 이곳에서 최종 승인(Sign-off)을 담당해야 합니다.

개인 개발자의 새로운 역할

이 모델은 1인 개발자에게도 적용됩니다.

혼자서도 멀티 에이전트(Multi-agent) 설정을 운영할 수 있습니다:

• 구현(Implementation)은 AI에게 위임
• 1차 리뷰(First-pass review)는 AI에게 위임
• 최종 책임(Final accountability)은 스스로 유지

그러한 설정에서 핵심 역량은 타이핑 속도가 아니라 다음과 같은 능력에 달려 있습니다:

• 명확한 의도(Intent) 작성
• 작업을 안전한 증분(Increments)으로 분할
• 수락 기준(Acceptance criteria) 정의
• 리스크를 명시적으로 우선순위화

따라서 무게 중심은 "모든 것을 코딩할 수 있는 사람"에서 "신뢰할 수 있는 개발 시스템을 설계하고 운영할 수 있는 사람"으로 이동합니다.

실무적인 최소 운영 규칙 세트

실무에서 잘 작동하는 가벼운 규칙 세트입니다:

1. 변경 사항을 작게 유지할 것: 하나의 PR(Pull Request)에는 하나의 목적만 담을 것
2. AI 리뷰를 권고 사항으로 취급할 것: 중요한 리스크 항목은 직접 재검토할 것
3. 보안, 라이선스, 결제 및 권한 변경에 대해서는 반드시 사람의 승인을 요구할 것

이를 통해 책임 소재를 모호한 영역(gray zone)으로 만들지 않으면서도 속도를 확보할 수 있습니다.

결론

AI 구현자(implementers)와 AI 리뷰어(reviewers)가 강력해짐에 따라, 인간의 역할은 "작성(writing)"에서 "소유(owning)"로 이동합니다.

• 무엇을 만들지 결정하기
• 무엇을 엄격하게 검토해야 하는지 결정하기
• 최종 배포(shipping) 결정을 책임지기

만약 당신이 이러한 책임들을 진정으로 소유한다면, 모든 코드를 한 줄 한 줄 깊게 읽는 것은 더 이상 필수 요구 사항이 아닙니다.

하지만 그렇지 않다면, AI의 속도는 단순히 관리되지 않는 리스크로 향하는 더 빠른 경로를 만들 뿐일 수도 있습니다.

AI 시대에 개발자는 여전히 빌더(builders)이지만, 점점 더 개발 프로세스 자체를 설계하는 시스템 디자이너(system designers)가 되어가고 있습니다.