40일차 회고｜AI 에이전트 설계·테스트·평가｜AI 오케스트레이션 개발자 국비지원

 

40일차에는 지금까지 학습한 AI 에이전트 설계와 구현을 어떻게 검증할 것인지에 대해 배웠다.
단순히 AI 에이전트를 만들어 정상적으로 실행되는 것을 확인하는 것에서 끝나는 것이 아니라, 실제 사용자가 예상하지 못한 질문이나 잘못된 요청을 했을 때도 에이전트가 제대로 대응하는지 테스트하는 과정이 중요하다는 내용이었다.

특히 오늘은 앞으로 진행할 미니 프로젝트에서 AI 에이전트 설계 → 구현 → 테스트 → 평가 결과 보고서까지 하나의 흐름으로 연결해서 생각해야 한다는 점이 인상적이었다.

---

오늘 배운 내용

AI 에이전트도 테스트가 필요하다

AI 에이전트를 만들었다고 해서 바로 완성되는 것은 아니다.

정상적인 질문을 입력했을 때 원하는 결과가 나오는 것은 기본적인 테스트에 가깝다. 실제 서비스에서는 사용자가 항상 우리가 예상한 방식으로 질문하지 않기 때문이다.

예를 들어 날씨와 여행 정보를 제공하는 AI 에이전트가 있다고 하면,

"제주도 날씨를 확인하고 비가 오면 실내 관광지를 추천해줘."

같은 정상적인 요청뿐만 아니라,

"시드니 날씨를 알려줘."

처럼 서비스 범위를 벗어난 요청도 들어올 수 있다.

이때 단순히 엉뚱한 답변을 생성하는 것이 아니라,

"저희는 해당 지역의 날씨 정보는 지원하지 않습니다."

처럼 서비스에서 지원하지 않는 요청임을 명확하게 알려주는 것도 AI 에이전트의 중요한 동작이라고 배웠다.

결국 AI 에이전트 테스트에서는 정상 케이스뿐만 아니라 비정상 케이스와 예외 상황까지 설계해야 한다.

---

AI 에이전트 설계와 테스트는 연결되어 있다

오늘 가장 중요하게 배운 부분이다.

처음에는 AI 에이전트 설계서와 테스트 보고서가 별개의 문서라고 생각할 수 있다. 하지만 실제로는 서로 연결되어 있었다.

AI 에이전트 설계

→ 정상적인 입력과 결과 정의
→ 비정상적인 입력과 대응 방법 정의
→ Agent Flow 및 상태 정의
→ 사용 Tool 정의
→ 구현
→ 테스트 시나리오 작성
→ 테스트 프로그램 실행
→ 기대 결과와 실제 결과 비교
→ Pass / Fail
→ 테스트 결과 보고서

이런 흐름으로 이어진다.

따라서 설계 단계에서 비정상적인 상황을 고려하지 않으면 나중에 테스트를 하려고 해도 무엇을 기대해야 하는지 기준 자체가 없는 문제가 발생할 수 있다.

반대로 설계 단계에서 정상·비정상 케이스와 예상 결과를 잘 정의해 놓으면 이것이 그대로 테스트 케이스가 될 수 있다.

---

Expected가 중요한 이유

AI 에이전트 테스트에서는 단순히 실행 결과가 나왔다는 것만 확인하는 것이 아니라 Expected, 즉 우리가 예상하는 결과를 기준으로 실제 결과를 판단한다.

예를 들어 특정 질문을 입력했을 때,

• 어떤 상태로 종료되어야 하는지
• 어떤 Tool을 사용해야 하는지
• 정상적으로 완료되어야 하는지
• 지원하지 않는 요청이라면 어떤 메시지를 출력해야 하는지
• 승인 과정이 필요한 경우 어느 상태에서 멈춰야 하는지

등을 미리 정해둘 수 있다.

이렇게 기준을 정해놓아야 테스트 프로그램이 실제 결과와 비교해서 Pass 또는 Fail을 판단할 수 있다.

결국 테스트의 핵심은 단순히

"실행됐는가?"

가 아니라,

"우리가 설계한 대로 동작했는가?"

를 확인하는 것이다.

---

승인(Approval)이 필요한 AI 에이전트 테스트

어제 배웠던 승인 방식의 AI 에이전트도 테스트해봤다.

승인이 필요한 에이전트는 한 번에 Complete 상태가 되는 것이 아니라,

승인 대기 → 승인 → 실행 → 완료

와 같은 상태 변화를 갖는다.

따라서 테스트에서도 단순히 최종 결과만 확인하면 안 된다.

예를 들어,

1. 승인 요청이 정상적으로 발생했는가?
2. 승인 전에는 실제 작업이 실행되지 않았는가?
3. 승인 후 작업이 실행되었는가?
4. 최종적으로 Complete 상태가 되었는가?

