SEESO · SECONDTEAM — PUBLIC TALK
발표 자료를
그대로 공개합니다.
- 01 퇴사하는 AI, 회사에 남는 AI 166장
- 02 직무 AX — 내 업무를 루프로 만드는 법 2026.08.01 · 모두의연구소
- 03 AI시대의 직무 변화와 미래 전망 2026.08.11 · AI행정혁신 거점학교 연수
- 04 지금 무슨 일이 일어나고 있나 2026.08.12 · 디캠프 펠로우십 멘토살롱 AX
- 05 내 업무에 AI 붙이기 — 업무 자동화의 설계도 2026.08.19 · 디캠프 펠로우십 멘토살롱 AX
박병규 · 시소 / 세컨팀
SEESO · SECONDTEAM — PUBLIC TALK
퇴사하는 AI,
회사에 남는 AI
AX 조직으로 가는 길에서 —
10년간 아웃소싱을 실험해온 스타트업이 직접 본 것들
10년간 아웃소싱을 실험해온 스타트업이 직접 본 것들
박병규 · 시소 / 세컨팀2026
이 발표는
2025년 6월의 페이스북 글 한 편에서 시작해,
한 스타트업이 AX 회사가 되기까지
1년의 기록입니다.
이론이 아니라, 저희와 고객사들이 직접 겪은 순서대로 말씀드립니다.
발표자
박병규 · 시소, 세컨팀
2016년 창업 — 아웃소싱이라는 방식을 10년간 새롭게 실험해온 스타트업입니다.
지금은 두 사업을 합니다.
세컨팀 — 회사 안에서 일하는 AI 팀을 만드는 일.
커리어리 — 42만 명이 가입한 커리어 플랫폼을 운영하는 일.
그리고 오늘 이야기의 대부분은, 저희가 먼저 겪은 일입니다.
지금은 두 사업을 합니다.
세컨팀 — 회사 안에서 일하는 AI 팀을 만드는 일.
커리어리 — 42만 명이 가입한 커리어 플랫폼을 운영하는 일.
그리고 오늘 이야기의 대부분은, 저희가 먼저 겪은 일입니다.
1
전복 — 내 손으로 겪은 변화
아웃소싱으로 10년을 산 사람이 "외주사는 없어질 것"이라고 쓰기까지
먼저, 제 얘기부터
재미없고,
아무도 가치를 안 쳐주던 일을
10년 했습니다.
2016 — 2025
제품을 만들고 싶은 대표님들 곁에서 —
전문가를 모으고, 기획을 정리하고, 수백 건의 프로젝트를 함께 만들었습니다.
전문가를 모으고, 기획을 정리하고, 수백 건의 프로젝트를 함께 만들었습니다.
우리를 찾아오던 분들
아이디어는 있는데…
이런 거 한번 만들어보고 싶어요.
창업가, 디자이너, 마케터, 기획자 — 대부분은 뭘 먼저 해야 할지 몰랐습니다. 당연했죠.
우리가 하던 일
'만드는 방법'을 모르는 분들과,
만드는 방식 자체를 실험하는 일.
N잡러 전문가 팀, 리모트 협업, 스프린트 운영 —
아웃소싱이라는 오래된 업을 새로운 방식으로 계속 실험해온 스타트업이었습니다.
아웃소싱이라는 오래된 업을 새로운 방식으로 계속 실험해온 스타트업이었습니다.
그런데
그 10년이,
AI 시대에 가장 필요한 훈련이었습니다.
그 시절 우리의 집착
"사람들이 어떻게 협업해야
일이 되는가."
내부 프로젝트 매니지먼트 솔루션을 만들려고 R&D까지 했을 정도로,
협업 방식이 늘 최대 관심사였습니다.
문제를 쪼개고 · 실패를 빨리 판별하고 · 되는 구조를 찾는 일 —
이 훈련이 AI에게 일을 시키고, AI와 협업하는 시대의 훈련이었던 겁니다.
협업 방식이 늘 최대 관심사였습니다.
문제를 쪼개고 · 실패를 빨리 판별하고 · 되는 구조를 찾는 일 —
이 훈련이 AI에게 일을 시키고, AI와 협업하는 시대의 훈련이었던 겁니다.
2025년 6월 8일
그날,
페이스북에 글을
하나 올렸습니다.
뉴스로만 듣던 변화를
제 손으로 겪은 직후였습니다.
제 손으로 겪은 직후였습니다.
외주사는 없어질 거예요.
(최소한 지금 우리가 아는 외주사는, 다 없어집니다.)
— 아웃소싱으로 10년을 산 사람이 쓴 문장입니다. 접니다.
그 글을 쓰게 만든 하루
시니어 개발자 한 명 + Claude Code
= 하루 만에 돌아가는 서비스
그 자리에서 기획 얘기하고, 흐름 잡고, 프롬프트 몇 개 쳤더니 —
우리의 첫 바이브코딩
standvibe.me
머릿속에 그리던 서비스의 80%가,
그날 저녁에 돌아가고 있었습니다.
(지금은 내려간 사이트입니다 — 그 이유도 곧 나옵니다.)
그날 저녁에 돌아가고 있었습니다.
(지금은 내려간 사이트입니다 — 그 이유도 곧 나옵니다.)
그날 이후
15년 넘게 알고 있던
'제품 만드는 법'이 —
완전히 전복됐다.
10년 동안 전문가를 모으고, 프로젝트를 관리하며 만들어온 그 '방법'이, 통째로.
이 변화의 본질 ①
예전엔 기능 하나 바꾸려면 —
예산을 고민하고,
개발자에게 지금 말하는 게 맞을까 눈치를 보고,
기획이랑 디자인은 또 어떻게 하나 고민하고…
개발자에게 지금 말하는 게 맞을까 눈치를 보고,
기획이랑 디자인은 또 어떻게 하나 고민하고…
이제 그 비용들이,
샤라락 — 날아갑니다.
"그 요구사항, AI한테 한번 시켜볼까요?"
회의 중에, 그 자리에서, 그냥 바꿔봅니다.
회의 중에, 그 자리에서, 그냥 바꿔봅니다.
변경 비용이 0에 가깝다.
무섭고도 강력한 변화다.
이걸 체감하면, 다시는 예전처럼 일 못 합니다.
이 변화의 본질 ②
"애자일이란 개념이
지금도 유효한가?"
우리 팀도 늘 애자일하게 일한다고 생각했지만 —
이렇게까지 빨리 만들고, 고치고, 다시 만들 수 있으니
이터레이션을 '돌리는' 그 리듬조차 느려 보이기 시작했습니다.
이렇게까지 빨리 만들고, 고치고, 다시 만들 수 있으니
이터레이션을 '돌리는' 그 리듬조차 느려 보이기 시작했습니다.
이 변화의 본질 ③ — 흐름의 역전
기획 → 디자인 → 개발
이 아니라,
제품을 보고 → 기획서를 쓴다.
기획자는 결과물을 보면서 기획서를 정리하고,
디자이너는 구현된 UI를 보면서 개선점을 고민하는 —
완전히 반대의 흐름. 그런데 이게 더 맞는 것처럼 느껴집니다.
디자이너는 구현된 UI를 보면서 개선점을 고민하는 —
완전히 반대의 흐름. 그런데 이게 더 맞는 것처럼 느껴집니다.
이 변화의 본질 ④
"그래도 유지보수는
사람이 해야지."
한 달 전의 제가 한 말입니다.
지금은 — 테스트도, 리팩토링도, 디버깅도 AI가 먼저 제안하고 수행까지 합니다.
"안정화"라는 개념 자체가 달라지고 있었습니다.
지금은 — 테스트도, 리팩토링도, 디버깅도 AI가 먼저 제안하고 수행까지 합니다.
"안정화"라는 개념 자체가 달라지고 있었습니다.
개발의 새 이름
코드 프리징 → '정비소'.
AI가 관리하고, 사람은 정비합니다 — 보안, 정책, 데이터 구조.
AI가 관리하고, 사람은 정비합니다 — 보안, 정책, 데이터 구조.
그래서, 그때부터 — 결단 하나
우리 회사의 제품은
전부 AI로만 만들기로 했습니다.
그 글의 말미에 이미 적혀 있었습니다 —
"우리 회사의 일하는 방식을 AI 기반으로 바꾸기로 했다."
선언이 아니라, 그날 내린 결정이었습니다.
"우리 회사의 일하는 방식을 AI 기반으로 바꾸기로 했다."
선언이 아니라, 그날 내린 결정이었습니다.
결단 둘 — 이상하게 들리실 겁니다
몇 년간 접어뒀던
아웃소싱 의뢰를,
다시 받아보기로 했습니다.
한동안 저희는 자사 서비스에 집중하느라 아웃소싱을 쉬고 있었거든요.
그런데 이 변화를 보고 — 다시 시작했습니다. 단, 조건을 걸고.
그런데 이 변화를 보고 — 다시 시작했습니다. 단, 조건을 걸고.
첫 실험
"과거 1,000만 원짜리 프로젝트를 —
100만 원에 해드리겠습니다."
조건은 하나. 처음부터 끝까지 AI로만 만드는 것에 동의하는 팀만.
그 전제에 동의하는 분들만 받아서, 진행해봤습니다.
그 전제에 동의하는 분들만 받아서, 진행해봤습니다.
왜 이렇게까지 했냐면
몸으로 부딪히는 게
제일 좋은 학습이니까요.
창업할 때 배운 그대로입니다.
그리고 직관이 하나 있었습니다 —
이 변화를 제일 먼저 고민하고 실행해본 경험 자체가, 자산이 될 것이다.
그리고 직관이 하나 있었습니다 —
이 변화를 제일 먼저 고민하고 실행해본 경험 자체가, 자산이 될 것이다.
6개월의 실전
시니어부터 주니어까지, 전원
Claude Code로 실제 프로젝트를
돌렸습니다.
· 부트캠프 출신 주니어 프론트 개발자는 혼자 어디까지 갈 수 있나?
· 시니어 개발자들끼리 협업하면 어떤 모습이 되나?
· 기획과 디자인 프로세스는 AI 개발에 어떻게 녹여야 하나?
· 애자일·스크럼·스프린트는 어떻게 다르게 느껴지나?
· 시니어 개발자들끼리 협업하면 어떤 모습이 되나?
· 기획과 디자인 프로세스는 AI 개발에 어떻게 녹여야 하나?
· 애자일·스크럼·스프린트는 어떻게 다르게 느껴지나?
거의 매주,
새로운 경험과 회고.
그리고 모델이 바뀌면 — 그 경험과 회고가 현장에서 다시 바뀌는 것까지,
6개월 내내 계속 겪었습니다.
정답을 찾은 게 아니라, 정답이 계속 바뀌는 속도를 배운 겁니다.
6개월 내내 계속 겪었습니다.
정답을 찾은 게 아니라, 정답이 계속 바뀌는 속도를 배운 겁니다.
사내 실험 — 바이브 리뷰 (2025년 8~9월)
코드 리뷰가 아니라,
프롬프트 리뷰.
개발자들이 Claude Code로 일한 프롬프트 데이터를 가져와서 —
AI가 역으로 우리가 한 일을 전통적인 칸반으로 정리해주고,
스크럼에서 작업이 애매하면 그 프롬프트를 보며 리뷰하고,
다시 '엑기스 프롬프트'를 뽑아주는 실험이었습니다.
AI가 역으로 우리가 한 일을 전통적인 칸반으로 정리해주고,
스크럼에서 작업이 애매하면 그 프롬프트를 보며 리뷰하고,
다시 '엑기스 프롬프트'를 뽑아주는 실험이었습니다.
그 실험들, 서비스로는 안 남았습니다. 하지만 —
2,209
바이브 리뷰에 쌓인 세션
16,000
기록된 프롬프트 로그
실험은 죽어도, 로그는 다음 실험의 입력이 됩니다.
이게 저희가 "자산화"를 처음으로 체감한 순간이었습니다.
이게 저희가 "자산화"를 처음으로 체감한 순간이었습니다.
그러다 욕심이 생깁니다
이 방식 —
어디까지 갈 수 있나?
작은 MVP는 되는 걸 알겠고. 그럼 난이도를 올려보자.
검증 사례가 두 개 있습니다.
검증 사례가 두 개 있습니다.
검증 ① — 우리 서비스로
커리어리.
10년 넘은 레거시 코드.
인수 시점에 이미 — 너무 방대하고, 수많은 개발자의 손을 거친 코드.
유지하는 데만 월 수백만 원이 나가고 있었습니다.
유지하는 데만 월 수백만 원이 나가고 있었습니다.
고칠 리스크가 너무 커서,
거북이걸음으로 줄이고만
있었습니다.
트래픽은 줄고, 서비스는 단순해지는데, 불필요한 기능은 많고 —
레거시를 파악하고 수정하는 리스크가 커서, 몇 년을 그렇게.
레거시를 파악하고 수정하는 리스크가 커서, 몇 년을 그렇게.
2025년 하반기, 결단
전면, 새 코드로
다시 짜기로 했습니다.
사용자들에게 조금 욕을 먹더라도 — 생존이 중요하니까.
42만 가입자의 서비스를, AI 기반으로 전면 리뉴얼하는 도박이었습니다.
42만 가입자의 서비스를, AI 기반으로 전면 리뉴얼하는 도박이었습니다.
우여곡절 끝에 —
성공했습니다.
10년 레거시를 AI로 전면 재작성. 이게 저희 방식의 난이도 상한을 뚫은 순간입니다.
검증 ② — 그리고 이런 일이 생깁니다
창업 초기, 1년을 갈리며
만든 앱이 있습니다.
몇 년 뒤 — 그 대표님이 다시 연락을 주셨습니다.
레거시는 그대로인 채로, 리뉴얼을 하고 싶다고.
레거시는 그대로인 채로, 리뉴얼을 하고 싶다고.
솔직히
망설였습니다.
옛날 방식의 외주면 — 서로 너무 힘들 걸 아니까요.
그 1년을 다시 할 자신이 없었습니다.
그 1년을 다시 할 자신이 없었습니다.
대신
앱 개발자가 아닌 제가,
Claude Code로 iOS와 Android를
직접 리뉴얼했습니다.
코드를 그냥 들고, 제가 해버렸습니다. 두 플랫폼 다.
성공적으로 끝났고 — AI의 임팩트를 다시 한번, 몸으로 느꼈습니다.
성공적으로 끝났고 — AI의 임팩트를 다시 한번, 몸으로 느꼈습니다.
우리가 알던 고객사들의
AI 프로젝트를,
이제 우리가 하고 있습니다.
10년 전 외주를 맡기던 회사들이, 이제 AX를 맡깁니다.
그 사이, 저희 견적서까지 바뀌었습니다
2024년의 견적서
- 기획비 · 디자인비 · 개발비 (분리 견적)
- 미팅 n회 · PM 공수 · 소통 비용
- 백엔드 / 프론트 인력 각각
- 변경은 "추가 견적"
지금의 견적서
- 제품 만드는 비용 → 거의 0
- 관리 인력의 최소 인건비 수준
- 변경은 그 자리에서
- 대신 — 환경과 운영에 값을 매김
제품을 만드는 건 거의 공짜가 됐습니다 — 완전히 다른 구조의 사업이 된 거죠.
1년을 돌아보면 — 회고 ①
패턴이 있었습니다.
① 개인이 일단 무지막지하게 써본다 — 그러면서 개인이 학습한다.
② 그걸 실제 일에, 조직 관점으로 같이 돌린다.
③ 그러면 기존 협업과 어디가 다른지, 어디서 새 관점이 필요한지가 드러난다.
이 순서는 건너뛸 수 없었습니다.
② 그걸 실제 일에, 조직 관점으로 같이 돌린다.
③ 그러면 기존 협업과 어디가 다른지, 어디서 새 관점이 필요한지가 드러난다.
이 순서는 건너뛸 수 없었습니다.
회고 ②
우리가 빨랐던 이유는,
아이러니하게도 —
항상 새로운 '일'이 있었기 때문입니다.
AI 모델의 변화 × 우리가 쌓은 경험 —
새롭게 시도해보고 싶은 방식이 생길 때마다, 그걸 실험할 새 프로젝트가 있었습니다.
새로운 시도가 새로운 '일'에서 경험이 되고, 자산이 됐습니다.
새롭게 시도해보고 싶은 방식이 생길 때마다, 그걸 실험할 새 프로젝트가 있었습니다.
새로운 시도가 새로운 '일'에서 경험이 되고, 자산이 됐습니다.
아이러니하게도 —
아웃소싱으로 일하는 것의 가치가,
AI 시대에 살짝 열렸던 건 아닐까.
모두가 끝났다고 말한 업에서, 우리는 가장 빠른 학습 환경을 발견했습니다.
1막을 닫으며
여기까지가
우리의 전복입니다.
한 팀이 겪으면 여기서 끝나도 됩니다.
그런데 이 변화를 세상의 회사들이 겪기 시작하면 — 진짜 이야기는 이제부터입니다.
그런데 이 변화를 세상의 회사들이 겪기 시작하면 — 진짜 이야기는 이제부터입니다.
2
여정 — 놀랍도록 비슷한 구덩이
전도사가 되어, 회사들 안에서 본 것
그 사이 제게 생긴 변화
바이브코딩 전도사 비슷한 게
됐습니다.
소셜 활동이라곤 안 하던 제가, 페북에 한동안 글을 연재하게 됐습니다.
진심으로 — 내가 경험한 이 변화의 현장을,
주변 지인 대표님들에게 외치고 싶어서였습니다.
진심으로 — 내가 경험한 이 변화의 현장을,
주변 지인 대표님들에게 외치고 싶어서였습니다.
그랬더니
"교육 좀 해주세요"라는
대표님들이 생겼습니다.
대표·임원 5인 내외의 과외 교육(AIwake)을 비정기적으로 열게 됐고,
바이브코딩 해커톤과 워크숍 문의가 계속 이어졌습니다.
우리가 가진 경험과 실무 경험치로 이 일을 하는 게 — 즐겁기도 했습니다.
바이브코딩 해커톤과 워크숍 문의가 계속 이어졌습니다.
우리가 가진 경험과 실무 경험치로 이 일을 하는 게 — 즐겁기도 했습니다.
그리고 용어가 바뀌기 시작합니다
'바이브코딩'이
'AI', 'AX'라는 이름으로.
개인의 코딩 기술 이야기가 — 조직의 전환 이야기가 되면서,
모든 방향이 조금씩 한 지점을 향하기 시작했습니다.
모든 방향이 조금씩 한 지점을 향하기 시작했습니다.
우리 자신도 그 지점으로 가고 있었습니다
커리어리는 —
사람이 아닌 에이전트 팀으로
동작하는 조직으로.
그리고 아웃소싱은 — 작년에 썼던 그대로,
코드 짜는 비용이 0에 가까워지면서 '코드를 짜주는 외주'는 정말로 사라졌습니다.
코드 짜는 비용이 0에 가까워지면서 '코드를 짜주는 외주'는 정말로 사라졌습니다.
우리는 아웃소싱업을
스스로 재규정했습니다.
이제 의뢰가 오면 — 그 일을 해줄
개발 에이전트를 셋업해 드립니다.
솔루션 사업으로 '강제로' 변하게 된 겁니다. 제 기준에서는, 강제라는 표현이 맞았습니다.
그리고 지금, 2026년
AX 전환. AI-Native. AI-OS.
스타트업부터 비영리, 중소기업, 대기업까지 — 전방위로 시도가 일어나고 있습니다.
그리고 저는, 작년 6월처럼 —
또 이야기하고 싶은 것이 생겼습니다.
그리고 저는, 작년 6월처럼 —
또 이야기하고 싶은 것이 생겼습니다.
질문이 바뀌었거든요
AI, 어떻게 잘 쓸 수 있어요?
우리 조직이 AI 조직으로
어떻게 변할 수 있어요?
요즘 대표님들이 제게 묻는 질문. 개인의 기술이 아니라 — 조직의 전환.
그 질문에 답하려고, 이 발표를 만들었습니다
지난 1년, 교육과 구축으로
수십 개 회사를 안에서 봤습니다.
교육으로 만나고, 진단으로 들어가고, 구축으로 함께 일하면서 —
대기업부터 10명짜리 팀까지.
대기업부터 10명짜리 팀까지.
회사들은 놀랍도록
비슷한 여정을 지나고 있었습니다.
업종도, 규모도, 대표의 성향도 다른데 —
겪는 단계와 고통이 거의 같았습니다.
겪는 단계와 고통이 거의 같았습니다.
우리만 본 게 아닙니다 — MIT 「State of AI in Business 2025」: 기업 GenAI 파일럿의 95%가 측정 가능한 성과 없이 멈춥니다.
AX 조직의 공통 여정
대부분의 회사가 이 지도 위 어딘가에 있습니다.
STAGE 1
필요 인식
대표·임원이 밖에서 먼저 느낀다
STAGE 2
교육·도구 도입
전사 교육, 구독 결제, 워크숍
STAGE 3
챔피언 등장
잘 쓰는 직원이 나타난다
STAGE 4
정체기
"우리, AI 잘 쓰는 거 맞나?"
STAGE 5
?
도약하는 회사와 머무는 회사가 갈린다
들으시면서 진단해보세요 — 우리 회사는 지금 몇 단계인지
STAGE 1 — 필요 인식
시작은 기술이 아니라
사람입니다.
대표·임원이 비즈니스 현장에서, 지인에게서, 미디어에서 —
"우리도 해야 하는 것 아닌가"를 먼저 느낍니다.
"우리도 해야 하는 것 아닌가"를 먼저 느낍니다.
요즘 다들 AI로 일한다던데,
우리 회사는 뭘 하고 있지?
이 질문이 나오는 순간 — 여정이 시작됩니다.
STAGE 1 — 필요 인식
아래에서 오는 신호도 있습니다.
내부에 AI를 적극적으로 쓰는 얼리어답터가 이미 있느냐 —
이게 초기 속도를 가릅니다.
있으면 그 사람이 씨앗이 되고, 없으면 밖에서 찾게 됩니다.
이게 초기 속도를 가릅니다.
있으면 그 사람이 씨앗이 되고, 없으면 밖에서 찾게 됩니다.
STAGE 2 — 교육·도구 도입
교육을 하고, 구독을 결제하고,
워크숍을 엽니다.
대표가 직접 배우러 가거나, 교육 업체를 부릅니다.
— 네, 저희가 그 '업체'입니다. 그래서 이 단계를 아주 많이 봤습니다.
— 네, 저희가 그 '업체'입니다. 그래서 이 단계를 아주 많이 봤습니다.
STAGE 2 — 교육·도구 도입
1인당 월 $20~200.
AI 구독을 결제해줍니다. 전사 도입이면 더 큰 결단이 필요하죠.
워크숍, 팀별 미니 프로젝트, 해커톤 —
"AI로 이런 것도 된다"를 체험하는 이벤트들이 열립니다.
워크숍, 팀별 미니 프로젝트, 해커톤 —
"AI로 이런 것도 된다"를 체험하는 이벤트들이 열립니다.
그런데 여기, 첫 번째 함정
교육을 해도 —
몇 명은 잘 다루게 되고,
몇 명은 아니게 됩니다.
교육하는 회사가 드리는 솔직한 말씀입니다.
교육은 트리거지, 전환 그 자체가 아닙니다.
교육은 트리거지, 전환 그 자체가 아닙니다.
STAGE 3 — 챔피언의 등장
잘 쓰는 사람이 나타나고,
슬랙이 활발해집니다.
슬랙이 활발해집니다.
STAGE 3 — 챔피언의 등장
익숙한 풍경들.
· 재밌는 걸 만들어 슬랙에 자랑하는 패턴
· "저 사람처럼 다른 사람도 잘 쓰게 하자"는 회의
· 잘하는 사람의 프롬프트를 정리해 전사 공유
· 그 사람이 만든 스킬을 올려두고 같이 쓰기
· "저 사람처럼 다른 사람도 잘 쓰게 하자"는 회의
· 잘하는 사람의 프롬프트를 정리해 전사 공유
· 그 사람이 만든 스킬을 올려두고 같이 쓰기
여기까지는,
대부분의 회사가 옵니다.
어느 조직이든 AI를 곧잘 다루는 몇 명은 반드시 나옵니다.
좋은 문화라면 서로 돕는 디스커션도 생기고요.
그리고 그 챔피언들은 — 직접 만들기 시작합니다.
좋은 문화라면 서로 돕는 디스커션도 생기고요.
그리고 그 챔피언들은 — 직접 만들기 시작합니다.
STAGE 3.5 — 바이브코딩의 명암
비개발자가 며칠 만에
어드민을 만드는 시대.
놀라운 진보입니다. 진심으로요.
저희 사업의 절반은 이걸 가르치는 일이기도 합니다.
다만 — 회사 관점에선, 뒤에 쌓이는 게 있습니다.
저희 사업의 절반은 이걸 가르치는 일이기도 합니다.
다만 — 회사 관점에선, 뒤에 쌓이는 게 있습니다.
STAGE 3.5 — 바이브코딩의 명암
만든 사람도 설명 못 하는 도구가
사내를 돌아다니기 시작합니다.
문서는 없고, 로직은 블랙박스고,
담당자가 자리를 비우면 — 그 도구는 멈춥니다.
도구의 문제가 아니라, 구조의 문제입니다.
담당자가 자리를 비우면 — 그 도구는 멈춥니다.
도구의 문제가 아니라, 구조의 문제입니다.
4
STAGE 4 — 정체기
오늘 이야기의 핵심. 여기서 회사들이 갈립니다.
잘 되는 것 같으면서도,
안 되는 것 같아요.
이 시기 대표님들이 실제로 하시는 말. 교육도 했고, 계정도 사줬고, 잘 쓰는 직원도 있는데.
정체기의 다섯 가지 증상
이 시기, 회사에는
다섯 가지 증상이 나타납니다.
하나라도 익숙하다면 — 여러분 회사는 지금 Stage 4입니다.
그리고 혼자가 아닙니다.
그리고 혼자가 아닙니다.
최근 조사 — 기업 79%가 AI 도입 난항, C-레벨 54%는 "AI 도입이 회사를 찢어놓고 있다"고 답했습니다.
증상 ① — 속도감의 착각
속도감의 착각.
분명 여러 가지가 일어나고 있는데, 얼마나 빨라졌는지 체감이 안 됩니다.
심지어 본인도 잘 모르겠습니다. 기분은 좋은데, 결과가 안 빨라지는 느낌.
좋아진 건 맞는데 — 기대한 만큼은 아닙니다.
심지어 본인도 잘 모르겠습니다. 기분은 좋은데, 결과가 안 빨라지는 느낌.
좋아진 건 맞는데 — 기대한 만큼은 아닙니다.
증상 ② — 2할의 회사
잘 쓰는 2할만, 잘 씁니다.
그 사람들은 효율적으로 일하고 재밌는 걸 만드는데 —
다른 사람들은 크게 관심이 없거나, 조금씩 맛만 보거나, 그냥 건드려보는 정도.
전파가 되는 것 같으면서도, 안 되는 모호한 지점.
다른 사람들은 크게 관심이 없거나, 조금씩 맛만 보거나, 그냥 건드려보는 정도.
전파가 되는 것 같으면서도, 안 되는 모호한 지점.
증상 ③ — 직원 복지형 AI
속된 말로…
직원들만 좋아지는 것 아닌가?
투자한 만큼 매출이나 생산성이 아니라 — "사람들이 편해지기만 한 것 같은" 경영진의 속마음.
증상 ④ — 챔피언 번아웃
챔피언의 번아웃.
원래 개발자도 아니었는데, 회사를 위해 배워서 만들었더니 —
그 도구의 관리와 디버깅이 내 추가 업무가 됐습니다.
혁신을 주도하던 그 사람이, 수동적으로 변하기 시작합니다.
그 도구의 관리와 디버깅이 내 추가 업무가 됐습니다.
혁신을 주도하던 그 사람이, 수동적으로 변하기 시작합니다.
증상 ⑤ — 역량 증발, 결정타
그 직원이,
퇴사합니다.
회사 AI 역량이
통째로 증발한 것 같은 느낌.
어제까지 "우리는 AI 잘 쓰는 회사"라고 말하려던 참이었는데.
우리는 'AI 잘 쓰는 회사'가 아니라
'AI 잘 쓰는 직원이 있는 회사'였던
겁니다.
학계도 이 구덩이를 발견했습니다
MIT가 붙인 이름 —
Learning Gap.
"도구가 기억하지 못하고, 배우지 못하고, 적응하지 못한다."
파일럿의 95%가 멈추는 원인이고, 성공한 5%의 공통점은 단 하나 —
기억과 학습 루프(memory & learning loops)를 가졌다는 것.
파일럿의 95%가 멈추는 원인이고, 성공한 5%의 공통점은 단 하나 —
기억과 학습 루프(memory & learning loops)를 가졌다는 것.
그런데 저희는 현장에서, 같은 문제에 다른 이름을 붙이고 있었습니다 —
STAGE 4
이 구덩이에는, 이름이 필요합니다.
이 발표의 한 단어
퇴사하는 AI vs 회사에 남는 AI
퇴사하는 AI
- 개인 계정의 대화 기록
- 개인 PC의 세팅과 하네스
- 그 사람 머릿속의 프롬프트
- → 퇴사와 함께 소멸
회사에 남는 AI
- 회사 서버의 컨텍스트
- 회사 깃헙의 코드와 스킬
- 팀이 같이 쓰는 에이전트
- → 사람이 바뀌어도 축적
퇴사하는 AI
그 사람이 떠나는 날 —
그 사람의 AI도 함께 떠납니다.
그 사람의 AI도 함께 떠납니다.
특히 이것
개인 PC의 하네스와 세팅 —
그 자체가 자산입니다.
혼자서 풀스택으로 일하기 너무 좋은 세상이 되다 보니,
일 잘하는 사람일수록 자기 PC에 자기만의 환경을 쌓아갑니다.
회사에서 가장 가치 있는 시스템이 — 회사 바깥에 있는 셈입니다.
일 잘하는 사람일수록 자기 PC에 자기만의 환경을 쌓아갑니다.
회사에서 가장 가치 있는 시스템이 — 회사 바깥에 있는 셈입니다.
감상이 아니라, 측정된 현실입니다
80%
기업 핵심 지식 중, 문서화된 적 없는 암묵지의 비율
1.3조 달러
지식 유출로 인한 연간 손실 (미국, 추정)
UC버클리 CMR이 2026년에 쓴 문장 그대로 —
"암묵지가 당신의 다음 경쟁 해자(moat)다."
"암묵지가 당신의 다음 경쟁 해자(moat)다."
※ 지식경영 연구들의 추정치입니다 — 정확한 수치보다 규모에 주목해 주세요.
자가진단 — 딱 하나만 세어보세요
회사에서 AI로 만든 것 중,
그 사람이 내일 퇴사해도 남는 것이
몇 개입니까?
그 숫자가 —
회사의 진짜 AX 점수입니다.
교육 횟수도, 구독 계정 수도, 토큰 사용량도 아니라.
갈림길
여기서 도약하는 회사와
머무는 회사가 갈립니다.
그리고 도약하는 회사들의 공통점은, 기술이 아니라 —
관점 하나였습니다.
관점 하나였습니다.
"개인이 더 빠르게 일하는 도구"에서
"조직에 축적되는 자산"으로.
프롬프트도, 산출물도, 일하며 AI에게 들려준 판단의 맥락까지 — 쌓이는 곳을 바꾸는 것.
2막을 닫으며
좋습니다.
그래서 — 구체적으로 뭘 해야 하나요?
지금부터가 오늘 발표의 본론입니다.
2막을 닫으며
여기서부터는,
인사를 하고 가고 싶어서요.
지금까지가 “무엇이 일어나고 있나”였다면,
3막부터는 “그래서 우리는 어떻게 하고 있나”입니다.
남은 이야기는 저희가 실제로 굴리고 있는 방법이라, 일방적으로 넘기기보다 — 짧게라도 서로 소개하고 이어가고 싶었어요.
오른쪽에서 잠깐 이야기 나눠요.
3막부터는 “그래서 우리는 어떻게 하고 있나”입니다.
남은 이야기는 저희가 실제로 굴리고 있는 방법이라, 일방적으로 넘기기보다 — 짧게라도 서로 소개하고 이어가고 싶었어요.
오른쪽에서 잠깐 이야기 나눠요.
M
마크 에이전트
온라인 · 이 발표를 만든 팀의 에이전트
오늘
3
프랙티스 — 우리가 지금 실험하고 있는 것
저희와 고객사들이 실제로 굴리고 있는 방법을 공유합니다
시작하기 전에
지금부터는 저희가 실제로
실험하고 있는 것들입니다.
저희 회사에서 직접 굴리고 있고, 고객사 파트너십으로도 함께 하고 있는 것들이라
공유드립니다. 거창한 자산이라기보다 —
하나의 프랙티스로 보시면, 도움이 되지 않을까 합니다.
공유드립니다. 거창한 자산이라기보다 —
하나의 프랙티스로 보시면, 도움이 되지 않을까 합니다.
누구에게 하는 이야기냐면
AI 조직으로 전환하고 싶은
대표님, 리더분들께
드리는 이야기입니다.
다들 비슷한 길을 걷게 되고, 비슷한 지점에서 고민하게 되더라고요.
지금 어떤 시도가 가능하고, 어떤 고민을 미리 해두면 좋은지 —
그 관점으로 말씀드리겠습니다.
지금 어떤 시도가 가능하고, 어떤 고민을 미리 해두면 좋은지 —
그 관점으로 말씀드리겠습니다.
대전제 — 세 단어만 기억하세요
만들기 → 협업 → 에이전트.
조직이 순서대로 통과해야 하는 세 가지 경험입니다.
개인의 도구가 되고 → 팀의 방식이 되고 → 조직의 동료가 되는 순서.
개인의 도구가 되고 → 팀의 방식이 되고 → 조직의 동료가 되는 순서.
경험 사다리
① 만들기(개인의 도구) → ② 협업(팀의 방식) → ③ 에이전트(조직의 동료)
경험 ① 만들기 — 개인의 도구
개인들이, 자기 업무를
효율화할 무언가를
일단 만들어보게 하세요.
데모가 아니라, 자기 일에 실제로 쓰이는 것.
이 경험이 없으면 AI는 계속 "신기한 것"에 머뭅니다.
이 경험이 없으면 AI는 계속 "신기한 것"에 머뭅니다.
경험 ② 협업 — 팀의 방식
같은 목적을 위해,
각자의 AI 결과물을
하나로 합쳐보게 하세요.
각자 AI로 만든 서로 다른 결과를 가져와 하나의 결과물을 만들어보는 경험 —
그 과정에서 서로의 컨텍스트, 소통 방식, AI를 같이 쓰는 법을
토론하고, 고찰하고, 실험하게 됩니다. 이게 팀의 방식이 만들어지는 순간입니다.
그 과정에서 서로의 컨텍스트, 소통 방식, AI를 같이 쓰는 법을
토론하고, 고찰하고, 실험하게 됩니다. 이게 팀의 방식이 만들어지는 순간입니다.
경험 ③ 에이전트 — 조직의 동료
우리와 협업하는
AI 존재를 구축하게 하세요.
시키면 하는 도구에서 → 맡기면 알아서 하는 동료로.
이 경험까지 해봐야, 조직은 다음 단계가 상상이 됩니다.
이 경험까지 해봐야, 조직은 다음 단계가 상상이 됩니다.
이 순서를 건너뛰면
교육만 세 번 반복하거나,
에이전트를 사놓고 방치하게 됩니다.
둘 다 실제로 아주 많이 봤습니다.
사다리는 한 칸씩만 오를 수 있습니다.
사다리는 한 칸씩만 오를 수 있습니다.
그리고, 단언 하나
이건 이제 우리가 생각하는
'개발'이 아닙니다.
'엑셀'입니다.
강의할 때마다 하는 이야기입니다. 진심입니다.
엑셀의 법칙
약간의 노력은 필요하지만, 관심을 갖고 다루면
말도 안 되는 생산성이 나오는 도구 — 그게 엑셀이었죠.
말도 안 되는 생산성이 나오는 도구 — 그게 엑셀이었죠.
AI-native 세대에게는,
방금 말한 모든 과정이
딱 엑셀 수준의 도구가 됩니다.
만들기도, 협업도, 에이전트 구축도 —
특별한 사람의 특별한 기술이 아니라, 일하는 사람의 기본기.
저는 이 순간을 '엑셀 모먼트'라 부릅니다 — 특별한 기술이 기본기가 되는 순간.
특별한 사람의 특별한 기술이 아니라, 일하는 사람의 기본기.
저는 이 순간을 '엑셀 모먼트'라 부릅니다 — 특별한 기술이 기본기가 되는 순간.
STEP 1 — 자산 체크리스트
우리 회사의 데이터가
어디에 있는지부터 정리합니다.
너무 복잡하게 생각하지 마세요.
지금 쓰는 도구를 그냥 쭉 나열하거나, 담당자들에게 받으면 됩니다. 그게 전부입니다.
지금 쓰는 도구를 그냥 쭉 나열하거나, 담당자들에게 받으면 됩니다. 그게 전부입니다.
STEP 1 — 도구 목록, 이 정도면 충분합니다
문서·파일
구글드라이브, NAS, 공유폴더 — 파일이 쌓이는 곳
소통
슬랙, 카톡, 메일 — 대화와 결정이 쌓이는 곳
지식·기록
노션, 위키, 회의록 도구
서비스 인프라
서비스가 있다면 — AWS, 서버, DB
업무 시스템
ERP, 인사·회계, CS 툴
구독 SaaS
유료로 쓰는 것 전부 — 월 비용과 인원까지
이 목록이 — 여러분 회사 AI 전환의 지도가 됩니다.
STEP 1 — 자산 체크리스트
특히 이 줄 —
"데이터가 어디에 쌓이는지."
회의록 SaaS의 회의록은 어디에 있습니까?
CS 툴의 고객 문의 기록은요?
대부분 — 남의 서버에 있습니다.
CS 툴의 고객 문의 기록은요?
대부분 — 남의 서버에 있습니다.
STEP 1 — 자산 체크리스트
직원들 개인 요금제의 합계
= 회사의 숨은 AI 예산.
이미 다들 각자 쓰고 있습니다. 회사가 모를 뿐.
이 숫자를 세어보면 — "도입할까 말까"가 아니라
"이미 도입돼 있는데 관리가 안 되고 있구나"가 됩니다.
이 숫자를 세어보면 — "도입할까 말까"가 아니라
"이미 도입돼 있는데 관리가 안 되고 있구나"가 됩니다.
업계는 이걸 Shadow AI라 부릅니다 — 직원의 90%가 개인 AI를 업무에 쓰는데, 기업 구독을 갖춘 회사는 40%뿐 (MIT).
STEP 2 — 자산의 내재화
그 모든 도구의 데이터에,
한 사람의 PC에서
다 접속되게 해보세요.
다소 개발적으로 들리지만 — 아까 말한 '만들기' 경험자 한 명만 있어도 됩니다.
드라이브도, 슬랙도, 노션도, DB도 — 그 한 명의 자리에서 다 열리게.
드라이브도, 슬랙도, 노션도, DB도 — 그 한 명의 자리에서 다 열리게.
STEP 2 — 자산의 내재화
흩어져 있던 회사 데이터가, 처음으로 한 자리에 모이는 경험.
STEP 2 — 자산의 내재화
그 한 사람이 대표거나
최고 권한 관리자면, 베스트.
데이터 전체를 볼 권한과 판단을 같이 가진 사람이니까요.
아니라면 — 누구에게 이 자리를 줄지, 한 번은 진지하게 고민하셔야 합니다.
아니라면 — 누구에게 이 자리를 줄지, 한 번은 진지하게 고민하셔야 합니다.
STEP 3 — 여기서 제일 추천하는 것
유료 도구 중 내부에서만 쓰는 건,
전부 바이브코딩으로 만드세요.
무조건.
회의록이든, ERP든, 근태·회의실 예약이든, HR이든 — 전부요.
요새는 슬랙도 그냥 만들어 쓰라고 하는 팀이 있을 정도입니다.
요새는 슬랙도 그냥 만들어 쓰라고 하는 팀이 있을 정도입니다.
간단한 계산 하나
직원 50명이 슬랙을
소통 허브로만 쓴다면 —
100만
월 — 50명 × 2만 원
1,200만
연 — 바로 세이브되는 금액
고도화된 기능은 안 쓰고 소통 허브로만 쓰는 팀 — 생각보다 많습니다.
그런 팀에겐 이게 바로 보이는 절감 포인트입니다.
그런 팀에겐 이게 바로 보이는 절감 포인트입니다.
※ 인당 2만 원대 유료 플랜 기준의 단순 계산입니다 — 요금제에 따라 달라집니다.
"만들어 쓰면 유지보수는 누가 하나요?"
당연한 걱정입니다. 그런데 —
유지보수의 관점이 달라진 세상입니다.
1막에서 말씀드린 그대로입니다.
테스트도, 리팩토링도, 디버깅도 AI가 먼저 제안하고 수행하는 시대 —
코드 프리징이 아니라 '정비소'의 관점으로 보시면 됩니다.
테스트도, 리팩토링도, 디버깅도 AI가 먼저 제안하고 수행하는 시대 —
코드 프리징이 아니라 '정비소'의 관점으로 보시면 됩니다.
매달 나가는 그 구독료 —
데이터는 남의 서버에 쌓입니다.
회의록도, 고객 문의도, 업무 기록도. 회사의 가장 좋은 데이터가 회사 밖에.
STEP 3 — 단, 판별 기준
다 만들라는 게
아닙니다.
이 판별을 잘못하면 오히려 관리 지옥이 됩니다.
기준은 명확합니다 —
기준은 명확합니다 —
자사화 판별표
그냥 쓰세요
- B2C 고객에게 서비스하는 것
- 관리 포인트가 너무 많은 것
- 결제·회계 등 규제가 무거운 것
- 표준 기능으로 충분한 것
자사화 후보
- 내부에서만 쓰는 것
- 핵심 가치가 LLM으로 대체 가능한 것
- 데이터가 자산 가치인 것
- "이 기능만 있으면"이 반복되는 것
내부에서만 쓰는 거잖아요. 충분히 내재화해서 써도 됩니다.
STEP 3 — 좋은 첫 후보
회의록. CS 응대. 문서 분류.
STT + 요약, 문의 분류, 지식 검색 —
핵심 가치가 이미 LLM으로 대체 가능해진 것들.
그리고 셋 다, 데이터가 회사의 자산이 되는 것들.
핵심 가치가 이미 LLM으로 대체 가능해진 것들.
그리고 셋 다, 데이터가 회사의 자산이 되는 것들.
자사화 원칙 ①
제품은 얇게,
지능은 에이전트로.
제품 안에 AI를 또 만들지 마세요.
제품은 UI와 도메인 로직만 — 지능이 필요하면 워크스페이스의 에이전트를 호출하게.
그래야 제품이 늘어도 같은 패턴으로 갑니다.
제품은 UI와 도메인 로직만 — 지능이 필요하면 워크스페이스의 에이전트를 호출하게.
그래야 제품이 늘어도 같은 패턴으로 갑니다.
자사화 원칙 ②
$12 서버로 시작하세요.
과설계 금지.
실화: 어느 회사의 회의록 서비스 — 월 $12짜리 서버에, 하루 만에 실서버 배포.
지금도 잘 돌아갑니다. AI 시대의 가장 흔한 낭비가 인프라부터 크게 잡는 것.
실화: 어느 회사의 회의록 서비스 — 월 $12짜리 서버에, 하루 만에 실서버 배포.
지금도 잘 돌아갑니다. AI 시대의 가장 흔한 낭비가 인프라부터 크게 잡는 것.
자사화 원칙 ③
담당 직원을 정하세요.
그 사람이 다음 챔피언이 됩니다.
외부가 만들어주고 떠나면 그건 또 하나의 외주일 뿐.
내부 담당자가 직접 굴리고 고칠 수 있어야 —
이 제품이 조직의 학습이 됩니다.
내부 담당자가 직접 굴리고 고칠 수 있어야 —
이 제품이 조직의 학습이 됩니다.
그다음은 루프
만들고 → 굴리고 → 데이터가 쌓이고 → 에이전트에 물리고 → 다시.
Trial & Error 루프
자사화는 끝이 아니라
시작입니다.
① 바이브코딩으로 만들고 → ② 담당자가 직접 컨트롤하고 →
③ 제품의 데이터를 독립적으로 관리하고 → ④ 그 데이터를 에이전트에 물리고 →
⑤ 에이전트가 할 일을 업무 조사로 다시 찾고 → 반복.
③ 제품의 데이터를 독립적으로 관리하고 → ④ 그 데이터를 에이전트에 물리고 →
⑤ 에이전트가 할 일을 업무 조사로 다시 찾고 → 반복.
두 번째 자사화는
더 싸고, 더 빠릅니다.
같은 패턴이니까요.
환경이 한번 깔리면 — 그다음 업무의 한계비용이 급감합니다.
이게 "환경이 먼저, 제품은 따라온다"의 경제학입니다.
환경이 한번 깔리면 — 그다음 업무의 한계비용이 급감합니다.
이게 "환경이 먼저, 제품은 따라온다"의 경제학입니다.
STEP 4 — 위임 (Delegation)
이제 각 담당자에게
넘기세요.
바이브코딩한 제품이 있다면 그걸 맡기는 게 베스트.
없다면 — 담당자가 회사 데이터로 자기 업무에 필요한 걸 직접 만들게 하세요.
최소한, 자기 업무의 대시보드라도.
없다면 — 담당자가 회사 데이터로 자기 업무에 필요한 걸 직접 만들게 하세요.
최소한, 자기 업무의 대시보드라도.
STEP 4 — 위임 (Delegation)
자기 업무의
대시보드를 만들게 하세요.
자기 일이 한눈에 보이는 화면 하나 — 이건 너무 당연한 시작입니다.
만들게 하고, 쓰게 하고, 데이터를 계속 넣게 하세요.
그리고 보통은, 그렇게 됩니다.
만들게 하고, 쓰게 하고, 데이터를 계속 넣게 하세요.
그리고 보통은, 그렇게 됩니다.
왜 그렇게 되냐면
엑셀을 한번 써본 사람 중에,
엑셀을 안 쓰는 사람은 없습니다.
자기 대시보드를 한번 써본 담당자도 — 정확히 같습니다.
여기까지 굴리기 시작했다면 — 운영 원칙 몇 가지
좋은 워크플로우는 승격,
환경은 계속 갱신.
개인의 산출물이 개인 PC에서 휘발되지 않게 —
좋은 것은 팀 공용으로 올리고, 모델과 도구는 계속 최신으로.
모델은 계속 바뀝니다. 환경을 살아있게 유지하는 게 운영의 실체.
좋은 것은 팀 공용으로 올리고, 모델과 도구는 계속 최신으로.
모델은 계속 바뀝니다. 환경을 살아있게 유지하는 게 운영의 실체.
이 시점부터 벌어지는 중요한 일
이제 규칙을 정하기 시작합니다.
규칙 1
되돌리기 어려운 일은 게이트
발송·배포·삭제는 반드시 사람 승인 후
규칙 2
떠나도 굴러가게
인수인계 없는 구축은 완료가 아니다
규칙 3
자동화보다 신뢰
사고 한 번이면 AX는 6개월 뒤로 밀린다
막 만들며 일해온 것들에서 규칙이 생기고, 규칙이 가드레일이 되고 —
그 가드레일이 우리 회사의 또 다른 원칙이 됩니다.
그 가드레일이 우리 회사의 또 다른 원칙이 됩니다.
그리고 한 가지, 착각하지 마세요
직원들이 교육받고 AI를 잘 쓴다고,
AI 조직이 된 게 아닙니다.
교육하는 회사가 드리는 말씀입니다.
잘 쓰는 직원은 시작일 뿐 — 2막에서 보셨듯,
'AI 잘 쓰는 직원이 있는 회사'와 'AI 조직'은 다릅니다.
잘 쓰는 직원은 시작일 뿐 — 2막에서 보셨듯,
'AI 잘 쓰는 직원이 있는 회사'와 'AI 조직'은 다릅니다.
완료의 기준
느낌이 아니라,
재현으로.
시작할 때 "잘된 결과물" 샘플 10건을 모아두세요 — 잘 쓴 보고서, 좋았던 답변.
새로 만든 것이 그 결과물을 재현하는가 —
이게 저희가 쓰는 검수 기준의 전부입니다.
새로 만든 것이 그 결과물을 재현하는가 —
이게 저희가 쓰는 검수 기준의 전부입니다.
STEP 5 — 에이전트로의 진화
드디어, 에이전트입니다.
플레이북의 마지막 스텝이자 — 오늘 이야기의 클라이맥스입니다.
그런데 그 직전에, 여러분 회사엔 아마 이런 일이 벌어지고 있을 겁니다.
그런데 그 직전에, 여러분 회사엔 아마 이런 일이 벌어지고 있을 겁니다.
STEP 4까지 잘 왔다면, 반드시 생기는 일
작업물이 사방에 흩어지기
시작합니다.
각자 알아서 — 자기 로컬에서, 자기 계정으로.
깃헙 · Vercel · Firebase · AWS…
잘 되고 있다는 신호이자, 다음 문제의 시작입니다.
깃헙 · Vercel · Firebase · AWS…
잘 되고 있다는 신호이자, 다음 문제의 시작입니다.
그래서 이 시점에 해야 하는 것
인프라 자산을 하나로 통합하는
원칙과 구조를 만드세요.
그리고 특히 중요한 결정 하나 —
프롬프트, 회의, 대화… 우리가 만드는 '날것' 데이터 중
무엇을 회사 자산에 넣고, 무엇을 뺄 것인가.
프롬프트, 회의, 대화… 우리가 만드는 '날것' 데이터 중
무엇을 회사 자산에 넣고, 무엇을 뺄 것인가.
2026년 업계가 컨텍스트 엔지니어링(Context Engineering)이라 부르기 시작한 일이 정확히 이겁니다 — 프롬프트가 아니라, AI에게 무엇을 기억하게 할지의 설계.
"그걸 왜 STEP 1에서 미리 안 했나요?"
스스로 겪어봐야 하기 때문입니다.
구성원들이 AI로 일하며 협업의 애로를 직접 경험해봐야 —
이런 구조가 왜 필요한지, 그리고 이렇게 해야 자기 효능감과 효율이 생긴다는 것을
이해하게 됩니다. 순서가 곧 설득입니다.
이런 구조가 왜 필요한지, 그리고 이렇게 해야 자기 효능감과 효율이 생긴다는 것을
이해하게 됩니다. 순서가 곧 설득입니다.
회의 음성 파일만 있으면 —
일은 무조건 됩니다.
팀이 이 생각에 도달하는 순간부터 — 모든 회의의 원본 음성을, 누가 시키지 않아도 무조건 기록하게 됩니다. 자산의 기준이 스스로 잡히는 순간입니다.
구조가 생기면, 다음 차이가 보이기 시작합니다
로컬에서 일하는 것과
서버에서 에이전트로 일하는 것.
내 자리의 Claude Code·Codex와, 서버에 상주하는 에이전트 —
그 경험의 차이를 스스로 인지하고, 다양한 시도를 하게 됩니다.
Hermes, OpenClaw, CrewAI, Managed Agents, LangChain…
다시 한번 '도구를 다루는 챔피언'의 존재가 중요해지는 단계입니다.
그 경험의 차이를 스스로 인지하고, 다양한 시도를 하게 됩니다.
Hermes, OpenClaw, CrewAI, Managed Agents, LangChain…
다시 한번 '도구를 다루는 챔피언'의 존재가 중요해지는 단계입니다.
가장 쉬운 첫 애드온
전 직원에게, 비서를 한 명씩 붙여주세요.
STEP 5 — 1인 1비서
회사의 지식을 주고 (권한에 맞춰),
행정 업무부터 맡기세요.
휴가 등록 · 회의록 보고 · 회의실 예약 —
모든 직원이 비서를 가진 것처럼.
단, 코드와 프롬프트는 회사 서버에 — 개인 PC가 아니라.
모든 직원이 비서를 가진 것처럼.
단, 코드와 프롬프트는 회사 서버에 — 개인 PC가 아니라.
그리고 — 비서 하나를 붙여보는 순간
이 여정에서 가장 재밌는 지점이
시작됩니다.
저희도 예상 못 했던 발견이었습니다.
에이전트를 만드는 건,
쉽습니다.
데이터 놓고, 도구 주고, 모델 고르고, 가드레일 치고 — 끝.
진심으로, 만드는 것 자체는 쉬워졌습니다.
진심으로, 만드는 것 자체는 쉬워졌습니다.
어려운 건
따로 있었습니다.
이 에이전트가 잘 만들어졌는지는 —
팀에서 그의 역할이 정의되어야만
판단할 수 있다.
성능의 문제가 아니었습니다. 조직의 문제였습니다.
에이전트 설계는
개발이 아니라, 조직론이었습니다.
생각해 보면 이 시점의 팀에는 —
1막에서 말한 '전복'을 직무에서 직접 겪은 사람들이 있고, 각자의 일하는 감각이 있고,
이제는 우리 회사의 업무 흐름을 보여주는 데이터까지 있습니다.
그러니 드디어 — 우리의 '일'과 '워크플로우' 자체를 이야기하게 되는 겁니다.
1막에서 말한 '전복'을 직무에서 직접 겪은 사람들이 있고, 각자의 일하는 감각이 있고,
이제는 우리 회사의 업무 흐름을 보여주는 데이터까지 있습니다.
그러니 드디어 — 우리의 '일'과 '워크플로우' 자체를 이야기하게 되는 겁니다.
그래서 팀은 이런 실험을 시작합니다
일 × 에이전트 —
매트릭스를 짜고, 실험합니다.
가로축엔 우리의 업무 흐름, 세로축엔 에이전트의 역할 —
어떤 일을 사람이 갖고, 어떤 일을 에이전트에 맡기고, 어디서 만나게 할지.
이 직교 구조를 어떻게든 짜보고, 굴려보고, 다시 짭니다.
어떤 일을 사람이 갖고, 어떤 일을 에이전트에 맡기고, 어디서 만나게 할지.
이 직교 구조를 어떻게든 짜보고, 굴려보고, 다시 짭니다.
이 일의 정체
회사를 창업하고,
첫 직원을 뽑는 일과 같습니다.
누구를 뽑아야 하고, 왜 뽑아야 하고, 어떤 일을 맡길지 —
그 일을 어느 정도로 줄지, 권한과 책임을 어떻게 바라볼지.
에이전트를 조직에 들이는 일이, 정확히 이 결정들입니다.
그 일을 어느 정도로 줄지, 권한과 책임을 어떻게 바라볼지.
에이전트를 조직에 들이는 일이, 정확히 이 결정들입니다.
자기 돈으로 사람을
고용해본 사람의 감각이,
여기서 빛납니다.
개인의 사이드 프로젝트가 아니니까요.
회사의 자산이고, 회사의 비용(토큰)을 쓰는 문제라 —
오히려 더 진지하게 생각할 수밖에 없습니다.
회사의 자산이고, 회사의 비용(토큰)을 쓰는 문제라 —
오히려 더 진지하게 생각할 수밖에 없습니다.
그리고 이 일은
혼자 할 수 없습니다.
같이 만들고, 같이 실험하는 존(zone)을
구축하게 됩니다.
실험하고, 결과를 보고, 다시 실험하는 —
지극히 스타트업이 잘하는, 가장 익숙한 존으로 들어오는 겁니다.
지극히 스타트업이 잘하는, 가장 익숙한 존으로 들어오는 겁니다.
그 존에서 —
회사의 세계관이
에이전트로 투영됩니다.
때로는 개인의 세계관까지. 생각해 보세요 — 모든 동료가 자신의 문제의식으로 에이전트를 1개부터 N개까지, 데이터와 권한, KPI, 비용(토큰)까지 스스로 고민하며 조직을 만드는 일.
고백하자면
저도 이 방식으로 일하도록
'강제'받고 있습니다.
그런데 — 즐겁습니다.
스타트업 조직을 만들고 싶어 하는 대표라면 아실 겁니다.
동료들이 각자의 세계관으로 조직을 설계하는 걸 지켜보는 일이
얼마나 즐거운 일인지.
동료들이 각자의 세계관으로 조직을 설계하는 걸 지켜보는 일이
얼마나 즐거운 일인지.
우리의 실험실 — 저희가 그 존을 직접 굴려보는 곳
커리어리 — 42만 명이 가입한
실제 서비스에서
실험 중입니다.
저희가 인수해 운영하는 커리어 플랫폼.
이 팀을 지금, 이렇게 굴립니다 —
이 팀을 지금, 이렇게 굴립니다 —
커리어리 팀 구성
사람 3명 + 에이전트 4명.
여기서 매일 배우는 것
에이전트에게 일을 주는 게 아니라,
역할을 주는 것.
"이 문서 요약해줘"는 일. "너는 우리 팀의 데이터 분석 담당이야"는 역할.
역할이 생기면 — 팀의 협업 구조 안에 에이전트의 자리가 생깁니다.
역할이 생기면 — 팀의 협업 구조 안에 에이전트의 자리가 생깁니다.
그리고 이 관찰
잘 쓰는 사람은 일하는 내내
AI에게 자기 안목과 판단의 근거를
말합니다.
왜 이 방향인지, 뭐가 중요한지, 어떤 건 안 되는지 —
혼잣말처럼 계속.
혼잣말처럼 계속.
그 맥락이 에이전트에 쌓이면 —
그 사람이 떠나도,
판단력은 회사에 남습니다.
'핵심 인력 의존' 문제의 — 기술적 해법.
이런 실측 보고도 있습니다 — 회사 맥락(institutional context) 없이 굴리는 에이전트는 정확도가 38%까지 떨어진다는 것 (업계 실측).
그래서 에이전트는
판단이 응축되어, 조직에 남는 그릇입니다.
3막을 닫으며
이 모든 것이 하나의 존에서 —
회사 서버, 회사 깃헙, 회사 레이어에 커넥티드되어.
회사 서버, 회사 깃헙, 회사 레이어에 커넥티드되어.
4
도착점 — 남는 회사
이 여정의 끝에는 뭐가 있나
도착점
AI가 회사 업무에 '항상 살아있는' 상태.
이런 회사에, 올해 이름이 생겼습니다
Frontier Firm —
AI가 운영하고, 사람이 이끄는 회사.
Microsoft가 M365 업무 신호 수조 건과 10개국 2만 명 설문을 분석해 내놓은 조직 진화 3단계 —
① AI 어시스턴트와 일하는 사람 → ② 사람이 이끄는 에이전트 →
③ 사람이 이끌고, 에이전트가 운영하는(agent-operated) 조직.
① AI 어시스턴트와 일하는 사람 → ② 사람이 이끄는 에이전트 →
③ 사람이 이끌고, 에이전트가 운영하는(agent-operated) 조직.
Microsoft Work Trend Index 2026. — 저희가 현장에서 그려온 지도와, 같은 그림입니다.
그곳에서 일은 세 레이어로 굴러갑니다
레이어 1
사람이 하는 일
가치 판단, 책임지는 결정, 관계
레이어 2
AI가 돕는 일
분석, 초안, 검토, 정리
레이어 3
AI가 직접 하는 일
반복 업무, 모니터링, 자동 워크플로우
이 구분선을 회사마다 자기 손으로 긋게 되는 것 — 그게 전환의 실체입니다.
Practice들이 시도되고,
실패하고, 성공하고 —
회사의 문화로 정착합니다.
한 방의 도입이 아니라, 계속되는 실험의 누적.
그게 AX 조직의 실체입니다.
그게 AX 조직의 실체입니다.
그리고 우리 회사 얘기로 끝내자면
저희도 이 여정을
그대로 지나왔습니다.
전복당했고(1막), 구덩이에 빠졌고(2막),
플레이북을 만들며 나왔습니다(3막). 그리고 도착한 곳에서 —
저희 회사의 정의가 바뀌어 있었습니다.
플레이북을 만들며 나왔습니다(3막). 그리고 도착한 곳에서 —
저희 회사의 정의가 바뀌어 있었습니다.
이제 우리는 개발을 대행하는 회사가 아니라,
그 일을 할 에이전트를 만드는 회사가
돼 버렸습니다.
구체적으로는, 이렇게 일합니다
①
개발 의뢰가 오면
코드를 만드는 값은 0원에 가깝게 — 값은 환경과 운영에 매깁니다
②
에이전트를 만들고
그 일을 할 개발 에이전트를 먼저 셋업합니다
③
50%쯤 함께 개발
에이전트로 절반을 만들어 보여드리고
④
환경을 남깁니다
고객사가 직접 그 에이전트로 일하는 환경을 구축
그리고 그 제품에서 시작해 — AX 전환을 함께 하는 파트너 팀이 되어가고 있습니다.
실무자인 당신에게
당신의 에이전트를
회사 자산으로 만드는 사람이,
다음 시니어입니다.
혼자 잘 쓰는 사람은 이미 많습니다.
팀이 같이 쓰게 만드는 사람은 — 아직 아주 귀합니다.
팀이 같이 쓰게 만드는 사람은 — 아직 아주 귀합니다.
Microsoft는 올해 이 역할에 이름을 붙였습니다 — agent boss: 에이전트를 만들고, 위임하고, 관리하는 사람.
대표인 당신에게
오늘의 자산 점검 체크리스트,
그대로 시작하세요.
제품 / 프로토타입 / SaaS 전수 / 외주 계약 / 업무 도구 / AI 사용 실태 —
여섯 칸을 채우는 데 하루면 됩니다.
그 표가 여러분 회사 AX의 1페이지가 됩니다.
여섯 칸을 채우는 데 하루면 됩니다.
그 표가 여러분 회사 AX의 1페이지가 됩니다.
그리고, 믿게 된 것 하나
결국 모든 회사에
AI 엔지니어가 필요한
세상이 오고 있습니다.
머신러닝 연구자 얘기가 아닙니다 — AI로 일이 되게 만드는 사람.
그 사람이 기존 개발팀에서 나오든, 비개발팀에서 나오든 —
누군가는 있어야 합니다.
그리고 없다면, 저희 같은 함께할 파트너를 찾게 되실 거라 믿습니다.
그 사람이 기존 개발팀에서 나오든, 비개발팀에서 나오든 —
누군가는 있어야 합니다.
그리고 없다면, 저희 같은 함께할 파트너를 찾게 되실 거라 믿습니다.
추세가 이미 그렇습니다 — '에이전트 운영(agentic ops)' 전담자를 지정한 기업: 2024년 11% → 2026년 56% (업계 조사).
AI 시대의 전문성이 개인의 것이라면 —
AI 시대의 경쟁력은,
회사에 남긴 것입니다.
SEESO · SECONDTEAM — 그래서, 함께할 팀을 찾습니다
저희 솔루션으로 함께 실험할
파트너 팀을 찾습니다.
2016년 아웃소싱의 실험으로 시작해, 지금은 회사에 남는 AI를 만듭니다.
세컨팀 — 회사 안에서 일하는 AI 팀 · 커리어리 — 에이전트 팀이 굴리는 42만 플랫폼
오늘 이야기한 여정 어딘가에 계시다면 — 관심 있는 팀이라면, 편하게 이야기 나눠요.
second-team.com
세컨팀 — 회사 안에서 일하는 AI 팀 · 커리어리 — 에이전트 팀이 굴리는 42만 플랫폼
오늘 이야기한 여정 어딘가에 계시다면 — 관심 있는 팀이라면, 편하게 이야기 나눠요.
second-team.com
감사합니다 🙌
박병규 · 시소 / 세컨팀 · second-team.com
BEHIND THIS CHAT — 이 에이전트의 구성
지금 대화하실 상대는,
이렇게 만들어졌습니다.
① 지식 — '날것'의 자산화마크의 구술 원문과 이 발표 166장 전문이 통째로 컨텍스트에 들어가 있습니다. "무엇을 회사 자산에 넣을 것인가" — 그 결정의 결과물입니다.
② 세계관 — 페르소나마크의 어투, 상담 문답 패턴, 판단 기준. "회사의 세계관이 에이전트로 투영된다"가 바로 이겁니다.
③ 행동 — 도구 4개비용 계산 · 자료 접수 · 단계 진단 기록 · 마크와의 미팅 어레인지. 일이 아니라 '역할'을 받았습니다.
④ 가드레일 — 운영 원칙10문 10답 제한, 가격 확약 금지, 발송·확정은 사람 승인. 발표의 규칙이 이 에이전트에게도 그대로 적용됩니다.
이 대화는 회사 서버에 쌓입니다 — '회사에 남는 AI'는 컨셉이 아니라 구조입니다.
여러분 회사에도, 이런 동료를 붙일 수 있어요.
여러분 회사에도, 이런 동료를 붙일 수 있어요.
M
마크 에이전트
온라인 · 이 발표를 만든 팀의 에이전트
10문 10답 · 10
오늘
← → 이동 · F 전체화면
M
📱 가로로 눕히면 더 잘 보여요