AI에게 일을 맡겼더니 코드 리뷰 대상이 둘이 되었습니다

AI에게 일을 맡겼더니 코드 리뷰 대상이 둘이 되었습니다

ai-code-review-two-suspects-hero

소개

AI에게 코드를 맡기면 일이 줄어들 것 같았습니다. 그런데 막상 써 보니 이상한 일이 생겼습니다. 코드 리뷰 대상이 하나에서 둘로 늘었습니다. 예전에는 내가 작성한 코드만 설명하면 됐는데, 이제는 AI가 만든 코드까지 "제가 시킨 겁니다"라고 책임져야 합니다. 마치 회의에 대리인을 보냈더니, 대리인이 회의록을 아주 자신 있게 잘못 써 와서 함께 해명하러 들어가는 상황과 비슷합니다.

AI 도구는 분명 강력합니다. 반복 작업을 줄이고, 익숙하지 않은 문법을 빠르게 떠올리게 해 주고, 테스트 케이스 초안을 만들어 주며, 에러 메시지를 해석하는 데도 도움을 줍니다. 하지만 AI가 작성한 코드는 자동으로 안전해지지 않습니다. 실행된다고 해서 좋은 코드가 되는 것도 아닙니다. 리뷰를 통과해야 하고, 운영 환경에서 버텨야 하며, 팀원이 읽을 수 있어야 합니다.

이 글에서는 AI에게 일을 맡겼을 때 왜 코드 리뷰 책임이 사라지지 않는지, 오히려 어떤 부분은 더 중요해지는지 살펴보겠습니다. 주니어 개발자와 실무 개발자가 AI 생성 코드를 어떻게 검토해야 하는지, 코드 리뷰에서 어떤 질문을 던져야 하는지, 그리고 AI를 팀의 생산성을 높이는 도구로 쓰기 위해 어떤 습관이 필요한지 정리해 보겠습니다.

AI가 코드를 작성해도 책임은 사람에게 남습니다

가장 먼저 인정해야 할 사실이 있습니다. AI가 작성한 코드라도 최종 책임은 그 코드를 프로젝트에 넣은 사람에게 있습니다. 코드 작성자는 AI일 수 있지만, 코드 소유자는 사람입니다. 코드 리뷰에서 "AI가 그렇게 만들었습니다"라는 말은 설명이 될 수는 있어도 면책 사유가 되기는 어렵습니다. 운영 장애 앞에서 로그는 작성자의 마음을 헤아려 주지 않습니다. 로그는 그저 차갑게 실패한 줄 번호를 보여줄 뿐입니다.

AI는 사용자가 준 맥락 안에서 답변합니다. 요구사항이 빠져 있거나, 보안 조건이 없거나, 기존 아키텍처를 알려 주지 않으면 그럴듯한 일반론을 제시합니다. 문제는 그 일반론이 우리 프로젝트에는 맞지 않을 수 있다는 점입니다. 예를 들어 인증 로직, 결제 흐름, 권한 처리, 개인정보 저장 방식은 프로젝트마다 제약이 다릅니다. AI가 만든 코드가 문법적으로 맞아도 서비스 정책에는 맞지 않을 수 있습니다.

그래서 AI를 활용하는 개발자는 단순한 사용자에서 검토자로 역할이 바뀝니다. 코드를 처음부터 모두 직접 작성하지 않더라도, 결과를 읽고 판단하고 수정해야 합니다. 이 과정이 빠지면 AI는 생산성 도구가 아니라 버그를 빠르게 복사해 주는 장치가 될 수 있습니다. 물론 아주 친절한 얼굴로 말입니다.

코드 리뷰 대상이 둘이 된다는 의미

AI를 쓰기 전 코드 리뷰의 중심은 사람이 작성한 코드였습니다. 왜 이런 구조를 선택했는지, 테스트는 충분한지, 예외 처리는 빠지지 않았는지 확인했습니다. AI를 사용한 뒤에는 여기에 한 가지 질문이 추가됩니다. "AI가 만든 결과를 작성자가 제대로 이해하고 있는가?"입니다.

