4A 기업 아키텍처 + TOGAF: Agent Skill 설계 가이드

서론: AI Skill 설계의 "바벨탑" 딜레마

현재의 AI Agent 생태계는 익숙한 혼란에 빠져 있습니다.

지난해 한 보험사의 Agent 기술 라이브러리(Skill library)를 정리하면서, 100개가 넘는 Skill들이 무질서하게 쌓여 있는 것을 발견했습니다. 어떤 것은 직접 API를 호출하고, 어떤 것은 비즈니스 로직이 내장되어 있으며, 어떤 것은 데이터 수집과 분석이 한데 뒤섞여 있었습니다. 아키텍트에게 이 Skill들을 어떻게 분류하느냐고 묻자, 답변은 "설치된 순서대로 나열했다"였습니다. 두 Skill 사이의 데이터 흐름을 묻자, 답변은 "각자 알아서 한다"였습니다. 한 주식 모니터링 Skill은 스스로 데이터를 크롤링하고, 스스로 분석하며, 스스로 메시지를 보냅니다. 세 가지 작업이 하나의 스크립트에 결합(Coupling)되어 있는 것입니다. 다른 시나리오에서 분석 로직만 재사용하려고 하면? 불가능하며, 새로 작성해야만 합니다.

이것은 단일 사례가 아닙니다. AI Agent를 선제적으로 도입한 거의 모든 기업이 동일한 곤경에 처해 있습니다. Skill은 점점 쌓여가지만, 쌓일수록 더 혼란스러워집니다. 통일된 능력 영역(Capability domain)의 구분이 없고, 표준화된 데이터 인터페이스가 부족하며, 명확한 조합 규칙이 없고, 재사용 가능한 빌딩 블록(Building block)의 축적이 부족합니다.

익숙하게 들리시나요? 맞습니다. 이것은 바로 20년 전 기업 아키텍처가 해결해야 했던 문제입니다. 당시 기업 정보화의 혼란과 오늘날 AI Skill의 혼란은 본질적으로 같습니다. 아키텍처의 제약이 없는 개발은 반드시 무질서로 향하게 됩니다.

4A 기업 아키텍처(비즈니스 아키텍처 BA, 데이터 아키텍처 DA, 애플리케이션 아키텍처 AA, 기술 아키텍처 TA)와 TOGAF의 빌딩 블록(Building block) 사고방식은 Agent Skill 설계에 검증된 방법론을 제공합니다. 본문은 이 둘 사이의 매핑 프레임워크를 구축하고, 실제 사례를 통해 그 실행 가능성을 설명하고자 합니다.

4A 매핑 프레임워크: 네 가지 질문 기반의 Skill 설계

기업 아키텍처의 핵심은 네 가지 질문입니다: 무엇을 하는가(BA), 데이터가 어떻게 흐르는가(DA), 무엇으로 조합하는가(AA), 하부 구조가 어떻게 지원하는가(TA). 이 네 가지 질문은 Skill 설계에도 동일하게 적용됩니다.

┌───────────────────────────────────────────────────────────────┐
│                  4A → Skill 매핑 프레임워크                           │
├───────────────────────────────────────────────────────────────┤
...

표를 통해 각 계층의 핵심 매핑 관계를 더 명확하게 보여줍니다:

아키텍처 계층	핵심 질문	Skill 매핑	예시
BA 비즈니스 아키텍처	Skill이 어떤 비즈니스 문제를 해결하는가?	능력 영역별 그룹화: 협업 도구, 콘텐츠 생산, 데이터 인텔리전스, 시스템 운영 등	"데이터 인텔리전스" 영역에는 고객 프로파일링, 주식 모니터링, 재무 인텔리전스 등의 Skill 포함
...

BA: 비즈니스 능력 영역(Capability Domain)에서 출발

BA 계층의 핵심 작업은 "능력 영역 구분"입니다. 기술적 구현에 따라 Skill을 분류하지 말고, 비즈니스 가치에 따라 분류하십시오. "협업 도구"라는 하나의 능력 영역 아래에는 Feishu 일정, 기업 위챗(WeChat Work) 할 일, DingTalk 승인 등이 있지만, 비록 연결된 플랫폼은 달라도 동일한 비즈니스 문제를 해결합니다. 반대로 "Feishu 패키지"가 캘린더, 문서, 메시지, 작업을 하나로 묶어 놓으면 정돈되어 보일 수는 있지만, 능력 영역의 본질을 가리게 됩니다.

