모델 발전 시대에 오래 남는 AI 자산

한 줄 요약

모델의 약점을 임시로 보완하는 하네스는 빠르게 낡지만, 현실의 요구사항·실패 증거·평가·권한·책임을 다루는 자산은 모델이 강해질수록 더 중요해진다.

먼저 읽을 결론

모델이 좋아지면서 긴 지침, 고정된 에이전트 역할, 퓨샷 예시, 재시도 규칙처럼 특정 모델의 약점을 보완하던 하네스의 감가상각 속도가 빨라지고 있다.

그렇다고 하네스 엔지니어링 전체가 사라지는 것은 아니다. 가치의 중심이 옮겨가고 있다.

모델을 더 똑똑하게 보이게 만드는 장치 → 모델이 현실에서 올바르고 안전하게 일하도록 만드는 계약·증거·통제 장치

기획도 같은 방식으로 봐야 한다. 무엇을 만들지, 누구의 문제를 우선할지, 어떤 손실을 감수할지 결정하는 기능은 계속 필요하다. 반면 PRD 작성, 사용자 스토리 생성, 일정 분해 같은 문서 생산은 상당 부분 자동화될 가능성이 크다.

기획이라는 기능은 남더라도 지금의 직무 구성과 산출물 형식이 그대로 유지된다고 보기는 어렵다. 오래 남는 것은 문서 작성 능력보다 문제 발견, 제품 판단, 현실의 증거, 트레이드오프와 책임이다.

왜 저장했나

모델이 한 세대 좋아질 때마다 기존 프롬프트와 하네스가 쓸모없어지면, 그동안 쌓은 지식과 작업이 빠르게 감가상각된다.

이 글은 무엇이 낡기 쉬운 구현물이고 무엇이 모델 발전에도 살아남는 자산인지 구분한다. 목표는 변하지 않는 기술을 찾는 것이 아니라, 모델이 좋아질수록 함께 가치가 커지는 자산을 만드는 것이다.

정리한 질문

모델 성능이 향상되면서 긴 지침, 퓨샷, 다중 에이전트 같은 기존 하네스가 오히려 방해가 되는 경우가 늘고 있다. 앞으로 시간을 투자할 때 무엇을 만들어야 모델 발전으로 가치가 사라지지 않을까? 무엇을 만들지 결정하는 기획은 비교적 오래 남는 역량일까?

하네스는 실제로 줄어드는가

긴 지침의 한계

OpenAI는 에이전트 중심 개발 사례에서 거대한 AGENTS.md가 실패했다고 설명했다. 긴 지침은 작업과 코드에 쓸 컨텍스트를 밀어내고, 모든 내용을 똑같이 중요하게 보이게 하며, 빠르게 낡고, 기계적으로 검증하기도 어렵다.

대신 약 100줄의 작은 진입점, 계층화된 문서, 버전 관리되는 실행 계획, CI로 검사하는 문서 최신성을 사용했다. 교훈은 지침이 필요 없다는 것이 아니다.

문장으로 모든 행동을 규정하는 방식은 약해진다.
저장소 구조, 타입, 테스트, 도구 계약, 정책, 단일 진실 공급원으로 행동을 유도하는 방식은 강해진다.
반드시 지켜야 할 조건은 프롬프트보다 코드와 검증기로 옮기는 편이 낫다.

Anthropic도 가장 단순한 구성에서 시작하고, 실제 평가에서 결과가 나아질 때만 복잡성을 추가하라고 권한다. 복잡한 프레임워크는 프롬프트와 응답을 가려 디버깅을 어렵게 만들 수 있다.

강한 단일 에이전트와 다중 에이전트

2026년 《Nature Machine Intelligence》 연구는 3개 모델 계열, 6개 벤치마크, 5개 아키텍처에 걸친 260개 통제 구성을 비교했다.

다중 에이전트의 효과를 예측하는 가장 강한 지표는 단일 에이전트의 기본 성능이었다. 연구에서 얻은 약 45%의 경험적 기준을 넘으면 다중 에이전트가 이득을 주지 않거나 성능을 낮추는 경우가 많았다. 별도 검증에서는 성능 변화의 방향을 16개 구성 중 94%에서 맞혔다.

다만 45%는 보편 법칙이 아니다. 연구진도 실험 범위에서 사용할 수 있는 선택 규칙으로 제한했다. 서로 독립적인 정보를 병렬로 수집하는 작업에서는 다중 에이전트가 유리할 수 있지만, 순차 의존성이 높은 계획과 소프트웨어 작업에서는 중복, 컨텍스트 분산, 오류 전파와 조정 비용이 커질 수 있다.

