구성 편

다시 한번 jinjer 주식회사에서 백엔드 엔지니어로 근무하고 있는 이케누마(池沼)입니다.

이번에는 구성 편입니다.

설명 편의 복습

설명 편에서는 AI 에이전트 활용에 있어서의 개발자 경험(Developer Experience)의 과제와, TRE 접근법을 통한 해결책의 기본 개념에 대해 설명했습니다.

단순한 프롬프트로 고품질의 결과를 얻기 위해, 암묵지를 규칙(Rule)으로서 파이프라인에 매립하는 접근법의 중요성을 이해하셨으리라 생각합니다.

TRE 파이프라인의 구조

TRE 파이프라인은 인간의 인지 프로세스를 3단계로 분해하고, 각각에 규칙을 정의한 것입니다.

멀티 에이전트(Multi-agent) 환경에서는 각 셀(Cell) 내에서 T(Translator), R(Realization), E(Executor)의 3가지 역할(Role)이 순차적으로 실행됩니다. 역할 간에는 YAML 형식의 인터페이스 계약(Interface Contract)으로 연결되어, 태스크가 파이프라인 방식으로 흐릅니다(T→R→E). 병렬화는 여러 셀이 각각 T→R→E 파이프라인을 가짐으로써 실현됩니다.

전체상

각 단계는 명확하게 정의된 인터페이스 계약으로 연결되어 있으며, 전 단계의 출력 형식이 다음 단계의 입력 형식과 일치합니다.

품질 게이트(Quality Gate)를 통과하지 못하는 경우에는 전 단계로 돌아가 수정이 이루어집니다.

역할 간의 YAML 인터페이스 계약을 통해, 각 역할은 독립적으로 동작하면서도 전체적으로는 일관된 처리 흐름을 실현하고 있습니다.

이를 통해 멀티 에이전트 환경에서의 병렬 처리와 품질 보증을 양립하고 있습니다.

Translator (대시보드 화면의 구조화 규칙)

Translator는 자연어 지시를 구조화된 사양(Specification)으로 변환하는 규칙 세트입니다. 입력으로 자연어 지시를 받아, 구조화된 YAML 사양을 출력합니다.

이 프로세스에서는 도메인 지식(Domain Knowledge)이나 제약 조건 체크리스트와 같은 규칙이 적용됩니다.

앞서 언급한 "대시보드 화면을 만들어줘"라는 예시로 살펴보겠습니다.

실제 규칙 예시:

# Web 앱용 구조화 규칙
domain_knowledge:
- "인증·인가 기능 필요"
...

대시보드 화면 변환 예시:

입력: "대시보드 화면을 만들어줘"
↓ 구조화 규칙 적용
출력:
...

Realization (결선 규칙)

Realization은 구조화된 사양을 구현 가능한 계획으로 결선(Wiring)하는 규칙 세트입니다. 입력으로 구조화된 YAML 사양을 받아, 구현 계획(컴포넌트 구성, 의존 관계, 구현 순서)을 출력합니다.

이 프로세스에서는 아키텍처 패턴(Architecture Pattern)이나 기술 선정 기준, 의존 관계 해결과 같은 규칙이 적용됩니다.

앞서 본 대시보드 화면의 예시를 이어서 살펴보겠습니다.

실제 규칙 예시:

# 아키텍처 선정 규칙
architecture_patterns:
data_heavy: "React + Chart.js + 가상화"
...

결선 예시:

architecture: "React + TypeScript + Chart.js"
components:
- name: "Dashboard"
...

Executor (실행 규칙)

Executor는 구현 계획에 따라 실제 코드를 생성하는 규칙 세트입니다. 입력으로 구현 계획을 받아, 실행 가능한 코드, 테스트, 문서를 출력합니다.

이 프로세스에서는 코딩 규약(Coding Convention)이나 품질 기준, 테스트 전략과 같은 규칙이 적용됩니다.

대시보드 화면의 예시에서는 전 단계에서 결정된 React + TypeScript + Chart.js 구성에 기반하여 실제 컴포넌트가 생성됩니다.

실제 규칙 예시:

# 구현 규칙
coding_standards:
- "TypeScript strict mode"
...

규칙 설계의 핵심

TRE 파이프라인을 실제로 구축할 때의 실천적인 포인트를 설명합니다.

YAML 규칙의 적용 메커니즘

