우리는 왜 코드를 이해하려고 하는가? (feat. 코드 읽기를 그만뒀더니 코드 리뷰가 더 좋아졌다)

최근 많은 개발자 분들이 AI로 인해 가지는 스트레스 중 하나가 '기능은 쏟아져나오는데 내가 이해/통제하지 못하는 코드가 늘어나고, 코드 리뷰가 병목이 되고 있다'일텐데요. 마찬가지로 채용 과제 구성에서도 어려움이 있고요.

저는 "코드 이해의 정의와 목적이 무엇인가?" 라는 질문을 던져볼 필요가 있다고 생각했습니다.

• 코드를 잘 이해했다는 것을 어떻게 측정/가시화할 수 있을까요?
• 그 지표를 높임으로써 우리가 원하는 JTBD가 뭘까요?
• 그 지표가 낮아져도 괜찮다는 결정을 한다면, 얼마나 낮아져도 괜찮을까요? 다른 어떤 지표와 트레이드오프가 있을까요?

그러다 마침 코드 리뷰에 대한 Every의 좋은 글이 눈에 띄어서 Opus에게 번역시켰습니다.

I Stopped Reading Code. My Code Reviews Got Better.

How 13 AI agents reviewing in parallel caught a critical bug I would have otherwise missed

Kieran Klaassen

(한글 번역 링크: https://claude.ai/public/artifacts/25407162-7000-4400-b931-c4ad42f08019)

<후반부 발췌>

대부분의 엔지니어는 모든 것을 읽어야 한다고 가정한다. 그 가정은 인간이 모든 코드를 작성했을 때는 말이 되었다. 하지만 더 이상은 아니다.

나는 대부분의 코드를 읽지 않고 이메일 서명 수정을 배포했다. 발견 사항을 리뷰하고 결정을 내렸다. Gmail의 스크린샷을 봤다. 하지만 이메일 콘텐츠를 추출하는 방법의 구현 세부 사항을 읽었나? 아니. 데이터베이스 변경이 엣지 케이스를 어떻게 처리하는지 추적했나? 아니.

그런데 기능은 작동한다. 사용자들은 적절하게 포맷된 서명을 받는다. 테스트--코드가 올바르게 동작하는지 확인하기 위해 모든 기능과 함께 작성하는 검사--가 모두 통과한다. 스크린샷이 올바르게 보인다. 수동 코드 리뷰를 놓아버리는 데 시간이 좀 걸렸지만, 결과가 스스로를 증명한다.

내가 한 거래는 모든 줄을 읽지 않겠다는 것이지만, 코드를 읽는 데 쓸 시간의 일부는 이제 시스템을 더 똑똑하게 만드는 데 간다. 이상한 포맷으로 가득 찬 마케팅 이메일에 대한 테스트 케이스를 추가하고 있다. "데이터가 있는 위치를 변경할 때, 그것을 읽는 모든 파일을 확인하라"를 에이전트들이 자동으로 시행하는 규칙으로 캡처하고 있다. 이렇게 하면, 이 코드를 건드리는 다음 사람--인간이든 AI든--은 내 실수를 반복하지 않는다.

아직 컴파운드 엔지니어링 플러그인이 없다면, 세 가지 질문으로 시작하라. AI가 생성한 출력--코드, 문서, 또는 전략 덱--을 승인하기 전에, AI에게 물어라:

1. 여기서 가장 어려웠던 결정은 무엇이었나?
2. 어떤 대안을 거부했고, 왜?
3. 무엇에 대해 가장 자신이 없나?

2분이 걸리는 그 대화가 30분의 집중하지 않은 수동 검사가 놓쳤을 것을 표면화한다. AI는 까다로운 부분이 어디인지 안다. 그저 물어보지 않으면 자발적으로 말하지 않을 뿐이다.

그런 다음 50/50 규칙을 적용하라. 시간의 절반은 즉각적인 문제를 수정하는 데, 절반은 문서화하여 문제가 다시는 돌아오지 않도록 하는 데 써라.

</후반부 발췌>

이런 워크플로우를 실제로 실행하려면 신뢰할 수 있고 광범위한 테스트와 QA가 필요합니다. 그래서 Vercel이 내놓은 https://agent-browser.dev/ 같은 도구도 눈여겨보고 있습니다.