AX는 도입이 아니라 운영입니다 — 스레드에 쏟아진 질문들에 답합니다

지난주 스레드에 짧은 글을 하나 올렸습니다.

메타에는 AX만 하는 조직이 있습니다. 운이 좋게도 저는 그 조직에서 테크리드(TL)로 일하고 있습니다. 무엇이든 물어봐주신다면, 답변 가능한 선에서 최대한 답변드려보겠습니다.

이틀 만에 48,000회 넘게 읽혔고, 100개가 넘는 질문과 댓글이 달렸습니다. LG전자에서 AX를 하는 엔지니어, 웹 에이전시 기획자, 게임회사 개발자, 사내 FDE, AX 교육자, 스타트업 리더 — 질문하는 자리도, 걱정도 전부 달랐습니다.

그런데 질문들을 한자리에 모아 놓고 보니, 서로 다른 언어로 같은 것을 묻고 있었습니다. 이 글은 그 질문들을 주제별로 묶어 다시 답하는 기록입니다. 질문은 여러 개를 합쳐 다듬었고, 답은 스레드에서 했던 답변을 기반으로 조금 더 길게 풀었습니다.

결론부터 말씀드리면 이렇습니다. AX는 AI 도입 프로젝트가 아니라, 컬쳐와 오퍼레이션 프로세스의 재정의입니다. 아래의 모든 답변은 이 한 문장의 각주에 가깝습니다.

AX는 시스템을 설계하는 일입니다

Q. AX를 무엇이라고 정의하시나요?

사람이 하던 많은 일들을 에이전트가 대신할 수 있도록 시스템을 설계하고, human-agent interface를 만드는 일입니다. 툴을 사주는 일이 아닙니다. 교육을 시키는 일도 아닙니다. 일이 흘러가는 구조 자체를 다시 설계하는 일입니다.

Q. IT, DX, AI, AX — 용어가 너무 많습니다. 어떻게 구분하나요?

미국에서는, 적어도 제 주변에서는, 위의 어떤 단어도 쓰지 않습니다. AX라는 단어는 신기하게도 한국에서만 쓰입니다. 용어의 구분보다 중요한 것은 문제의 핵심과 본질입니다. "우리 조직의 어떤 병목을 에이전트로 풀 것인가"에 답할 수 있다면, 그 일을 무엇이라 부르는지는 중요하지 않습니다.

Q. 메타에서는 어떤 것들을 AX하나요? AX팀은 직접 만드는 팀인가요, 지원하는 팀인가요?

전부 다 합니다. 하네스, 메모리/컨텍스트, 툴링, 인프라, 애플리케이션, 그리고 각 팀에 들어가는 FDE(Forward Deployed Engineer)까지. 공용 인프라에 투자하는 팀과 각 부서를 돕는 팀이 서로 소통하며 하나의 로드맵을 같이 만들어갑니다. 사내 FDE의 일을 한 줄로 줄이면 — 각 팀의 성공지표를 돕는 일입니다.

기술의 도입이 아니라 프로세스의 변화입니다

Q. AX 챔피언을 세워야 하나요, AX팀이 조직에 직접 들어가야 하나요?

AX는 기술의 도입보다는 프로세스의 변화입니다. 컬쳐에 더 가깝습니다. 그래서 "AX 챔피언"보다 리더십의 디렉션이 더 중요합니다. 당장의 비효율이 생기더라도 AI-native 방식을 채택하고 시도해보는, 리더십의 risk taking이 필요합니다.

예를 들어 한국에서는 아직 .hwp 파일을 많이 씁니다. hwp를 고집하면서 AX 혁신을 이뤄내기는 어렵습니다. "우리 이제 보고서를 markdown으로 받아보자, 그리고 하나씩 개선해 나가보자"라고 리더십이 정해주는 것 — 그 한 번의 결정이 챔피언 열 명보다 효과적입니다.

Q. 어디서부터 시작해야 하나요?

AX의 목표 정의가 먼저입니다. 문제를 해결하는 프로세스의 병목이 무엇인지 파악하고, 그것을 어떻게 개선할지에서 시작합니다. "한 가지 의사결정을 위해 5명이 최소 10시간을 들여야 했던 프로세스를 어떻게 바꿀 것인가" — 이런 질문이 AX의 시작점입니다.

