AI에게 코드 리뷰를 맡겼을 때 깨진 것들 (그리고 내가 고친 방법)

발행: (2026년 1월 2일 오후 06:47 GMT+9)
17 min read
원문: Dev.to

I’m happy to translate the article for you, but I don’t have the full text of the post. Could you please paste the content you’d like translated (excluding any code blocks or URLs you want to keep unchanged)? Once I have the text, I’ll provide the Korean translation while preserving the original formatting and the source line exactly as you requested.

I – 당신이 모르는 문제

다음은 대부분의 개발자들이 현재 하고 있는 일입니다:

  • 그들은 코드를 작성한다.
  • 그들은 코드를 ChatGPT나 Claude에 붙여넣고 “이게 괜찮은가요?”라고 묻는다.
  • AI는 예라고 답하거나(또는) 사소한 변경을 제안한다.
  • 그들은 이를 병합한다.

그들은 효율적이라고 생각하지만, 실제로는 규모 있게 기술 부채를 쌓고 있다.

문제는 AI의 출력이 아니다. 판단을 외주화할 때 뇌에 일어나는 일이다.

AI에게 코드 리뷰를 맡기면 라는 질문을 멈추게 된다. 아키텍처에 의문을 제기하지 않게 된다. 여러 컨텍스트를 동시에 머릿속에 유지해야 했던 것이 사라져 코드베이스 전반의 패턴을 보지 못하게 된다.

코드 리뷰는 단순히 버그를 잡는 것이 아니라 전체 시스템이 어떻게 동작하는지에 대한 정신 모델을 유지하는 것이다.

인쇄기는 서기들을 쓸모 없게 만들었다. 구텐베르크 이전에 서적 제작자는 수십 명의 숙련 장인을 고용해 손으로 원고를 복사했으며, 이 기술은 수년간 연마해야 했다. 어느 순간 그 기술은 가치가 없어졌다.

하지만 편집자가 등장했는데, 그 역할은 무엇을 인쇄할 가치가 있는지 결정하는 것이었다.

패턴은 기술이 상향 추상화된다는 것이다.

모든 코드를 작성하는 사람이 될 필요는 없지만, 어떤 라인이 중요한지 아는 사람은 반드시 필요하다.

그렇다면 이번이 왜 다른가?

대부분의 개발자는 AI를 연구팀처럼 활용해야 함에도 불구하고 맞춤법 검사기처럼 사용하고 있기 때문이다.

II – Single‑model review is a guess dressed up as certainty

나는 Claude Opus 4.1을 모든 작업에 사용하고 있었다. 훌륭한 모델이고, 분석에 뛰어나며, TypeScript에도 강하지만, 눈에 보이지 않는 약점이 있다.

어느 날 불필요하게 다시 렌더링되는 React 컴포넌트를 리뷰해 달라고 요청했다. Claude는 메모이제이션을 제안했다. 합리적인 판단이었다. 나는 그것을 적용했다.

그런데 호기심에 같은 코드를 GPT‑5에 넣어 보니, GPT는 실제 문제는 prop drilling이라고 지적했다—메모이제이션은 증상을 치료하는 것이지 원인을 해결하는 것이 아니었다.

그때 깨달았다.

모든 AI 모델은 서로 다르게 학습된다. 각 모델마다 강점이 다르다:

  • Claude는 미묘한 분석에 뛰어나다.
  • GPT는 아키텍처 패턴에 더 강하다.
  • Gemini는 Claude가 놓치는 엣지 케이스를 잡아낸다.

하나의 모델만 사용할 경우, 코드 리뷰를 받는 것이 아니라 그 모델의 관점을 받는 것이다. 그리고 그 관점에는 당신이 더 이상 보지 않게 된 빈틈이 존재한다.

보통 수준과 뛰어난 수준 사이의 차이는 감각이다. 누구나 코드를 생성할 수 있게 되면서, 어떤 코드를 신뢰할지 아는 능력이 바로 기술이 된다.

이것이 여러 모델에 걸쳐 동일한 리뷰를 실행하는 것이 단순한 기능을 넘어 새로운 사고 방식이 되는 이유다.

III – 실제로 무슨 문제가 있었고 (그것이 나에게 가르쳐 준 것)

