프롬프트에서 하네스로, 그 다음은

— AI 활용 방법론의 흐름과 다음 분기점에 대한 메모

AI 활용 방법론은 ChatGPT 등장 이후 짧은 시간 사이에 빠르게 진화해 왔습니다. 처음에는 모델에게 어떻게 묻느냐가 핵심이었지만, 지금은 모델이 자율적으로 일할 수 있는 환경 자체를 설계하는 단계까지 와 있습니다. 이 글은 그 흐름을 짚어 본 뒤, 다음 분기점이 어디일지 가늠해 보는 메모입니다.

 

1. 지금까지의 흐름

1.1. 프롬프트 엔지니어링

대규모 언어 모델이 보편화된 직후의 초기 단계입니다. 모델의 출력 품질을 끌어올리기 위해 입력 자체를 정교하게 다듬는 방법론으로, Chain of Thought, Few-shot, 역할 부여 같은 기법들이 등장했습니다. 본질은 ‘모델이라는 새로운 액터에게 어떻게 효과적으로 지시하느냐’의 문제였습니다.

그러나 한계는 명확했습니다. 모델이 학습 시점에 보지 못한 정보, 가령 최신 사실이나 사적 데이터에는 근본적으로 답할 수 없습니다. 프롬프트를 아무리 정교하게 다듬어도, 모르는 것은 모르는 것입니다.

1.2. RAG (Retrieval-Augmented Generation)

이 한계를 넘기 위해 등장한 방법론입니다. 임베딩 모델로 외부 문서를 벡터화하고, 사용자 쿼리와 가장 유사한 문서를 가져와 모델에게 컨텍스트로 주입합니다. 이로써 모델은 학습되지 않은 지식까지 다룰 수 있게 되었습니다.

문서를 그래프 구조로 체계화하기, 청킹 전략 최적화, 재귀 추론을 통한 답변 정제 등 RAG 변형 기법은 지금도 활발히 연구되고 있습니다. 그러나 RAG는 본질적으로 읽기 전용입니다. 모델이 외부 세계의 정보를 가져올 수는 있지만, 외부 세계에 직접 영향을 미치지는 못합니다.

1.3. MCP (Model Context Protocol)

모델이 외부 세계와 상호작용하는 도구를 표준화한 프로토콜입니다. 2024년 말 등장 이후 도구 사용의 사실상 표준으로 자리 잡았습니다. 모델이 캘린더 일정을 잡고, 코드 저장소에 커밋하고, 데이터베이스를 조회하는 등의 행위가 표준화된 프로토콜 위에서 가능해졌습니다.

그러나 도구가 늘어날수록 새로운 문제가 드러났습니다. 호스트에 연결된 MCP 서비스가 많아질수록 LLM이 보유해야 할 컨텍스트가 폭증합니다. 도구 설명만으로도 토큰이 소진되어, 본격적인 작업이 시작되기 전에 컨텍스트 윈도우가 좁아지는 현상이 일반화되었습니다.

1.4. Skills

이 컨텍스트 점유 문제를 우아하게 풀어낸 개방형 표준입니다. 3단계 점진적 로딩 구조를 가집니다.

•      1단계: 항상 로드되는 메타데이터 (이름, 설명)

•      2단계: 트리거될 때 로드되는 지침 (SKILL.md)

•      3단계: 필요 시 참조되는 리소스와 스크립트 (코드, 보조 문서)

특히 3단계에서는 정보를 컨텍스트에 주입하지 않고 직접 실행할 수도 있어 컨텍스트 윈도우를 한층 더 절약합니다. MCP가 ‘도구의 가능성’을 열었다면, Skills는 그 가능성을 지속 가능한 형태로 관리하는 답입니다.

1.5. 하네스 엔지니어링

프롬프트에서 RAG로, MCP로, Skills로 이어진 흐름의 끝에 하네스 엔지니어링이 있습니다. 비결정적인 에이전트가 올바른 결과로 향하도록 환경 자체를 설계하는 작업입니다. 컨텍스트 관리 전략, 권한과 안전 경계 설계, 테스트 케이스 관리, 실패 시 복구 메커니즘 등이 핵심 요소입니다.

이미 실무에서 자리를 잡아 가고 있습니다. 일부 선도 조직에서는 개발자가 직접 코드를 작성하지 않고, 에이전트가 일할 환경을 설계하는 것으로 엔지니어의 업무 자체를 재정의하기 시작했습니다. 야간에 사람이 자는 동안 에이전트가 정의된 목표를 수행하는 ‘랄프 루프’ 같은 패턴은, 모델의 단위 작업 시간이 늘어남에 따라 점점 일반화될 것으로 보입니다.