등을 각각 확인할 수 있다.

테스트 프로그램에서는 실제 사용자가 승인 버튼을 누르는 상황을 대신해서 승인 과정을 수행하고, 승인 전과 승인 후의 상태가 정상적으로 변화하는지 확인하는 방식이었다.

이 과정을 통해 AI 에이전트에서 상태(State)를 명확하게 설계하는 것이 얼마나 중요한지도 다시 이해할 수 있었다.

---

Redis와 SSE를 이용한 상태 전달

AI 에이전트가 여러 단계를 거쳐 작업하는 경우에는 현재 어떤 작업을 수행하고 있는지 사용자에게 알려줄 필요가 있다.

예를 들어,

현재 날씨 정보를 확인하고 있습니다.
날씨 정보를 확인했습니다.
호텔 정보를 검색하고 있습니다.
호텔 검색이 완료되었습니다.

와 같은 상태를 실시간으로 보여줄 수 있다.

수업에서는 이러한 AI 에이전트의 실행 상태를 Redis에 저장하고 SSE(Server-Sent Events)를 통해 사용자 화면으로 전달하는 구조를 다시 연결해서 생각해봤다.

Redis는 데이터를 빠르게 저장하고 조회할 수 있는 저장소이고, SSE는 서버에서 발생한 데이터를 웹 화면에 실시간으로 전달할 때 사용할 수 있는 기술이다.

즉,

AI Agent 실행 → 상태 변경 → Redis 저장 → SSE를 통해 Frontend로 전달

이라는 구조로 이해할 수 있었다.

---

테스트 프로그램에서 print()를 사용하면 안 되는 이유

오늘 의외로 기억에 남았던 내용은 print()에 대한 이야기였다.

개발하면서 결과를 확인하기 위해 print()를 자주 사용했는데, 실제 서비스의 백엔드 코드에 무분별하게 print()를 넣는 것은 좋지 않다고 했다.

print()는 실행될 때마다 운영체제의 표준 출력으로 데이터를 계속 내보내기 때문에 서비스 규모가 커지면 불필요한 출력이 엄청나게 발생할 수 있다.

특히 로그인처럼 사용자가 매우 많이 접근하는 API에 print()를 남겨놓으면 많은 요청이 발생할 때 문제가 될 수 있다.

물론 지금처럼 학습 과정에서 값을 확인하기 위해 임시로 사용하는 것은 이해할 수 있지만, 실제 서비스 코드에서는 적절한 로깅 방식을 사용하는 것이 필요하다.

테스트 프로그램 역시 단순히 결과를 print()로 출력하는 것이 아니라,

실제 결과값과 Expected 값을 비교해서 Pass / Fail을 판단하는 방식

으로 만드는 것이 중요하다고 배웠다.

---

Codex를 테스트에도 활용할 수 있다는 점

이번 수업에서 앞으로 AI 코딩 도구를 어떻게 활용할 수 있을지에 대한 방향도 생각해볼 수 있었다.

예를 들어 AI 에이전트 기획서와 설계서를 준비한 뒤 Codex 같은 AI 코딩 도구에 전달하고,

이 AI 에이전트를 테스트하려고 한다.
정상·비정상 시나리오를 만들어줘.

라고 요청할 수 있다.

그 다음에는 생성된 시나리오를 바탕으로 테스트 프로그램을 만들고, 테스트를 실행한 뒤 결과 보고서까지 만드는 방식으로 활용할 수 있다.

특히 AI 에이전트 테스트에서 가장 어려운 부분 중 하나가 다양한 테스트 시나리오를 만드는 것이라고 했다.

AI를 활용하면 사람이 생각하기 어려운 다양한 케이스를 만들어볼 수 있기 때문에 테스트 자동화에 상당히 유용할 것 같았다.

다만 AI가 만들어준 결과를 그대로 사용하는 것이 아니라 내가 만든 프로젝트의 의도와 맞는지 직접 검토하는 과정이 반드시 필요하다.

AI가 좋은 구조를 제안하더라도 프로젝트를 불필요하게 복잡하게 만들 수 있기 때문이다.

---

프로젝트에서는 무엇을 보여줘야 할까?

이번 미니 프로젝트에서는 단순히 "AI 에이전트가 동작합니다."만 보여주는 것보다,

어떤 구조로 설계했고 → 어떻게 구현했고 → 어떻게 테스트했으며 → 어떤 결과가 나왔는지

를 보여주는 것이 중요하다는 이야기도 들었다.

특히 프로젝트의 주제 자체보다 우리가 학습한 기술을 어떻게 활용했는지를 보여주는 것이 중요하다는 점이 기억에 남았다.

기본적인 시스템 구성은 다음과 같이 생각할 수 있다.

