AI 에이전트 만들기 전 꼭 확인할 25가지: 실전 구축 체크리스트

처음 만든 AI 에이전트가 데모에서 그럴듯하게 움직이면 마음이 급해집니다. 이제 실제 업무에 연결해도 될 것 같고, 사용자에게 공개해도 될 것 같습니다.

하지만 데모와 운영 사이에는 큰 간격이 있습니다. 운영 환경의 에이전트는 모호한 요청을 만나고, 오래된 정보를 검색하고, 실패한 도구를 다시 호출합니다. 심지어 권한이 허용하는 범위 안에서 너무 많은 일을 해버릴 수도 있습니다.

좋은 에이전트는 똑똑한 답을 한 번 내는 시스템이 아니라, 실패해도 피해가 제한되고 원인을 추적할 수 있는 시스템입니다. 그래서 모델을 고르기 전에 먼저 확인해야 할 25가지 질문을 정리했습니다.

왜 ‘기능 목록’보다 체크리스트가 먼저일까?

에이전트를 만들 때는 보통 검색, 요약, 코드 실행 같은 기능부터 생각합니다. 그러나 실제 사고는 기능 자체보다 기능 사이의 빈틈에서 생깁니다. 목표가 모호한데 쓰기 권한이 넓거나, 종료 조건이 없는데 재시도 비용이 열려 있거나, 결과는 저장하지만 어떤 도구를 왜 호출했는지는 남기지 않는 식입니다.

아래 여섯 영역은 서로 연결되어 있습니다. 하나라도 비어 있으면 나머지 장치도 제 역할을 하기 어렵습니다.

영역핵심 질문빠졌을 때 생기는 일

문제와 가치	왜 에이전트여야 하는가?	복잡하고 비싼 자동화가 됨
지침과 종료	언제 멈춰야 하는가?	무한 재시도와 범위 확장
도구와 권한	무엇을 어디까지 바꿀 수 있는가?	과도한 변경과 복구 불가
컨텍스트와 메모리	어떤 정보를 기억하고 버리는가?	낡은 정보·사용자 간 정보 혼합
평가와 관측	성공과 실패를 재현할 수 있는가?	개선 여부를 판단하지 못함
안전과 사람 개입	언제 사람이 승인하고 중단하는가?	고위험 행동이 자동 실행됨

1. 문제와 가치: 에이전트가 정말 필요한가?

가장 먼저 구현 난이도가 아니라 에이전트가 해결할 작업의 가치를 확인해야 합니다.

1. 작업이 구체적인가? “업무를 도와줘” 대신 “지난 24시간 오류 로그를 분류하고 담당자에게 초안을 제안한다”처럼 입력과 결과가 보여야 합니다.
2. 단순 워크플로보다 나은가? 순서와 조건이 고정돼 있다면 일반 코드나 워크플로가 더 싸고 예측 가능합니다.
3. 성공과 실패를 측정할 수 있는가? 정답률, 완료율, 오수정률, 검토 시간처럼 비교할 기준이 필요합니다.
4. 비용과 지연을 정당화하는가? 모델 호출, 검색, 도구 실행, 사람 검토까지 합친 총비용을 봐야 합니다.

경고 신호: “일단 붙여보고 생각하자”는 말만 있고, 누가 어떤 시간을 얼마나 줄이는지 설명할 수 없다면 아직 에이전트를 만들 때가 아닙니다.

2. 지침과 종료: 잘하는 것보다 멈출 줄 아는 것이 먼저다

에이전트는 한 번의 답변이 아니라 여러 단계의 판단과 실행을 반복합니다. 따라서 시작 프롬프트보다 종료 규칙이 더 중요할 때가 많습니다.

1. 목표·비목표·범위·제약이 명시됐는가?
2. 완료 조건과 중단 조건이 있는가?
3. 모를 때 추측하지 않고 질문하는 조건이 있는가?
4. 시간·비용·재시도 예산이 있는가?

예를 들어 “테스트를 고쳐라”가 아니라 “제품 코드는 변경하지 않고 실패한 테스트 원인을 분석한다. 근거가 부족하면 질문한다. 같은 실패가 두 번 반복되거나 15분이 지나면 중단한다”라고 적는 편이 안전합니다. 종료 조건은 실패를 인정하는 장치가 아니라 피해를 제한하는 장치입니다.

3. 도구와 권한: 모델의 능력보다 권한의 경계를 설계하라

모델이 틀린 답을 하는 것과, 틀린 판단으로 파일·데이터·외부 시스템을 바꾸는 것은 전혀 다른 문제입니다. 도구를 연결하는 순간부터는 최소 권한과 기본 거부가 출발점이어야 합니다.

