저는 에이전트 플랫폼을 구축했습니다. 데모가 아니라, 모든 도구 호출(tool call)이 관리되고, 감사(audit)되며, 워크스페이스(workspace)로 범위가 제한되는 실제 플랫폼입니다.

제가 배운 점들은 다음과 같습니다.

모든 기술(skill)은 일급 시민(first-class citizen)이다

이 플랫폼은 7개 그룹에 걸쳐 **27개의 기술(skills)**을 보유하고 있습니다 — 플랫폼 운영(platform ops), 퍼블리싱 (dev.to, LinkedIn), 테스트 (리스크 매트릭스, 베이스라인 특성 분석, NFR 감사 기능을 포함한 전체 TEA 스위트), 커뮤니케이션 (Slack, Telegram, Gmail), 지식 (RAG + 지속성 메모리), 개발, 그리고 스크래핑(scraping)입니다.

기술(skills)은 단순한 프롬프트가 아닙니다. 각 기술은 생성, 검증, 버전 관리, 워크스페이스 삽입이라는 관리된 생명주기(lifecycle)를 가집니다. 길을 잃은 스크립트는 없습니다.

14개의 통합 서비스, 하나의 감사 추적(audit trail)

• GitHub (이슈/PR), Jira (티켓), Slack & Telegram (메시징)
• Gmail, Google Calendar, Google Drive (OAuth2)
• LinkedIn (프로필 + 게시물 퍼블리싱), Dev.to (블로그)
• Knowledge Base (RAG 검색), Memory (세션 간 지속성 메모리)
• Web Search, Transcribe (Whisper)

모든 외부 호출은 platform_cli 디스패치 연산(dispatch op) 또는 service_call 어댑터(adapter)를 거칩니다 — 동일한 감사 파이프라인(audit pipe)과 동일한 추적 ID(trace ID)를 사용합니다.

CLI가 신뢰할 수 있는 유일한 원천(source of truth)이다

설정 파일을 편집하고 요행을 바라지 마십시오. loop_list, policy_show, skill_list, service_list, workflow_catalog를 통해 검증하십시오. 거기서 볼 수 없다면, 그것은 존재하지 않는 것입니다.

테스트는 사후 고려 사항이 아니다

TEA (Test Engineering Architecture) 스위트는 6가지 워크플로우를 제공합니다: 테스트 설계 (리스크 매트릭스), 베이스라인 특성 분석 (golden-master diffing), NFR 증거 감사, 자동 테스트 생성, 테스트 리뷰, 그리고 요구사항-커버리지 추적(requirement-to-coverage tracing). 모든 출력은 커밋된 JSON 또는 markdown 형식이며, 독점적인 포맷을 사용하지 않습니다.

솔직한 부분

모든 것이 프로덕션 환경에 즉시 적용 가능한 수준은 아닙니다. 27개의 스킬 중 4개는 차단되어 있습니다 (서비스 누락 또는 워크스페이스 범위 초과). 모델은 deepseek-chat을 사용하며 deepseek-reasoner를 폴백 (fallback)으로 사용합니다. 이는 화려함보다는 실용성을 택한 결과입니다. 워크스페이스의 임시 파일 (scratch files) TTL (Time To Live)은 24시간입니다. 위험한 명령 (kubectl delete, helm uninstall)은 패턴 차단 (pattern-blocked) 처리됩니다.

하지만 핵심 아이디어는 작동합니다: 워크스페이스로 범위가 제한되고, 실제 통합 (integration), 실제 메모리 (memory), 그리고 실제 감사 (audit) 기능을 갖춘, 통제된 에이전트 도구 (governed agent tools). 이는 대부분의 에이전트 프레임워크 (agent frameworks)가 제공하는 것 이상입니다.

단순히 텍스트를 생성하는 것을 넘어 실제 API를 다뤄야 하는 에이전트를 구축하고 있다면 다음을 고려하십시오: 모든 통합은 통제된 스킬 (governed skill)이어야 하며, 모든 호출은 추적 (traced)되어야 하고, 추측이 아닌 플랫폼으로부터의 데이터를 읽어옴으로써 상태를 검증할 수 있어야 합니다.