개요
대부분의 팀이 2026년 가장 수요가 많은 스킬셋에서 잘못 알고 있는 것과 AI 에이전트 구현에서 배운 교훈을 공유합니다.
교훈 1: AI 에이전트 구축은 실제로 먼저 AI 에이전트를 구축하는 것이 아닙니다
진짜 작업은 단일 프롬프트를 작성하기 전에 일어납니다
McKinsey의 50개 이상 기업 구현 분석은 대부분의 팀이 완전히 놓치는 것을 밝혀냈습니다: 성공적인 AI 에이전트는 기술적 정교함 위에 구축되지 않습니다. 워크플로우 이해 위에 구축됩니다.
우리는 “AI 에이전트를 구축하자”로 시작하지 않습니다. “여기서 실제로 어떻게 작업이 이루어지는지 이해하자”로 시작합니다.
근본적인 단절
팀에 임베드할 때, 우리는 반복적으로 동일한 패턴을 발견합니다: 문서화된 프로세스와 실제 작업은 완전히 다른 두 가지입니다.
일반적인 시나리오를 살펴보겠습니다:
공식 문서:
- 깔끔하고 선형적인 프로세스
- 명확한 단계별 절차
- 잘 정의된 의사결정 지점
실제 현실:
- 진짜 의사결정은 부서 간 30초 비공식 대화에서 일어남
- 중요한 평가는 수년간 개발된 패턴 인식에 의존하며, 사람들의 마음속에만 존재하고 절대 기록되지 않음
- 시스템이 엣지 케이스를 플래그하면, 경험 많은 팀원들은 여러 데이터 소스와 판단 요청을 포함하는 완전히 문서화되지 않은 해결 방법을 가지고 있음
이 중 어느 것도 프로세스 문서에 없었습니다. 하지만 모두 AI 에이전트가 실제로 작동하는 데 필수적이었습니다.
대부분의 팀이 잘못된 것을 구축하는 이유
대부분의 AI 에이전트 구현이 실패하는 이유는 팀이 표면 절차를 운영 현실로 착각하기 때문입니다. 실제 작업이 일어나는 상호 연결된 워크플로우 생태계 대신 문서, 해피 패스, 격리된 작업을 기반으로 에이전트를 구축합니다.
이는 데모에서는 작동하지만 실생활에서는 고장 나는 에이전트를 만듭니다.
문제는 기술이 아닙니다 - 운영 현실에 대한 이해가 문제입니다.
구축할 것을 정의하는 4가지 작업 인텔리전스 계층
단일 시스템 지시사항을 작성하기 전에, 실제로 작업이 수행되는 방식의 이 4가지 계층을 매핑해야 합니다:
계층 1: 표면 절차
공식 플레이북이나 SOP (대부분의 AI 프로젝트가 멈추는 곳).
예시:
1. 고객 요청 접수
2. 티켓 카테고리 할당
3. 적절한 팀에 라우팅
4. 24시간 내 응답
계층 2: 운영 현실
해결 방법과 “우리는 실제로 이렇게 합니다” 규칙.
실제로 일어나는 일:
- 경험 많은 직원이 컨텍스트에 따라 특정 케이스를 다르게 라우팅하는 이유
- 문서화되지 않은 우선순위 규칙
- 부서 간 비공식 커뮤니케이션 채널
계층 3: 컨텍스트 인텔리전스
직무에서 수년 후 전문가가 개발하는 직관.
에이전트가 진짜 잘해야 하는 것:
- “이게 옳지 않다”는 느낌의 정의
- 패턴 인식 능력
- 뉘앙스 있는 판단 요청
계층 4: 문화적 DNA
의사결정을 형성하는 가치와 규범.
에이전트가 어떻게 행동해야 하는지 결정:
- 무엇을 해야 하는지뿐만 아니라
- 어떻게 해야 하는지
- 어떤 가치를 우선시해야 하는지
실제로 작동하는 사전 구축 발견 프로세스
다음은 어떤 종류의 에이전트를 구축해야 하는지, 그리고 애초에 구축해야 하는지를 결정하는 전술적 접근 방식입니다:
1. 위기 지점에서 임베드하기
정상 운영 중에 관찰하지 마세요. 다음 상황에서 사용자를 섀도잉하세요:
- 시스템이 다운되었을 때
- 가장 복잡한 케이스를 처리할 때
- 문서화된 프로세스가 완전히 실패할 때
왜? 진짜 중요한 것을 볼 수 있는 때입니다.
2. 보이지 않는 네트워크 매핑하기
다음을 문서화하세요:
- 막혔을 때 사람들이 실제로 누구에게 묻는지
- 그 사람들이 무엇을 답하는지
- 비공식 커뮤니케이션 패턴
실제 사례: 한 참여에서 고객 피칭 관련 내부 의사결정 프로세스가 완전히 문서화되지 않았다는 것을 발견했습니다. 그 인사이트가 우리가 구축한 것을 완전히 바꿨습니다.
3. 의사결정 뒤의 “왜” 포착하기
사람들이 무엇을 하는지만 문서화하지 말고 의사결정 트리를 이해하세요.
질문할 것:
- 전문가가 “이게 옳지 않다”고 말할 때, 어떤 패턴을 인식하고 있나요?
- 무엇이 그 판단을 유발하나요?
- 어떤 데이터 포인트가 중요한가요?
이것이 에이전트가 복제해야 할 인텔리전스가 되며, 단순히 완료해야 할 작업이 아닙니다.
이것이 구축하는 것을 어떻게 바꾸는가
이 수준에서 작업을 이해하면, 더 나은 에이전트를 구축하는 것이 아니라 근본적으로 다른 시스템을 구축합니다:
작업 자동화 대신:
- 작업이 어떻게 수행되는지의 비밀 소스를 코드화
프로세스 복제 대신:
- 비즈니스를 이해하는 것처럼 느껴지는 의사결정 지원 구축
더 중요한 것은:
- 최고 성과자의 머리에 잠겨 있던 경쟁 우위를 포착하고 전체 운영에 걸쳐 확장
💡 핵심 인사이트: 이 발견 프로세스는 단순한 준비 작업이 아닙니다. 전략 작업입니다. 이러한 계층에서 발견하는 것이 에이전트를 어떻게 구축할지뿐만 아니라 실제로 어떤 비즈니스 문제를 해결하고 있는지를 결정합니다.
교훈 2: 평가 우선이 에이전트 우선을 이깁니다
대부분의 팀이 거꾸로 구축합니다 (그리고 일부는 무엇을 놓치는지조차 모릅니다)
대부분의 팀이 취하는 접근 방식:
에이전트 구축 → 몇 가지 예제로 테스트 → "괜찮아 보이면" 배포
→ 프로덕션에서 왜 고장 나는지 궁금해합니다
McKinsey의 연구는 평가를 신뢰 구축과 실패 방지에 중요하다고 식별했습니다. 하지만 우리가 정말 강조하고 싶은 것은: 평가는 단순한 품질 관리가 아니라, 에이전트를 실제로 작동하게 만드는 인텔리전스를 포착하는 방법입니다.
평가(Evals)란 실제로 무엇인가?
**평가(또는 “evals”)**는 AI 시스템이 좋은 출력을 생성하는지 측정하는 체계적인 방법입니다.
대부분의 사람들은 여기서 멈추고 최종 체크포인트처럼 취급합니다: “출시하기에 충분히 잘 작동하나요?”
하지만 성공적인 실무자들이 이해하는 것:
당신의 평가 작업이 에이전트 전략입니다.
대부분이 놓치는 중요한 인사이트
AI 에이전트가 자율적으로 작동할 때, 단순히 낮은 성능의 위험이 아니라 예측하거나 제어할 수 없는 시스템으로 조직적 책임을 만들고 있습니다.
전통적인 소프트웨어는 예측 가능하게 실패합니다. AI 에이전트는 창의적으로 실패할 수 있습니다. 당신이 예상하지 못한 방식으로.
실제 위험:
- 고객 서비스 에이전트가 잘못된 정보 제공
- 문서 처리 시스템이 중요한 데이터 잘못 분류
- 판매 지원 도구가 마진을 잠식하는 가격 오류 발생
모두 누군가 패턴을 알아차리기 전에 대규모로 작동합니다.
대부분의 팀이 이것을 잘못하는 이유
대부분의 팀은 평가를 사후 고려사항으로 접근합니다:
잘못된 접근:
1. 프롬프트 작성
2. 몇 가지 예제로 테스트
3. "괜찮아 보이면" 배포
4. 프로덕션에서 왜 고장 나는지 궁금해함
해야 할 것:
1. 도메인에서 "좋음"이 실제로 어떤 모습인지 정의
2. 그 품질을 측정하는 체계적인 방법 만들기
3. 해피 패스 예제뿐만 아니라 수백 가지 시나리오에 대해 테스트
4. 그 인사이트를 사용하여 시스템의 모든 부분 개선
이러한 접근 방식 간의 격차가 대부분의 AI 구현이 데모에서는 인상적이지만 실제 현실에서는 평범한 이유입니다.
평가 성숙도의 3가지 수준
대부분은 레벨 1에서 작동하며 더 정교한 접근 방식이 경쟁 우위를 만든다는 것을 깨닫지 못합니다:
레벨 1: 기본 품질 관리 (모두가 하는 것)
일반적인 정확도 메트릭과 간단한 통과/실패 테스트.
예시: “에이전트가 80% 정확도로 문서를 처리했나요?”
레벨 2: 비즈니스 가치 연결 (작동하는 것)
시스템 성능이 실제 비즈니스 결과와 어떻게 일치하는지 측정.
예시: “에이전트가 실제 비즈니스 의사결정에 중요한 패턴을 발견했나요?”
레벨 3: 대규모 전문성 인코딩 (당신의 경쟁 우위)
최고 성과자의 직관을 구조화된 평가 시스템으로 포착하고 확장.
여기서 평가가 전략이 됩니다.
레벨 3가 모든 것을 바꾸는 이유
최고 성과자가 문제가 있는 케이스를 즉시 발견할 수 있는 팀과 작업한다고 가정해봅시다.
그 이유를 이해하는 것은 단순히 테스트 케이스를 만드는 것이 아닙니다.
그 인사이트가 AI 에이전트 설계를 알리는 인텔리전스가 됩니다:
- 시스템 지시사항: 전문가 의사결정 패턴으로 인코딩됨
- 컨텍스트 선택: 전문가가 실제로 사용하는 데이터 포인트 강조
- 훈련 예제: 전문가 수준의 패턴 인식 시연
이것이 순환 인텔리전스를 만듭니다:
더 나은 평가 → 더 나은 접근 방식 발견
→ 더 나은 출력 생성 → 더 나은 평가 기준 학습
평가가 당신의 경쟁 우위입니다
누구나 동일한 AI 모델에 액세스할 수 있으므로, 기본 기술이 경쟁 우위가 아니라면 무엇이 우위인가요?
AI 능력의 상품화는 경쟁 우위가 평가 전문성으로 이동한다는 것을 의미합니다.
평가 프레임워크가 포착하고 확장하는 것:
- 최고 성과자와 평균 성과자를 구분하는 것
- 모범 사례와 재앙의 차이
- 평범한 결과 대신 예외적인 결과를 일관되게 만드는 방법
이것은 단순한 측정이 아닙니다. 경쟁자가 복제할 수 없는 조직 인텔리전스의 체계적 포착입니다.
이 과정을 통해 당신의 비밀 소스를 포착하고 확장하고 있습니다.
전술적으로 의미하는 것
→ 현재 ‘분위기 체크’를 통해 AI 출력을 테스트하고 작동하기를 바라고 있다면: 도메인 전문성을 포착하는 체계적인 평가 프레임워크가 필요합니다.
→ 기본 정확도 메트릭을 측정하고 있다면: 특정 컨텍스트에서 예외적인 성능이 실제로 어떤 모습인지 식별해야 합니다.
→ 평가를 최종 품질 체크로 취급하고 있다면: 평가가 지속적인 개선을 주도하는 순환 시스템이 필요합니다.
교훈 3: 조기 일반화가 좋은 에이전트를 죽입니다
”한 번 구축, 모든 곳에서 사용” 함정
McKinsey의 연구는 대규모 효율성을 주도하기 위한 재사용 가능한 컴포넌트의 중요성을 강조했습니다. 우리는 “그렇습니다. 그리고 타이밍이 중요합니다”라고 말합니다.
대부분의 팀이 빠지는 타이밍 함정: 첫날부터 “재사용 가능”하게 구축하려고 하다가 모든 곳에서 제대로 작동하지 않는 일반적인 도구로 끝납니다.
우리는 이 패턴을 지속적으로 봅니다: 팀이 AI의 잠재력에 흥분하여 즉시 “우리의 모든 부서에서 어떻게 작동하게 만들 수 있을까?”라고 생각합니다. 그들은 예외적인 솔루션 대신 광범위한 솔루션을 구축합니다.
일반적으로 시작하는 것이 평범함을 보장하는 이유
실제로 작동하는 것:
1. 먼저 한 사람 또는 한 팀의 특정 워크플로우를 위해 구축
2. 그들의 하루를 10배 더 좋게 만들기
3. 그런 다음 다른 곳에 적용할 수 있는 패턴 추출
이유는 간단합니다: 깊이 이해하지 못하는 것을 일반화할 수 없습니다.
처음부터 “모든 사람”을 위해 구축하려고 하면, 특정한 누구를 위한 것도 아닌 것을 구축하게 됩니다.
인텔리전스 포착 문제
모든 고성능 워크플로우는 특정 인텔리전스를 포함합니다:
- 엣지 케이스 처리
- 컨텍스트 의사결정
- 전문가가 수년간 개발한 “이게 옳지 않다”는 패턴 인식
일반적으로 구축하면, 이 인텔리전스를 완전히 놓칩니다.
명백한 것은 처리하지만 판단이 필요한 것은 실패하는 에이전트가 됩니다.
하지만 먼저 한 특정 전문가를 위해 구축하면, 그들의 의사결정 패턴을 포착합니다.
그 인텔리전스가 당신이 구축하는 다른 모든 것의 기초가 됩니다.
이 접근 방식은 더 나은 AI 에이전트를 만들 뿐만 아니라, 복제하기 어려운 경쟁 우위를 만듭니다.
경쟁자는 당신의 기술을 복사할 수 있지만, 최고 성과자로부터 포착한 특정 워크플로우 인텔리전스는 복사할 수 없습니다.
2025-2026 스킬셋 기회
Forward-Deployed Engineer의 부상
YC의 채용 게시판은 “Forward-Deployed Engineer” 역할을 채용하는 100개 이상의 스타트업을 보여줍니다. 불과 3년 전만 해도 0개였습니다.
하지만 그들이 정말 찾는 것은 무엇일까요?
우리가 공식 이름이 생기기 훨씬 전부터 **새로운 AI 실무자(최근에는 Forward Deployed AI 실무자)**라고 불러온 것입니다.
AI 에이전트를 초기에 구축하면서
슬픈 데모가 실제 사용에서 붕괴되는 동일한 패턴을 반복해서 봤습니다.
컨설턴트는 회의실에 앉아 요구사항을 수집했지만:
- 진짜 워크플로우(엣지 케이스와 판단 요청으로 가득한)는 현장에서 일어났습니다
그래서 우리는 다르게 임베드했습니다:
- 가장 이상한 케이스를 처리하는 사람을 섀도잉
- 예외적일 때까지 하나의 중요한 워크플로우를 위해 설계
우리가 나중에야 깨달은 것은 Palantir가 이것을 “Forward-Deployed Engineering”으로 공식화했다는 것입니다.
하지만 우리에게는 필요성에서 태어났습니다: 작업 자체를 깊이 이해하지 않고는 예외적인 에이전틱 워크플로우를 구축할 수 없습니다.
Forward-Deployed AI 실무자
Palantir의 forward-deployed 엔지니어는 데모를 판매하지 않았습니다 - 내부에서 직무를 이해할 때까지 팀에 임베드했습니다. 그런 다음 템플릿이 아닌 현실을 반영하는 시스템을 가지고 돌아왔습니다.
그것이 “돈 가져가세요” 순간을 촉발한 것입니다.
그들이 실제로 하는 일
1. 비밀 소스 추출
도메인 전문가를 예외적으로 만드는 것 발견 - 매뉴얼이 절대 포착하지 못하는 암묵적 지식.
2. 의사결정 로직 표면화
전문가는 종종 무언가가 이상하다는 것을 왜 아는지 설명할 수 없습니다.
실무자는:
- 그 직관을 패턴과 의사결정 트리로 분해
- 확장 가능하게 만들기
3. 현실 기반 시스템 설계
문서에서 설계하는 대신, 임베드된 관찰에서 구축:
- 워크플로우가 실제로 전개되는 방식 매핑
- 실패, 예외 등 모두 포함
이것이 “돈 가져가세요” 효과를 촉발하는 이유
이 수준의 이해에서 설계된 시스템은 일반적으로 느껴지지 않습니다.
작업을 이해하는 누군가가 구축한 것처럼 느껴집니다.
결과는 단순한 자동화가 아닙니다:
- 모범 사례를 확장하는 능력
- 경쟁 우위 포착
이 역할이 지금 중요한 이유
이것은 단순한 또 다른 “AI 직무” 트렌드가 아닙니다.
세 가지 가속화 forces의 교차점에 있습니다:
- AI 상품화: 모델은 널리 사용 가능 - 구현의 전문성이 차별화 요소
- 구현 격차: 대부분의 조직은 채택에서 훨씬 뒤처져 있음
- 워크플로우 복잡성: 현대 작업은 적절하게 설계된 AI만 처리할 수 있는 뉘앙스로 계층화됨
실무에서 어떻게 보이는가
Forward-Deployed AI 실무자는 “AI가 무엇을 할 수 있나요?”로 시작하지 않습니다.
“이 도메인에서 우수성은 어떤 모습인가요?”로 시작합니다 - 그런 다음 역으로 작업하여 그것을 확장하는 시스템을 설계합니다.
그것이 진짜 시장 신호입니다. 그리고 점점 더 커지고 있습니다.
핵심 요점 요약
교훈 1: 워크플로우 이해가 먼저
하지 말아야 할 것:
- 문서만 보고 에이전트 구축
- 표면 절차를 운영 현실로 착각
- 해피 패스에만 집중
해야 할 것:
- 위기 지점에서 임베드
- 4가지 작업 인텔리전스 계층 매핑
- 보이지 않는 네트워크와 비공식 프로세스 발견
교훈 2: 평가가 전략
하지 말아야 할 것:
- 평가를 사후 품질 체크로 취급
- 기본 정확도 메트릭에만 의존
- 몇 가지 예제로만 테스트
해야 할 것:
- 레벨 3 평가 성숙도 목표
- 최고 성과자의 전문성 포착
- 평가를 순환 개선 시스템으로 사용
교훈 3: 작게 시작, 특화하기
하지 말아야 할 것:
- 첫날부터 모든 부서를 위해 구축
- 워크플로우 인텔리전스 없이 일반화
- 특화보다 범위 우선시
해야 할 것:
- 한 전문가를 위해 먼저 구축
- 그들의 의사결정 패턴 포착
- 패턴 추출 후 확장
Forward-Deployed AI 실무자가 되기
필요한 스킬
-
기술적 능력
- AI/ML 기초 이해
- 워크플로우 자동화 도구
- 시스템 통합
-
도메인 전문성 추출
- 심층 인터뷰 기술
- 프로세스 매핑
- 패턴 인식
-
시스템 사고
- 홀리스틱 워크플로우 이해
- 엣지 케이스 예측
- 확장 가능한 설계
경력 기회
- 스타트업: 100+ YC 기업 채용 중
- 기업: AI 변환 리더 필요
- 컨설팅: 전문 AI 구현 서비스
- 자체 벤처: 산업별 솔루션 구축
관련 리소스
마무리
AI 에이전트 구축의 미래는 기술이 아니라 이해에 관한 것입니다.
성공적인 조직은:
- 워크플로우를 깊이 이해합니다
- 전문성을 체계적으로 포착합니다
- 특화에서 시작하여 확장합니다
시작 위치:
- 한 중요한 워크플로우 식별
- 최고 성과자를 섀도잉
- 그들의 의사결정 패턴 매핑
- 작고 예외적으로 구축
기억하세요: 경쟁 우위는 AI 모델에 있지 않습니다. 작업이 실제로 어떻게 수행되는지에 대한 이해와 그 이해를 확장 가능한 시스템으로 코드화하는 능력에 있습니다.