올바른 방법은 먼저 비즈니스 능력 지도를 그린 다음, 그 안에 Skill을 채워 넣는 것입니다. 누락된 능력 영역은 새로운 Skill이 필요함을 의미하며, 동일 영역 내의 중복된 Skill은 병합 또는 계층화가 필요함을 의미합니다. 실무에서 우리는 7개의 능력 영역(협업 도구, 콘텐츠 생산, 데이터 인텔리전스, 시스템 운영, 개발 도구, 메시지 채널, 엔터테인먼트/라이프스타일)만으로도 70개 이상의 Skill을 분류하기에 충분하다는 것을 발견했습니다.

DA: Skill 간의 자유로운 데이터 흐름 보장

데이터 아키텍처는 Skill 사이의 "대화 프로토콜(Dialogue protocol)"을 해결합니다. 두 Skill이 협업하려면 반드시 데이터 형식을 약속해야 합니다. 실무에서 우리는 몇 가지 규칙을 확립했습니다: 문서형 출력은 Markdown으로 통일, API 데이터 교환은 JSON으로 통일, 시간 필드는 ISO 8601로 통일, 사용자 식별자는 오픈 플랫폼 ID로 통일합니다. 동시에 세 가지 데이터 역할(Role)을 식별했습니다: 데이터 소스 Skill(검색, 시세 인터페이스), 데이터 변환 Skill(요약, 프로파일 생성), 데이터 소비 Skill(보고서 푸시, 경고 알림). 데이터 흐름은 반드시 "소스 → 변환 → 소비"여야 하며, 소비 Skill이 원시 데이터를 직접 수집하는 것은 허용되지 않습니다. 이는 데이터 웨어하우스의 ODS → DWD → ADS 계층 구조와 동일한 논리입니다.

AA: 조립 가능한 Skill 그래프 구축

애플리케이션 아키텍처는 Skill 간의 조합과 의존성에 주목합니다. 핵심 원칙은 다음과 같습니다: 상위 Skill은 반드시 하위 Skill을 조합해야 하며, 하위 로직을 절대 중복 구현해서는 안 됩니다. 주식 모니터링 Skill이 스스로 크롤러를 작성하는 것은 이 원칙을 위반하는 것입니다. 올바른 방법은 "검색 Skill"에 의존하여 데이터를 가져오고, 자신은 분석 로직만 담당하는 것입니다. 이렇게 하면 검색 능력이 업그레이드될 때(예: 더 빠른 API로 교체), 모든 상위 Skill이 자동으로 혜택을 받습니다.

의존성은 강한 의존성(Strong dependency)과 약한 의존성(Weak dependency)으로 나뉩니다. 강한 의존성은 Skill이 독립적으로 실행될 수 없음을 의미하며(예: 보고서 Skill이 PDF 변환에 의존), 약한 의존성은 기능이 저하될 수는 있지만 사용은 가능함을 의미합니다(예: 장애 조치 Skill이 플랫폼 패키지에 의존하는 것은 선택 사항임). 실제 배포 시 강한 의존성은 반드시 Skill 메타데이터에 표시해야 하며, 약한 의존성은 환경 조건에 따라 로드할 수 있습니다.

TA: 인프라가 Skill의 상한선을 결정한다

기술 아키텍처 (TA) 계층은 간과되기 쉽지만, 전체 Skill 체계의 상한선(Ceiling)을 결정합니다. 네 가지 하위 계층을 명확히 정의해야 합니다: 런타임 계층 (Runtime Layer: Node.js 게이트웨이, Python 스크립트 엔진, Bash 커맨드라인, 브라우저 자동화), 도구 체인 계층 (Toolchain Layer: Git, tmux, curl, Chromium), 인프라 계층 (Infrastructure Layer: Skill 등록 센터, 기억 시스템, 메시지 라우터), 그리고 외부 통합 계층 (External Integration Layer: Feishu/企微/钉钉/GitHub 등 오픈 플랫폼). 각 계층의 선정은 Skill의 이식성(Portability)과 확장성(Scalability)에 영향을 미칩니다. 예를 들어, 특정 Skill이 Chromium의 특정 버전에 강하게 의존한다면, 헤드리스(Headless) 서버에서의 배포가 제한될 수 있습니다.

TOGAF 빌딩 블록(Building Block) 사고방식: 원자적 능력에서 멀티 에이전트 연동까지