이 질문은 생각보다 중요합니다. AI가 만든 코드를 그대로 붙여 넣은 경우, 작성자가 코드의 의도를 설명하지 못할 수 있습니다. 리뷰어가 "여기서 이 조건문은 왜 필요한가요?"라고 물었을 때 "AI가 넣었습니다"라고 답하면 분위기가 살짝 서늘해집니다. 그 순간 코드 리뷰는 기술 검토에서 작은 진실의 방으로 바뀝니다.

리뷰 대상	확인해야 할 질문	놓치면 생기는 문제
사람이 작성한 코드	요구사항을 정확히 반영했나요?	기능은 돌아가지만 실제 목적과 어긋날 수 있습니다.
AI가 생성한 코드	작성자가 코드의 의도와 한계를 이해하나요?	문제가 생겼을 때 수정 방향을 잡기 어렵습니다.
프롬프트	AI에게 충분한 맥락과 제약을 줬나요?	그럴듯하지만 프로젝트와 맞지 않는 코드가 나옵니다.
검증 절차	테스트와 예외 상황을 확인했나요?	리뷰에서는 통과해도 운영에서 실패할 수 있습니다.

결국 AI 시대의 코드 리뷰는 코드만 보는 시간이 아닙니다. 코드가 만들어진 과정도 함께 보는 시간이 됩니다. 어떤 질문을 했고, 어떤 답변을 받았고, 무엇을 수정했고, 어떤 검증을 했는지 설명할 수 있어야 합니다. AI에게 일을 맡겼다면 그 작업 지시서도 어느 정도는 리뷰 대상이 되는 셈입니다.

AI 생성 코드에서 자주 보이는 위험 신호

AI가 만든 코드는 겉보기에는 깔끔한 경우가 많습니다. 변수명도 제법 그럴듯하고, 주석도 친절하며, 구조도 정돈되어 보입니다. 그래서 더 조심해야 합니다. 보기 좋은 코드는 믿음을 빠르게 얻지만, 믿음이 빠른 만큼 검증도 빨라야 합니다.

프로젝트 맥락을 모르는 코드

AI는 현재 프로젝트의 역사와 팀의 암묵적인 규칙을 모를 수 있습니다. 예를 들어 이미 공통 에러 처리 미들웨어가 있는데도 함수 안에서 별도 처리 로직을 만들 수 있습니다. 기존 상태 관리 방식이 있는데 새로운 패턴을 제안할 수도 있습니다. 결과만 보면 동작하지만, 전체 구조에서는 이질적인 코드가 됩니다.

예외 상황이 부족한 코드

AI는 정상 흐름을 중심으로 코드를 만들 때가 많습니다. 하지만 실제 서비스는 정상 흐름보다 예외 흐름에서 더 자주 흔들립니다. 네트워크 실패, 빈 응답, 권한 부족, 만료된 토큰, 중복 요청, 잘못된 입력값을 확인해야 합니다. 사용자는 늘 우리가 기대한 순서대로 움직이지 않습니다. 버튼이 있으면 두 번 누르는 사람도 있고, 세 번 누르는 사람도 있으며, 가끔은 누르면 안 되는 순간에 가장 정확히 눌러 줍니다.

보안 기준이 빠진 코드

인증, 권한, 개인정보, 파일 업로드, 외부 API 호출이 들어가는 코드는 특히 조심해야 합니다. AI가 예시 코드에서 민감한 값을 하드코딩하거나, 입력값 검증을 생략하거나, 권한 확인을 단순화할 수 있습니다. 예제 코드와 운영 코드는 다릅니다. 예제는 설명을 위해 간단해야 하지만, 운영 코드는 사용자의 창의적인 실수까지 견뎌야 합니다.

너무 일반적인 코드

AI가 만든 코드는 특정 프로젝트에 딱 맞기보다 일반적인 구조로 나올 때가 많습니다. 이 자체가 나쁜 것은 아닙니다. 하지만 팀의 기존 코드 스타일, 폴더 구조, 로깅 방식, 테스트 전략과 맞지 않으면 유지보수가 어려워질 수 있습니다. 좋은 코드는 독립적으로 멋진 코드가 아니라, 프로젝트 안에서 자연스럽게 읽히는 코드입니다.

