제조업 AI 에이전트 프로젝트 1차 회고 — 평가, 저장소, 코드 정리에 대한 세 가지 교훈

제조업 개발자를 위한 AI 에이전트 프로젝트의 1차를 마쳤습니다. 프로젝트의 구체적인 내용은 다룰 수 없지만, 그 과정에서 얻은 교훈은 다른 에이전트 프로젝트에도 그대로 적용될 것 같아 정리해 두려 합니다.

TL;DR

• 평가 기준과 롤백이 있으면, 프롬프트 개선은 에이전트에게 맡겨도 된다. 자동화의 안전성은 고치는 쪽이 아니라 검증하고 되돌리는 쪽에서 나온다. 단, 평가 에이전트를 검증하는 건 결국 사람의 몫이다.
• 온톨로지는 설계이고, 저장소는 규모에 따른 선택이다. 지난 프로젝트에선 Neo4j, 이번엔 YAML. “온톨로지 = 그래프 DB”라는 공식을 버렸다.
• “언젠가 정리한다”가 아니라 “핵심이 안 보이면 바로 정리한다.” 에이전트 코드는 구조가 흐려지는 순간 “왜 이렇게 동작했는지”를 추적할 수 없게 된다.

Why — 1차 목표는 ‘와’ 포인트였다

1차의 목표는 분명했습니다. 제조업 현장 개발자가 써보고 “와” 할 만한 포인트를 만드는 것.

완성도 높은 시스템보다, 현장 개발자가 “이게 정말 내 일을 줄여주겠구나”라고 납득하는 순간을 먼저 만드는 게 중요하다고 봤습니다. 그 순간이 있어야 다음 단계로 갈 수 있으니까요.

그 목표를 향해 빠르게 달리면서, 세 가지를 배웠습니다. 하나는 품질을 끌어올리는 방법에 관한 것, 하나는 데이터를 담는 방식에 관한 것, 마지막 하나는 코드를 다루는 태도에 관한 것입니다.

교훈 1. 평가 기준이 있으면 프롬프트 개선을 에이전트에게 맡겨도 된다

‘와’ 포인트를 만들려면 결과물의 품질을 계속 끌어올려야 했습니다. 그런데 프롬프트를 사람이 하나하나 고치는 방식으로는 속도가 나지 않았습니다. 그래서 프롬프트 개선 자체를 에이전트에게 맡겼습니다.

흐름은 이렇습니다.

에이전트가 프롬프트를 수정한다
        ↓
평가 에이전트가 수정된 결과를 평가한다
        ↓
  나아졌다 → 평가를 근거로 데이터나 프롬프트를 업데이트한다
  나빠졌다 → 이전 버전으로 롤백한다

실제로 에이전트가 고친 프롬프트가 오히려 결과를 나쁘게 만든 경우가 있었습니다. 그때 평가 에이전트가 그걸 잡아냈고, 바로 이전 상태로 되돌렸습니다.

이 경험에서 얻은 핵심은 이것입니다. 중요한 건 “에이전트가 고친다”가 아니라, “고친 결과를 판단할 기준과 되돌릴 장치가 있다”는 것입니다.

에이전트가 스스로를 고치는 구조는 매력적이지만, 그 자체로는 위험합니다. 수정이 항상 옳다는 보장이 없으니, 기준 없이 돌리면 잘못된 수정이 쌓이며 점점 나빠질 수 있습니다. 반대로 평가 기준과 롤백이 있으면, 에이전트는 마음껏 시도해도 됩니다. 나쁜 시도는 걸러지고 되돌려지니까요. 자동화의 안전성은 수정하는 쪽이 아니라 검증하고 되돌리는 쪽에서 나온다는 걸 체감했습니다.

돌아보면 이 루프가 굴러가려면 몇 가지 전제가 필요합니다.