1.6. 흐름의 큰 방향

다섯 단계를 한 줄로 요약하면 다음과 같습니다.

•      모델에게 잘 묻기 (프롬프트 엔지니어링)

•      모델에게 지식 건네기 (RAG)

•      모델에게 도구 쥐여 주기 (MCP)

•      모델 컨텍스트를 효율적으로 관리하기 (Skills)

•      모델이 일할 환경 자체를 설계하기 (하네스 엔지니어링)

무게중심이 일관되게 ‘사용자가 무엇을 해야 하는가’에서 ‘시스템이 무엇을 해 주는가’로 옮겨가고 있습니다. 사용자에게 지우던 부담이 한 단계씩 시스템 쪽으로 흡수되어 온 것입니다.

 

2. 다음 분기점에 대한 세 가지 가설

이렇게 흐름을 정리하고 나면 자연스러운 질문이 따라옵니다. 다음 단계는 무엇일까.

미래 예측이라 정량 근거는 없습니다. 현재 관찰 가능한 신호로부터 합리적으로 추론한 시나리오 세 가지를 제시합니다.

2.1. 검증 우선 하네스 (Verification-first Harness)

현재 하네스 엔지니어링의 가장 약한 고리는 ‘에이전트의 결과가 맞는지 어떻게 확인하는가’ 입니다. 야간 자율 실행 같은 패턴이 늘어날수록 인간 검증 병목이 폭발적으로 커집니다. 자율 실행 시간이 길어질수록 사람이 검토해야 할 출력의 양도 같이 늘어나기 때문입니다.

다음 단계는 검증과 평가가 1급 시민이 되는 구조입니다. 적대적 페어링(adversarial pairing)이나 다중 에이전트 책임 분리가 표준이 될 가능성이 큽니다.

보안 도메인에서는 익숙한 패턴입니다. SOC가 탐지/분석/대응을 분리하고, Red/Blue 팀이 적대 구조를 짭니다. 모델 하나가 만들고, 다른 모델이 비판하고, 또 다른 모델이 회귀 테스트를 생성하는 구조가 자연스러운 다음 단계입니다. Skills가 검증 스크립트를 결정적 컴포넌트로 포함하는 방향, 주요 모델들이 reasoning trace 검증에 투자하는 흐름이 이 방향성의 신호로 읽힙니다.

2.2. 조직 통합 하네스 (Org-level Harness)

지금까지의 하네스는 개인 개발자나 소규모 팀 단위입니다. 다음은 조직 거버넌스와의 통합입니다. 권한 매트릭스, 감사 로그, 변경 통제, 데이터 분류, 인가된 도구 카탈로그가 하네스에 1급 시민으로 들어옵니다.

보안과 IT 거버넌스 도메인 관점에서 보면 이게 가장 큰 비즈니스 분기점이라고 봅니다. ISMS, ITIL, SOC 2 같은 거버넌스 통제 항목이 그대로 에이전트 워크로드 표면에 매핑됩니다. 지금 ZTNA, IAM, SIEM 시장에서 일어나는 일이 ‘AI 워크로드 거버넌스’라는 한 단계 위 추상에서 재현될 가능성이 큽니다. 익숙한 구조가 한 층 위에서 다시 펼쳐지는 셈입니다.

2.3. 컨텍스트 경제학 (Context Economy)

Skills의 점진적 공개는 컨텍스트 절약에 대한 정적인 답입니다. 다음은 명시적 예산과 가격이 메타데이터로 붙는 단계입니다. ‘이 결정에 토큰 N개’, ‘이 워크플로우 비용 상한 X달러’, ‘이 도구 호출 컨텍스트 깊이 M’ 같은 자원 관리 어휘가 일반화될 거라 봅니다.

토큰 비용, 추론 비용, 응답 지연이 본격적인 운영 비용 항목으로 잡히는 시점이 오면, 모델 호출이 ‘무료에 가까운 한 번의 요청’이 아니라 자원 할당을 받아 처리되는 작업 단위로 다뤄지게 됩니다. 운영체제가 메모리와 CPU를 스케줄링하는 방식과 닮은 구조가 에이전트 런타임에 들어오는 것입니다.

 

3. 빠뜨린 한 축 — 의도 추론과 되묻기