AI에게 일을 맡기기 전에 해야 할 일

AI에게 일을 맡기는 것은 단순히 요청 문장을 쓰는 일이 아닙니다. 작은 작업 지시서를 작성하는 일에 가깝습니다. 좋은 지시가 좋은 결과를 만듭니다. 개발 업무에서 AI를 사용할 때는 다음 내용을 먼저 정리해 보세요.

1. 해결하려는 문제를 한 문장으로 정의합니다.
2. 현재 프로젝트의 기술 스택과 관련 파일 구조를 설명합니다.
3. 반드시 지켜야 할 제약 조건을 적습니다.
4. 원하는 출력 형태를 구체적으로 말합니다.
5. 테스트 방법이나 검증 기준도 함께 요청합니다.
6. AI 답변을 그대로 쓰지 않고 수정할 계획을 세웁니다.

예를 들어 "로그인 기능 만들어 주세요"라고 하기보다 다음처럼 요청하는 편이 좋습니다.

React 기반 화면에서 로그인 상태를 관리하는 함수를 개선하고 싶습니다.
현재 JWT를 사용하고 있고, API 요청에는 Authorization 헤더가 필요합니다.
외부 상태 관리 라이브러리는 추가하지 않으려고 합니다.
토큰이 없거나 만료된 경우의 예외 처리도 포함해 주세요.
코드와 함께 테스트해야 할 시나리오를 목록으로 정리해 주세요.

이렇게 요청하면 AI는 단순 코드 생성기가 아니라 더 유용한 초안 작성 도구가 됩니다. 물론 이 결과도 바로 병합하면 안 됩니다. 초안은 초안입니다. 초안을 바로 운영에 올리는 것은 라면 봉지를 뜯자마자 "요리가 끝났다"고 말하는 것과 비슷합니다. 아직 끓여야 합니다.

AI 생성 코드를 리뷰하는 실전 체크리스트

AI가 만든 코드를 받았다면 아래 체크리스트를 사용해 보세요. 모든 항목을 매번 깊게 볼 필요는 없지만, 중요한 기능일수록 꼼꼼히 확인해야 합니다.

검토 항목	확인 질문	실무 팁
요구사항	정말 필요한 기능을 구현했나요?	처음 요청한 목표와 결과 코드를 비교합니다.
이해도	내가 이 코드를 설명할 수 있나요?	리뷰 전에 주요 흐름을 말로 설명해 봅니다.
예외 처리	실패 흐름을 충분히 다뤘나요?	빈 값, 만료, 중복 요청, 네트워크 실패를 확인합니다.
보안	민감한 값이나 권한 검사가 안전한가요?	토큰, 개인정보, 파일 업로드, 외부 요청을 집중적으로 봅니다.
일관성	팀의 기존 코드 스타일과 맞나요?	폴더 구조, 네이밍, 로깅, 에러 처리 방식을 비교합니다.
테스트	자동 또는 수동 검증이 가능한가요?	정상 흐름과 실패 흐름을 함께 테스트합니다.

이 체크리스트의 핵심은 "AI가 맞았는가"만 묻지 않는 것입니다. 더 중요한 질문은 "이 코드가 우리 프로젝트에서 안전하게 유지될 수 있는가"입니다. 코드는 작성 순간보다 유지보수 시간이 훨씬 깁니다. 오늘의 편리함이 다음 달의 야근으로 돌아오지 않게 하려면 리뷰가 필요합니다.

코드 리뷰에서 AI 사용 사실을 숨기지 않는 편이 좋습니다

AI를 사용했다는 사실을 무조건 크게 알릴 필요는 없지만, 중요한 부분에서는 투명하게 공유하는 것이 좋습니다. 특히 복잡한 로직, 보안 관련 코드, 성능에 민감한 코드라면 "초안은 AI 도움을 받아 작성했고, 제가 이 부분을 수정했습니다"라고 설명하면 리뷰어가 더 적절하게 볼 수 있습니다.