• 비교 기준이 고정돼 있어야 합니다. 수정 전과 후를 같은 입력으로 평가해야 “나아졌다”는 판단이 의미를 갖습니다. 매번 다른 입력으로 평가하면 개선인지 운인지 구분할 수 없습니다.
• 되돌릴 수 있는 단위로 버전이 남아 있어야 합니다. 프롬프트와 데이터의 변경 이력이 남아 있어야 롤백이 “기억에 의존한 복구”가 아니라 한 번의 동작이 됩니다.
• 평가가 수정과 분리돼 있어야 합니다. 고친 에이전트가 스스로 “좋아졌다”고 판단하게 두면, 자기 수정을 정당화하는 쪽으로 기울기 쉽습니다.

평가를 선택·실행·결과로 나눠 보는 관점은 에이전트의 도구와 세 층의 평가에서, 멀티에이전트 구조에서 평가가 왜 해법이 되는지는 멀티에이전트의 두 숙제에서 다룬 적이 있습니다. 그때는 정리였다면, 이번에는 그 내용을 직접 겪어 본 셈입니다.

남은 과제 — 평가 에이전트는 누가 평가하는가

물론 이 구조에는 빈틈이 하나 있습니다. 평가 에이전트도 LLM이라 틀릴 수 있다는 점입니다. 평가 에이전트가 나쁜 결과를 좋다고 판단하면, 그 판단을 근거로 잘못된 업데이트가 반영됩니다.

그렇다고 평가 에이전트를 또 다른 에이전트로 검증하는 건 답이 아닙니다. 그 에이전트도 LLM이니까요. 결국 어딘가에서는 사람이 평가 에이전트의 판단을 검증해야 합니다. 평가 에이전트가 내린 판단 중 일부를 사람이 직접 확인하고, 둘의 판단이 얼마나 일치하는지 보는 체계가 필요합니다.

이렇게 하면 사람이 모든 결과를 볼 필요 없이, 평가 에이전트를 믿어도 되는지만 주기적으로 확인하면 됩니다. 일치율이 높으면 루프를 더 자율적으로 돌리고, 떨어지면 평가 기준부터 다시 손보는 식입니다. 사람이 결과를 검수하는 대신 검수자를 검수하는 구조입니다. 이게 2차의 가장 큰 과제입니다.

교훈 2. 저장소는 데이터 규모에 맞춘다

에이전트가 도메인을 이해하려면 온톨로지가 필요했습니다. 어떤 개념이 있고, 그 개념들이 어떻게 연결되는지를 정의한 지도 같은 것이죠.

이전 프로젝트에서는 데이터가 많았고, 그래서 Neo4j로 온톨로지를 구축했습니다. 개념과 관계가 많고 여러 단계를 건너는 탐색이 필요할 때 그래프 DB는 좋은 선택이었습니다.

그래서 이번에도 자연스럽게 같은 방식을 떠올렸는데, 막상 들여다보니 이번 프로젝트는 데이터가 적었습니다. 이 규모에서 그래프 DB는 과했습니다. DB를 띄우고, 스키마를 관리하고, 데이터를 적재하는 비용이 얻는 것보다 컸습니다. 그래서 YAML로 온톨로지를 작게 시작했습니다.

이 경험에서 정리된 생각은 이렇습니다. 온톨로지는 개념과 관계의 설계이고, 저장 형식은 규모에 따라 바꿀 수 있는 선택입니다.

“온톨로지 = 그래프 DB”라고 묶어서 생각하면, 데이터가 작을 때도 무거운 인프라부터 깔게 됩니다. 하지만 정말 중요한 건 개념과 관계를 잘 정의하는 일이고, 그걸 어디에 담을지는 그다음 문제입니다. 잘 설계된 YAML 온톨로지는 나중에 데이터가 커지면 그대로 그래프 DB의 스키마가 됩니다. 규모가 방식을 정하게 하고, 방식이 규모를 앞서가지 않게 하는 것. 지난 프로젝트와 이번 프로젝트를 모두 겪고 나서야 이 구분이 선명해졌습니다.

YAML 온톨로지를 컨텍스트에 어떻게 넣었는지, 그리고 언제 다음 단계로 넘어가야 하는지는 데이터가 작을 때의 온톨로지 설계에 자세히 정리해 두었습니다.

교훈 3. 부가 로직이 핵심 로직을 가리기 시작하면 정리할 때다