프로덕션 버그는 미묘했습니다: 스테이징에서는 정상적으로 동작했지만 부하가 걸리면 실패하는 캐싱 레이어였습니다. AI는 로직을 검토했으며—그 로직은 올바랐습니다. AI가 잡지 못한 것은 구현에 내재된 가정, 즉 캐시 무효화가 동기적으로 일어날 것이라는 전제였습니다.

AI가 왜 잡지 못했을까?

제가 충분한 컨텍스트를 제공하지 않았기 때문입니다. 함수를 붙여넣었지만 전체 데이터 흐름이나 배포 아키텍처를 보여주지는 않았습니다. AI는 보여지는 부분만 검토할 수 있으며, 빠르게 진행할 때는 최소한의 정보만 제공하게 됩니다.

예측 가능한 세 가지 실패 유형

Failure ModeDescription
Context Collapse50줄을 붙여넣으면 AI는 그 50줄만 검토하지만, 버그는 포함하지 않은 다른 200줄과의 상호작용에 숨어 있습니다. 전체 코드베이스를 analyze code across your entire codebase 하면 통합 버그를 놓치지 않게 됩니다.
Architectural BlindnessAI는 로컬 최적화에는 뛰어나지만 시스템 설계에는 서툽니다. 하나의 함수는 더 빠르게 만들면서 전체 아키텍처를 더 취약하게 만드는 영리한 해결책을 제시할 수 있습니다.
The Confidence ProblemAI는 절대 “모르겠어요”라고 말하지 않습니다. 답변을 제시하고, 그 답변이 설득력 있기 때문에 틀렸을 때조차도 신뢰하게 됩니다.

이 점을 깨달은 사람들은 AI를 포기하지 않습니다; 오라클처럼 대우하던 방식을 버리고, 방향을 제시해 주어야 하는 주니어 개발자 팀처럼 대합니다.

IV – 실제로 AI를 코드 리뷰에 활용하는 방법 (판단력을 잃지 않으면서)

LevelDescription
Level 1 – The Paster코드를 복사해서 챗봇에 붙여넣고, 챗봇이 말하는 대로 받아들입니다. 생각을 외주 줍니다.
Level 2 – The Prompt Engineer더 좋은 프롬프트를 작성하고, 더 많은 컨텍스트를 제공해 더 나은 답변을 얻지만, 여전히 하나의 모델 관점에 의존합니다.
Level 3 – The Orchestrator동일한 코드를 여러 모델에 넣어 실행하고, 결과를 비교·통합합니다. Claude가 잡아낸 것이 GPT가 놓친 경우, 그 반대도 확인합니다.
Level 4 – The Architect특정 리뷰 작업에 AI를 활용하되, 시스템 사고는 직접 제어합니다. 어떤 모델을 어떤 상황에 사용할지 알고, 워크플로우를 구축했습니다.

대부분의 개발자는 Level 1을 떠나지 못합니다. 다음은 단계별로 올라가는 방법입니다:

Step 1: 혼자서 리뷰하지 않기

단일 함수만 붙여넣지 마세요. 호출자, 데이터 흐름, 배포 제약조건 등 전체 컨텍스트를 붙여넣습니다. 리뷰 전에 문서에서 패턴을 추출하면 AI가 볼 수 없는 가정을 포착할 수 있습니다.

Step 2: 항상 여러 모델 사용하기

코드를 최소 세 개 이상의 서로 다른 모델에 넣어 실행합니다. 의견 차이를 찾아보세요—불일치는 조사할 가치가 있는 신호입니다. 병목은 리뷰를 얻는 것이 아니라, 배포 전에 어느 관점을 신뢰할지 아는 것입니다.

Step 3: AI에게 작업 과정을 보여달라

단순히 “예” 혹은 “아니오”만 받아들이지 마세요. 모델에게 변경을 권하는지, 논리를 단계별로 설명하고, 어떤 가정을 하고 있는지 알려달라고 요청하세요. 이렇게 하면 AI가 사고 과정을 드러내고, 여러분은 이를 검증하거나 거부할 기회를 얻게 됩니다.

Source:

V – 프로토콜

제가 현재 정확히 하는 방법은 다음과 같습니다:

아침: 아키텍처 검토 (20 분)

코드를 작성하기 전에 세 모델에게 동일한 아키텍처 질문을 합니다:

“**[시스템 제약조건]**이 주어졌을 때, **[기능]**을 이렇게 구현할 경우의 트레이드‑오프는 무엇인가요?”

