▲

코드 리뷰를 잘하면 AI 에이전트도 잘 다룰 수 있음

 (seangoedecke.com)
8P by GN⁺ 16시간전 | ★ favorite | 댓글 1개
  • AI 에이전트 활용에 능숙해지려면 코드 리뷰 실력이 중요함
  • 대형 언어 모델은 코드 생성은 잘하지만 깊이 있는 판단력이 부족하여 잘못된 방향으로 시간을 낭비하는 경우가 많음
  • 단순히 세부 문법만 지적하는 사소한 리뷰나 무비판적 승인인 도장찍기 리뷰는 AI 활용에 도움이 되지 않음
  • 좋은 코드 리뷰는 구조적 관점을 포함해 더 나은 방법이 있는지를 따져보고, 복잡한 설계를 피하게 함
  • 결국 AI 코딩은 “센타우르 체스” 처럼 인간의 판단과 기계의 생산성을 결합하는 모델이며, 코드 리뷰 능력이 곧 AI 활용 역량으로 이어짐

AI 에이전트와 코드 리뷰의 관계

  • AI 에이전트를 올바르게 사용하는 것은 곧 코드 리뷰 과정임
  • 코드 리뷰를 잘하는 사람은 Claude Code, Codex, Copilot과 같은 AI 코드 도구도 효과적으로 활용함

왜 코드 리뷰 실력이 중요한가

  • 대형 언어 모델은 대량의 코드 생성에 능하지만, 숙련된 소프트웨어 엔지니어의 판단력은 아직 부족함
  • 따라서 감독 없이 두면 불필요하거나 나쁜 설계로 많은 리소스를 낭비하는 경향이 있음

AI 에이전트의 한계와 설계 오류

  • 예시로 VicFlora Offline 프로젝트 개발 중 Codex는 프런트엔드 코드를 역설계하는 데 많은 노력을 쏟았음
    • 실제로는 더 단순한 데이터 접근법이 존재했음
    • AI 에이전트 사용 시 한 시간에 한 번쯤은 뭔가 수상한 작업을 수행하는 경우가 발견됨
    • 이런 문제 발견 시 직접 방향을 바꾸면 수 시간의 작업을 절감하는 효과가 있음
  • 또 다른 앱 개발 경험에서, AI는 간단한 병렬 처리 작업에도 과도한 백그라운드 인프라 구축을 제안함
    • 단순히 프론트엔드에서 논블로킹 방식으로 처리하면 충분한데도 복잡한 아키텍처를 도입하려 함
    • 단순성을 유지하기 위해 계속해서 AI를 제어하는 것이 중요함
  • 비전문가가 AI만 믿고 개발하면 코드베이스 복잡성과 비효율이 누적되어 오히려 문제 해결 능력이 급격히 떨어지는 현상이 발생함

코드 리뷰의 본질과 효과

  • AI와의 협업은 열정적이지만 경험 부족한 주니어 개발자와 협업하는 것과 유사함
    • AI는 시간이 지나도 판단력이 성장하지 않으므로 지속적인 관찰이 필요함
  • 코드 리뷰의 가장 큰 실수는 작성된 코드만 보고, 더 좋은 대안이 있는지는 생각하지 않는 것
    • 최적의 코드 리뷰는 구조적 관점에서 전체 시스템 문맥을 통합적으로 고려함
    • 필요 없는 시스템을 새로 만들기보다는 기존 시스템을 재활용하는 방안이 우선임
  • 세밀한 코드 스타일만 집착하는 'nitpicky' 리뷰어는 AI 도구의 진정한 활용을 놓칠 수 있음
  • 'rubber-stamp' 리뷰어처럼 비판 없이 통과시키면 AI/주니어 개발자와 효과적 협업이 어려워짐