강한 단일 에이전트와 명확한 도구, 검증 루프로 시작한다. 평가에서 병렬 탐색이나 독립 검증의 이득이 확인될 때만 에이전트를 늘린다.

퓨샷은 언제 도움이 되고 언제 오염을 만드는가

퓨샷이 항상 해롭다고 일반화할 수는 없다. 다만 예시를 습관적으로 붙이는 방식은 재검토할 필요가 있다.

EMNLP 2025 Findings 연구에서는 Qwen2.5 계열처럼 비교적 강한 모델의 수학 추론에 전통적인 CoT 퓨샷 예시를 추가해도 제로샷 CoT보다 추론 성능이 좋아지지 않았다. 예시는 주로 출력 형식을 맞췄고, 더 강한 모델이 만든 예시도 추론 능력을 높이지 못했다.

반면 Google DeepMind의 many-shot 연구에서는 예시가 새로운 정보를 제공할 때 효과가 있었다. 저자원 번역, 일부 계획 문제, 코드 검증기 학습에서는 성능이 좋아졌다. 같은 연구에서도 XSum 요약은 예시가 50개를 넘자 성능이 떨어졌고, 존재하지 않는 날짜와 시간을 생성하는 사례도 나타났다.

따라서 예시는 프롬프트 장식이 아니라 데이터로 다뤄야 한다. 예시를 추가하기 전에 다음을 확인한다.

모델이 모르는 도메인 정보나 판단 기준을 제공하는가?
출력 형식만 맞추려는 예시인가?
제로샷 기준보다 실제 평가 점수가 오르는가?
다른 분포나 예외 사례의 판단을 오염시키지 않는가?
예시의 순서와 개수에 따라 결과가 흔들리지 않는가?
모델을 교체한 뒤에도 이득이 유지되는가?

효과가 측정되지 않은 예시는 삭제 후보로 본다.

빨리 낡는 하네스와 오래 남는 하네스

하네스에는 성격이 다른 두 종류가 섞여 있다.

능력 보정형 하네스

현재 모델이 못하는 일을 임시로 대신한다.

반드시 먼저 계획하라는 반복 지침
단계별 CoT 유도
역할극 기반 planner·reviewer·executor 분리
같은 문제를 여러 에이전트에게 중복 질의하는 구조
출력 형식을 강제하는 퓨샷
특정 모델의 도구 호출 버그를 보정하는 재시도
현재 컨텍스트 길이에 맞춘 압축 규칙

이런 구성은 모델의 약점에 역으로 연동된다. 모델이 좋아질수록 가치가 내려간다.

현실 결합형 하네스

모델 밖에 존재하는 사실과 책임을 다룬다.

실제 제품 요구사항과 비목표
도메인 불변식
데이터 스키마와 API 계약
사용자·조직별 권한
승인과 책임 소재
샌드박스와 네트워크 경계
트랜잭션, 멱등성, 롤백
로그, trace, provenance
회귀 평가와 실제 실패 사례
법률·권리·보안 정책
비용·지연·품질의 허용 한계

강한 모델은 더 많은 일을 빠르게 실행한다. 잘못된 권한이나 계약이 있을 때 피해 범위도 함께 커진다. OpenAI의 Agents SDK 설계 역시 프롬프트 인젝션과 데이터 유출 시도를 전제로 하며, 모델이 만든 코드를 실행하는 환경에서 자격증명을 분리하라고 권고한다.

자산	모델이 좋아질 때	투자 판단
마법 문구와 페르소나	대체되거나 무시될 가능성이 커짐	최소화
오래된 퓨샷 묶음	불필요하거나 오염을 일으킬 수 있음	평가 후 재승인
고정 다중 에이전트 조직도	조정 비용의 비중이 커짐	기본값으로 두지 않음
특정 벤더용 파싱·재시도 요령	API와 모델 교체에 취약함	격리
도구의 명확한 입출력 계약	계속 필요함	적극 투자
도메인 불변식과 단일 진실 공급원	실행량이 늘수록 중요해짐	적극 투자
실제 실패로 만든 eval	모델 교체와 회귀 비교에 유용함	매우 적극 투자
trace·provenance·결정 기록	자율성이 높아질수록 중요해짐	매우 적극 투자
권한·샌드박스·승인·롤백	피해 범위가 커질수록 중요해짐	최우선
고객·유통·가격·사용 데이터	모델이 스스로 소유할 수 없음	최우선

