메타 9년차 AX 테크리드가 경고하는 "진짜 AX" — AI 도입과 에이전트 전환의 결정적 차이

한 문장 요약: 이 글을 읽으면 "AI 도구를 깔고 토큰을 쓰는 것"과 "조직을 에이전트 중심으로 재설계하는 것"이 왜 완전히 다른 일인지, 그리고 그 차이를 메타 현직 테크리드의 실경험 기준으로 판별할 수 있게 됩니다.

1. 개요

2. 핵심 메시지 3가지

① AX의 정의 — "에이전트가 일하도록 시스템을 설계하는 일"

사람이 하던 일을 에이전트가 대신하도록 설계하고 human-agent interface를 만드는 것이 AX입니다. 툴 구매도, 교육도 아닙니다 — 구조의 재설계입니다.

이 정의가 성립하는 이유는 단순합니다. 그동안 회사·조직·워크플로우는 모두 인간에게 초점이 맞춰져 있었습니다. 인간이 가장 중요하고 가장 차별화된 리소스였기 때문입니다. 그 전제가 흔들리는 순간, 설계 대상 자체가 바뀌어야 합니다.

② 시작점은 사람이 아니라 리더십 — "챔피언 열 명보다 결정 한 번"

"AI 잘 쓰는 똑똑한 사람 한 명 뽑아서 팀 프로세스를 바꿔야 하나요?"라는 질문이 가장 많았습니다. 답은 챔피언보다 리더십입니다. 프롬프트를 잘 써서 보고서를 빨리 만드는 일은 조직 프로세스가 그대로면 사실상 쓸모가 없습니다. 병목을 풀지 않으면 프로세스는 바뀌지 않기 때문입니다.

③ 끝은 "AI를 잘 쓰는 회사"가 아니다

"AX의 끝은 AI를 잘 쓰는 회사가 아닙니다. Human-on-the-loop 회사입니다. 그 회사는 아직 없습니다. 지금 만드는 중입니다."

3. AX를 무엇이라 정의하는가 — 그리고 무엇으로 오해되는가

한국에서 AX는 주로 AI 도입 / AI 네이티브로 해석됩니다. A는 AI 또는 에이전트, X는 트랜스포메이션을 함축하기 때문에 "AI를 도입해서 조직 문화를 바꾸는 시스템" 정도로 쓰이지만, 실제 현장에서는 대부분 도구 도입으로 축소됩니다. 임원·리더십이 "AI가 좋다던데 우리 회사도 한번 바꿔보자"고 말하는 순간 AX라는 단어가 퍼진 구조입니다.

용어 논쟁을 넘어서는 방법

"IT, DX, AI, AX… 용어는 어떻게 구분하나요?"에 대한 답은 냉정합니다. 미국에는 AX라는 단어가 없습니다. 적어도 화자의 주변에서는 그 어떤 단어도 쓰지 않습니다. 에이전트 워크플로우, AI 네이티브, 컨텍스트 엔지니어링, 하네스 엔지니어링 같은 버즈워드는 많지만 용어보다 문제의 핵심과 본질이 중요합니다.

"어떤 병목을 에이전트로 풀 것인가"에 답할 수 있으면 됩니다.

메타에서는 무엇을 AX하는가

답은 "전부 다 합니다"입니다. 사람이 하던 일을 에이전트 중심으로 바꾸는 데서 시작하기 때문에, 모든 개인·조직·팀이 가진 문제를 가져와 프로세스를 개선·탐구·시스템 설계하다 보면 다 할 수밖에 없습니다.

• 자체 하네스 · 메모리 시스템 · 툴링 · 인프라 · 애플리케이션 개발
• FDE(Forward Deployment Engineer) 를 배치해 컨설턴트처럼 각 팀 지원
• 공용 인프라 팀과 부서 지원 팀이 하나의 로드맵을 함께 설계

4. 어디서 시작하는가 — 기술이 아니라 프로세스부터

① 병목 구조를 먼저 깨는 리더십

한국의 기업이 아무리 AI를 도입하고 AX를 한다고 해도 HWP 파일을 고집한다면 프로세스는 바뀔 확률이 매우 낮습니다. 그 형식에 맞춰야 하고, 결국 같은 병목에 다시 들어가기 때문입니다. 그래서 hwp 대신 markdown — 한 번의 결정이 챔피언 열 명보다 효과적입니다.

② 지식도 인력도 부족할 때의 시작점

시작점은 "이 사람이 하고 있는 일에 가장 큰 병목이 어딘가"입니다. 일 100가지를 해서 일을 끝낸다면, 0과 100 사이에 가장 리소스가 많이 들어가는 지점이 병목입니다.

슬라이드 기준 예시: 의사결정 하나에 5명이 10시간 들이던 프로세스를 어떻게 바꿀 것인가 공략 지점: 필요성은 느끼지만 하기 귀찮은 일

• 품질 검수
• 보고서 작성 → 프레젠테이션
• 미팅 진행 및 정리