AI 도구 활용 기술에 대한 생각

  • git 등 전통적인 도구는 명확한 구조와 조작법이 있으나, AI의 기본 구조는 불투명함
    • AI는 거의 모든 종류의 연산을 수행할 수 있음
  • 일부는 AI 도구를 전방위적으로 활용하는 것이 AI 활용 능력이라 보고 있음
    • 실제로는 숙련된 사용자가 더 많은 가능성을 끌어낼 수 있음
  • 아직까지는 AI 코드 에이전트가 다양한 작업을 도와줄 수 있지만 밀접한 감독이 요구됨
  • "센타우르 체스" 모델처럼, 숙련된 인간의 방향성과 AI의 제안이 결합되면 최적의 생산성 달성이 가능함
  • AI 활용 실력은 결국 코드 리뷰 실력과 비판적 설계 판단력에 달려 있음
  • 코드 리뷰 스킬이 좋을수록 agentic AI 도구 활용 효과가 극대화됨

최종 생각 및 전망

  • AI 에이전트는 시간이 지남에 따라 점점 더 숙련된 엔지니어처럼 성장하는 듯한 느낌을 줄 수 있음
  • 향후 몇 년 내에는 AI와 협업하는 경험이 중견 엔지니어와 협업하는 수준까지 진화할 수 있음
  • 현재는 다양한 AI 도구(Codex, Claude Code, Copilot 등)를 활용해 실험하는 것이 바람직하며, 비판적 감독 능력이 가장 중요한 차별점

추가 의견

  • Hacker News 등에서 “AI 에이전트가 어느 수준까지 쓸모가 있는가”에 대한 논의가 있었음
    • 필자는 코드 리뷰만으로 AI가 리눅스 커널 수준에 기여할 수 있을 것이라 보지 않음
    • 일부는 스타일과 이름짓기와 같은 코드 리뷰 방법이 중요하다는 의견도 있음
    • 디자인 논의를 코드 리뷰에서 한다는 점에 대해 비판적 시각이 있지만, 필자는 이를 부정적으로 보지 않음