이 말은 부끄러운 고백이 아닙니다. 오히려 작업 과정을 설명하는 것입니다. 개발자는 이미 검색, 문서, 예제 코드, 동료의 조언을 활용해 왔습니다. AI도 그 도구 목록에 들어왔을 뿐입니다. 다만 AI의 답변은 검증 없이 받아들이기 쉽기 때문에, 검토 과정을 함께 말하는 것이 중요합니다.

AI를 썼다는 사실보다 중요한 것은 AI가 만든 결과를 내가 이해했고, 프로젝트 기준에 맞게 검토했다는 사실입니다.

리뷰어에게는 이렇게 말할 수 있습니다. "이 부분은 AI로 초안을 만들었고, 기존 에러 처리 방식에 맞게 수정했습니다. 다만 토큰 만료 처리 흐름은 한 번 더 확인받고 싶습니다." 이 정도면 충분히 좋은 협업 신호입니다. 리뷰어도 어디를 집중해서 봐야 할지 알 수 있습니다.

AI에게 다시 리뷰를 맡기는 방법

재미있는 점은 AI가 만든 코드를 다시 AI에게 리뷰시킬 수도 있다는 것입니다. 다만 이것도 완전한 해결책은 아닙니다. 같은 도구가 만든 코드를 같은 방식으로 검토하면 같은 맹점을 놓칠 수 있습니다. 그래서 질문을 다르게 구성해야 합니다.

예를 들어 "이 코드 리뷰해 주세요"라고만 묻지 말고, 관점을 나눠서 요청하세요.

• 보안 관점에서 위험한 부분을 찾아 주세요.
• 예외 처리와 실패 흐름이 부족한 부분을 찾아 주세요.
• 테스트 케이스로 검증해야 할 상황을 정리해 주세요.
• 기존 코드 스타일과 맞지 않을 수 있는 부분을 추정해 주세요.
• 성능보다 가독성을 우선할 때 개선할 부분을 제안해 주세요.

이렇게 관점을 나누면 AI 리뷰의 품질이 좋아집니다. 사람 리뷰 전에 한 번 걸러내는 용도로도 좋습니다. 다만 최종 판단은 여전히 사람이 해야 합니다. AI에게 AI가 만든 코드를 리뷰시키는 모습은 약간 거울을 들고 거울을 보는 것 같지만, 각도를 잘 잡으면 생각보다 유용합니다.

주니어 개발자에게 특히 중요한 이유

주니어 개발자는 AI를 통해 빠르게 많은 코드를 볼 수 있습니다. 이것은 큰 장점입니다. 예전에는 특정 패턴을 익히려면 예제 프로젝트를 찾아보고 직접 따라 해 봐야 했습니다. 이제는 원하는 상황을 설명하면 AI가 여러 가지 접근을 빠르게 보여줍니다. 학습 속도가 빨라질 수 있습니다.

하지만 위험도 있습니다. 코드를 이해하기 전에 결과만 복사하는 습관이 생길 수 있습니다. 겉으로는 생산성이 오른 것처럼 보이지만, 실제 실력은 느리게 자랄 수 있습니다. 주니어 시절에 중요한 것은 단순히 많은 코드를 작성하는 것이 아니라, 왜 그렇게 작성하는지 이해하는 것입니다.

AI를 쓸 때마다 다음 질문을 스스로에게 던져 보세요. "이 코드를 내가 설명할 수 있는가?", "이 코드가 실패한다면 어디서 실패할까?", "이 방식 말고 다른 선택지는 무엇인가?", "팀의 기존 방식과 충돌하지 않는가?" 이 질문을 반복하면 AI는 단순 대필 도구가 아니라 학습 도구가 됩니다.

AI와 함께 일하는 팀의 코드 리뷰 문화

AI 사용이 늘어나면 팀의 코드 리뷰 문화도 조금 바뀌어야 합니다. 예전처럼 결과 코드만 보는 방식으로는 부족할 수 있습니다. 이제는 코드가 만들어진 맥락, 프롬프트의 품질, 작성자의 이해도, 검증 절차도 함께 보는 것이 좋습니다.