공략할 곳도 정해져 있습니다. 모두가 pain point라고 느끼는 부분, 그중에서도 "필요성은 느끼지만 하기 귀찮은 일"입니다. 그것을 해결했을 때 내부 반응이 가장 좋습니다.

Q. 사내 에이전트는 어떻게 시작되고, 어떻게 확산되나요?

집중적인 투자, 사용성, 그리고 브랜딩입니다. 가장 중요한 것은 사람들이 가진 가장 큰 병목이 무엇인지 파악하고 그것부터 설계하는 일입니다. 비개발자에게 "클로드 코드 쓰세요"라고 말하는 것에는 결국 한계가 있습니다.

그리고 모든 회사는 자체 하네스가 필요하다고 생각합니다. 서드파티 하네스는 회사 내부 툴과의 연동성과 behavioral control에서 떨어질 수밖에 없습니다. 사내 에이전트는 거기서 출발합니다.

Q. 기존의 PI 컨설팅과는 다른 방식인가요?

크게 다르지 않습니다. 문제를 푸는 과정은 비슷합니다. 다른 점이 있다면 틀에 갇히지 않고, 과감하되 유연한 시도를 훨씬 많이 한다는 것입니다. 기존 개발팀과 AX팀의 차이도 같습니다 — 전체적으로는 비슷하지만 더 열려 있고 더 과감합니다. 빠르게 시도하고, 바꿔 나가고, 좋은 것들을 쌓아갑니다.

궁극의 목표는 가치 창출입니다

Q. AX 도입의 성공지표를 어떻게 설정하나요?

결국 business impact로 측정해야 합니다. 회사가 기준으로 잡는 topline business metric이 있습니다. 가장 뚜렷한 것은 역시 매출입니다. 모든 비즈니스는 이윤 창출을 위해 설립되었고, 나머지 topline metric도 결국 이윤 창출에 대한 proxy입니다.

Q. 툴 채택률은 높은데 아웃풋이 안 바뀌는 '가짜 도입'은 어떻게 보시나요?

실재합니다. Second Brain과 Obsidian만 봐도 알 수 있습니다. 지식 그래프가 딱 나왔을 때, 많은 사람들이 "나는 이제 AI-native가 됐고 생산력이 늘었다"고 느낍니다. Adoption도 많았습니다. 틀린 이야기는 아닙니다 — 컨텍스트 엔지니어링에서 개인화된 knowledge graph는 필수가 되어가고 있습니다. 하지만 그것이 있다고 모두의 생산력이 좋아지는 것은 아닙니다.

궁극적인 목표는 가치 창출입니다. 엔드투엔드 프로젝트 딜리버 시간이 얼마나 줄었는가. 사람 간의 미팅 수가 얼마나 줄었는가. 프로덕트 퀄리티가 얼마나 올라갔는가. 같은 인력으로 매출을 얼마나 더 냈는가. 채택 지표가 아니라 이런 임팩트 지표가 훨씬 중요합니다. 물론 측정이 어렵습니다. 그 measurement를 설계하는 것까지가 AX의 일부입니다.

Q. 그 임팩트가 객관적인 수치로 안 떨어지면요?

그래서 AX가 어렵습니다. 임팩트 측정이 어렵다면 두 가지로 내려갑니다. 시간을 얼마나 아꼈는가. 리소스 — 사람과 돈 — 를 얼마나 아꼈는가.

Q. 눈에 띄는 성과가 없다면 돈만 쓰는 조직 아닌가요?

그렇기에 이 조직이 존재합니다. 유의미한 성과는 분명 있습니다. 다만 부분적입니다. 지금은 회사 전체가 transform할 수 있는 방법에 집중하고 있습니다.

AX에는 '이후'가 없습니다

Q. AX 이후의 유지보수는 어떻게 하나요? 자동화해 놓아도 결국 문제가 생기던데요.

"AX 이후"라는 말부터 다시 보게 됩니다. AX는 한 번 하고 끝나는 일이 아닙니다. 진정한 AX의 끝은, 대부분의 운영과 결정을 에이전트가 주도하고 반드시 필요한 상황에만 인간이 개입하는 human-on-the-loop 시스템입니다.