기획은 없어지지 않는가

기획을 하나의 직무가 아니라 네 가지 기능으로 나누면 변화가 선명해진다.

문서 생산

PRD 초안, 기능 목록, 사용자 스토리, 회의록, 티켓 분해와 일정 초안은 빠르게 자동화될 가능성이 크다.

실행 계획

작업 순서, 의존성, 마일스톤, 리스크와 테스트 계획도 상당 부분 자동화될 것이다. 다만 목표와 제약을 정확하게 제공해야 한다. 계획 자체가 없어지는 것이 아니라, 사람이 계획 문장을 모두 직접 작성할 필요가 줄어든다.

선택과 판단

다음 기능은 훨씬 오래 남는다.

어떤 문제를 풀 것인가
누구의 문제를 우선할 것인가
어떤 손실을 감수할 것인가
무엇을 만들지 않을 것인가
품질·속도·비용 가운데 무엇을 우선할 것인가
어느 정도의 증거가 있어야 출시할 것인가
틀렸을 때 누가 중단하고 책임질 것인가

모델은 후보와 분석을 만들 수 있지만, 목적함수를 저절로 정하지는 못한다. 사용자 선호, 조직 전략, 자본, 법적 책임, 브랜드 위험과 윤리적 선택은 외부에서 주어져야 한다.

현실 발견

고객 인터뷰, 결제 의사, 사용 행동, 이탈 원인, 유통 채널, 영업 관계, 현장 운영과 이해관계자 협상은 모델 내부 지식만으로 대체할 수 없다.

모델은 수집된 데이터를 해석할 수 있다. 아직 수집되지 않은 시장 정보와 신뢰 관계를 대신 소유하지는 못한다.

기획자라는 직무가 현재 모습 그대로 남는다고 단정할 수는 없다. 그러나 목표 설정, 현실 발견, 트레이드오프와 승인 책임으로 이루어진 기획 기능은 남는다.

실행력이 싸질수록 선택이 중요해진다

《Organization Science》에 게재된 현장 실험에서는 AI 능력 범위 안의 18개 현실적인 비즈니스 과제에서 AI 사용자가 평균 12.2% 더 많은 과제를 완료하고, 25.1% 더 빠르게 일했으며, 결과 품질도 높아졌다.

반대로 AI 능력 범위 밖의 과제에서는 AI 사용자가 정답을 낼 확률이 19%포인트 낮았다.

과제를 잘 선택하고 규정하면 AI가 실행을 크게 가속한다.
과제를 잘못 규정하거나 모델의 능력 경계를 넘으면 잘못된 방향으로 빠르게 달릴 수 있다.
실행 비용이 내려갈수록 문제 선택, 경계 인식과 검증 기준이 새로운 병목이 된다.

따라서 단순한 기획 문서 작성법보다 제품 판단, 시장 증거와 평가 설계를 공부하는 편이 오래간다.

변하지 않는 기술보다 모델 발전에 양의 노출을 만든다

문자 그대로 변하지 않는 기술은 거의 없다. 더 나은 질문은 다음과 같다.

모델이 좋아져도 유지되는가? → 모델이 좋아질수록 이 자산의 가치도 커지는가?

장기 가치
≈ 외부 현실 결합도
× 축적되는 고유 증거
× 검증 가능성
× 책임성

감가상각 위험
≈ 현재 모델 약점 의존도
× 벤더 종속성
× 프롬프트 문구 의존도

오래 남는 자산은 다섯 축에 모인다.

현실: 고객, 시장, 규제, 실제 시스템 상태, 비용, 지연, 장애
의도: 목표, 비목표, 우선순위, 허용 가능한 손실, 제품 원칙
증거: 사용 데이터, 실패 사례, eval, 실험 결과, 검수 기록
통제: 권한, 샌드박스, 승인, 예산, 중단 조건, 롤백, 멱등성
책임: 누가 승인하고 출시했으며 어떤 근거로 결정했는지

모델은 이 정보를 이용해 실행할 수 있지만, 모델의 파라미터가 커진다고 해서 이 정보가 저절로 생기지는 않는다.

오래 남는 투자 대상

컨텍스트 생명주기와 provenance

프롬프트 문구를 더 그럴듯하게 고치는 기능보다 정보의 출처와 소유자, 적용 범위, 충돌 여부, 실제 코드·정책과의 일치 여부, 규칙을 만든 실패와 eval, 마지막 검증 모델, 재검토 날짜와 폐기 조건을 관리하는 편이 오래간다.

검증 가능한 변경 기록

