이 웨비나는 "AI를 많이 쓰면 생산성이 오른다"는 감각이 왜 조직의 성과로는 잘 이어지지 않는지, 그 구조적 이유를 먼저 짚습니다. 그리고 플렉스팀이 직접 실험하며 겪은 실패(측정·순서·조직 적용의 함정)를 바탕으로, 라스트마일과 병목부터 푸는 AX 설계 전략(SSOT·평가환경·검증·권한/보안)을 단계적으로 제시합니다. 결론은 간단히 말해, 생산량이 아니라 병목·검증·의사결정·협업 구조를 바꿔야 성과가 난다는 것입니다.
1. 웨비나 시작: "제품 소개보다, 조직의 AX 전략을 이야기하겠다"
영상은 짧은 BGM/리액션 구간 후, 플렉스팀 CCPO 김태은 님이 인사하며 시작합니다. 여러 산업/조직에서 신청자가 많아 "편한 제품 소개"가 아니라 조금 더 범용적인 이야기로 준비했다고 밝히고, 이번 웨비나는 녹화 다시보기나 발표 자료 제공이 어렵다는 안내도 함께 합니다.
"제품 소개나 저희 팀이 일하는 방법을 소개하는 자리였으면 훨씬 편했을 텐데… 다양한 조직에서 신청을 해주셔서 살짝 걱정이 되긴 합니다만, 최선을 다해서 준비했으니까요."
곧바로 오늘의 핵심 메시지를 한 문장으로 못 박습니다. 조직 성과로 이어지는 AX는 '개인의 생산성'만 올려서는 해결되지 않는다는 주장입니다.
"조직의 성과로 연결되는 조직의 AX는… 개인의 생산성을 올리는 AI 도입과 적용만으로는 해결되지 않는다."
또한 오늘은 개인의 'AI 잘 쓰는 법(활용 팁)'보다, 조직이 AI 도입을 바라보는 관점을 중심으로 말하겠다고 방향을 잡습니다. 플렉스팀도 비슷한 시행착오를 겪었고, 그 과정에서 실험·실패·학습한 내용을 공유하겠다고 예고합니다.
2. "AI는 분명 빨라졌는데, 왜 지표는 그대로일까?" — 성과 착시의 구조
발표자는 많은 조직이 2026년 현재도 AI 예산을 계속 늘리고, 툴을 도입하고, 구성원도 쓰는데도 성과 지표가 크게 변하지 않는 경험을 한다고 말합니다. 제미나이, 클로드, 코파일럿 등 다양한 툴을 도입해 개인의 작업 시간 단축·산출물 증가는 실제로 일어나지만, 그게 조직 목표 달성으로 이어지는 건 "다른 이야기"라는 겁니다.
"AI를 통해 생산량은 확실히 늘었습니다. 개인의 업무 시간 단축도 실제 일어나고 있습니다. 하지만 조직적인 목표 달성, 성과로 이어지게 만드는 것은… 다른 이야기 같아요."
특히 흔한 기대 시나리오를 콕 집습니다. "더 빠른 개발 → 더 많은 릴리즈 → 결국 매출"을 기대하지만, 시간이 지나도 이터레이션 기간, 릴리즈 노트의 개선이 기대만큼 나오지 않는 상황을 말하죠. 그러면 조직은 이렇게 묻게 됩니다.
"다들 AI로 성과를 올리는데… 우리만 잘 안 되는 건가?"
여기서 발표자는 개인과 조직의 차이를 핵심 원인으로 제시합니다. 작은 팀/개인 작업이 곧바로 성과로 직결되는 환경이라면 AI 효과가 선명하지만, 고객에게 전달되는 라스트마일까지 과정이 복잡하고 협업 관계가 많을수록 개인 생산량 증가만으로는 성과로 가기 어렵다고 설명합니다.
"라스트마일까지의 과정이 굉장히 복잡하고, 다양한 협업 관계가 있을수록… AI를 통한 생산량 증가만으로는 성과로 이어지기 어렵습니다."
그리고 중요한 경고를 덧붙입니다. 한 지점만 빨라지면 다른 지점이 따라오지 못해 새 병목이 생긴다는 겁니다.
"PM이 AI로 기획서/PRD를 많이 만들었지만 개발 생산량이 늘지 않는다면… 그냥 병목이 됩니다."
또 하나의 본질로, 조직의 생산성은 수많은 의사결정의 '마지막 결과'라고 말합니다. 스펙 변경, 전달 지연, 의도 오해가 있으면 아무리 빨리 만들었어도 일이 무의미해지거나 성과로 연결되지 않을 수 있죠. 그래서 AI로 진짜 풀어야 할 문제는 코드/문서 생산량이 아니라, 종종 의사소통·협업·의사결정 체계 쪽이라는 결론으로 이어집니다.
"생산성 그 자체보다는 조직의 의사결정 체계나 협업 과정이… 더 개선해야 하는 병목일 수 있습니다."
"AI를 통해 해결해야 되는 지점은 의사소통과 협업에 문제가 훨씬 많을 수 있고요."
3. 플렉스가 직접 부딪힌 3가지 함정: 측정, 순서, 조직 적용
발표자는 플렉스가 겪은 함정을 3가지로 정리해 공유합니다. (1) 측정의 함정, (2) 도입/적용 순서의 함정, (3) 조직 적용의 함정입니다.
3-1. (함정 1) 측정: "사용량·생산량을 성과로 착각한다" 📈
AI 도입 후 가장 자연스럽게 보는 지표는 사용량(토큰), 사용 빈도, 답변 수, 산출물 수입니다. 그런데 이 지표는 "열심히 썼다"는 신호일 뿐, 비즈니스 성과와는 다르다고 강조합니다.
"사용량이 굉장히 많다는 것, 생산량이 굉장히 늘어난다는 것이 곧 성과라고 착각하기 쉽습니다."
"하지만 사용량과 생산량 자체가 성과는 아니죠."
그래서 조직 목표와 연결된 지표(목표 달성 기여도, 비용 절감, 리드타임, 품질 등)로 연결해 봐야 한다고 말합니다.
"얼마나 목표 달성에 기여가 됐는지… 조직 목표와 연관된 지표에 연결되어 있는지를 확인해야 합니다."
개발팀 실험: "병렬 에이전트 돌려도 총 시간은 크게 안 줄 수 있다"
플렉스 개발자가 에이전트를 돌리며 캘린더에 시간을 찍어 측정했는데, 병렬로 여러 에이전트를 돌려도 실제 총 작업 시간은 순차로 한 것과 큰 차이가 안 나는 경우가 있었다고 합니다. 게다가 최근 체감상 모델 속도가 느려진 부분도 "측정하지 않으면 놓친다"고 말합니다.
"병렬로 에이전트를 돌렸을 때… 실제 총 작업 시간을 계산해 보니까 시퀀셜하게 돌린 것과 크게 차이가 안 나는 경우도 있었어요."
"실제 측정하지 않으면 우리가 잘 인지하지 못하는 경우가 있다."
또 병렬 작업은 컨텍스트 스위칭(문맥 전환) 부담을 키워, 사람에 따라 효율이 크게 갈린다고 합니다.
"멀티로 병렬 작업을 하게 되면 문맥 전환이 굉장히 많이 걸립니다… 결과가 매우 달라집니다."
결정적으로, 코드 생산량이 늘어도 코드 리뷰/검증 프로세스가 그대로면 그 구간이 병목이 됩니다.
"AI 코드 생산량은 좋았죠. 하지만 여전히 코드 리뷰 프로세스가 존재한다면… 검증 문제를 해결하지 못하면 병목이 발생합니다."
비용 착시: "엔지니어 채용보다 싸다?" → 기대만큼 안 나올 수 있다
AI 코딩툴을 잔뜩 도입했지만, 실제 아웃풋이 기대보다 낮았던 사례도 공유합니다. PR 증가 수치로 봤을 때 약 15% 수준에 그쳤고, "버려지는 토큰/작업"도 많았다고 합니다.
"예상은 한 두 배 정도 빨라질 줄 알았는데… PR 증가 수만으로 봤을 때 15%에 그치고 있었습니다."
"사용되지 않고 버려지는 작업들도 생각보다 많습니다."
지식 기반/에이전트도 "무엇을 아꼈는지"를 못 보면 실패한다
조직 내부 지식 기반과 에이전트를 만들어 커뮤니케이션 비용을 줄이려 했지만, 단순 사용 횟수만 봐서는 어떤 직무의 어떤 시간/비용이 줄었는지가 연결되지 않았다고 합니다. 또 답변 오류를 알아차리기 어렵고, 고객/계약 등 리스크가 큰 업무에 쓰이면 위험하다는 점도 강조합니다.
"어떤 조직과 직무의 시간과 비용을 아껴주고 있는지 측정하지 않았고… 연결되지 않고 있다는 걸 알았어요."
"그대로 믿고 사용하게 되는 경우가 발생… 고객에게 나가는 일에 사용되는 답변의 오류가 있으면 리스크가 커집니다."
그리고 지식은 최신화가 생명이라, 누가 SSOT(싱글 소스 오브 트루스)를 보장할지, 권한/접근 제어까지 포함해 풀어야 한다고 정리합니다.
"누가 지식의 싱글 소스 오브 트루스를 보장할 수 있는가에 대한 답이 필요합니다."
"사용 권한 관리, 데이터 접근 관리 문제를 풀어야 됩니다."
3-2. (함정 2) 순서: "쉬운 곳부터 붙이면, 병목 이전만 빨라진다" 🧩
AI 도입 초기에 보통 "쉽고 적용 가능한 곳부터" 시작해 리터러시를 높이는데, 발표자는 이것이 큰 함정일 수 있다고 말합니다. 병목을 해결하지 않은 채 AI를 붙이면, 병목 '이전 단계'만 빨라지고 성과로는 안 바뀐다는 겁니다.
"병목을 해결하지 않은 채 AI를 붙이면 병목 이전 단계만 더 빨라지지, 성과로 바뀌진 않습니다."
그래서 어디서부터 시작하느냐(도입 순서)가 성과를 크게 좌우한다고 강조하며, 뒤에서 전략 파트에서 다시 자세히 다루겠다고 연결합니다.
AI 리터러시도 "사용법"이 아니라 "이해·평가·책임"이 핵심
리터러시를 올린다며 툴을 많이 사는 흐름을 인정하면서도, AI 리터러시는 단순 숙련이 아니라 이해·평가·활용·윤리/책임을 포함한다고 정리합니다. 특히 조직에서는 '평가' 역량이 부족한 경우가 많고, 그게 AX 실패로 이어졌을 수 있다고 짚습니다.
"AI 리터러시는 단순히 사용에 대한 익숙함을 의미하지는 않아요."
"오히려 평가에 대한 부분이… 잘 갖추지 않은 경우가 굉장히 많은 것 같고… 조직에서 AI를 도입하는 데 문제가 되지 않았을까…"
3-3. (함정 3) 조직 적용: "혼자 쓸 때와 같이 쓰는 순간, 보안·권한 문제가 폭발한다" 🔒
개인이 쓰는 AI는 빠르고 편하지만, 조직에서 함께 쓰려는 순간 완전히 다른 문제가 터진다고 말합니다. 특히 오픈형 도구(예: 오픈 클라우드/에이전트형 도구)를 예로 들며, 개인에게는 매력적이지만 조직에서는 데이터 접근, 외부 통신, 신뢰할 수 없는 콘텐츠 노출 같은 치명적 문제가 생길 수 있다고 설명합니다.
"혼자 쓰는 AI는 걱정도 없고 보안 리스크도 없… 그런데 조직에서 함께 쓰려는 순간 전혀 다른 문제에 부딪히게 되죠."
또 실제 사례로, 메신저 접근 권한을 줬다가 AI가 통제 불능 상태로 스팸 메시지 500건 이상을 발송한 사건 같은 얘기도 언급합니다. 주요 기업이 사용을 금지했는데도, 조사에 따르면 직원 20%가 승인 없이 사용한다는 점을 "위험하다"고 강하게 말합니다.
"20% 직원들이 여전히 승인 없이 사용하고 있다고 합니다. 이건 되게 위험하다고 생각해요."
조직의 지식을 하나로 모아 에이전트를 붙이려는 시도는 많지만, 결국 가장 큰 실패 원인은 데이터 접근 제어(인가)라고 정리합니다. 신입부터 경영진까지 봐야 하는 정보가 다르고, 인사 이동/조직 개편이 잦으면 권한이 실시간으로 바뀌어야 하니, 이걸 못 풀면 사고 가능성이 커진다는 것이죠.
"데이터를 한 곳에 모았다고 해결되는 게 아닌 것 같아요."
"직무 이동, 조직 개편, 직책 변경이 일어날 때마다 접근 권한이 실시간으로 바뀌어야 합니다."
이 지점에서 플렉스 AI는 인사 발령과 동시에 권한 판단이 가능하다는 식으로, 짧게 제품 강점(광고)을 예고합니다.
4. 조직 AX의 '핵심 엔진': 검증(Validation)과 하네스 엔지니어링
발표자는 여러 이슈 중에서도 AI 산출물 검증이 핵심이라고 강조합니다. 조직이 원하는 AX 결과로 가는 데, 검증을 얼마나 풀었는지가 결정적이라는 겁니다.
"AI 산출물에 대한 검증의 영역… 이 주제가 핵심의 문제라고 생각해요."
플렉스 개발팀은 코드량이 늘어도 성과로 못 간 가장 큰 이유가, 기존과 동일한 코드리뷰 프로세스였다고 말합니다. AI 코드가 늘면 리뷰 부담도 폭증하니, "기존 방식 그대로"는 의미가 없었다는 것이죠.
"AI가 작성한 코드도 검증해야 되는데 양은 더 많이 늘었고… 기존과 같은 방식으로는 아무 의미가 없는 거죠."
그래서 사람 중심 검증을 버리고, AI 산출물을 검증할 환경을 만들기 시작합니다. 예로 테스트 코드, 실제 API/DB를 검증하는 E2E 테스트를 AI가 작성하게 하는 것, 필요하면 화면 녹화로 가시화하는 방식까지 언급합니다. 이런 체계를 갖추고 나서야 성과로 이어지기 시작했다고 말합니다.
"AI 산출물을 검증할 환경을 구축하는 데 시간을 드리기 시작했어요."
"E2E 테스트를 AI가 직접 작성하게 하는 것까지 만들었습니다."
또 "AI 시대에는 중복 코드 같은 약속이 필요 없지 않나?"라는 착각을 반박합니다. AI도 결국 현재 기술 기반(검색/패턴)에 의존하므로, 코드베이스의 패턴/규칙(약속)이 오히려 더 중요해졌다고 설명합니다. AI가 "다 고쳤다"고 해도 10개 중 9개만 고치는 식의 일이 생기기 때문입니다.
"AI가 다 찾았다고 했지만 실제는 열 개 중에 아홉 개만 수정… 이런 일들이 발생했죠."
"코드베이스의 패턴, 약속이 AI 시대에도 중요하다… 아니면 더 높은 가치를 갖는다."
이 흐름에서 하네스 엔지니어링(Harness Engineering)이라는 개념을 소개합니다. "강력한 에이전트가 안정적으로 원하는 방향으로 달리도록 고삐(제약/피드백/검증/정리)를 채우는 메타 엔지니어링"이라고 풀어 설명합니다.
"에이전트라는 강력한 말에 고삐와 안장을 채워서 우리가 원하는 방향으로 안전하게 달리게 하자."
발표에서 언급된 구성요소는 컨텍스트, 아키텍처 제약, 피드백 루프, 자기 검증, 가비지 컬렉션의 5가지입니다. 엔지니어는 직접 코딩만 하는 사람이 아니라, 환경 설계자·의도 명시자·피드백 아키텍처 설계자로 역할이 이동한다고 말합니다.
"엔지니어는 환경의 설계자, AI의 의도를 명시하는 사람… 피드백 아키텍처를 만드는 사람으로 변모하게 되는 것 같아요."
그리고 "개발자 필요 없다 / SaaS 죽었다" 같은 주장에 대해서도, 검증·관리·개선 환경을 만들 엔지니어는 여전히 필요하다고 반박합니다. 예로, 클로드 코드를 만든 앤트로픽이 "개발자 필요 없다"는 식의 메시지를 냈지만 채용 공고는 늘었다는 이야기를 덧붙입니다.
"AI가 코딩한다는 말은 거짓은 아닐 거예요. 하지만 AI를 만들고 관리하고 검증할 엔지니어는 더 많이 필요한 시점이 있다."
5. 성과로 이어지는 AX 설계 전략 4가지: 라스트마일 → SSOT/평가 → 직무 재정의 → 단계적 확장
이제 발표는 "그럼 어떻게 설계해야 성과로 이어지나?"로 넘어가며, 전략을 4가지로 정리합니다. 전체적으로 관통하는 키워드는 라스트마일, 병목 제거, SSOT, 평가/검증, 권한/보안입니다.
5-1. 전략 1) "라스트마일부터 시작하라" + 병목을 재검토하라 🎯
발표자는 AX를 라스트마일(고객 가치가 실제로 확정되는 지점)에서 시작하길 권합니다. 그래야 AI 효과가 측정 가능한 성과 지표에 바로 연결되고, "측정의 함정"도 피하기 쉽다고 말합니다.
"성과로 이어지는 AI 도입은 목표 달성에 가장 직접적으로 연결되는 지점이어야 합니다. 즉 라스트마일부터 시작해야… 용이한 거죠."
"성과에 연결된 지점이 가까울수록 지표도 단순해지고 명확해집니다."
또 라스트마일에서 시작하면 "새 병목을 만들 가능성이 낮다"고 설명합니다. 예시로 소프트웨어 개발에서 라스트마일은 프런트엔드가 아니라 QA 단계라고 강조하고, 그 외에도 고객 접점인 CS, 운영, 컨설팅/세일즈, 내부 헬프데스크 같은 조직을 라스트마일 예시로 듭니다.
"라스트마일의 예시… QA 단계, 고객 접점의 CS팀, 운영 조직, 세일즈 조직, 헬프데스크…"
그리고 중요한 전제도 붙입니다. 라스트마일로 가는 프로세스를 정리하지 않고 AI를 붙이면 또 다른 병목이 생길 수 있으니, 업무 프로세스와 병목을 함께 재설계해야 한다는 말로 이어집니다.
"업무 프로세스를 해결하지 않고 AI를 적용할 경우… 또 다른 병목을 야기할 가능성이 매우 높습니다."
플렉스 사례: CS/파트너스/인터널/QA에서 "라스트마일 효과"를 만들다
플렉스는 고객 접점에서 업셀링과 이슈 응대를 맡는 CS팀 효율화를 위해 인터콤을 도입했고, 다음 성과를 공유합니다.
- 평균 70% 문제 해결
- 비용 절감 2.2억
- AI 고객 응대 만족도 83%
- 2022년 대비 CX 인원 60% 절감
"인터콤을 도입했고… 평균 70%의 문제를 해결… 코스트 세이빙 2.2억… 만족도 83%… 22년 대비 CX 인원 60% 절감."
또 제품에 AI를 "먼저 넣는 것"보다, 매출과 직접 연결되는 HR 파트너스/페이롤 파트너스 같은 서비스 제공 조직부터 시작했다고 말합니다. 파트너스 인력이 한정돼 고객이 "줄 서는 상황"이어서 임팩트가 큰 지점이었다는 설명입니다.
"플렉스는 AI를 제품에 녹이는 것부터 생각하지 않았어요… HR 파트너스, 페이롤 파트너스부터 시작했습니다."
또한 세일즈·CS를 위해 기업 정보를 통합하고, 도입 문의부터 미팅/컨설팅 히스토리를 이어주는 맥락 유지 에이전트에 투자했다고 말합니다.
"도입 문의부터… 그간의 대화, 미팅, 컨설팅 히스토리 맥락을 지속해서 이어주는 에이전트를 지원했습니다."
내부적으로는 조직 병목을 AI로 해결하는 인터널 '인핸스(Enhance) 팀'을 만들고, 계약서 검토나 기업 정보 통합 에이전트 등을 제공했다고도 합니다.
QA 쪽은 더 강하게 밀었습니다. QA 조직을 QP(퀄리티 플랫폼) 팀으로 재정의하고, AI 영향 하에서 품질 검증 병목을 줄이려 투자했다고 합니다. 테스트셋 생성, 코드에서 스펙을 뽑아 슬랙에서 답하게 하는 도구, 크롬 확장으로 오류 화면 녹화 후 티켓 생성, AI 성능 테스트 도구 등을 만들어낸 사례를 소개하며 "엔지니어 출신이 아닌 퀄리티 매니저도 AI로 해낸다"고 말합니다.
"크롬 익스텐션을 직접 만들어서 오류가 발생하면 화면을 녹화하고 티켓을 만드는 것도 만들었고요."
"엔지니어 출신이 아닌 퀄리티 매니저가 이 모든 것을 AI로 해내고…"
5-2. 전략 2) "SSOT(조직의 진실) + 에이전트 평가환경" 없이는 조직의 두뇌가 안 된다 🧠
두 번째 전략은 조직을 위한 SSOT(Single Source of Truth)가 필요하고, 이를 제대로 굴리려면 에이전트/LLM 답변 평가환경이 반드시 필요하다는 주장입니다.
발표자는 SSOT를 "그냥 데이터를 한데 모아 둔 데이터 스톤"과 구분합니다. SSOT는 조직의 약속이며, 최신/의미 있는 데이터 중심으로 불필요한 것은 제거되어야 하고, 질문 의도에 맞게 "진실"을 제공해야 한다고 말합니다. 예를 들어 노션의 PM 문서, 피그마 디자인 스펙, 개발 코드 스펙이 서로 다르면 "어디가 진실이냐"를 답할 수 있어야 SSOT라고 합니다.
"SSOT는 조직의 약속 같은 거죠."
"노션 스펙, 피그마 스펙, 코드 스펙이 다를 경우… '어디가 진실의 스펙이야?'를 답할 수 있어야…"
또 많은 조직의 문제는 생산 자체가 아니라, 라스트마일까지 가는 과정의 의사소통 문제(정보 불일치, 잘못된 의사결정, 담당자 찾기/검색 비용)에서 발생한다고 정리합니다.
"대부분의 조직 문제는 생산 자체에 있지 않은 경우가 많아요."
"정보 불일치로 인한 잘못된 의사결정… 담당자를 찾거나 정보를 검색하는 비용…"
따라서 조직은 통합 데이터를 SSOT로 만들고, 이를 활용하는 에이전트가 필요하지만, 에이전트도 평가 체계 없이는 개선이 어렵다고 합니다.
"SSOT의 측정 체계 없이는… 에이전트 개선을 통한 협업 문제 해결까지 가기 어렵습니다."
플렉스의 평가/운영 체계: 프롬프트 버전관리 + 모델 성능/비용 모니터링 + 피드백 루프
플렉스는 이를 위해 다음과 같은 운영 체계를 구축했다고 설명합니다.
- 프롬프트 관리 체계(버전 관리, 변경 이력, 중앙 관리)
- LLM 성능·비용 모니터링
- 지속적 피드백 루프(개선 사이클)
"프롬프트의 버전 관리, 변경 이력… 중앙 관리 시스템."
"LLM 성능과 비용을 모니터링… 비용 최적화."
"지속적인 피드백 사이클… 피드백 루프."
이 체계가 갖춰져야 AI 투자가 블랙박스에서 벗어나 문제에 맞는 모델 선택과 비용 최적화가 가능해진다고 말합니다. 또한 미팅 STT, 요약 모델, 노무 어시스턴트, 헬프데스크 등 업무마다 최적 모델이 다르다고 언급합니다.
5-3. 전략 3) "직무/조직을 재정의하라" — AI는 툴이 아니라 '일하는 방식 변화'다 🔄
세 번째 전략은 AI 툴 사용을 넘어, 일하는 방식 자체를 바꾸는 것입니다. 협업 병목을 AI로 풀기 시작하면 직무 경계가 자연스럽게 흐려지고, 이를 위해 규칙/약속이 더 필요해진다고 말합니다.
"AI 툴의 사용을 넘어서 일하는 방식의 변화를 만들어야 되는 것 같아요."
"협업을 AI로 해결하기 위해서는 약속과 규칙이 훨씬 많이 필요하다는 것을 알게 됩니다."
예로 QA가 AI로 품질을 검증하려면 스펙 문서 규칙, 규칙이 적용된 코드, AI 테스트 코드와 E2E 적용 등 "약속"이 필요하고, 프런트엔드는 모듈 사용 규칙/디자인 시스템 명세가 필요하며, 디자이너·PM도 AI가 읽고 실행할 수 있는 형태로 스펙을 명세해야 한다고 연결합니다. 이렇게 환경이 갖춰지면 PM/PD/FE/QA 경계가 점점 허물어지는 게 자연스럽다고 말합니다.
"PM은 이제 AI를 위한 스펙 문서가 필요… 검증을 AI와 담당자가 적절히 나눌 수 있는 환경이 되면… 경계가 허물어지는 게 자연스러운 일…"
플렉스 내부 변화 예시 1: 디자인 시스템을 "AI가 쓰게" 명세화
플렉스는 기존 디자인 시스템(FX)을 AI가 활용할 수 있게 명세화(MD 파일 기반 스펙 등)하는 쪽으로 확장하고 있다고 설명합니다. 스펙 문서가 바뀌면 피그마 디자인이 바뀌고, 변경된 디자인이 FE 코드에 반영되는 흐름을 지향한다고 말하며, 이 기반이 플렉스 AI의 커스텀 페이지/대시보드 기능에 활용됐다고 언급합니다.
"이제는 AI가 사용 가능하도록 명세화하는 것을 선택했습니다."
"변경된 피그마 디자인은 바로 FE 코드에서 반영…"
플렉스 내부 변화 예시 2: AI 제품팀 PM의 역할이 바뀌었다
플렉스 AI 제품은 "화면"보다 "대화" 중심 제품이 되었고, 그 팀의 PM은 개발자를 기다리지 않고 평가 기반 셋업, 프롬프트 관리, 소스코드 공유까지 한다고 합니다. 그래서 개발 사이클이 "설득-스프린트"에서 가설-구현-검증으로 바뀌고, 검증까지 걸리는 시간이 주 단위에서 시간 단위로 줄어든다고 말합니다.
"PM은 더 이상 개발자를 기다리지 않아요… 평가 기반을 셋업하고 프롬프트를 관리하고 소스 코드를 개발자와 함께 공유…"
"가설 구현 검증의 사이클로 전환… 주 단위에서 시간 단위로 줄어듭니다."
또 "기획서"라는 추상 매체 없이, 코드로 의도를 전달할 수 있게 됐다고 강조합니다. PM이 에이전트 설계를 위해 작성한 코드가 "어떤 기획서보다 정확한 의도 전달"을 했다는 대목이 인상적으로 등장합니다.
"기획서라는 추상화된 매체를 더 이상 쓸 필요가 없었고… 코드로 직접 의사 전달을 할 수 있게 된 거죠."
"PM이 작성한 코드가 어떤 기획서보다 정확한 설계 의도가 전달…"
실제 예시로 2주 동안 PM이 PR 10개를 리뷰/완료했고, 코드 4,000라인 이상 추가, 변경 파일 75개, 4시간 걸리던 지식 마이그레이션을 3분에 끝낸 경험도 소개합니다(해당 PM은 엔지니어 출신이 아니라고 덧붙임).
"2주 동안 PR 10개… 코드 추가 4,000라인 이상… 변경 파일 75개."
"4시간 걸리던 일을 3분 만에 완료…"
플렉스 내부 변화 예시 3: 모바일 엔지니어 팀 — "개인이 잘 쓰는 것"과 "팀이 AI 네이티브"는 다르다
모바일팀은 코틀린 멀티플랫폼, 모바일 BFF 등으로 경계를 허물었지만, 앞서 말한 함정도 겪었다고 합니다. 생산량 지표(파일 수, 코드 줄 수)를 성과로 착각했고, 코드 생성보다 시나리오 명세·검증 환경을 먼저 했어야 하는데 순서를 잘못 잡은 경험도 있었다고 말합니다.
"생산량 지표를 처음에는 AI의 성과로 착각…"
"코드 생성보다 시나리오 명세, 검증 환경을 먼저 했어야…"
그리고 결론처럼, "개인이 클로드를 잘 쓰는 것"과 "팀 전체가 AI 네이티브로 일하는 것"은 완전히 다르며, 팀 차원에서는 스킬 공유 구조, 서브 에이전트 설계의 프로젝트 레벨 관리, 워크플로우 개선이 중요하다고 정리합니다.
"개인이 잘 쓰는 것과 팀 전체가 AI 네이티브로 일하는 것은 굉장히 다른 문제입니다."
여기서 발표자는 제목과도 연결되는 결론을 하나 더 말합니다.
"엔지니어도 결국 PM처럼 일해야 한다… 하우(How)보다 왓(What)과 와이(Why)에 집중하고, 코드는 수단일 뿐…"
5-4. 전략 4) "퍼블릭 지식부터 시작해, 인가/보안을 풀며 단계적으로 확장하라" 🪜
네 번째 전략은 욕심내서 "전사 확장"부터 하려 하면 결국 인가/보안 문제에 막히니, 공개된 정보(퍼블릭 지식)에서 시작해 단계적으로 확장하라는 것입니다.
"조직 AI 도입을 한 번에 전사로 확장하려면 인가와 보안 문제에 결국 막혀요."
"퍼블릭 지식에서 시작하고… 그게 해결되면 전사 확장 순서로 단계적으로 설계해야 합니다."
플렉스도 빌링/페이롤 스펙처럼 퍼블릭에 가까운 지식, 노무 법령/판례 검색, 회사 정책·복리후생·IT 보안 질문 같은 "누구나 접근 가능한 정보"부터 에이전트를 만들었다고 말합니다.
"조직 내에 누구나 접근 가능한 정보로부터 에이전트를…"
그 다음 단계로 조직/직책/직급별 접근이 필요한 정보로 확장하면서, HR 데이터와 AI 플랫폼의 연결이 중요해졌다고 합니다. 플렉스는 HR 카테고리를 15개로 나누고, 문서를 자동 분류해 지식 기반을 구성한 뒤 멀티 에이전트 시스템으로 전사 적용했다고 설명합니다. 내부 파트너스를 위한 노무 어시스턴트 에이전트는 내부 검증 후 클로즈 베타로 출시했다고도 합니다.
"지식 기반을 15개 카테고리로 만들고… 멀티 에이전트 시스템을 적용해서 전사에 먼저 적용…"
"노무 어시스턴트 에이전트… 클로즈 베타로 출시…"
또 미팅 로그처럼 "참석자만 봐야 하는 정보"는 인가 제어 기반으로 확장해 내부 제품에 먼저 쓰고, 반년 이상 사용하며 제품화해 플렉스 AI에 탑재했다고 합니다.
마지막 단계(궁극 단계)는 전사 에이전틱 AI로, 구성원·조직·목표 데이터가 실시간 연결되어 AI가 조직 상태를 파악하고 의사결정을 지원하는 단계라고 설명합니다. 이를 위해서는 발령부터 보상까지 HR 전반 데이터가 AI 플랫폼 기반이 되어야 한다고 말합니다.
"구성원, 조직, 목표라는 세 가지 데이터가 실시간으로 연결… 조직의 상태를 AI가 파악하고 의사결정을 지원하는 단계."
"발령 정보부터 보상 정보까지 HR 전체 데이터가 AI 플랫폼에 기반이 되어야…"
6. "내일 당장 시작할 수 있는 것" 체크리스트
발표자는 끝부분에서 실행 팁을 짧게 요약합니다. 핵심은 라스트마일·병목·측정 지표·평가환경입니다.
- AI 도입 초기라면, 먼저 AI를 적용할 라스트마일을 찾는다.
- "생산량"이 아니라 협업 문제/병목 지점을 먼저 찾는다.
- 라스트마일과 연결되는 측정 가능한 성과 지표를 먼저 설정한다.
- 지금 측정하는 것이 사용량인지(토큰/횟수), 성과 지표인지 점검한다.
- SSOT를 고민한다면, 그 전에 에이전트를 평가/측정할 환경이 있는지 확인한다.
"라스트마일을 찾아보시기를 권장… 기존 협업 문제, 병목 지점을 먼저 찾으시기를."
"측정하고 있는 것이 사용량인지 성과로 연결되는 지표인지 확인…"
"에이전트의 평가 없이는 SSOT로 지속해서 관리되기 어렵고…"
7. HR 기반 AX와 플렉스 AI 소개(광고) + 인재상 제안
마무리 구간에서 발표자는 "혼자 다 하기 어렵다면"이라는 전제로, 플렉스 AI가 HR 기반으로 조직의 두뇌를 만드는 AI 플랫폼을 제공한다고 안내합니다.
"조직 AI 도입, 측정, SSOT 구축까지 혼자 하지 않아도 됩니다."
또 "AI를 잘 다루는 조직의 인재"를 이렇게 정의해 봤다고 제안합니다. 요지는 멀티 컨텍스트, 업무의 시작과 끝(라스트마일) 이해, 병목 발견/해결, 직군 경계 넘어 맥락 확장, AI 네이티브 환경을 즐기는 태도, 개인 지식을 조직 자산으로 스케일하는 능력입니다.
"하나의 업무보다는 라스트마일까지 이어지는 업무의 시작과 끝을 이해할 수 있는 사람."
"개인의 지식을 조직의 자산 스케일로 변환할 줄 아는 사람…"
이어 "AX 성공에는 HR 데이터 기반이 중요하다"는 관점을 강조합니다. 조직이 궁금해하는 질문—목표에 가까워지는지, 현재 상태와 목표 달성률은 어떤지, 구성원 상태는 어떤지, 지난주/지난달과 무엇이 달라졌는지—에 답하려면 HR 데이터 기반이 필요하다는 겁니다.
"우리의 목표에 가까워지고 있는가? 조직의 현재 상태와 목표 달성률은 어떻지?… 지난주와 지난달은 무엇이 달라졌지… 이런 답변이 조직이 풀어야 되는 문제."
플렉스를 쓰면 근태 정보를 바탕으로 브리핑을 만들고, "요즘 어때?" 같은 질문에 목표 달성률/협업 동료/원온원 주제 예측 등도 제공할 수 있다고 설명합니다. 마지막으로 HR 영역에서의 데이터 트랜스포메이션(DX)이 선행되어야 AX가 가능하다고 정리하며, 플렉스 도입과 향후 플렉스 AI 정식 오픈을 안내하고 감사 인사로 마칩니다.
"AI 전에 HR 영역에서의 데이터 트랜스포메이션이 굉장히 중요하다고 생각해요."
"조만간 플렉스 AI 정식 오픈이 있을 텐데요. 그때 또 뵐 수 있었으면 좋겠고…"
"끝까지 들어 주셔서 너무 감사합니다."
마무리
이 웨비나는 AI 도입 = 생산성 향상 = 성과라는 단순한 등식을 깨고, 조직 성과를 만들려면 라스트마일에서 병목을 풀고, 검증·평가·SSOT·권한/보안 같은 "조직 시스템"을 먼저 설계해야 한다고 말합니다. 결국 AX의 승부처는 개인의 프롬프트 스킬이 아니라, 성과에 닿는 지점에서 측정 가능하게 만들고, 협업/의사결정 비용을 구조적으로 줄이는 설계라는 점을 반복해서 강조합니다.