팀 차원에서는 AI 사용 기준을 간단히 정해 두는 것이 도움이 됩니다. 예를 들어 민감한 내부 정보는 AI 도구에 입력하지 않기, 보안 관련 코드는 반드시 사람 리뷰를 받기, AI 생성 코드는 테스트 없이 병합하지 않기, 주요 로직은 작성자가 직접 설명할 수 있어야 하기 같은 원칙입니다.

이런 기준은 AI 사용을 막기 위한 것이 아닙니다. 오히려 안심하고 쓰기 위한 안전장치입니다. 안전벨트가 자동차의 속도를 없애는 것이 아니라, 더 안전하게 이동하게 해 주는 것과 같습니다. 물론 안전벨트를 했다고 운전대를 놓아도 된다는 뜻은 아닙니다. AI도 마찬가지입니다.

자주 묻는 질문

AI가 만든 코드는 코드 리뷰에서 반드시 밝혀야 하나요?

항상 의무처럼 말할 필요는 없지만, 중요한 로직이나 보안 관련 코드라면 밝히는 편이 좋습니다. 핵심은 AI 사용 여부 자체보다 작성자가 코드를 이해하고 검증했는지입니다. 리뷰어가 집중해서 봐야 할 부분을 알 수 있도록 작업 과정을 간단히 공유하세요.

AI가 만든 코드도 테스트를 꼭 작성해야 하나요?

네. 오히려 더 필요할 수 있습니다. AI가 만든 코드는 정상 흐름은 그럴듯하게 처리하지만 예외 흐름을 놓칠 수 있습니다. 정상 입력, 빈 입력, 권한 실패, 네트워크 실패, 중복 요청 같은 상황을 테스트하는 것이 좋습니다.

AI에게 코드 리뷰까지 맡기면 사람 리뷰는 줄여도 되나요?

AI 리뷰는 사람 리뷰 전에 사용하는 보조 점검으로는 유용합니다. 하지만 사람 리뷰를 완전히 대체하기는 어렵습니다. 프로젝트 맥락, 운영 이력, 팀의 설계 의도는 사람이 더 잘 알고 있기 때문입니다.

주니어 개발자는 AI를 어느 정도까지 써도 괜찮을까요?

학습과 생산성을 위해 적극적으로 사용할 수 있습니다. 다만 결과를 이해하지 못한 채 붙여 넣는 습관은 피해야 합니다. AI에게 초안을 받았다면 반드시 직접 읽고, 수정하고, 테스트하고, 설명할 수 있는 상태로 만들어야 합니다.

마무리

AI에게 일을 맡긴다고 해서 개발자의 책임이 사라지지는 않습니다. 오히려 질문하는 능력, 검토하는 능력, 설명하는 능력이 더 중요해집니다. AI가 코드를 빠르게 만들어 주는 시대에는 "누가 더 빨리 붙여 넣는가"보다 "누가 더 정확히 이해하고 검증하는가"가 실력의 차이를 만듭니다.

코드 리뷰 대상이 둘이 되었다는 말은 농담처럼 들리지만, 그 안에는 중요한 현실이 있습니다. 이제 우리는 사람이 작성한 코드뿐 아니라 AI가 만든 초안, 그 초안을 만든 질문, 그리고 결과를 검증한 과정까지 함께 봐야 합니다. 번거로워 보일 수 있지만, 이 과정을 잘 익히면 AI는 위험한 자동완성기가 아니라 강력한 협업 도구가 됩니다.

다음에 AI가 멋진 코드를 만들어 주면 바로 병합 버튼을 누르기 전에 한 번만 더 물어보세요. "내가 이 코드를 설명할 수 있을까?" 그 질문에 자신 있게 답할 수 있다면, AI에게 일을 맡긴 것이 진짜 생산성으로 이어질 가능성이 높습니다. 그렇지 않다면 아직 리뷰 대상은 코드만이 아닙니다. AI와 나, 둘 다 잠시 회의실에 남아야 합니다.