구체적으로, 미팅에서 노트테이킹을 반드시 하고 그걸 정리해 보고까지 하는데 아직도 사람이 손으로 하고 있다면 이미 꽤 늦은 것입니다. AI는 노트테이킹과 요약을 잘하기 때문에 프롬프트로 바로 쓸 수 있는 수준의 개선이 필요합니다.

③ 사내 에이전트 확산의 조건 — 자체 하네스

모든 기업은 그 기업 고유한 하네스가 어느 정도 필요합니다. 하네스는 일종의 툴킷이며, 에이전트 엔진이나 오픈소스를 포크해 모델을 중심으로 쌓아 올리는 구조를 말합니다.

④ 모델 업데이트와 충돌할 때 — "새로 깎습니다"

새 모델이 나왔다고 스킬이 갑자기 작동하지 않는 문제는 평가(Evaluation)의 일부입니다. 하네스가 바뀌면 충분히 검증하고 이밸리에이션을 한 상태에서 업그레이드해야 합니다. "새 모델이 나왔으니까 무조건 다 바꾸자"는 산으로 갈 수 있습니다. 실제로 상위 버전이 이전 버전보다 낫다는 체감이 안 되는 경우가 있는데, 사람들이 이미 클라우드·스킬·하네스를 세팅해 둔 상태에서 베이스가 바뀌어 더 나쁘게 느껴지기 때문입니다.

5. 무엇으로 측정하는가 — 채택률이 아니라 가치 창출

지표의 원칙: Business Impact

AX의 성공 지표는 Business impact입니다. 회사가 기준으로 잡는 topline metric — 가장 뚜렷한 것은 매출이며, 나머지 지표도 결국 이윤 창출의 proxy입니다.

핵심은 두 개로 수렴합니다.

토큰 사용량은 왜 지표가 아닌가

"AI를 많이 쓰고 토큰을 많이 쓰면 AI를 잘 쓰는 회사"라는 공식은 더 이상 성립하지 않는다는 것이 판명났습니다. AI를 도입하고 토큰을 대량으로 쓴 회사들의 자료를 검토한 통계에서, 실제로 더 많은 성과를 낸 회사는 5% 수준에 그쳤습니다.

산식 관점의 해석 - 토큰 사용량 ↑ ≠ 아웃풋 ↑ (비례 관계 성립하지 않음) - 따라서 측정 대상은 투입량이 아니라 동일 자원 대비 증분 가치 - 임팩트가 숫자로 바로 떨어지지 않으면 → 시간과 리소스로 내려갑니다

"가짜 도입" 판별법 — 측정 설계까지가 AX

채택률은 높은데 아웃풋이 안 바뀌는 가짜 도입을 구분하려면, 비즈니스 임팩트로 바로 드러나지 않는 영역은 프록시 메트릭을 만들어 측정해야 합니다.

지식 그래프가 나오면 "AI-native가 됐다"고 느끼지만, 딜리버리 시간·미팅 수·퀄리티·매출 같은 임팩트 지표가 훨씬 중요하며 그 측정 설계까지가 AX입니다.

6. 어떻게 유지하는가 — "AX 이후"는 없다, 개선만 있다

"컨설팅 받아 AI를 도입하고 클라우드 코드·코덱스를 쓰기 시작했습니다. 그 다음은요?"라는 질문 자체가 잘못된 AX 정의입니다. AX의 끝은 훨씬 방대한 목표 — 인간이 해온 프로세스·작업·조직까지 재구성하는 것입니다.

운영 루프 구조

① 사람이 "이거 안 되는데요", "숫자가 이상한데요"라고 보고
↓
② 그 피드백조차 시스템 안의 피드백 루프에 들어감
↓
③ 에이전트가 failure case를 픽업해 개선
↓
④ 사람에게 결재받는 구조까지 설계
↓
⑤ Human-in-the-loop 최소화 → Human-on-the-loop

프로덕션 에이전트 평가는 어떻게 하는가

평가는 실제로 시간이 가장 많이 드는 작업이며, 두 축을 모두 운영합니다.

멀티에이전트 설계도 evaluation 정의가 먼저입니다.

기준과 퀄리티 — 중구난방을 이기는 방법

AI 도입 후 개발자는 디자인을, 디자이너는 개발을, PM은 "나 다 만들어봤는데 이거 되던데"를 들고 옵니다. 이 마찰의 해법은 검증 시스템입니다.

• 첫째 — objective하고 scalable한 퀄리티 기준
• 둘째 — 디벨롭 프로세스의 적용
• 기준이 서면 포지션과 상관없이 만들고 발의할 수 있습니다

PM 100명이 모든 걸 개발자에게 떠밀면 오히려 낭비입니다. 누구나 코딩하고 디자인하되, 모두가 공평하고 체계적인 평가 기준 안에서 검증받고 소통하도록 만드는 것이 AX의 중심입니다.

