제가 처음 AI 에이전트(AI agents)를 구축하기 시작했을 때, 가장 어려운 부분은 LLM(대규모 언어 모델)을 통합하는 것이라고 가정했습니다. 하지만 API를 호출하는 것은 시작에 불과했습니다.

실제적인 엔지니어링 과제는 애플리케이션이 실제 사용자를 처리하고, 효율적으로 확장하며, 비용을 제어하고, 일관되게 정확한 응답을 제공해야 할 때 나타났습니다.

다음은 제가 AI 개발에 접근하는 방식을 완전히 바꿔 놓은 일곱 가지 교훈입니다.

1. 프롬프트 엔지니어링 (Prompt Engineering)만으로는 부족하다

많은 개발자가 모델이 마법처럼 더 정확해지기를 바라며 프롬프트를 다듬는 데 수 시간을 소비합니다.

프롬프트 엔지니어링 (Prompt engineering)이 확실히 도움이 되기는 하지만, 누락된 컨텍스트(context), 오래된 정보, 또는 열악한 시스템 아키텍처 (system architecture) 문제를 해결할 수는 없습니다.

프로덕션(Production) 단계의 AI 애플리케이션에는 잘 작성된 프롬프트 그 이상의 것이 필요합니다:

- 구조화된 시스템 지침 (Structured system instructions)
- 외부 지식 검색 (External knowledge retrieval)
- 도구 통합 (Tool integration)
- 응답 검증 (Response validation)
- 에러 핸들링 (Error handling)

좋은 프롬프트는 출력을 개선합니다. 좋은 아키텍처는 제품을 개선합니다.

2. RAG가 항상 파인튜닝 (Fine-Tuning)보다 나은 것은 아니다

가장 큰 오해 중 하나는 모든 AI 애플리케이션에 검색 증강 생성 (RAG, Retrieval-Augmented Generation)이 필요하다는 것입니다.

현실은 더 단순합니다.

다음과 같은 경우에는 RAG를 사용하세요:

- 정보가 빈번하게 변경될 때
- 회사 특유의 지식이 필요할 때
- 문서가 정기적으로 업데이트될 때
- 정확도가 외부 데이터에 의존할 때

다음과 같은 경우에는 파인튜닝 (Fine-Tuning)을 사용하세요:

- 일관된 글쓰기 스타일이 필요할 때
- 응답이 고정된 형식을 따라야 할 때
- 모델이 반복적인 동작을 학습해야 할 때
- 도메인 특화 추론 (Domain-specific reasoning)이 필요할 때

때로는 두 가지 접근 방식을 결합하는 것이 최선의 해결책이 될 수 있습니다.

3. 메모리 (Memory)는 대화 기록 그 이상이다

이전 메시지를 저장하는 것은 진정한 의미의 메모리가 아닙니다.

프로덕션 AI 에이전트는 종종 여러 유형의 메모리를 필요로 합니다:

- 단기 대화 컨텍스트 (Short-term conversation context)
- 장기 사용자 선호도 (Long-term user preferences)
- 비즈니스 특화 정보 (Business-specific information)
- 세션 상태 (Session state)
- 외부 데이터베이스 (External databases)

적절한 메모리 관리 없이는 AI 에이전트가 빠르게 컨텍스트를 잃고 일관성 없는 응답을 생성하게 됩니다.

4. 토큰 비용은 생각보다 빠르게 증가합니다

개발 단계에서는 토큰 사용량이 비싸게 느껴지는 경우가 거의 없습니다.

하지만 배포 후에는 수천 명의 사용자가 매일 수백만 개의 토큰을 생성할 수 있습니다.

비용 최적화 (Cost optimization)는 엔지니어링의 문제가 됩니다.

실질적인 기술에는 다음이 포함됩니다:

- 반복되는 응답 캐싱 (Caching)
- 긴 대화 요약 (Summarizing)
- 가능한 경우 더 작은 모델 사용
- 불필요한 컨텍스트 (Context) 감소
- 비용이 많이 드는 함수 호출 (Function calls) 제한

좋은 아키텍처는 모델을 교체하는 것보다 훨씬 더 많은 돈을 아껴줍니다.

## 5. 함수 호출 (Function Calling)이 AI를 실제로 유용하게 만듭니다

대규모 언어 모델 (Large Language Models, LLM)은 텍스트를 생성하는 데 탁월합니다.

실제 애플리케이션은 행동을 수행해야 합니다.

함수 호출 (Function calling)을 통해 AI 에이전트는 다음을 수행할 수 있습니다:

- 데이터베이스 쿼리 (Query)
- 예약 잡기
- 이메일 전송
- 결제 처리
- 보고서 생성
- CRM 시스템 업데이트
- 백엔드 워크플로우 (Backend workflows) 트리거

도구가 없다면 AI 에이전트는 대부분 대화형 어시스턴트에 불과합니다.

도구가 있다면, 그것은 소프트웨어 시스템이 됩니다.

6. 관찰 가능성 (Observability)은 지능만큼이나 중요합니다

전통적인 애플리케이션은 API 요청을 로그로 남깁니다.

AI 애플리케이션은 훨씬 더 깊은 가시성을 요구합니다.

유용한 지표 (Metrics)에는 다음이 포함됩니다:

- 프롬프트 (Prompt) 버전
- 토큰 사용량
- 지연 시간 (Latency)
- 모델 응답
- 환각률 (Hallucination rate)
- 사용자 피드백
- 도구 실행 성공 여부

AI 시스템을 측정할 수 없다면, 이를 개선하는 과정은 추측에 의존하게 됩니다.

7. 보안은 사후 고려 사항이 되어서는 안 됩니다

AI 애플리케이션은 많은 팀이 간과하는 보안 리스크를 초래합니다.

예시에는 다음이 포함됩니다:

- 프롬프트 인젝션 (Prompt injection)
- 데이터 유출 (Data leakage)
- 민감 정보 노출
- 탈옥 (Jailbreak) 시도
- 승인되지 않은 도구 실행
- 악성 업로드 문서

보안은 출시 후가 아니라 첫날부터 고려되어야 합니다.

마치며

AI 에이전트를 구축하는 것은 단순히 최신 언어 모델을 선택하는 것만이 아닙니다.

성공은 검색 (Retrieval), 메모리 (Memory), 도구 (Tools), 모니터링 (Monitoring), 비용 최적화 (Cost optimization), 그리고 보안 (Security)을 결합한 신뢰할 수 있는 시스템을 설계하는 데서 옵니다.

최고의 AI 제품은 가장 거대한 모델을 사용하는 제품이 아니라, 실제 문제를 일관되게 해결하도록 설계된 제품입니다.

토론 질문 (Discussion Question)

AI 애플리케이션을 구축하면서 직면했던 가장 큰 어려움은 무엇인가요? 댓글을 통해 여러분의 경험을 들려주세요.