TOGAF는 아키텍처 요소를 아키텍처 빌딩 블록(ABB, Architecture Building Block)과 솔루션 빌딩 블록(SBB, Solution Building Block)으로 나눕니다. 이를 Skill 체계에 매핑하면 다음과 같습니다: ABB는 더 이상 나눌 수 없는 원자적(Atomic) 수준의 Skill이며, SBB는 여러 ABB가 조립되어 구성된 조합형 Skill입니다. 더 나아가, 여러 SBB가 다시 조합되어 특정 산업 시나리오를 해결하는 "조합의 조합"을 형성할 수 있으며, 에이전트(Agent) 간의 협업 오케스트레이션(Orchestration)은 멀티 에이전트 연동 시나리오를 구성합니다.

┌─────────────────────────────────────────────────────────┐
│  ABB → SBB → 조합의 조합 → 멀티 에이전트 연동              │
│                                                         │
...

"투자 연구 생산 라인"을 예로 들면: L1 계층의 검색 Skill과 시세 Skill은 ABB입니다. L2 계층의 보고서 템플릿 엔진은 SBB입니다. L3 계층의 투자 연구 보고서 생성은 비즈니스 도메인(Business Domain) Skill입니다. L4 계층에서는 투자 연구 보고서 + 주식 모니터링 + 고객 프로파일링 + 일일 보고서 푸시가 결합되어 완전한 생산 라인을 구성하며, 여러 Agent가 각자의 역할을 수행합니다.

빌딩 블록 사고방식의 핵심 가치는 재사용성(Reuse)입니다. 통계에 따르면, 하나의 핵심 L1 Skill(예: 메시지 푸시)은 5개 이상의 L3 Skill에 의해 의존됩니다. 만약 빌딩 블록 계층화가 없다면, 각 L3 Skill이 메시지 푸시 로직을 개별적으로 구축하게 되어 알림 형식을 하나만 바꿔도 5곳을 수정해야 합니다. 빌딩 블록이 있다면, 한 번의 수정으로 모두가 혜택을 입습니다.

L0-L4 5단계 분류 체계

4A 사고방식과 빌딩 블록 재사용 원칙을 결합하여, L0부터 L4까지의 5단계 분류 모델을 설계했습니다:

┌───────────────────────────────────────────────────────────┐
│  L4 멀티 에이전트 연동  │ 코딩 군단, 투자 연구 생산 라인, 장애 대응 센터      │
│                   │ 에이전트 간 협업, 분산 실행                       │
...

계층	수량	재사용도	개발 비용	산업 속성
L0	~15	매우 높음	낮음	전 산업 공통
...

한 가지 핵심 규칙: L3 이상의 Skill은 반드시 L2와 L1에 의존해야 하며, 하위 계층의 로직을 절대 중복 구현해서는 안 됩니다. L0 계층에는 절대 비즈니스 로직을 포함하지 않습니다. 이를 통해 85%의 Skill이 산업을 초월하여 범용적으로 사용될 수 있도록 보장하며, 산업 특수성은 L3와 L4 계층에서만 나타나도록 합니다.

경계 없는 정보 흐름: Skill 간의 정보 장벽 허물기

TOGAF의 III-RM 참조 모델에는 핵심 비전이 있습니다: 경계 없는 정보 흐름(Seamless Information Flow) — 정보는 조직의 경계나 기술적 경계에 구애받지 않고, 적절한 시간에 적절한 형식으로 필요한 사람이나 시스템에 전달되어야 합니다.

이를 Skill 체계에 매핑하면 다음과 같은 의미를 갖습니다: 분석 결과가 그것을 생성한 Skill 내부에 갇혀 있어서는 안 되며, 그것을 필요로 하는 어떤 Skill이라도 소비할 수 있어야 합니다. 이를 구체적으로 구현하기 위해서는 세 가지가 필요합니다.

첫째, 데이터 형식의 통일. Markdown은 문서 표준으로, JSON은 API 표준으로, ISO 8601은 시간 표준으로 사용합니다. 모든 Skill의 출력은 이 세 가지 표준 중 하나를 준수해야 합니다.

둘째, 데이터 소스와 데이터 소비의 디커플링(Decoupling). 검색 Skill은 "획득"만 담당하고, 분석 Skill은 "가공"만 담당하며, 푸시 Skill은 "전달"만 담당합니다. 전형적인 정보 흐름은 다음과 같습니다: 외부 데이터 소스 → 검색 계층 → 분석 계층 → 분배 계층. 검색 Skill이 뉴스를 가져오면, 요약 Skill이 핵심 내용을 추출하고, 보고서 Skill이 브리핑을 생성하며, 메시지 Skill이 Feishu나 企微로 푸시합니다. 네 개의 Skill이 각자의 역할을 수행하며 데이터가 파이프라인을 따라 흐릅니다.

