# AI가 코드 리뷰하고 업무 맥락을 쌓는다: 두 가지 내부 에이전트 사례 > 2026-08-10 · How I AI · 큐레이션 김태우 > https://challengekim.com/insights/ai가-코드-리뷰하고-업무-맥락을-쌓는다-두-가지-내부-에이전트-사례 > 원문: https://www.lennysnewsletter.com/p/how-i-ai-build-an-ai-code-review ## 핵심 요약 - Claire는 Vercel Eve와 Codex를 이용해 풀 리퀘스트(PR)의 위험을 평가하고, 낮은 위험의 변경을 자동 승인하는 에이전트를 만들었다. - 이 에이전트는 변경 규모·영향 범위·되돌리기 용이성·데이터 및 보안·운영 영향·테스트와 CI 완료 여부를 평가한다. 직접 병합하지는 않는다. - AI 리뷰를 운영하려면 판단 기준을 정책에 반영하고, 결정 기록을 남기며, 평가가 맞았는지 지속해서 확인해야 한다. - Grace Clarke는 고객 발굴, 제안서 작성, 자신의 판단과 문체를 담은 가이드에 Claude를 활용한다. 이메일 처리도 Claude로 옮겨 고객과의 상호작용을 다음 업무의 맥락으로 쓴다. ## PR 위험을 점수로 구분한 코드 리뷰 에이전트 Claire가 만든 ‘Merge Mommy’는 PR을 검토해 위험을 평가한다. 출발점은 검사 작업이 끝나기를 기다린 뒤 PR을 낮음·중간·높음 위험으로 분류하고, 낮은 위험의 PR을 자동 승인하는 GitHub 봇을 만들라는 짧은 요청이었다. 이후 한 번의 Codex 세션에서 지시를 다듬어 에이전트를 완성했다. 위험 모델은 변경 규모, 변경의 영향 범위, 되돌리기 용이성, 데이터 및 보안에 미치는 영향, 운영상 영향, 테스트와 지속적 통합(CI) 작업의 완료 여부를 본다. 24점 미만은 낮은 위험으로 분류해 에이전트가 승인하고, 64점 초과는 사람에게 검토를 넘긴다. 원문은 두 경계 사이의 처리 규칙을 구체적으로 설명하지 않는다. ## 승인 신호와 최종 병합은 구분한다 Merge Mommy는 PR을 직접 병합하지 않는다. GitHub에 회색 체크 표시를 남기고, Slack에 위험 점수와 함께 승인·병합할 준비가 됐다는 메시지를 보낸다. 검토에 필요한 판단을 덜어주되 마지막 병합 동작은 사람에게 남기는 방식이다. 원문은 AI 리뷰의 비교 사례로 Intercom을 든다. Intercom의 AI 시스템이 승인한 PR은 사람이 검토한 PR보다 처리 속도가 5배 빠르고 되돌림 비율도 낮았다고 소개한다. 이는 해당 사례의 결과이며, 모든 코드베이스에서 같은 성과가 난다는 근거는 제시하지 않는다. ## 배포 편의만큼 기록과 평가가 중요하다 Vercel Eve는 Slack·GitHub 연결, 토큰 갱신, 격리 실행 환경, 채널 간 전달을 맡는다. 이 덕분에 Claire는 복잡한 인증 설정보다 마크다운으로 작성하는 지시와 스킬에 집중할 수 있었다. Slack 봇과 GitHub 앱 설정의 상당 부분은 Codex가 브라우저에서 처리했고, 사람은 주로 저장 버튼을 누르고 2단계 인증을 마쳤다. 자동 승인 절차를 운영할 때는 위험 모델을 조직의 코드 리뷰·보안 정책에 반영하고 각 결정을 기록해야 한다는 것이 원문의 주장이다. Intercom은 에이전트의 PR 리뷰를 모두 기록한 뒤 엔지니어가 점수와 권고가 적절했는지 평가한다고 소개된다. 내부 에이전트도 이런 평가를 통해 판단이 나빠지는지 확인할 필요가 있다는 설명이다. ## 문제 설명에서 시작한 Grace의 업무 흐름 AI 교육자이자 전 마케팅 컨설턴트인 Grace Clarke는 Claude를 중심으로 자신의 서비스 업무를 재구성했다. 처음에는 이메일이 너무 많고 고객과의 소통이 원하는 만큼 따뜻하지 않으며 매주 행정 업무에 20시간을 쓴다는 문제를 Claude Code에 말로 설명했다. 이후 고객 발굴을 매시간 수행하는 파이프라인, 제안서 작성 도구, 자신의 사고방식을 담은 가이드를 스킬로 운영하게 됐다. 여기서 스킬은 Claude가 반복해서 따를 수 있도록 문서화한 업무 지침이다. Grace는 완벽한 프롬프트를 만드는 것보다 문제와 원하는 결과를 설명하고 Claude가 제안을 가져오게 하는 방식을 중시한다. 스킬도 새 직원에게 일을 가르치듯 업무를 설명하고, 실행 결과를 고치며 지침을 개선하는 식으로 만든다고 소개한다. ## 문체 가이드와 이메일을 업무 맥락으로 바꾸다 Grace의 문체 가이드는 글투만 정하는 문서가 아니다. 의사결정 방식, 교육과 컨설팅에 대한 생각, 좋은 소통의 기준, 닮고 싶지 않은 LinkedIn 게시물의 유형까지 담는다. 마음에 들지 않는 표현을 발견하면 Claude에 음성 메모를 보내 가이드를 고친다. 그는 Gmail에만 쌓이는 답장에는 고객의 소통 방식과 관심사, 관계의 이력이 담겨 있지만 그 정보가 다음 AI 작업에 활용되기 어렵다고 봤다. 그래서 이메일 처리 흐름을 Claude로 옮겨 상호작용을 이후 업무의 맥락으로 쓰도록 했다. 주도적으로 조사하고 처리할 일이 있을 때는 Claude Code를 쓰고, 시각적으로 다루기 쉬운 환경이 필요할 때는 마크다운 인수인계 파일을 만들어 새 Cowork 세션으로 옮긴다. ## 도구를 익히는 방식도 바꿨다 Grace는 예전에 학생들에게 정교하게 작성한 프롬프트를 제공했지만, 학생들은 그 방식이 오히려 어렵다고 말했다. 이후에는 무엇을 완성할지 먼저 정하기보다 작업 중인 화면을 캡처해 Claude에 넣어보는 식으로 AI를 사용하는 습관을 강조했다. 새 고객에게는 Claude로 만든 비밀번호 보호형 대화식 환영 화면을 보여준다. 이 화면은 고객 안내와 제안서, 작업 방식의 시연을 겸한다. ## 결론 두 사례는 서로 다른 업무를 다루지만, 반복되는 판단을 지침으로 만들고 실제 결과를 보며 고친다는 공통점이 있다. 코드 리뷰 사례에는 위험 기준과 결정 기록, 사후 평가가 필요하고, 고객 업무 사례에는 소통과 판단의 맥락을 계속 갱신하는 과정이 필요하다. --- 원문을 바탕으로 AI 가 한국어로 요약·재구성한 글입니다. 인용·수치는 원문 링크에서 확인해 주세요. [원문 링크](https://www.lennysnewsletter.com/p/how-i-ai-build-an-ai-code-review)