그래서 중요한 것은 유지보수가 아니라 피드백 루프입니다. 스스로 개선해 나가는 시스템을 어떻게 구성할 것인가. "유지보수"에 해당하는 failure case의 처리도 이미 AX 시스템 안에 설계되어 있어야 합니다. 누군가 "여기 리포트 숫자가 좀 이상한데?"라고 말하는 순간, 에이전트가 그것을 픽업해서 시스템 자체를 개선하고 사람에게 결재를 받는 구조 — 거기까지가 설계 범위입니다.

Q. 프로덕션에 올라간 에이전트의 평가는 어떻게 하나요?

Online eval과 offline eval 둘 다 필요합니다. 자체적인 qualitative eval(UXR)도 합니다. User feedback loop와 in-app survey도 당연히 중요합니다. 에이전트를 발전시키는 근거는 결국 이 평가 체계에서 나옵니다. 멀티에이전트로 나눌지, 툴을 어떻게 관리할지 같은 설계 질문도 마찬가지입니다 — evaluation을 어떻게 정의하는가가 먼저입니다.

Q. 모델이 업데이트될 때마다 기존 하네스와 부딪히면요?

기존 하네스를 새로 깎아야 합니다. 하네스는 한 번 만들고 끝나는 자산이 아니라, 모델과 함께 계속 깎아 나가는 살아 있는 시스템입니다.

기준과 퀄리티가 중심 과제입니다

Q. 바이브코딩으로 만든 결과물을 개발자와 디자이너가 꺼립니다.

퀄리티 컨트롤과 컬쳐의 문제입니다. 개발자가 바이브코딩을 무시하는 일은 이제 거의 없다고 봅니다. 아직 반감이 있는 사람들도 머지않아 납득할 수밖에 없는 상황이 옵니다. 디자인도 마찬가지입니다.

중요한 것은 두 가지입니다. 첫째, 어떤 기준으로 퀄리티를 평가할 것인가 — objective하고 scalable하게. 둘째, 디벨롭 프로세스를 어떻게 바꾸고 적응할 것인가. 첫째가 확실하면 둘째는 쉬워집니다. 기준이 확실하면 포지션과 상관없이 만들고 발의할 수 있게 됩니다. 그 과정에서 검열과 리뷰 비용이 너무 커진다면, 그 비용을 줄이는 프로세스 재설계가 둘째의 일입니다.

Q. 팀마다, 개인마다 다른 툴과 스킬을 만들어 쓰니 중구난방입니다.

저마다 다른 스킬과 툴을 쓰면 퀄리티 컨트롤이 낮아지고, 리소스가 분산되고, 남의 결과물을 이해하고 리뷰해야 하는 더 큰 병목이 생깁니다. 회사 또는 팀 단위의 공용 plugin(하네스, hooks, skills, memory), 그리고 표준화된 프로세스 — 디자인은 이 스킬로, 리뷰는 이 방식으로 — 가 필수입니다. "기준"과 "퀄리티"를 만들고 거기에 집중 투자하는 것이 AX의 중심 과제입니다.

Q. 정보 접근 권한과 보안 문제는 없나요?

AX의 가장 어려운 문제 중 하나가 security와 privacy입니다. 정보는 많을수록 도움이 됩니다. 하지만 그렇다고 무작정 모두 가져다 쓸 수는 없습니다. 여러 리뷰와 검증을 거치고, 사용자가 납득 가능한 프로덕트와 프로세스를 만드는 것 — 어렵지만 그래서 중요합니다. 여기서도 결정을 내리는 리더십의 스탠스가 가장 중요합니다.

Q. AI가 쓴 글에서 AI 느낌을 빼려면 어떻게 하나요? 코딩 에이전트 결과물은 손볼 곳이 많은데요.

같은 답입니다. 하네스 엔지니어링 — rules, skills, context, hooks를 잘 깎는 일입니다. 모델에게 정확한 지시와 예시를 주어야 합니다. 틀어진 것을 손볼 때마다 "이렇게 하지 말 것을 기억하고 메모리에 저장해"라고 말하는 것과 같은 원리입니다. 결국 프롬프트 엔지니어링이고, 그 축적이 하네스입니다.

Q. 이런 것도 결국 AI한테 배우시죠?