위의 세 가지 분기점은 모두 시스템 아키텍처 관점의 분석입니다. 그런데 빠뜨리면 안 되는 축이 하나 더 있습니다. 사용자 입력의 모호함을 시스템이 얼마나 흡수하느냐 입니다.

컴퓨터 인터페이스 역사가 이 명제를 증명합니다. CLI(정확한 명령) → GUI(시각적 어포던스) → 자연어(의도 추론). 각 단계마다 사용자에게 지우던 부담이 시스템 쪽으로 넘어왔고, 그것이 사용자 풀을 넓힌 본질이었습니다. 사용자가 ‘개떡같이 말해도 잘 알아듣는 능력’이야말로 ‘범용’이라는 단어의 출발점입니다.

도메인 전문가도 모든 발화를 정밀하게 명세하지 않습니다. 작업 기억의 한계, 맥락 의존성, 그리고 무엇보다 간결히 말하고 싶다는 효율 본능 때문입니다. 솔직히 말해 저 자신도 IT 종사자임에도 일상에서는 항상 두루뭉술하게 말합니다. 시스템이 이 모호함을 결함으로 보고 ‘더 명료하게 말해 주세요’라고 대응하는 순간, 범용성은 죽습니다.

그러나 단서가 하나 있습니다. ‘잘 알아듣기’가 너무 강해지면 잘못된 자율성 문제가 생깁니다. 모호한 요청을 모델이 알아서 해석한 결과가 사용자 의도와 어긋나면 책임 소재 문제가 발생합니다. 보안 도메인에서는 특히 위험합니다. ‘이 사용자 정보 정리해 줘’라는 발화에 모델이 알아서 범위를 정해 행동하면, PII 처리 사고로 직결될 수 있습니다.

그래서 수정된 명제는 다음과 같습니다. 범용 하네스의 핵심 축 하나는 ‘개떡같이 말해도 잘 알아듣되, 중요한 결정 지점에서는 잘 되묻는 능력’입니다. 두 요소가 반드시 짝을 이뤄야 합니다. 알아듣기만 강하면 앞에서 말한 검증과 거버넌스 축이 무너지고, 되묻기만 강하면 범용성이 죽습니다.

좋은 부하 직원의 모습과 비슷합니다. ‘그 보고서 정리해 줘’라는 요청을 받았을 때 80%는 알아서 처리하지만, 20%의 분기점에서는 ‘○○님께 보낼 건가요, 임원 보고용인가요?’ 하고 한 번 묻는 사람. 매번 묻는 신입은 답답하고, 한 번도 안 묻는 사람은 사고를 칩니다.

 

4. 종합

다음 분기점에 대한 결론을 정리합니다.

가장 가능성 높은 시나리오는 앞서 본 세 가지 분기가 합쳐지는 그림입니다. 검증 가능하고, 조직 거버넌스에 통합되며, 컨텍스트 자원을 명시적으로 관리하는 런타임. 이것이 ‘범용 안정적 하네스’가 다음 단계로 진화하는 가장 자연스러운 경로라고 봅니다.

여기에 의도 추론과 되묻기라는 인터페이스 축이 짝패로 따라옵니다. 시스템 아키텍처(검증, 거버넌스, 컨텍스트 경제)는 신뢰성을 책임지고, 인터페이스 축(의도 추론과 되묻기)은 접근성을 책임지는 구조입니다. 둘 중 하나만 강해서는 진짜 범용 하네스가 성립하지 않습니다.

반례 가능성도 짚어 둡니다. AGI에 가까운 모델이 갑자기 등장해 검증, 거버넌스, 의도 추론까지 모델 자체가 내재화해 버리면 위 분석은 무너집니다. 다만 그 시나리오는 적어도 향후 2~3년 안에는 도달하지 않을 가능성이 더 높다고 봅니다.

정리하면, 모델에게 잘 묻는 시대에서 시작해 모델이 일할 환경을 설계하는 시대까지 왔습니다. 다음은 ‘그 환경이 스스로를 검증하고, 조직 안에서 통제 가능하고, 자원을 의식하며, 사용자의 모호한 의도를 우아하게 흡수하는 단계’입니다. 이름이 무엇이 되든, 본질은 그쪽으로 수렴하리라 봅니다.

 

이상은 현재 시점에서의 개인적 가설이며, 흐름의 단계마다 새로운 변수가 등장하면 얼마든지 수정될 수 있습니다. 다른 시나리오나 반론이 있으시다면 언제든 들려주시면 좋겠습니다.