‘와’ 포인트를 향해 빠르게 달리다 보니, 코드에 핵심 로직 외의 것들이 계속 붙었습니다. 예외 처리, 임시 분기, 로깅, 실험용 옵션 같은 부가 로직들입니다. 하나하나는 필요해서 넣은 것이었지만, 쌓이고 나니 문제가 생겼습니다.

코드를 열었을 때 정작 핵심 로직이 잘 보이지 않았습니다. 가독성이 떨어지니 에이전트의 동작을 바꾸려 할 때마다 어디를 건드려야 할지 찾는 데 시간이 걸렸고, 하나를 고치면 다른 곳이 영향을 받는 일이 생기면서 제어가 점점 어려워졌습니다.

그래서 그 시점에 코드를 정리했습니다. 그리고 이번에 기준 하나를 세웠습니다.

“언젠가 정리한다”가 아니라, “핵심이 안 보이기 시작하면 바로 정리한다.”

“나중에 정리하자”는 말은 대부분 지켜지지 않습니다. 기능을 만드는 속도가 정리하는 속도보다 늘 빠르기 때문입니다. 그래서 막연한 시점 대신 신호를 기준으로 삼기로 했습니다. 코드를 읽었을 때 이 모듈이 무엇을 하는지가 바로 안 보인다면, 그게 정리할 때라는 신호입니다.

조금 더 구체적으로 적어 두면, 저는 이런 순간들을 신호로 봅니다.

• 함수를 열었을 때 핵심 흐름보다 예외 처리와 분기가 먼저 눈에 들어올 때
• 동작 하나를 바꾸려는데 고쳐야 할 곳이 여러 파일에 흩어져 있을 때
• 실험용 옵션 중 무엇이 아직 쓰이고 무엇이 죽은 코드인지 바로 대답할 수 없을 때
• 하나를 고쳤더니 상관없어 보이던 다른 동작이 바뀌었을 때

에이전트 프로젝트에서는 이 신호가 특히 중요하다고 느꼈습니다. 에이전트는 프롬프트, 도구, 분기, 상태가 얽혀 동작하기 때문에, 구조가 흐려지면 “왜 이렇게 동작했는지”를 추적하기가 일반 코드보다 훨씬 어렵습니다. 핵심이 잘 보이는 코드는 디버깅 속도와 직결됩니다.

마무리 — 2차에서는

1차는 ‘와’ 포인트를 만드는 데 집중했습니다. 빠르게 시도하고, 평가하고, 되돌리고, 다시 시도하는 과정이었습니다.

2차의 목표는 두 가지입니다.

• 평가 체계를 더 단단히 하기. 평가 에이전트의 판단을 사람이 검증하는 체계를 만들어, 자동 개선 루프가 믿을 수 있는 기준 위에서 돌게 하는 것.
• 구조를 정돈된 상태로 유지하기. 기능이 늘어나도 핵심 로직이 계속 보이도록, 정리를 일회성 이벤트가 아니라 습관으로 만드는 것.

1차에서 “와”를 만들었다면, 2차에서는 그 “와”가 계속 유지될 수 있는 바닥을 다지는 단계라고 생각합니다.

---

📚 시리즈: AI 에이전트, 만들고 평가하기

1. Workflow와 Agent, 그리고 하네스 — LLM에게 얼마만큼의 자유를 줄 것인가
2. 에이전트의 도구(Tool)와 세 층의 평가 — 선택·실행·결과
3. 멀티에이전트의 두 숙제 — 토큰 비용과 안정성, 그리고 평가라는 해법
4. ReAct와 Plan-and-Execute를 LangGraph로 직접 구현하며 배운 것
5. 그래서 Agent에 데이터를 어떻게 입히나요? — 데이터가 작을 때의 온톨로지 설계
6. 제조업 AI 에이전트 프로젝트 1차 회고 — 평가, 저장소, 코드 정리에 대한 세 가지 교훈 ← 지금 글
7. AI 에이전트의 예시 데이터는 어떻게 다룰까 — 컨텍스트 엔지니어링부터 파인튜닝 준비까지