AI 에이전트팀에게 챗봇 API를 맡겼더니 — 2단계 리뷰가 잡은 숨은 버그
📚 「AI 헬스케어 파이널 프로젝트」 연재 11편입니다. (10편: 모르면 ‘왜?‘만 물었다)

📝 한줄 요약
지난 편까지 터미널에서만 돌던 의료 RAG(자료를 찾아 근거로 답하는 방식) 챗봇을 이번엔 진짜 서비스 통로(API)로 연결했습니다. 혼자 짜는 대신 AI 에이전트팀(여러 AI 역할을 나눠 협업시키는 방식)에게 작업을 쪼개 맡기고 매 단계 2단계로 검토하게 했습니다. 그랬더니 혼자선 절대 못 잡았을 버그를 잡아냈습니다. 바로 컨테이너(실제 서버 환경) 안에서만 터지는 오류였죠.
바쁘시면 이것만 읽어도 돼요:
- 의료 챗봇의 ‘검색·추론’을 실제 서비스 통로(API)로 연결
- 팀원의 작업 97개와 내 작업을 처음으로 합치고(merge), 남이 짠 코드 9,600줄을 AI로 점검해 보안 구멍을 발견
- 챗봇 통로는 혼자 안 짜고 AI 에이전트팀에게 작업 단위로 분업 + 매 단계 요구사항·품질 2단계 검토
- 그 2단계 검토가 “내 컴퓨터에선 되는데 서버에선 죽는” 숨은 버그를 잡음
- 합친 뒤 자동검사(CI)가 깨졌다가 복구 — “합치는 타이밍”의 교훈
🎯 이런 분들께 도움돼요
- AI로 만든 결과물을 “내 컴퓨터에서만”이 아니라 진짜 서비스로 연결하고 싶은 분
- 팀 프로젝트에서 남의 코드와 내 작업을 합치는 게 막막한 비개발자
- AI에게 큰 작업을 통째로 시켰다가 품질이 들쭉날쭉했던 경험이 있는 분
😫 문제 상황 (Before)
지난 두 편에서 만든 RAG 챗봇은 잘 작동했지만 터미널 창에서 명령어로만 쓸 수 있었습니다. 실제 사용자가 쓰려면 앱·웹에서 불러올 수 있는 **서비스 통로(API)**가 필요했죠.
게다가 이번엔 혼자가 아니었습니다. 팀원이 그동안 작업 97개를 GitHub에 올려놨고, 그걸 내 작업과 처음으로 합쳐야 했습니다. 남이 짠 백엔드 코드도 받았는데, 안전한지 확인하지 않고 그냥 쓸 수는 없었습니다.
🛠️ 사용한 도구
- 도구: Claude Code
- 모델: Claude Opus
- 특이사항: 큰 작업을 잘게 나눠 AI 에이전트팀에게 분업시키고 각 결과를 자동으로 2단계 검토(요구사항 일치 → 코드 품질)
🔧 작업 과정
자료 추가, 매번 손이 갔다 — “한 번에” 자동화
챗봇이 참고할 의료 자료는 계속 늘어납니다. 그때마다 여러 단계를 손으로 거쳐야 했는데, 앞으로도 반복될 일이라 한 번에 끝내고 싶었습니다.
data 폴더에 새로운 자료를 추가하면 어떻게 해야하지?
그럼 추가해야되는 파일이 나중에도 발생할수 있으면 한번에 하는것이 좋겠네
AI는 “폴더에 파일 넣고 스크립트 한 번 실행”이면 끝나도록 자동화 통로를 만들어줬습니다. 한국어와 영어도 알아서 구분하고 설정 파일을 고칠 필요도 없게요. “반복될 일이면 자동화하자”는 한마디가 앞으로의 수십 번 손길을 줄였습니다.
💡 반복될 작업이면 처음 한 번 자동화에 투자하세요. AI에게 “앞으로도 또 생길 일”이라고 말해주면 일회용이 아닌 재사용 도구를 만들어줍니다.
팀원 97커밋과 합치기 — 협업의 첫 관문
현재 로컬 커밋은 어디에 저장되어 있는거야?
그럼 새로 업데이트 된 메인을 가져오려고해
처음엔 “내가 작업한 게 어디 저장되는지”부터 물었습니다. 그리고 팀원의 작업 97개를 가져와 합쳤는데 세 군데에서 충돌(같은 파일을 서로 다르게 고친 상황)이 났습니다. AI가 충돌마다 어느 쪽이 맞는지 판단해 풀어줬고, 다행히 제 RAG 작업과 겹치는 충돌은 0건이었습니다.
💡 “합치기(merge)“는 비개발자에게 가장 무서운 단계인데, AI가 충돌을 하나씩 설명하며 풀어주니 훨씬 덜 막막했습니다. 무서워서 미루지 말고 AI를 옆에 두고 함께 합치세요.
남이 짠 코드 9,600줄을 AI로 점검 — 보안 구멍 발견
받은 코드를 확인해 보자 백엔드 담당자가 만든 코드인데 점검 해보자
팀 공유용 마크다운 리포트로 정리해줘
받은 백엔드 코드를 그냥 쓰지 않고 AI에게 네 가지 관점(코드 품질·보안·내 RAG와의 연결·실제 실행)으로 점검시켰습니다. 그랬더니 심각한 보안 문제 1건(로그인 토큰을 악용할 수 있는 허점)과 그 밖의 여러 위험이 나왔습니다. 발견한 내용은 팀이 바로 볼 수 있게 리포트로 정리했고요.
💡 “남의 코드라 잘 모르겠다”가 아니라, AI에게 점검을 맡기면 비개발자도 코드 리뷰어가 됩니다. 받은 코드를 그냥 믿지 말고 한 번 검증하는 습관이 안전합니다.
AI 에이전트팀에게 API를 맡기다 — 분업의 힘
이번 핵심 작업이었습니다. 챗봇의 검색·추론을 실제 서비스 통로로 연결하는 일인데 혼자 한 번에 짜는 대신 작업을 11개 단위로 쪼개 AI 에이전트팀에게 분업시켰습니다.
통째 표시 라는것도 잘 설명해줘
설계 확정하고 파일 구조로 넘어가자
둘 다 동의, 모듈화대로 분리하자
먼저 브레인스토밍으로 설계를 정했습니다. “답변을 한 글자씩 흘려보낼지, 다 만든 다음 통째로 보여줄지” 같은 결정도 여기서 내렸죠. 그다음 에이전트가 한 조각씩 만들게 했습니다. 사용자가 질문하면 작업 대기열(요청을 순서대로 쌓아두는 줄)에 넣고, AI 작업자가 하나씩 꺼내, RAG로 답을 만들어 돌려주는 구조가 완성됐습니다.
💡 큰 작업일수록 “한 번에 다 짜줘”보다 “단위로 쪼개서 하나씩 짜줘”가 품질이 좋습니다. AI도 사람처럼 한 입 크기로 나눠주면 실수가 줄어듭니다.
2단계 리뷰가 잡은 숨은 버그 — “내 컴퓨터에선 되는데”
여기서 진짜 가치가 나왔습니다. 에이전트가 작업을 끝낼 때마다 2단계로 검토하게 했는데(① 시킨 대로 만들었나 ② 코드 품질이 괜찮나), 이 검토가 혼자선 절대 못 잡았을 버그를 잡았습니다.
대표적으로 “내 컴퓨터에선 멀쩡한데 실제 서버(컨테이너) 안에서는 죽는” 오류가 있었습니다. 코드 조각끼리 잘못 얽혀 있어서 평소엔 안 보이다가 진짜 배포 환경에서만 터지는 문제였죠. 통합 검토 단계에서 이걸 발견해 미리 고쳤습니다. 빈 답변, 주인 없는 메시지 같은 문제도 품질 검토가 잡아냈고요.
💡 AI에게 큰 일을 맡길 땐 만들게만 하지 말고 “검토자 AI”를 따로 붙이세요. 만드는 AI와 검토하는 AI를 나누니 품질이 확 올라갔습니다.
머지했더니 CI가 깨졌다 — 합치는 타이밍의 교훈
(자동검사 링크) 뭐가 문제야?
feat/RAG 브랜치 정리해줘
작업을 메인에 합쳤더니 GitHub의 자동검사(코드를 올릴 때마다 기계가 알아서 돌리는 검사, CI)가 빨간불이 떴습니다. 코드 스타일 검사(lint)를 통과 못 한 건데 내 컴퓨터에서 개발할 땐 안 보이다가 합치고 나서야 드러난 문제였습니다. 스타일을 고쳐 다시 올려 초록불을 복구했습니다.
💡 “내 컴퓨터에서 됐으니 됐겠지”가 가장 위험합니다. 합치기 전에 자동검사를 미리 돌려보는 습관이 필요하다는 걸 배웠습니다.
✅ 결과 (After)
Before vs After
| 항목 | Before | After |
|---|---|---|
| 챗봇 사용 방식 | 터미널 명령어로만 | **서비스 통로(API)**로 앱·웹에서 호출 가능 |
| 자료 추가 | 여러 단계 수작업 | 폴더에 넣고 스크립트 한 번 |
| 팀 코드 | 합쳐본 적 없음 | 작업 97개 통합 + 보안 점검 완료 |
| 코드 품질 | 혼자 짜고 끝 | AI 분업 + 2단계 검토로 숨은 버그 사전 차단 |
결과물
- 챗봇 서비스 통로 완성 (검색·추론·안전가드 전 과정 연결)
- 백엔드 보안 점검 리포트 (팀 공유)
- 최종 메인 브랜치 초록불(CI 통과) 복구
💬 이 과정에서 배운 AI 활용 팁
효과적이었던 것
- 큰 작업은 잘게 나눠 분업: 통째로 시키지 말고 작업 단위로 쪼개 에이전트에게 맡기기
- 만드는 AI ≠ 검토하는 AI: 만든 결과를 다른 AI가 2단계(요구사항·품질)로 검토하면 숨은 버그가 드러남
- 남의 코드도 AI로 점검: 받은 코드를 그냥 쓰지 말고 보안·품질 관점으로 검증
이렇게 하면 안 돼요
- “내 컴퓨터에서 됐으니 됐다”: 실제 배포 환경(컨테이너)과 자동검사(CI)는 다름. 합치기 전에 미리 확인
- 합치기를 미루다 한꺼번에: 충돌이 쌓이면 더 무서워짐. 자주 합치고 자주 확인
🌍 다른 업무에 적용한다면?
여러 사람·여러 소스의 자료를 하나로 합쳐야 하는 일(예: 부서별 데이터 취합)에 그대로 적용됩니다. “합치기 전 검증 → 충돌 해결 → 합친 뒤 재확인”의 흐름은 코드가 아니어도 똑같이 쓸 수 있습니다.
🚀 앞으로의 계획
통로까지 연결됐지만 아직 진짜 환경(docker)에서 처음부터 끝까지 돌려본 적은 없습니다. 다음 편에서는 전체를 실제로 띄워 “정말 작동하는지” 검증하고, 챗봇을 테스트합니다. 그런데 그 테스트 도중 사고가 터집니다. 운영 데이터베이스를 통째로 날려버린 날이거든요. 다음 편에서 원인과 복구 과정을 솔직하게 풀어보겠습니다 😅
📋 재사용 가능한 프롬프트
프롬프트 1: 받은 코드 점검
[백엔드 담당자/동료]가 만든 코드인데 점검해보자. 코드 품질·보안·내 작업과의 연결·실제 실행, 이렇게 여러 관점으로 봐주고 발견한 내용은 팀이 바로 볼 수 있게 [마크다운 리포트]로 정리해줘.
프롬프트 2: AI 분업 + 2단계 리뷰
이 작업을 한 번에 짜지 말고, 작업 단위로 나눠서 진행해줘. 각 단위를 끝낼 때마다 ① 시킨 대로 만들었는지 ② 코드 품질이 괜찮은지 두 단계로 검토하고, 문제가 있으면 고친 뒤 다음으로 넘어가줘.
프롬프트 3: 합치기 전 자동검사 미리 돌리기
합치기(push) 전에 [자동검사(CI)]가 보는 것과 똑같은 검사를 내 컴퓨터에서 먼저 돌려서, 통과 못 하는 부분이 있으면 미리 알려줘.
📌 「AI 헬스케어 파이널 프로젝트」 연재 11편입니다. 다음 막에서 또 이어집니다.