셋째, 기억 계층(Memory Layer)을 통한 세션 간 장벽 제거. 많은 Skill의 출력은 영속화(Persistence)되어야 합니다. 기억 계층(장기 기억 파일, 일일 로그)을 도입하면 오늘의 분석 결과가 내일의 컨텍스트(Context)가 될 수 있습니다. 한 번의 투자 연구 보고서에서 나온 산업 판단이 다음번에 유사한 보고서를 생성할 때 자동으로 인용됩니다. 이것이 더 높은 차원의 경계 없음, 즉 시간 차원의 정보 흐름입니다.

실전 사례: 4개 수직 산업의 Skill 블루프린트

4A 아키텍처는 이론에 그치지 않습니다. 다음은 교육, 의료, 법률, 부동산 4개 산업의 Skill 설계 아이디어를 보여주며, 각 항목은 BA → DA → AA → TA의 하향식(Top-down) 추론을 따릅니다.

교육 산업: 커리큘럼 구성 및 학습 현황 추적

교육 산업: 커리큘럼 구성 및 학습 현황 추적

BA 계층은 세 가지 핵심 역량 영역을 식별했습니다: 과정 관리, 학업 성취도 추적, 교육 자료. DA 계층의 데이터 표준은 다음과 같습니다: 과정은 JSON Schema로 설명하고, 학습 진도는 시계열 데이터로, 과제는 Markdown으로 사용합니다. AA 계층 조합 방안: 학업 성취도 추적 Skill = Feishu 다차원 표(데이터 소스) + 요약 Skill(분석) + 메시지 푸시(학부모에게 알림). TA 계층은 캘린더 API 통합과 점수 수집 인터페이스가 필요합니다.

의료 산업: 건강 모니터링 및 진료 조정

BA 계층 역량 영역: 건강 모니터링, 예약 관리, 병력 해석. DA 계층: 건강 지표는 FHIR 표준 형식으로, 예약 데이터는 병원 HIS 인터페이스를 거치고, 병력 텍스트는 Markdown으로 저장합니다. AA 계층: 건강 모니터링 Skill = 웨어러블 기기 데이터 소스 + 임계값 경보 엔진(L2 재사용 가능) + 기업 위챗 카드 푸시. TA 계층은 의료 장비 연동과 개인 정보 보호 규정 준수(데이터 비식별화가 전제 조건)가 필요합니다.

법률 산업: 계약 검토 및 사례 검색

BA 계층 역량 영역: 계약 검토, 법규 검색, 사례 분석. DA 계층: 계약은 구조화된 JSON으로 위험 조항을 설명하고, 법규 데이터는 조항 번호 인덱스를 사용하며, 사례는 Markdown 요약본을 사용합니다. AA 계층: 계약 검토 Skill = 문서 파싱(L1) + 위험 식별 엔진(L2) + 수정 제안 생성(L3). 이 시나리오의 가치는 L2 계층의 위험 식별 엔진이 계약 검토와 규정 준수 점검이라는 두 개의 L3 Skill에 동시에 서비스를 제공할 수 있다는 점이며, 구성 요소 재사용을 보여줍니다.

부동산 산업: 매물 매칭 및 시장 분석

BA 계층 역량 영역: 매물 검색, 시장 분석, 대출 계산. DA 계층: 매물은 GeoJSON으로 위치 속성을 설명하고, 시세 데이터는 시계열 데이터를 사용하며, 대출 파라미터는 구조화된 JSON을 사용합니다. AA 계층: 시장 분석 Skill = 지도 POI 검색(L1) + 추세 분석(L2) + 지역 보고서 생성(L3). 이 중 L2 추세 분석 엔진은 금융 산업의 주식 추세 분석과 동일하며, 업계 간 재사용이 가능합니다.

네 가지 산업의 공통점은 다음과 같습니다: L0와 L1 계층은 완전히 범용적입니다(검색, 메시지, 문서, 지도). L2 계층의 패턴 엔진(경보, 분석, 템플릿)은 높은 수준으로 재사용 가능하며, 산업별 차이는 주로 L3 계층의 비즈니스 규칙과 L4 계층의 협업 방식에 집중됩니다. 이것이 바로 4A 아키텍처의 가치입니다—분리된 계층을 사용하여 변화를 격리하고, 구성 요소를 통해 재사용성을 확보합니다.

돌아보면 흔한 오해는