YAML로 정의된 규칙이 AI 에이전트에게 어떻게 적용되는지는 구현상의 중요한 요소입니다.

실제 운용에서는 다음과 같은 3가지 방식을 조합하고 있습니다.

먼저, 시스템 프롬프트(System Prompt)에의 내장에서는 각 역할(T/R/E) 기동 시 기본적인 YAML 규칙을 시스템 프롬프트에 읽어들입니다.

이를 통해 에이전트는 항상 일관된 규칙 세트를 참조할 수 있게 됩니다.

다음으로, 파일 기반 참조에서는 태스크 YAML에 규칙 파일 경로를 기재하고, 실행 시에 동적으로 읽어들입니다.

이것은 RAG (Retrieval-Augmented Generation)와 같은 외부 지식 참조 형식으로, 태스크 고유의 규칙을 적용하는 메커니즘입니다.

실제 운용에서는 하이브리드 (Hybrid) 방식을 채택하고 있습니다.

기본 규칙은 시스템 프롬프트 (System Prompt)에 포함시키고, 태스크 고유 규칙은 태스크 YAML에서 지정함으로써 재사용성과 커스터마이징 (Customizability)을 양립하고 있습니다.

이러한 다층적인 규칙 적용을 통해, 범용성을 유지하면서도 개별 요구사항에도 대응할 수 있는 유연한 메커니즘을 실현하고 있습니다.

출력 포맷의 고정

가장 효과적인 방법은 각 단계의 출력 포맷 (Output Format)을 고정하는 것입니다. YAML 형식을 채택함으로써 구조화된 정보 표현이 가능해지며, 사람과 기계 모두 읽기 쉽고 검증 (Validation)이 용이해집니다.

또한, 계층 구조를 사용함으로써 정보 정리가 자연스러워지고 단계적인 상세화가 가능해져 인지 부하 (Cognitive Load) 경감으로도 이어집니다.

품질 게이트 (Quality Gate) 설계

품질 게이트는 '무엇을 통과시킬 것인가'가 아니라 '무엇을 통과시키지 않을 것인가'로 정의한다는 설계 접근 방식이 매우 유효하다는 통찰을 얻었습니다. 이 접근 방식을 채택함으로써 판정 정밀도를 극적으로 향상시키고 있습니다.

실제 품질 체크는 다음과 같은 세 가지 수단을 조합하여 실현하고 있습니다.

AI 에이전트에 의한 자동 체크에서는 rejection_criteria (거절 기준)에 기반하여 AI 에이전트 스스로 출력 내용을 검증하며, 기준을 충족하지 못할 경우 자동으로 이전 단계로 돌아갑니다.

YAML 스키마 (Schema)에 의한 검증에서는 출력된 YAML 파일이 정의된 스키마를 준수하는지 기계적으로 체크하여 구조적인 결함을 검출합니다.

그리고 중요한 태스크나 복잡한 요구사항의 경우에는 사람에 의한 확인을 옵션으로 두어 비즈니스 요구사항과의 정합성을 검증합니다.

이러한 다층적인 체크 메커니즘을 통해 품질의 안정성을 확보하고 있습니다.

Translator 품질 게이트:

rejection_criteria:
- "primary_functions가 비어 있음"
- "acceptance_criteria가 측정 불가능함"
...

Realization 품질 게이트:

rejection_criteria:
- "순환 의존성이 존재함"
- "구현 순서가 의존 관계와 모순됨"
...

Executor 품질 게이트:

rejection_criteria:
- "테스트 커버리지 80% 미만"
- "Lint 에러가 존재함"
...

도메인 지식의 임베딩 (Embedding)

도메인 지식은 체크리스트로서 규칙에 임베딩합니다:

Web 앱용 체크리스트:

domain_checklist:
security:
- "인증·인가의 적절한 구현"
...

입도 (Granularity) 조절

태스크의 복잡도에 따라 각 단계의 깊이를 조정하는 것도 중요합니다.

심플한 태스크의 경우:

Translator에서는 경량화된 구조화를 수행하고,

Realization에서는 기본적인 결선을 수행하며,

Executor에서는 표준적인 구현을 진행합니다.

반면, 복잡한 태스크의 경우:

Translator에서는 상세한 요구사항 분석을 수행하고,

Realization에서는 복잡한 의존 관계의 해결을 수행하며,

Executor에서는 고도의 품질 관리를 실시하도록 하고 있습니다.

여기까지가 구성 편입니다.

Discussion