물론입니다. 하지만 AI가 모든 것을 알려주지는 않습니다. 지금 처한 상황과 현존하는 프로세스, 오퍼레이션, 도메인 지식에 기반해 솔루션을 만들고 깎아 나가는 과정은 결국 사람 중심입니다.

결국 사람의 문제를 푸는 일입니다

Q. AX는 코어 기술이나 핵심 비즈니스와 거리가 있는, 소모적인 커리어 아닌가요?

완전히 반대라고 생각합니다. AX는 비즈니스 운영 그 자체입니다. 코어 비즈니스를 생각하지 않은 AX는 처음부터 방향이 잘못된 것입니다. 목표 수준과 기한도 정할 수 없습니다 — AX의 끝은 완전한 에이전트 자동화와 human-on-the-loop 설계이고, 결코 쉬운 목표가 아니기 때문입니다. 그래서 AX의 역량 또한 비즈니스와 사람에 대한 이해에서 옵니다.

Q. 메타에서 AX 테크리드로 일하려면 어떤 커리어패스를 밟아야 하나요?

세 가지로 정리해봅니다.

1. Track record와 reputation — 저는 메타 9년차이고, 한 팀에서만 일해왔습니다. 열심히 일했고, 운 좋게 성과도 여러 번 냈습니다.
2. Risk taking과 AI-native — 저는 원래 광고팀이었습니다. 하지만 언제나 AI와 에이전트에 관심을 두고, 팀과 관련 없는 일에도 도전하고, 글을 쓰고, 플러그인을 만들고, 회사 안에서 열심히 팔았습니다.
3. Leadership과 action-driven — AI 쪽은 전문가가 많으면서도 많지 않습니다. 인더스트리 전체의 새로운 과제라서 그렇습니다. 어려운 문제에 집중력과 끈기를 갖고, 열정 있는 사람들을 모아 슬기롭게 풀고자 했습니다.

Q. AX 팀을 꾸릴 때 가장 중요한 능력은 무엇인가요?

정답은 없지만, 첫째는 리더십입니다. 다음은 도메인 지식. 그다음은 문제 해결 능력이라는 카테고리 안의 여러 가지 — 지능, 끈기, 열정, 도전정신, 커뮤니케이션입니다.

Q. 해외 빅테크 AX로 가고 싶습니다. 영어가 우선인가요? 모델 지식과 실전 능력 중에는요?

AX는 기술보다 컬쳐와 사람의 병목을 푸는 일에 가깝습니다. 그래서 영어와 커뮤니케이션 스킬은 필수입니다. 클라이언트를 설득하지 못하면 아무것도 할 수 없습니다. 지금의 AX는 테크니컬한 지식보다 프로세스와 도메인, 비즈니스에 대한 이해가 더 필요합니다.

Q. AX로 일자리가 불안해진 구성원들의 저항은 어떻게 하나요?

쉽지 않은 문제입니다. 다만 불안함과 두려움 때문에 현실을 회피할 수는 없습니다.

Q. 일반 개발자는 무엇을 목표로 삼아야 하나요?

목표는 똑같습니다. 더 많이 실패하고(배우고), 더 많이 도전하고, 더 많이 이루는 것입니다.

딸깍의 반대편

가장 기억에 남는 질문은 이것이었습니다. "앞으로 딸깍 하면 다 만들어주는 AI가 나올 텐데, AX 팀원들은 개인적으로 뭘 준비하고 있나요?"

제 답은 짧았습니다. 그 딸깍 버튼을 더 잘 만들고자 합니다.

딸깍 버튼은 저절로 생기지 않습니다. 누군가 병목을 찾고, 기준을 세우고, 하네스를 깎고, 피드백 루프를 설계해야 그 버튼이 존재합니다. 버튼이 좋아질수록 그 뒤의 설계는 더 어려워지고, 더 중요해집니다.

AX의 끝은 AI를 잘 쓰는 회사가 아닙니다. 대부분의 운영과 결정을 에이전트가 하고, 사람은 꼭 필요한 순간에만 개입하는 회사입니다.

그 회사는 아직 없습니다.

지금 만드는 중입니다.

---

이 글의 원문 문답은 2026-08 스레드 AMA에 있습니다. 질문은 여러 개를 합쳐 다듬었고, 질문자 정보는 싣지 않았습니다.