프롬프트 및 응답에서 에이전트 워크플로우로: 원격 의료를 위한 AI 콘텐츠 플랫폼 구축

한 헬스케어 기업이 저희에게 내부용 AI 기반 SEO 플랫폼을 가지고 찾아왔습니다.

프로토타입은 이미 작동하고 있었습니다.

주제 리서치, 콘텐츠 생성, SEO 검사 수행 및 WordPress에 게시하는 것이 가능했습니다.

문제는 확장성이었습니다.

시스템이 커지면서 유지보수가 점점 어려워졌습니다. 아키텍처가 단일 AI 제공업체(AI provider)에 너무 의존했고, 브라우저 측 상태(browser-side state), 그리고 여러 브랜드에 맞춰 설계되지 않은 워크플로우들이 문제였습니다.

우리는 이미 검증된 워크플로우를 잃지 않으면서 프로토타입을 상용 소프트웨어로 전환해야 했습니다.

1. 기존 아키텍처의 한계 도달

초기 시스템은 비교적 단순한 상호작용을 중심으로 구축되었습니다:

User Input
    ↓
LLM
...

이것은 실험에는 잘 작동합니다.

하지만 워크플로우가 이전 결정을 기억하고 여러 단계 간에 구조화된 컨텍스트(structured context)를 전달해야 할 때는 한계가 됩니다.

새로운 워크플로우는 다음과 같았습니다:

Topic Discovery
      ↓
Research
...

각 단계는 특정 책임(specific responsibility)을 가졌습니다.

시스템은 더 이상 LLM을 하나의 범용 어시스턴트처럼 취급하지 않았습니다.

여러 전문화된 작업들을 둘러싼 오케스트레이션 레이어(orchestration layer)가 되어가고 있었습니다.

2. 단일 모델 의존성에서 벗어나기

원래 플랫폼은 하나의 LLM 제공업체에 직접적으로 의존했습니다.

이것은 실제 엔지니어링 문제를 야기합니다.

모델 변경, 가격 변동, 가용성 문제 또는 기능 변화가 갑자기 애플리케이션 레벨의 문제가 될 수 있습니다.

우리는 AI 레이어를 OpenRouter로 옮겨서 애플리케이션이 공통 통합(common integration)을 통해 여러 모델과 작동할 수 있도록 했습니다.

이미지 생성 라우팅 레이어(image-generation routing layer)도 추가되었습니다.

목표는 단순히 더 많은 모델을 사용하기 위함이 아니었습니다.

애플리케이션 레이어를 하나의 제공업체에 덜 의존하게 만드는 것이었습니다.

3. 영구 컨텍스트가 워크플로우의 일부가 되다

여러 단계로 구성된 콘텐츠 시스템은 워크플로우 초기에 무슨 일이 있었는지 기억할 수 있는 메모리가 필요합니다.

예를 들어, 새로운 기사를 평가할 때, 시스템은 다음을 알아야 합니다:

– 어떤 콘텐츠가 이미 존재하는가?
– 이 주제는 이미 다루어졌는가?
– 연구 단계에서 무엇을 발견했는가?
– 이전 평가 단계에서는 무엇을 식별했는가?
– 인간 검토자는 어떤 피드백을 제공했는가?

이러한 맥락(context) 없이는 모든 단계가 또 다른 고립된 AI 요청에 불과합니다.

따라서 아키텍처는 영구적인 워크플로우 컨텍스트(persistent workflow context)를 향해 전환되었습니다.

이를 통해 여러 에이전트들이 연속성을 유지하면서 서로 다른 단계에서 작업할 수 있게 되었습니다.

4. AI 생성 콘텐츠에도 여전히 인간 평가가 필요함

헬스케어는 단순히 생성 볼륨을 늘리는 것만으로는 충분하지 않은 영역입니다.

이 플랫폼은 높은 볼륨의 콘텐츠 생산을 지원하는 동시에 인간 검토 계층(human review layer)을 유지하도록 설계되었습니다.

SEO 전문가와 작가들은 자연어 피드백을 제공할 수 있었습니다.

그리고 그 피드백은 시스템 컨텍스트의 일부가 될 수 있었습니다.

목표는 다음과 같지 않았습니다:

AI → 발행(Publish)

오히려 다음과에 가까웠습니다:

AI
↓
평가(Evaluation)
...

5. 여러 게시 환경 지원하기

플랫폼은 결국 WordPress와 Astro 기반 웹사이트를 모두 지원해야 했습니다.

WordPress는 기존의 CMS 워크플로우를 제공했습니다.

Astro는 근본적으로 개발자 중심 아키텍처를 사용함에도 불구하고 콘텐츠 전문가들이 CMS 스타일 인터페이스가 필요하다는 점에서 다른 과제를 제시했습니다.

해결책은 WordPress와의 호환성을 유지하면서 플랫폼 자체에 CMS 기능을 추가하는 것이었습니다.

HTML 기반 인포그래픽과 같은 특정 생성 콘텐츠를 위해 사용자 지정 WordPress 컴포넌트도 필요했습니다.

6. 결과

내부 AI 실험으로 시작했던 것이 약 14개 브랜드를 지원하는 멀티테넌트 플랫폼이 되었습니다.

이 플랫폼은 다음을 연결할 수 있었습니다:

발견(Discovery)
↓
연구(Research)
...

중요한 엔지니어링 교훈은

여기서부터 비로소 엔지니어링 작업이 본격적으로 시작됩니다.