▲
GN⁺ 16시간전  [-]
Hacker News 의견

  • 나쁜 프로세스라도 품질 관리를 잘하면 좋은 결과가 나온다는 생각은 상당히 의심스러움, "잡동사니를 계속 뱉어내도 누군가 확인만 하면 괜찮다"는 식인데, 현실에서는 잘 작동하는 경우를 본 적이 없음, 미국 자동차 산업에서 이렇게 시도했던 적 있지만 성공적인 사례가 떠오르지 않음, 상상해보면 팀장인 나에게 상사가 "유능한 5명 대신에 완전 초보자 25명을 데리고, 운 좋게 뭔가 맞아떨어지는 결과물을 기다리겠다, 너는 다 검토해라"고 한다면 이건 말도 안 되는 이야기임, 그런데 AI가 이 시나리오에 들어오면 많은 사람들이 "음? 혹시 될지도?"라고 생각하게 되는 점이 신기함

    • 경험이 적거나 동기가 부족한 사람들의 코드를 리뷰하는 것도 매우 피곤함, 정신적으로나 감정적으로 엄청난 에너지 소모가 있음, 같은 기능을 4번이나 리뷰하다 보면 질려서 품질이 더 이상 올라갈 수 없는 단계에서 포기해버리게 됨

    • 이건 데밍(Edward Deming)이 일본에서 개발하고 서구권에 전파한 품질관리의 모범과는 완전 반대임, 품질은 사람에서 나오는 게 아니라 프로세스에서 나옴, 결함이 많은 공정을 선택해놓고 인간이 실수를 잡아줄 거라 기대하는 것은 품질이 목표라면 전혀 좋은 방법이 아님, LLM은 여러 방식으로 활용 가능하지만 그 중 일부만 이점이 있음, 경영진은 AI로 모든 문제를 해결할 수 있다고 환상에 빠져있고, AI의 장점·한계를 제대로 이해하지 못하거나 데밍의 교훈을 잊어버린 것으로 보임

    • 진화는 무작위 변이와 선택, 또는 모든 복잡한 생명의 존재 자체가 그 사례임, 내가 선호하는 방법은 아니지만, 유행하는 유행어에 열광해서 어울리지 않는 곳에도 마구잡이로 시도하는 경향이 있음, 주방용품 중 일부 플라스틱 부품 생산에선 품질이 나쁜 상태로 찍어낸 뒤 일용직이 수동으로 칼로 수정해서 포장하는 방식이 남아있음, 나 역시 이런 임시직을 해본 적이 있음, 반도체의 칩 빈닝/수율 관리도 실패율이 아주 높은 사례로 볼 수 있음, 현실만 둘러봐도 의심스러운 공정이 특이한 게 아니라 오히려 일상이 됨

    • "AI를 잘 다룬다"고 스스로 평가하기 시작하면 '내가 해결할 수 있는 문제의 범위가 엄청 넓어졌다'는 착각이 들게 됨, 이 현상은 모든 범용 기술에서 나타남, 과거에는 유전 알고리즘 붐이 있었을 때도 비슷함, 모두가 '범용' 도구를 찾고서 그 도구로 다 할 수 있다고 착각하게 됨, 실제론 아무런 맥락도 없는 상황에서 최적화를 시도함, AI는 이 현상이 더욱 극대화된 예시임

    • 아무리 프로세스가 잘 되어 있더라도 제대로 작동하는 시스템을 만드는 법 자체를 배울 수 없음, 반복해서 보게 되는 패턴은 팀이 한참을 헤매다가 결국 문제 해결 방법을 아는 엔지니어가 직접 나서서 제대로 방향을 잡아주는 것임

  • AI에게 요구 파라미터를 지키게 하는 게 정말 어려움, 항상 엉뚱한 방향으로 랜덤하게 벗어남, nftables 하이라이팅 작업을 할 때 토큰 230개, 상태 2,500개, 상태 전이 5만 개가 넘음, AI에게 다음 다섯 가지 명확한 규칙을 줘도 전부 무작위 지점에서 어긋남, 코딩 결과만이 아니라 아주 간단한 Vimscript도 제대로 못 만듦, 결과적으로 AI는 문서화 용도로만 사용함, 그래도 'rule', 'chain_block stmt', 'map_stmt_expr' 같이 쪼개서 설명하는 데는 AI가 제법 잘해주기 시작함, 내가 원하는 구문 패턴만 복붙해서 쓰면 됨

  • AI 코드 생성은 프로젝트 초기 단계에선 꽤 유용하지만, 성숙한 프로젝트에는 걱정스러운 점이 있음, 최근 28만+ LOC의 Postgres 파서를 Multigres에 머지했는데 공개 리뷰 없이 진행됨, 오픈소스 생태계에서 이런 건 경계해야 할 일임, 많은 사람들이 학습과 참고를 위해 이런 프로젝트에 의존하는데 제대로 된 리뷰 없이 AI 코드가 들어가면 교육용 가치와 의존성에 대한 신뢰가 약화됨, 코드 리뷰는 버그만 잡는 게 아니라 협업자들이 학습하고, 설계 이유를 이해하고, 집단 지식을 쌓는 핵심임, 속도가 아니라 지식 전달 프로세스가 문제임, 참고로 PR 공개까지 걸린 시간 관련해서는 링크 참조

    • 내가 이 작업을 감독했고, 더 나은 방향에 대한 피드백은 언제든 환영함, 이번 상황이 특별한 이유는 LLM을 활용해 Postgres C 파서를 번역한 일이라는 점임, 이 규모는 하나씩 줄줄이 리뷰할 수 없어서, 정합성을 확보하는 절차를 별도로 만들었음, 매일매일 꼼꼼히 점검해서 두 달이 걸림, Postgres의 테스트 대부분을 가져와 성공적으로 포팅했기에 동작 신뢰성도 충분히 확보함, Multigres의 현재 단계는 매우 초기라 앞으로 더 많은 프로젝트(Vitess 등)에서 대량 복사/번역을 시도할 예정임, 개선사항이 있으면 수용 예정임, 저자분이 전체 과정을 설명하는 블로그도 준비 중이니 참고 바람, 개인적으로 LLM의 도움으로 달성할 수 있었던 성과에 무척 놀랐음, 물론 어느 정도 숙련도는 필수였고, 이 분은 여기서 제시한 기준을 모두 뛰어넘음

  • 내 프로세스는 대략 이러함

    1. AI에 요구사항 제시
    2. AI가 나에게 명확하지 않은 부분을 질문하게 함
    3. 더 이상 질문이 없으면 요구사항을 공식 PRD 형태로 다시 설명하게 시킴
    4. 내가 비판
    5. 대안적 아키텍처 두 개 제안하도록 시킴
    6. 내가 하나 선택해서 비판
    7. 세부 TODO 리스트 두 가지 제안하게 시킴
    8. 내가 하나 선택해서 비판
    9. TODO 중 하나에 대해 두 가지 구현안 제시하도록 시킴
    10. 내가 하나 선택해서 비판
    11. 9번으로 반복
      수행 결과 중간중간 스냅샷을 찍어서 되돌아가기도 함
      이렇게 하면 훌륭한 수준까진 아니어도 최소한 내 구현의 기준점이 되는 결과물을 얻을 수 있음
      단점은 엄청나게 시간이 많이 걸리고, 80%의 경우 그냥 내가 혼자서 처음부터 다 하는 게 더 빨랐을 거라는 생각이 듦

    • 혼자 하는 것보다 느려 보임, AI 코딩을 하면 마치 "술 한잔 하면서 네가 써준 메모대로 대충 만들어봤어, 어때?"라는 중간 수준 개발자가 주말 밤새 즉흥적으로 만들어놓은 작업물을 보는 기분임, "NO, 마음에 들지 않음"이라고 한마디 해주고, 그래도 대략 방향성이 맞았다면 그걸 리팩터링하면서 월요일 아침부터 시작하는 것보다 좀 더 빠른 느낌임

    • 이런 단계별 가이드들을 매번 보면 결국 엄청난 번거로움을 추가하는 거라서 애초에 AI가 가져다줄 거라 기대했던 효율성이 다 사라짐, 실제로 내 경험에선 거의 사실임, 물론 AI가 도움이 되는 순간도 있지만, 언제·어디서 쓸모가 있는지 판단하는 것도 하나의 중요한 스킬임이라는 게 내 생각임

    • 나는 좀 더 낮은 레이어에서 작업하는데 보통 이런 식으로 함:

      • 기본 인터페이스를 직접 만들거나 이미 있으면 다음 단계 진행
      • LLM을 자동완성 도구로 활용
      • 요구사항을 서술하고 바뀌어야 할 진입점 파일도 알려줌
      • 목표는 한 번에 주지 않고 매번 한 단계씩만 제시함
      • 잘못될 조짐이 보이면 바로 개입해서 중단하거나 AI가 틀렸을 경우에는 방향을 잡아줌
        대체로 너무 넓고 긴 목표를 한 번에 주면 에이전트가 작업 완료 시점을 잘못 판단하는 경우가 많았음

    • 비슷하지만 좀 더 단순화된 프로세스를 씀, PRD까지 주고, 내가 대략적 아키텍처도 알려주고, 각 컴포넌트 구현을 원하는 방식으로 시킴, 여전히 시간은 많이 들고, 직접 작업이 더 빠르겠지만, 이제는 손수 줄줄이 코딩하는 게 귀찮아서 LLM에게 함수 단위로 시켜볼까 생각 중임

    • AI를 대략적인 접근방식, 라이브러리, 언어 특징 등을 알려주는 데에만 썼다면, 본 업무는 그냥 내가 직접 했으면 훨씬 빨랐을 것 같음

  • 코드 리뷰를 잘한다면, AI 에이전트는 아예 안 쓰는 게 나을 수 있음

    • 내가 직접 Claude Code 같은 에이전트와 사랑에 빠진 동료들의 코드를 리뷰하고 버그를 수정하면서 느낀 점은, 코드가 마치 환각 상태에서 쓴 것처럼 엉뚱하고, 짠 사람은 그 코드에 대해 전혀 설명도 못하는 경우가 많았음, 그래도 정말 좋은 코드를 만드는 사람도 있을 거라 믿지만, 내가 실제로 본 것들은 죄다 실망스러웠음, 다행히 몇몇은 스스로 깨닫고 다시 제대로 된 방식을 찾았음, 요즘 에이전트 기반 워크플로우에서 나오는 결과물을 비판적으로 보면 답이 명확하다고 생각함, 코드를 잘 리뷰하는 사람이라면 이 결론에 훨씬 더 빨리 도달할 것임

    • 내가 코드 리뷰를 잘한다면, 계속 더 실력을 쌓고 싶음

  • 코드 리뷰를 꼼꼼히 하는 사람은 AI 도구 사용에 어려움을 겪고, 반대로 대충하는 사람은 AI에 너무 의존하게 됨
    즉, 코드 리뷰를 잘하는 사람들은 직접 코딩하는 게 더 낫고, 이런 프로젝트일수록 장기적으로 본인이 관리해야 하니 직접 짜는 게 훨씬 자연스러움, 코딩이 귀찮지도 않고 능숙하게 할 수 있다면 굳이 AI 쓸 필요가 없음, AI는 모르는 도구나 새로운 걸 익힐 때 단편적으로 살짝 알아보는 용도가 최적임, 요즘 LLM 덕분에 검색 엔진 요약이 좋아진 건 인정함, 쓸 데 없는 문서 해석하느라 헤매거나, 본질과 상관없는 내용에 잡생각 빠지던 시간이 제로가 됨

  • 코드 리뷰도 업무의 일부이긴 하지만, 가장 즐겁지 않은 파트임, 개발자들이 직접 코딩하는 순간에서 만족감을 얻으니까, AI 툴은 도움이 되긴 하지만, 비예측적이면서도 설득력 있어 보이기 때문에 더 꼼꼼하게 리뷰해야 해서 오히려 부담이 늘어남, 왜 우리는 재밌는 부분을 빼앗기고 비재미 요소만 늘리는 도구를 만든 걸까, "코드 리뷰" 전담 에이전트는 어디 있는지 궁금함

    • 사실 나는 코드 '작성' 그 자체는 별로 즐겁지 않음, 문제를 풀고 새로운 걸 만들어내고, 시스템을 쪼개서 더 나은 구조로 재조합하는 게 더 재밌음, LLM을 이용해서 코딩하면 아이디어를 실제로 만져볼 수 있는 결과물로 옮기는 속도가 훨씬 빨라진 느낌임, 기존 코드도 타입 안정성이 더 높아지고, 문서화가 잘 되어 있고, 복잡한 리팩터링이 더 쉬워짐, LLM을 문제해결 용도로 기대하지 않고, 맥락 모으기, 패턴 재적용, 반복코드 자동화 등에서 기대함, 특히 여러 파일에 분산된 코드를 일일이 작성하지 않고 AI가 자동 생성해주면 각 변경만 확인하면 되니까 엄청 편함

    • OpenAI Codex Cloud가 코드 리뷰 기능을 추가했고, 새로운 GPT-5-Codex 모델은 코드 리뷰에 특화되어 훈련됨 [Codex 업그레이드 소개], Gemini와 Claude도 GitHub Actions 연동 코드 리뷰 기능이나 클로드 GitHub 연동 등이 생겼음, GitHub도 자체적으로 Copilot Code Review 기능을 런칭함, CodeRabbit, Greptile, Qodo Merge 같은 전담 스타트업들도 많음

    • 내가 진짜로 짜릿함을 느끼는 순간은, 구현하면서 그 아래 숨겨진 아주 우아한 구조를 발견해 예전까지의 프로그래밍 방식이나 심지어 삶의 방식 자체가 달라질 때임 (이런 일은 정말 드물게 일어나지만)

    • 신입 개발자일수록 코드를 직접 작성하는 걸 좋아하고, 시니어는 오히려 코드를 줄이는 걸 사랑함, 개인적으로는 코드 리뷰가 내 업무 중 가장 재밌는 부분임 (내 작업 마감이 쫓기지 않을 때), 코드 리뷰가 재미없다는 주장에는 동의하지 않음

    • 도입부에서 "대다수 개발자들이 새로 만들기를 좋아한다"는 언급이 있었는데, 실제로는 남들이 만들어놓은 코드베이스 위에서 패턴과 구조 파악하고 개선하는 걸 선호하는 사람도 많음, 완전히 새로운 걸 만드는 과정(초기 설계 - 무한 반복)이 더 힘든 사람도 있다는 점을 감안해야 함, "재미를 빼고 비재미만 늘렸다"는 질문에 대해선, 아마 생산성 향상이 가장 크게 느껴지는 부분에 집중했기 때문일 것임, 리뷰 AI로는 CodeRabbit, GitLab Duo 등 다양한 선택지가 이미 있음, RooCode처럼 Git diff 입력해서 코드 리뷰를 맡기는 것도 무리 없음

  • 이 글 제목은 너무 단순하게 느껴짐, 코드 리뷰와 설계 리뷰는 다르고, AI로 시도하는 건 이 둘만도 아님, AI를 활용하려면 그 영역에 대한 전문 지식이 필요하고, 코딩만 놓고 봐도 리뷰 능력만으론 부족하고, AI에게 맡긴 작업이 어떤 분야건 그걸 검증할 수 있는 역량이 필요함, 오히려 AI가 도움이 되는 건 내가 잘 모르는 언어나 프레임워크를 접할 때지만, 그땐 코드 리뷰도 깊게 못하게 됨, "코딩"이란 단어가 AI/LLM 시대에 다시 유행하는 것도 신기함, 요즘 기업들은 단순한 코더보다 아키텍처, 요구사항 분석, 풀스택 개발, 운영까지 다 할 수 있는 엔지니어를 선호하는 것 같음

    • 내 공식 직함은 "Software Engineer"지만 최근 5년 동안

      1. 우리 팀 위한 Kubernetes 클러스터 직접 세팅/운영
      2. Docker를 정말 많이 사용
      3. CI/CD 파이프라인 개발
      4. 통합작업/테스트는 수없이 해옴
      5. 각종 시스템 도식을 비롯해 요구사항 문서화도 엄청 많이 함
      6. 인프라 팀이 안 해주는 IT 기타 업무
      7. 간혹 코드도 짬

    • AI 에이전트 올바르게 활용하는 건 리뷰 프로세스와 동일함
      왜냐하면 LLM은 엄청난 양의 코드를 생산할 수 있지만, 아직 유능한 소프트웨어 엔지니어가 가진 깊은 판단력을 갖추지 못했기 때문임
      잘 모르는 방향으로 한참 코드가 쌓이게 두는 것보다 일찍 코스 수정하는 게 훨씬 나음, 신입 개발자랑 할 때처럼 먼저 큰 그림/디자인을 논의하고, 방향이 틀어질 때마다 일찍 잡아주는 게 현명함, 100K 토큰의 코드가 다 쌓이고 나서야 처음 100줄이 잘못됐다는 걸 알면 결국 전체를 뜯어고쳐야 하니까

  • 동료들과 코드 리뷰하면서 공동 지식과 기준이 향상된다는 생각에 매우 좋아함, 하지만 고집 세고 비협조적인 AI의 코드는 리뷰 생각만 해도 번아웃이 올 것 같음

  • 내가 업무 중 가장 지루한 파트를 잘하게 되면, 그 업무만 평생 하게 되는 건가 싶은 생각이 듦, 솔직히 싫음, 그리고 글에서 말한 것처럼, 버그는 애초에 안 들어가는 게 언제나 더 좋음, 들어간 이후에 잡히는 건 위험 부담임

답변달기