보안과 데이터 접근은 AX의 가장 어려운 문제 중 하나이며, 특히 대기업일수록 많은 것을 슬로우다운시킵니다. 사내 임플로이들이 납득할 만큼 보안이 잘 설계된 인프라·플랫폼을 만드는 것이 핵심 과제입니다.

앞으로 사람의 일은 피드백 위주의 하네스 엔지니어링이 됩니다. 에이전트에게 "이렇게 하지마, 저렇게 하지마, 앞으로 이렇게 해"라고 가르치는 일입니다.

7. 커리어 — AX는 소모적인가

"AX를 하면 내 직업을 내가 대체하는 것 아니냐"는 불안에 대한 답은 완전히 반대입니다.

AX의 핵심은 병목이 어디에서, 어떤 식으로 사업이 비율적으로 돌아가고, 사람이 일할 때 프로세스의 병목이 어디서 나타나는지 정확히 짚고 솔루션을 만드는 것입니다. 그래서 AX를 배울수록 비즈니스를 더 잘 굴릴 수 있는 인재가 되고, 이 역량은 반복 사용이 가능해 어떤 비즈니스에서든 에이전틱 워크플로우를 최적화할 수 있습니다.

메타 AX 테크리드가 된 세 가지 길

해외 빅테크 AX에서 영어가 우선인 이유

"설득하지 못하면 아무것도 할 수 없습니다."

AX는 기술보다 컬처와 사람의 병목을 푸는 일이기 때문입니다. 기술 지식보다 프로세스와 비즈니스 이해가 더 필요하고, 문제 파악 → 솔루션 설계 → 그걸 파는(설득하는) 커뮤니케이션이 핵심입니다. AI 스택, 프롬프트 엔지니어링, 온/오프라인 Eval 같은 기술적 이해는 필수이지만, 비즈니스 임팩트로 연결하려면 설득이 훨씬 중요합니다.

일반 개발자의 목표

"목표는 똑같습니다." — 더 많이 실패하고(배우고), 더 많이 도전하고, 더 많이 이루는 것. 주어진 리소스로 최대 아웃풋을 내는 얼리어답터가 되는 길은 AX나 일반 개발자나 같습니다.

8. 관점 포인트 (실무 체크)

• 도구 도입과 AX를 분리해서 보고 있는가 — 컨설팅 결과가 "클라우드 코드를 이렇게 쓰시면 됩니다"로 끝난다면 그건 AX가 아닙니다.
• HWP 같은 구조적 병목을 방치하고 있지 않은가 — 형식 하나가 에이전트 도입 전체를 무력화합니다.
• 리더십이 당장의 비효율을 감수하는 Risk Taking을 했는가 — 챔피언 채용은 그 다음입니다.
• 병목 정량화가 되어 있는가 — "의사결정 1건 = 5명 × 10시간"처럼 0과 100 사이에서 리소스가 몰리는 지점을 숫자로 뽑아야 합니다.
• 임팩트가 안 나오면 시간·리소스 지표로 내리고 있는가 — 10시간→1시간, 1개월→몇 주 같은 프록시 설계까지가 AX의 업무 범위입니다.
• 하네스를 '자산'이 아니라 '살아 있는 시스템'으로 운영 중인가 — 모델 업데이트 시 검증 없는 일괄 전환은 역효과를 냅니다.
• 피드백 루프가 시스템 안에 있는가 — "숫자가 이상한데요"를 사람이 처리한다면 아직 Human-in-the-loop 단계입니다.
• 중복 제작(Re-inventing the wheel)을 막는 플랫폼이 있는가 — 스킬 마켓플레이스, 플러그인 평가 체계.
• 보안·데이터 정제 인프라가 AX 속도의 병목이 되고 있지 않은가 — 특히 대기업.
• 커리어 관점에서 "AI를 잘 쓰는 사람"이라는 인식을 밖으로 증명하고 있는가 — 팀 밖 시도·발표·사이드 프로젝트가 리크루팅으로 이어진 실제 경로입니다.

9. 최종 핵심 정리

확인해야 할 핵심 질문

1. 우리 조직의 0과 100 사이에서 가장 리소스가 몰리는 지점은 어디인가?
2. 그 지점을 에이전트가 수행 가능한 형태로 재설계했는가, 아니면 사람에게 도구를 쥐여줬는가?
3. 우리 AX 지표는 투입량(토큰·채택률) 인가, 가치 창출(매출·시간·리소스) 인가?
4. 실패 케이스를 에이전트가 픽업해 개선하고 결재받는 구조가 있는가?
5. 사람이 남는 5%의 결정은 무엇인가?

수치로 보는 AX의 방향

한 줄 요약: AI를 잘 쓰는 사람을 뽑는 것이 AX가 아니라, 에이전트가 일하도록 병목부터 조직과 컬처까지 다시 설계하는 것 — 그리고 그 끝에는 사람이 5%의 핵심 결정에만 집중하는 Human-on-the-loop 회사가 있습니다.