1. 도구 입력·출력 스키마가 명확한가? 자유 형식 문자열보다 타입, 필수값, 허용 범위를 정의합니다.
2. 읽기와 쓰기 권한이 분리됐는가? 조회가 필요한 작업에 수정 권한까지 줄 이유는 없습니다.
3. 최소 권한과 기본 거부가 적용됐는가? 필요한 대상만 허용하고 나머지는 거부합니다.
4. 미리보기·실행·롤백이 분리됐는가? 변경 내용을 먼저 보여주고, 승인 후 실행하며, 되돌릴 경로를 준비합니다.
5. 비밀 값이 모델 컨텍스트에 노출되지 않는가? API 키와 토큰은 도구 계층에서 주입하고 모델에게 원문을 전달하지 않습니다.

행동기본 정책예시

읽기	허용 목록 안에서 자동	지정 저장소의 로그 조회
제안	자동 생성, 사람이 검토	코드 패치·메일 초안
쓰기	미리보기 후 승인	파일 수정·DB 업데이트
외부 실행	고위험은 매번 승인	배포·결제·메시지 발송

4. 컨텍스트와 메모리: 많이 넣는 것이 아니라 맞는 것을 제때 넣는다

긴 컨텍스트가 곧 좋은 컨텍스트는 아닙니다. 정보가 많아질수록 오래된 문서와 상충하는 지침이 함께 들어갈 가능성도 커집니다.

1. 필요한 정보만 적시에 검색하는가?
2. 출처와 최신성을 추적하는가?
3. 장기 메모리의 보존·삭제·정정 정책이 있는가?
4. 사용자와 프로젝트 간 메모리가 격리되는가?

메모리에는 저장 이유, 출처, 생성 시각, 만료 시각을 함께 기록하는 편이 좋습니다. 사용자가 사실을 정정했을 때 과거 기억이 계속 검색된다면, 에이전트는 같은 실수를 자신 있게 반복합니다.

5. 평가와 관측: 최종 답뿐 아니라 과정도 검사한다

에이전트가 정답을 냈더라도 금지된 데이터를 읽었거나, 불필요한 도구를 열 번 호출했거나, 우연히 성공했다면 운영상 좋은 결과라고 보기 어렵습니다.

1. 대표 작업과 실패 사례 평가 세트가 있는가?
2. 결과뿐 아니라 과정과 정책 위반을 검사하는가?
3. 모든 도구 호출과 상태 변경이 추적되는가?
4. 모델·지침·도구 버전별 성능을 비교할 수 있는가?

최소한 요청 ID, 사용한 모델과 지침 버전, 도구 호출 입력·결과, 승인 여부, 비용, 지연 시간, 최종 상태를 남겨야 합니다. 그래야 “어제는 됐는데 오늘은 왜 안 되지?”라는 질문에 추측 대신 증거로 답할 수 있습니다.

6. 안전과 사람 개입: 사람은 장식이 아니라 제어 장치다

사람의 승인은 모든 단계에 붙이는 장애물이 아닙니다. 위험이 큰 분기점에 정확히 놓는 브레이크입니다.

1. 고위험 행동의 승인 기준이 있는가?
2. 프롬프트 인젝션과 악성 도구 출력을 가정했는가?
3. 샌드박스와 네트워크 허용 목록을 쓰는가?
4. 중단 스위치와 사고 대응 절차를 실제로 시험했는가?

특히 외부 문서나 웹페이지는 ‘데이터’이지 ‘지침’이 아닙니다. 검색 결과 안의 명령을 그대로 따르지 않도록 신뢰 경계를 분리해야 합니다. 또한 중단 스위치는 문서에만 있으면 부족합니다. 누가, 어디서, 어떤 권한으로 멈추고 변경을 되돌리는지 훈련해봐야 합니다.

10분 만에 하는 출시 전 점검

각 질문에 아래처럼 점수를 매겨보세요.

• 0점: 기준도 구현도 없다
• 1점: 기준은 있지만 자동 검사나 운영 증거가 없다
• 2점: 기준, 구현, 로그나 테스트 증거가 모두 있다

총점보다 중요한 것은 0점인 항목입니다. 특히 쓰기 권한, 비밀 값, 고위험 승인, 중단 스위치 중 하나라도 0점이면 공개 범위를 넓히기 전에 먼저 보완하는 편이 좋습니다.

판정다음 행동

안전 핵심 항목에 0점 존재	운영 연결을 멈추고 권한·중단 장치부터 보완
1점 항목이 다수	소수 사용자·읽기 전용으로 제한해 증거 수집
핵심 항목 모두 2점	작은 범위부터 점진적으로 권한 확대

마치며: 에이전트의 품질은 실패했을 때 드러난다

성공하는 데모는 만들기 쉽지만, 안전하게 실패하는 시스템은 의도적으로 설계해야 합니다. 문제와 가치, 지침과 종료, 도구와 권한, 컨텍스트와 메모리, 평가와 관측, 안전과 사람 개입. 이 여섯 축을 함께 점검하면 에이전트를 ‘신기한 기능’에서 ‘운영 가능한 제품’으로 바꿀 수 있습니다.

지금 만들고 있는 에이전트가 있다면 25개 질문 중 가장 먼저 0점이 나온 항목 하나만 골라보세요. 그 한 항목을 고치는 일이 새로운 기능을 하나 더 붙이는 것보다 훨씬 큰 개선일 수 있습니다.