합의점을 찾습니다. 모델들이 동의하면 빠르게 진행하고, 의견이 갈리면 속도를 늦추고 생각합니다.

개발 중: 컨텍스트‑풍부 프롬프트

이제 개별 함수는 검토하지 않습니다. 대신 검토하는 항목은:

  • 함수 자체
  • 호출자
  • 데이터 흐름
  • 오류 처리
  • 배포 컨텍스트

매번 전체를 붙여넣습니다.

병합 전: 다중‑모델 분석

최종 코드를 다음 모델에 통과시킵니다:

모델들이 수렴하면 신뢰하고, diverge(다르면) 조사합니다.

주간: 깨진 부분 검토

매주 금요일에 그 주의 버그를 살펴보고, AI 검토로 돌아가 AI가 놓친 부분과 그 이유를 파악한 뒤 프롬프트를 업데이트합니다.

목표: 완벽함이 아니라 반복입니다—매주 더 똑똑해지는 시스템을 구축하는 것이 목표입니다.

VI – 실제로 이것이 당신에게 드는 비용

당신은 이렇게 생각하고 있을 겁니다: “이건 더 많은 작업처럼 들리는데, 덜 하지 않나요?”

맞습니다. AI를 잘 활용하려면 노력​이 필요합니다—잘못 활용하는 것보다, 아예 사용하지 않는 것보다 더 많은 노력​이 듭니다. 하지만 얻을 수 있는 것은 다음과 같습니다:

Before (단일 모델, 빠른 붙여넣기)After (다중 모델, 컨텍스트 풍부)
검토 시간검토당 5 분검토당 15 분
버그 잡기 비율~70 %~95 %
판단 개선없음빠르게 개선
코드 품질 추세하락복합적인 개선

추가된 10 분은 부가 비용이 아니라 투자입니다. 단순히 코드를 검토하는 것이 아니라, 중요한 것을 보는 눈을 훈련하는 것이죠.

  • 빠르지만 단기적인 개발자는 6개월 동안 빠르게 작업하지만, 그 후에 자신이 만든 혼란을 디버깅하는 데 6개월을 보낼 것입니다.
  • 지금 속도를 늦추는 사람은 6개월 후에 더 빠르게 작업할 수 있게 되는데, 그 이유는 판단력이 훨씬 날카로워지기 때문입니다.

VII – 당신이 스스로 물어야 할 질문들

  • AI를 더 빨리 생각하기 위해 사용하고 있나요, 아니면 생각을 피하기 위해 사용하고 있나요?
  • AI가 변화를 제안할 때, 그 변화가 왜 더 나은지 설명할 수 있나요?
  • 내일 AI를 사용할 수 없게 된다면, 코드 품질이 떨어질까요?

솔직히 답했다면, 아마 불편함을 느낄 것입니다. 그 불편함이 바로 요점입니다—판단을 외주화하고 이를 효율성이라고 부르고 있다는 뜻이죠.

지금 바로 격차가 벌어지고 있습니다:

  • AI를 지팡이처럼 사용하는 개발자 vs. AI를 지렛대로 활용하는 개발자.
  • 모델에게 생각을 맡기는 사람 vs. 여러 관점을 조율해 더 나은 결정을 내리는 사람.

변화

코드 리뷰가 상위 레벨로 추상화되었습니다. 모든 세미콜론을 잡을 필요는 없지만, 시스템을 이해해야 합니다.

  • AI가 당신을 대체하지 않을 것입니다.
  • AI를 조율할 줄 아는 개발자가 그렇지 못한 개발자를 대체할 것입니다.

다음 6개월 안에 이를 파악한 사람은 완전히 다른 수준에서 개발하게 될 것입니다. 코드를 계속해서 ChatGPT에 붙여넣고 반환된 결과를 그대로 받아들이는 사람은 생산 환경이 불타는 이유를 계속 궁금해 할 겁니다.

지능은 파편화되지 않고 유동적이어야 합니다.
당신은 어느 한쪽을 선택하는 것이 아니라—**모두를 조율**합니다.

— Leena :)

Back to Blog

관련 글

더 보기 »

InDesign 파일을 번역하는 최고의 방법

InDesign 파일 .IDML을 온라인으로 번역하기 – 최고의 방법 InDesign 파일 .IDML을 온라인으로 번역하는 최고의 방법을 찾고 있지만 별다른 운이 없으셨나요? As seas...