강한 에이전트는 더 많은 파일과 시스템을 빠르게 변경한다. 설명문보다 변경 의도, 불변식, 실행한 테스트와 결과, 영향 범위, 롤백 가능성, 승인 주체, 실제 산출물과 digest의 결합이 중요해진다.

실패를 학습 자산으로 바꾸는 루프

실제 trace
→ 실패 해석
→ 재현 가능한 eval
→ 검증된 변경 후보
→ 승격 또는 롤백

OpenAI의 에이전트 개선 루프도 trace, 사람과 모델의 피드백, 재사용 가능한 eval, 하네스 변경 제안을 하나의 과정으로 연결한다. 개별 프롬프트는 바뀌어도 실제 행동에서 배운 내용을 평가와 증거로 보존하는 구조는 남는다.

실행 제어면

에이전트 프레임워크 자체보다 도구 정책, 권한 분리, 승인, append-only 이벤트 기록, replay, timeout, 예산, redaction, idempotency, 출력 제한과 실행 provenance의 반감기가 길다.

하네스 반감기 관리

앞으로 유용한 도구는 하네스를 계속 추가하는 도구보다, 새 모델에서도 각 구성 요소가 필요한지 검사하고 안전하게 제거하는 도구일 수 있다.

각 지침·예시·서브에이전트·재시도 규칙에 다음 메타데이터를 붙인다.

id: reviewer-second-pass
purpose: prevent missed API compatibility regressions
introduced_for:
  model: gpt-x
  failure_case: eval/api-compat-017
validated_by:
  - eval/api-compat-017
  - eval/api-compat-031
expected_effect:
  quality_delta: 0.06
  latency_delta_ms: 8400
  token_delta: 18000
review_after: 2026-10-01
rollback: remove reviewer stage

모델을 업데이트하면 다음 순서로 재검증한다.

최소 지침의 단일 에이전트 기준선을 측정한다.
현재 전체 하네스를 측정한다.
구성 요소를 하나씩 제거해 ablation을 수행한다.
품질·안전·비용·지연을 비교한다.
각 요소를 necessary, redundant, harmful, uncertain으로 분류한다.
불필요한 요소의 삭제 변경과 검증 기록을 만든다.
새 실패가 나타나면 trace를 eval로 승격한다.

Meta-Harness 프리프린트는 소스 코드, 이전 점수와 실행 trace를 바탕으로 하네스 코드를 자동 탐색하는 방향을 보여준다. 다만 이 연구는 평가 점수 최적화에 초점을 둔다. 구성 요소의 유효기간, 안전한 삭제, 모델 업그레이드 마이그레이션과 변경 승인 기록은 여전히 별도의 문제다.

시간 낭비를 줄이는 운영 규칙

새 모델에서는 최소 기준선부터 다시 측정한다

zero/minimal
→ tool-only
→ retrieval
→ examples
→ workflow
→ multi-agent

각 단계가 실제 측정값을 높일 때만 다음 복잡성을 추가한다.

모든 지침은 실패 사례와 연결한다

어떤 실제 실패 때문에 생겼는가?
실패를 재현하는 eval은 무엇인가?
현재 모델에서 지침을 제거하면 다시 실패하는가?

“예전에 필요했던 것 같다”는 유지 근거로 충분하지 않다.

결정적인 제약은 프롬프트 밖으로 옮긴다

제약	옮길 위치
데이터 형식	스키마·타입·파서
권한	정책 코드
파일 접근 범위	샌드박스
작업 순서	상태 머신
값의 허용 범위	validation
승인	서명된 기록
회귀 방지	테스트
문서 최신성	CI

프롬프트에는 판단에 필요한 의미를 남기고, 반드시 지켜야 하는 조건은 코드로 강제한다.

예시는 버전 관리되는 데이터로 취급한다

각 예시에 대표하는 분포, 필요한 이유, 반례, 검증한 모델, 제거 전후 점수, 편향과 오염 가능성을 기록한다.

프롬프트보다 실패 코퍼스를 축적한다

오래 남는 것은 정답을 잘 내게 한 문장보다 실제 실패 입력, 기대 결과와 허용 범위, 실패 원인, 재현 환경, 검증기, 수정 전후 trace다.

하네스에 재검토 날짜를 둔다

새 모델 출시, SDK major update, 3개월 경과, 관련 eval의 기준선 3회 연속 통과, 도구 계약 변경 중 하나가 발생하면 규칙과 예시를 다시 평가한다.

예시 투자 포트폴리오