Frontend
   ↓
Backend
   ↓
AI Agent
   ↓
MCP Server
   ↓
Tools / Database

여기에 Redis를 이용한 상태 관리와 SSE를 이용한 실시간 상태 전달 등을 연결할 수 있다.

프로젝트에 필요하지 않은 로그인, JWT, 관리자 기능 등을 무조건 추가하기보다는 AI 에이전트를 중심으로 필요한 기술을 선택해서 구현하는 것이 중요하다는 점도 다시 확인했다.

---

오늘 새롭게 이해한 점

오늘 수업을 들으면서 AI 에이전트 개발에서 설계가 단순히 구현 전에 작성하는 문서가 아니라 테스트의 기준이 되는 문서라는 것을 이해하게 됐다.

처음에는 설계서라고 하면 어떤 AI 에이전트를 만들지 설명하는 문서 정도라고 생각했다.

하지만 실제로는,

"이 입력이 들어오면 어떻게 처리하고, 어떤 Tool을 사용하며, 어떤 상태가 되고, 어떤 결과를 반환해야 하는가?"

를 정의하는 기준이 될 수 있었다.

그리고 여기서 한 단계 더 나아가면,

"만약 이상한 입력이 들어오면?"

까지 설계해야 한다.

이 부분이 오늘 가장 큰 변화였다.

AI 에이전트가 정상적인 상황에서 잘 작동하는 것만 확인하는 것이 아니라 실패할 수 있는 상황을 미리 정의하고 그 상황에서도 의도한 방식으로 동작하는지 검증하는 것까지 AI 에이전트 개발의 일부라는 것을 알게 됐다.

---

현재 부족한 부분

아직 테스트 시나리오를 직접 설계하는 부분은 어렵게 느껴진다.

특히 정상적인 케이스는 비교적 쉽게 생각할 수 있지만, 실제 사용자가 어떤 식으로 엉뚱한 질문을 할지까지 생각하려면 여러 상황을 고려해야 한다.

앞으로 프로젝트를 진행하면서 AI에게 테스트 시나리오를 생성하도록 도움을 받더라도, 그 결과를 그대로 사용하는 것이 아니라 우리 프로젝트의 서비스 범위와 설계 의도에 맞게 직접 검토하는 연습이 필요할 것 같다.

또한 Redis, SSE, MCP Server, Backend 등이 각각 어떤 역할을 하는지는 어느 정도 이해하고 있지만, 이 기술들을 하나의 시스템으로 연결해서 설계하고 구현하는 부분은 계속 복습해야 할 것 같다.

---

오늘의 회고

40일차에는 AI 에이전트를 만드는 과정에서 검증하는 과정으로 시야를 넓힐 수 있었다.

지금까지는 AI 에이전트를 설계하고 MCP Server와 Tool을 연결해서 원하는 결과를 만들어내는 것에 집중했다면, 이제는 그 결과가 정말 제대로 만들어진 것인지 확인하는 단계까지 생각해야 한다.

특히 정상 케이스 + 비정상 케이스 → Expected 정의 → 테스트 케이스 → 자동 테스트 → Pass/Fail → 결과 보고서라는 흐름이 인상적이었다.

결국 좋은 AI 에이전트는 단순히 한두 번 실행했을 때 잘 작동하는 에이전트가 아니라, 예상하지 못한 입력과 다양한 상황에서도 설계한 기준에 맞게 동작하는 에이전트라는 생각이 들었다.

앞으로 진행할 미니 프로젝트에서도 기능을 빠르게 만드는 것만 생각하기보다는 처음 AI 에이전트를 설계할 때부터 "이걸 어떻게 테스트할 것인가?"를 함께 생각하면서 구현해봐야겠다.

---

핵심 정리

• AI 에이전트는 정상 케이스뿐 아니라 비정상·예외 케이스까지 테스트해야 한다.
• AI 에이전트 설계서의 Expected 결과가 테스트의 기준이 된다.
• 설계 → 구현 → 테스트 → 평가 보고서는 하나의 흐름으로 연결된다.
• 승인 에이전트는 승인 대기 → 승인 → 실행 → 완료 상태를 각각 검증해야 한다.
• Redis에 에이전트 상태를 저장하고 SSE로 사용자에게 실시간 상태를 전달할 수 있다.
• 테스트에서는 단순 출력보다 실제 결과와 기대 결과를 비교하는 방식이 중요하다.
• Codex 같은 AI 코딩 도구를 테스트 시나리오와 테스트 코드 작성에도 활용할 수 있다.
• 프로젝트에서는 기능을 무작정 늘리기보다 AI Agent + Frontend + Backend + MCP Server + DB + Redis를 중심으로 학습한 기술을 연결하는 것이 중요하다.