다음 배분은 연구 통계가 아니라 앞선 분석에서 도출한 전략적 예시다.

분야	예시 비중	축적할 자산
문제·고객·도메인·유통	40%	인터뷰, 실제 사용, 지불 의사, 도메인 모델, 비목표
eval·데이터·실패 증거	25%	golden set, trace, 회귀, 실제 오류 코퍼스
통제·보안·관측	20%	정책, 승인, sandbox, provenance, rollback
안정적인 도구·API 계약	10%	명확한 I/O, idempotency, 결정적 검증기
모델별 프롬프트·하네스 튜닝	5% 이하	평가에서 이득이 확인된 최소 보정

직무 이름도 같은 방향으로 바뀔 가능성이 크다.

Prompt Engineer → AI Evaluation / Reliability Engineer
Agent Framework Developer → AI Runtime / Control Plane Engineer
Context Optimizer → Context Governance Engineer
문서 중심 AI 기획 → 제품 판단·도메인·증거를 다루는 역할

최종 판단

기획은 절반은 오래 남고 절반은 자동화된다.

무엇을 만들지, 누구를 위해 만들지, 어떤 손실을 감수할지 결정하는 기능은 계속 필요하다.
PRD와 로드맵을 작성하는 현재 방식이나 별도 직무가 그대로 유지된다는 보장은 없다.
문제 발견, 제품 판단, 도메인 사실, 고객 관계, 유통, 평가 기준, 권한, 책임과 실제 증거가 더 오래 남는다.

과거의 하네스 작업도 전부 사라지는 것은 아니다.

프롬프트 문구와 역할 배치는 감가상각되는 구현물이다.
그 과정에서 발견한 실패 사례와 불변식은 장기 자산이다.
trace, eval, gate, 승인 기록과 rollback은 모델이 강해질수록 중요해진다.

모델의 현재 약점을 자산으로 만들지 않는다. 모델이 바뀌어도 남는 의도·현실·증거·통제·책임을 자산으로 만든다.

한계와 주의점

약 45%의 단일 에이전트 기준은 특정 6개 벤치마크와 실험 구성에서 얻은 선택 규칙이다. 모든 업무에 적용되는 법칙이 아니다.
퓨샷이 효과가 없다는 연구는 강한 모델의 수학적 CoT 추론을 다뤘다. 예시가 새로운 도메인 정보를 제공하는 과제에는 그대로 일반화할 수 없다.
OpenAI와 Anthropic의 개발 사례는 각 회사의 제품과 하네스 환경에서 얻은 경험이다.
Meta-Harness는 2026년 3월 공개된 프리프린트다. 동료평가를 마친 확정 결과로 보기는 어렵다.
기획 기능이 남는다는 결론이 현재의 기획자 직무나 조직 구조가 유지된다는 뜻은 아니다.
투자 비중은 연구 결과가 아니라 전략적 예시이므로 개인의 도메인과 목표에 맞게 조정해야 한다.

검증이 필요한 주장

장기적으로 기획 직무와 AI 신뢰성 관련 직무의 고용 수요가 어떻게 변할지는 아직 실증 자료가 부족하다.
모델 발전 속도에 따른 하네스 구성 요소별 실제 반감기는 장기간 추적한 데이터가 필요하다.
퓨샷 오염과 예시 순서 민감도가 최신 모델 전반에서도 같은 규모로 나타나는지 계속 재검증해야 한다.
하네스 자동 제거와 ablation이 실제 프로덕션 안전성까지 보장하는지는 별도 운영 사례가 필요하다.

Source Fidelity Notes

260개 구성, 6개 벤치마크, 5개 아키텍처, 3개 모델 계열, 약 45% 선택 기준, 94% 방향 예측과 19%포인트 감소 등 핵심 수치를 보존했다.
능력 보정형·현실 결합형 하네스 구분, 현실·의도·증거·통제·책임의 다섯 축, 기획의 네 가지 기능과 장기 가치 판단식을 유지했다.
퓨샷 검토 질문, 최소 기준선 단계, 지침 유지 기준, 결정적 제약의 이전표, 예시 관리 항목과 하네스 재검토 조건을 보존했다.
개인 이름, 경력 배경, 개인 프로젝트별 평가와 맞춤형 직업 추천은 제거했다.
원문 끝에 붙어 있었지만 본문 주장을 뒷받침하지 않는 Reuters, AP, WSJ 링크는 제외했다.
개인화된 사례를 삭제했지만 일반 결론과 판단 기준을 해석하는 데 큰 위험은 없다.