일하는 ai

✍️ 13. 남는 일은 고객 옆에 있다

32 min read

-

AI가 문서를 쓰고, 화면을 만들고, 분석을 대신하고, 코드까지 뽑아내는 시대에 사람들은 자연스럽게 같은 질문으로 모인다. 그러면 이제 내게 무엇이 남는가. 이 질문은 얼핏 직업 생존에 대한 질문처럼 들린다. 하지만 실제로는 그보다 더 깊다. 내가 하던 일의 본질은 무엇이었는지, 내가 경쟁력이라고 믿었던 것들 중 무엇은 사실 본질이 아니었는지, 그리고 도구가 강해질수록 오히려 더 선명해지는 인간의 역할은 무엇인지 묻는 질문이다.

얼마 전 모두의연구소에서 열린 세미나를 들으며 오래 남은 것도 바로 이 지점이었다. 강의 제목부터 꽤 직설적이었다. “AI는 다 알고 있습니다, OO만 빼고요: AI가 대체할 수 없는 고객 집착과 문제 해결 역량.” 나는 이 제목이 좋았다. 요란한 낙관도, 값싼 위기감도 아니었기 때문이다. AI가 강해질수록 결국 인간의 일은 더 본질 쪽으로 밀려난다는 사실을, 이 제목은 처음부터 정면으로 인정하고 있었다.

모두의연구소 현장 슬라이드. 이 강의의 문제의식은 처음부터 분명했다. 도구의 성능이 높아질수록, 인간의 경쟁력은 기능 생산보다 고객과 문제 쪽으로 이동한다.

이 글은 그 강의를 단순히 요약하려는 글이 아니다. 오히려 그 강의가 왜 오래 남는지, 왜 이 주제가 지금 특히 중요해졌는지, 그리고 나는 어디까지 동의하고 어디에서 더 확장해서 읽었는지를 붙여 하나의 에세이로 정리해보려는 글에 가깝다. 결론부터 말하면 나는 이 강의의 핵심 메시지에 대체로 동의한다. 다만 그 메시지는 “PM은 살아남는다” 같은 직군 보호 선언으로 읽으면 오히려 얕아진다. 더 정확히는 이렇다. 직함은 흔들려도, 고객을 읽고 문제를 정의하고 해결 가능한 크기로 바꾸는 기능은 한동안 더 비싸질 가능성이 크다.

AI 활용 고지: 이 글은 생성형 AI를 활용해 강의 전사를 구조화하고 초안을 확장한 뒤, 원문과 참고 링크를 다시 확인하며 표현과 해석을 다듬어 완성했습니다. 본문 시각자료는 Nano Banana 기반 이미지 생성과 카드 렌더링을 활용해 제작했습니다.

원문과 참고 링크

flowchart TD
A[웹마스터] --> B[서비스 기획자]
B --> C[PM · PO]
C --> D[그로스 · 데이터 PM]
D --> E[AI 시대의 대통합]
E --> F[직함보다 기능이 남는다]
F --> G[고객 이해]
F --> H[문제 정의]
F --> I[해결 가능한 수준으로 쪼개기]

이 직군은 원래부터 애매했고, 그래서 더 불안해졌다

세미나가 좋았던 첫 번째 이유는 청중의 불안을 너무 빨리 처방하지 않았다는 점이다. 연사는 먼저 PM과 PO, 혹은 기획 직군이 원래부터 얼마나 흔들려 온 역할인지 차근차근 짚었다. 웹마스터, 서비스 기획자, PM, PO, 그로스 PM, 데이터 PM. 이름은 계속 바뀌었고, 이름이 바뀔 때마다 사람들은 늘 비슷한 질문을 했다. 그게 뭐가 다른데? 결국 비슷한 일 하는 거 아니야? 왜 이렇게 이름만 자꾸 바뀌어?

이 장면은 중요하다. 지금의 불안을 AI라는 외부 충격 하나로만 읽으면, 사람은 지나치게 빨리 공포에 압도되기 쉽다. 하지만 이 직군의 역사를 조금만 길게 보면, 원래부터 이 역할은 조직이 필요로 하는 변화의 압력을 가장 먼저 받는 자리였다. 과거의 기획자는 거대한 요구사항을 수집하고, 산출물을 만들고, 일정과 이해관계를 조율하는 역할이었다. 그러다 제품 중심 조직이 등장하면서 고객과 데이터를 읽고, 실험하고, 우선순위를 바꾸고, 팀의 방향을 조정하는 역할이 더 중요하다고 말하기 시작했다. 다시 말해 이 역할은 원래부터 고정된 직업이 아니라, 변화가 생길 때마다 가장 먼저 다시 정의되는 기능 묶음에 가까웠다.

그래서 AI가 들어온 지금의 불안은 일종의 가속된 버전이다. 원래도 애매했던 역할이, 이제는 너무 많은 도구가 너무 많은 중간 노동을 대신하면서 더 근본적인 질문 앞에 서게 된 것이다. 도대체 무엇이 남는가. 여기서 나는 강의의 톤이 마음에 들었다. “PM은 안전합니다”도 아니고 “이제 PM은 끝났습니다”도 아니었다. 대신 “이름이 아니라 기능을 보자”는 쪽으로 방향을 틀었다. 이건 더 성숙한 접근이다.

내가 보기에도 AI가 가장 먼저 가져간 것은 손이 많이 가는 중간 단계들이다. 문서 초안, 아이디어 1차 정리, 화면 시안, 기본 SQL, 기본 리서치, 1차 분류, 회의록 정리 같은 것들. 문제는 많은 사람이 이 중간 단계를 자기 일의 본체라고 착각해 왔다는 점이다. 그래서 그것이 줄어들면 자기 존재 이유까지 줄어드는 느낌을 받는다. 하지만 차분히 보면 그 단계들은 본질이라기보다 본질을 둘러싼 노동의 껍질에 더 가까운 경우가 많았다.

AI 시대의 가장 흔한 착시는 “빨리 만들 수 있으면 더 가치 있다”는 생각이다

OpenAI가 ChatGPT를 소개할 때, 사람들은 처음으로 “말 몇 줄로도 제법 쓸 만한 결과가 나온다”는 충격을 경험했다. 그 뒤로 이 충격은 일상의 언어가 됐다. 요약해줘, 초안 써줘, 분석해줘, 화면 만들어줘, 코드로 바꿔줘. 이 모든 것이 너무 쉽게 일어나기 시작하면서 사람들은 은근히 같은 착시에 빠진다. 생성 속도가 빨라지면 가치도 자동으로 커질 것이라는 착시다.

하지만 제품과 서비스는 그렇게 움직이지 않는다. 속도는 가치의 일부일 뿐, 가치 자체는 아니다. 사용자가 사는 것은 보통 기능이 아니라 해결이다. 더 정확히 말하면 해결의 형태다. 빠른 답이 필요한 사람도 있지만, 많은 경우 사용자가 진짜로 사고 있는 것은 신뢰, 맥락, 설명력, 사람의 책임감, 혹은 예측 가능한 경험이다. 그래서 AI가 아무리 빨리 답을 주더라도 그 답이 사용자가 원래 원했던 가치와 어긋나면, 그 순간 속도는 장점이 아니라 잡음이 된다.

Anthropic의 「What 81,000 people want from AI」를 보면 사람들은 AI에게 단순히 더 빨리 일하게 해달라고만 말하지 않는다. 오히려 더 자주 말하는 것은 삶의 마찰을 줄여 달라는 요청이다. 반복 업무를 덜고 싶고, 더 중요한 판단에 집중하고 싶고, 더 덜 불안하게 배우고 싶고, 덜 외롭게 버티고 싶다고 말한다. 이 차이는 매우 중요하다. 사람들은 시간을 원하지만, 그 시간을 원하는 이유는 시간 자체가 아니라 다른 더 중요한 것에 주의를 다시 배치하기 위해서다. AI가 이 지점을 놓치는 순간, 제품은 기능은 늘었는데 삶은 하나도 좋아지지 않는 이상한 상태로 미끄러진다.

이것이 내가 요즘 자주 느끼는 위화감이기도 하다. 많은 조직이 “우리도 AI 붙였다”는 사실로 스스로를 설득한다. 하지만 사용자는 훨씬 단순한 질문을 던진다. 그래서 내 문제가 더 잘 풀렸나? 이 질문 앞에서 머뭇거리면, 대개 그 기능은 예쁘게 실패한다.

고객 집착은 낡은 구호가 아니라, 도구가 강해질수록 더 중요해지는 방향 감각이다

고객 집착이라는 말은 너무 유명해서 오히려 낡아 보이기도 한다. 하지만 낡아 보인다는 이유로 중요하지 않은 것은 아니다. Amazon이 리더십 원칙의 맨 앞에 여전히 Customer Obsession을 두는 이유는 단순한 상징이 아니다. 도구가 강해질수록 조직은 더 자주 ‘무엇이 가능한가’ 쪽으로 기울고, 그럴수록 누군가는 계속 ‘무엇이 정말 의미 있는가’를 붙들고 있어야 하기 때문이다.

세미나에서 가장 강하게 남은 사례도 여기 있었다. 커리어 커뮤니티 서비스에서 AI 답변 기능을 붙였던 이야기다. 겉으로 보면 너무 자연스러운 시도다. 사용자는 질문을 올리고, 현직자 답변을 기다린다. 답은 느릴 수 있다. 그러니 AI가 더 빨리 답을 주면 좋지 않을까? 기능은 실제로 만들어졌고, 당시로서는 꽤 빠르고 과감한 시도였고, 언론에도 소개됐다. 그런데 결과는 좋지 않았다. 만족도는 낮았고, 사용자는 그 기능을 핵심 가치로 받아들이지 않았다.

이 실패가 중요한 건 단순히 성능이 부족해서가 아니다. 더 본질적인 이유는 사용자가 그 서비스에서 사던 것이 ‘빠른 답변’이 아니라 ‘현직자에게서 오는 신뢰 가능한 답변’이었기 때문이다. 다시 말해 속도는 가치의 보조선이었지 중심축이 아니었다. 팀은 기술적으로 가능한 질문에 너무 빨리 답했고, 사용자가 실제로 붙들고 있던 가치에는 충분히 닿지 못했다.

나는 이 사례가 지금 AI 도입 실패의 전형을 보여준다고 생각한다. 많은 팀이 이런 순서로 움직인다.

  1. 새로운 모델이 나왔다.
  2. 뭔가 붙일 수 있다.
  3. 붙이면 더 빨라진다.
  4. 그러니 사용자도 좋아할 것이다.

문제는 4번이 너무 자주 검증되지 않은 가정이라는 점이다. 사용자는 단순히 더 빠른 결과물을 원하지 않는다. 어떤 서비스에서는 속도보다 신뢰가 중요하고, 어떤 서비스에서는 설명 가능성이 더 중요하고, 어떤 서비스에서는 인간의 책임 서명이 더 중요하다. 이 차이를 읽지 못하면 AI는 혁신이 아니라 노이즈가 된다.

🧠 칠판 치트시트

  • 속도는 가치의 일부다.
  • 하지만 속도 자체는 핵심가치가 아니다.
  • AI 도입의 질문은 “붙일 수 있나?”가 아니라 “붙였을 때 고객이 원래 사던 가치가 더 선명해지나?”여야 한다.

문제를 잘못 정의하면, 기술은 놀라울 만큼 정확하게 틀린 방향으로 일한다

두 번째 사례는 더 무겁다. 어떤 공간 기반 서비스가 재계약률을 높이고 싶어 했다. 데이터도 있고, 출입 기록도 있고, 사용자 특성도 있고, 머신러닝 모델도 만들었다. KPI도 있고, 모델도 있고, 분석도 있다. 겉으로 보면 꽤 잘하고 있는 것처럼 보인다. 그런데 회의실로 돌아오자 남는 질문은 하나였다. “그래서 이제 무엇을 하면 되나요?”

이 질문 앞에서 많은 분석은 갑자기 공중에 뜬다. 왜냐하면 예측을 만들기 전에, 그 예측이 어떤 행동 변화로 이어져야 하는지가 먼저 정의되어 있어야 하기 때문이다. 누가 무엇을 보고 어떤 결정을 바꾸는가. 어떤 결과가 나오면 어떤 조치를 취하는가. 그 조치가 비즈니스나 경험에 어떤 식으로 연결되는가. 이런 질문 없이 도구를 먼저 들면, 결과는 대개 그럴듯하지만 행동 불가능한 분석이 된다.

이 사례가 강하게 남는 이유는, AI 이전 시대의 실패가 AI 시대에도 그대로 반복될 것임을 보여주기 때문이다. 도구는 바뀐다. 예전에는 머신러닝이었고, 지금은 LLM과 에이전트다. 하지만 실패 구조는 같다. 문제보다 도구를 먼저 사랑하는 순간, 팀은 꽤 많은 에너지를 써서 놀라울 만큼 정확하게 틀린 방향으로 간다.

세미나 후반부에서 연사가 기업 실무자 교육 현장에서 본 장면을 이야기하는 부분도 같은 맥락으로 읽혔다. 많은 사람이 AI를 진짜로 어려워하는 이유는 사용법을 몰라서가 아니라, 자신이 원하는 결과를 명확히 설명하지 못하기 때문이라는 이야기. 나는 이 대목이 특히 현실적이었다. 실제 현업에서 막히는 것은 “툴 버튼이 어디 있지?”보다 “나는 정확히 무엇을 원하고 있지?”다. 자동화하고 싶다는 말은 쉽다. 그런데 무엇을 자동화하고 싶은지, 그 전에 어떤 기준으로 현재 과정을 나눠 봐야 하는지, 자동화 이후에 무엇이 더 좋아져야 하는지까지 적기 시작하면 대부분의 문장은 금세 흐려진다.

이건 단순한 표현력 문제가 아니다. 사고의 단위가 아직 너무 크거나, 너무 욕심이 많거나, 너무 추상적이라는 뜻이다. 결국 문제는 작게 정의될수록 더 잘 풀린다. 반대로 팀이 무너지는 순간은 거의 늘 비슷하다. 문제를 쪼개는 대신 문제 전체의 위엄에 취해버릴 때다.

flowchart LR
A[도구부터 잡는다] --> B[그럴듯한 기능이 빠르게 나온다]
B --> C[핵심가치와 어긋난다]
C --> D[사용자 반응 저조]
D --> E[AI가 별로였다고 오해한다]

F[문제부터 정의한다] --> G[누구의 어떤 맥락인지 적는다]
G --> H[성공 기준을 정한다]
H --> I[도구를 나중에 고른다]
I --> J[작지만 의미 있는 검증이 된다]

생각보다 많은 실무 프레임워크는 사실 한 가지 일을 하고 있었다

강의를 들으며 가장 좋았던 통합 중 하나는 이 부분이었다. KPI, OMTM, 로드맵, 스프린트, 백로그, 우선순위, MVP, PoC, AB 테스트. 겉으로 보면 모두 다른 기법 같고, 시대에 따라 유행도 달랐다. 그런데 연사의 설명을 듣다 보면 결국 이 모든 것이 하나의 일을 하고 있었다는 사실이 보인다. 복잡하고 거대한 문제를 해결 가능한 수준으로 줄이는 일.

로드맵은 모든 요구사항을 동시에 하지 않기 위한 장치다. 스프린트는 긴 시간을 짧은 실행 단위로 자르는 장치다. 우선순위는 다 중요한 것처럼 보이는 것들 사이에서 먼저 풀 문제를 고르는 장치다. MVP는 완벽함의 유혹을 버리고 본질만 검증하기 위한 장치다. AB 테스트는 감으로 싸우지 않고 비교 가능한 단위로 바꾸는 장치다. 결국 이 모든 것은 제품을 예쁘게 포장하는 방법론이 아니라, 사람이 감당 가능한 크기로 문제를 바꾸는 관리 기술이었다.

나는 이 해석이 AI 시대에 특히 중요하다고 생각한다. 만드는 비용이 떨어질수록 무언가를 한 번 만들어보는 것 자체의 희소성은 줄어든다. 그 대신 무엇이 더 희소해질까. 내 생각엔 두 가지다. 첫째는 고객의 맥락을 정확히 읽는 능력이고, 둘째는 너무 큰 문제를 풀 수 있는 크기로 나누는 능력이다. 생성은 쉬워져도 선택은 여전히 어렵다. 구현은 빨라져도 우선순위는 여전히 아프다. 초안은 넘치지만, 무엇을 남기고 무엇을 버릴지는 여전히 인간이 책임져야 한다.

Builder의 시대가 와도, Builder만으로는 부족하다

세미나 후반에는 요즘 자주 나오는 화두도 함께 스쳤다. 이제 PM도 만들 줄 알아야 한다, 기획도 빌더가 되어야 한다, PRD는 줄고 프로토타입이 더 중요해질 것이다, 개발자와 디자이너와 기획자의 경계는 계속 무너질 것이다. 이 방향 자체를 부정하기는 어렵다. 실제로 많은 조직은 이미 그런 방향으로 가고 있다. 나도 교집합은 분명 커질 것이라고 본다. 기획자는 더 많이 만들게 될 것이고, 개발자는 더 많이 제품을 설명하게 될 것이고, 디자이너는 더 많이 전략과 정책에 관여하게 될 것이다.

하지만 나는 동시에 하나의 경계도 필요하다고 생각한다. 도구의 교집합이 커진다고 해서 역할의 중심 감각까지 모두 같아지는 것은 아니다. 가장 많이 만드는 사람이 반드시 가장 중요한 사람은 아니다. 오히려 앞으로 더 비싸지는 사람은 무엇을 만들어야 하는지, 무엇은 만들지 말아야 하는지, 무엇을 먼저 검증해야 하는지를 끝까지 붙드는 사람일 가능성이 크다. 이건 빌더의 반대말이 아니다. 오히려 더 좋은 빌더가 되기 위해서도 먼저 필요한 감각이다.

그래서 나는 “이제 PM도 결국 코드를 쳐야 한다”는 주장에는 절반만 동의한다. 맞다, 더 많이 만들게 될 것이다. 하지만 그것이 본질의 전부는 아니다. 기획자의 본질이 개발자의 느린 버전이 되는 순간, 기획은 대체로 자기를 잃는다. 반대로 고객을 읽고, 문제를 정의하고, 스코프를 자르고, 검증 순서를 정하는 감각을 가진 사람이 조금 더 많이 만들 수 있게 되는 것은 매우 큰 힘이 된다. 차이는 미묘하지만 중요하다.

PoC에서 시장으로, MVP에서 사랑받을 최소치로

강의에서 인상적이었던 또 하나의 대목은, 만드는 비용이 내려갈수록 PoC와 MVP의 의미도 달라질 수 있다는 관측이었다. 예전에는 만들기 자체가 비쌌기 때문에 “기술적으로 가능한가”를 먼저 물었다면, 이제는 “가능한 건 알겠는데 정말 누가 원하느냐”를 더 자주 먼저 물어야 한다는 것이다. 나는 이 관측에 꽤 동의한다.

다만 여기서 한 걸음 더 가고 싶다. 앞으로 많은 팀은 최소기능제품보다 최소신뢰제품 혹은 최소사랑가능제품을 더 자주 붙잡아야 할 것이다. 사용자가 “되네”라고 말하는 수준과 “이건 다시 쓰겠다”라고 말하는 수준 사이에는 큰 간격이 있다. AI는 첫 번째 간격을 많이 줄여준다. 그런데 제품의 승패는 대개 두 번째 간격에서 갈린다. 돌아오는가, 추천하는가, 믿는가, 다시 맡기는가. 결국 제품은 이 반복 사용의 감정 위에서 살아남는다.

그래서 앞으로 더 자주 실패하는 팀은 대충 돌아가는 것을 너무 빨리 완성으로 오해하는 팀일 가능성이 크다. 반대로 오래 살아남는 팀은 작게 만들더라도 사용자가 왜 그것을 믿고, 왜 다시 오고, 왜 남에게 추천하는지에 더 집요하게 붙는 팀일 것이다. 기능이 아니라 귀환 이유를 읽는 팀, 속도가 아니라 신뢰의 축적을 묻는 팀 말이다.

flowchart TD
A[쉽게 만든다] --> B[초안은 빠르게 나온다]
B --> C{사용자가 왜 다시 오는가?}
C -->|모른다| D[기능은 많지만 기억에 남지 않는다]
C -->|안다| E[핵심가치를 더 선명하게 만든다]
E --> F[작아도 다시 찾는 제품이 된다]

내가 이 강의에서 가장 중요하게 들은 문장

이 강의의 표면적 메시지는 고객 집착, 문제 정의, 문제 해결이었다. 그런데 내게 더 깊게 남은 것은 그 세 단어 뒤에 숨어 있는 정서였다. 인간은 앞으로도 한동안 고객을 대신 느껴야 하고, 문제를 대신 견뎌야 하고, 너무 큰 것을 감당 가능한 수준으로 줄이기 위해 자신의 판단을 계속 써야 한다는 정서. 그건 화려하지 않다. 오히려 꽤 피곤한 역할이다. 하지만 아마 그래서 더 쉽게 사라지지 않을 것이다.

나는 앞으로 직무명이 더 많이 흔들릴 거라고 본다. PM이라는 이름이 줄어들 수도 있고, 다른 이름과 섞일 수도 있다. 빌더, 프로덕트 엔지니어, AI 오퍼레이터 같은 말이 더 흔해질 수도 있다. 하지만 그 와중에도 한동안 사라지지 않을 기능은 분명해 보인다.

  • 고객이 진짜로 겪는 마찰을 읽는 일
  • 그 마찰 중 무엇이 풀 가치가 있는지 고르는 일
  • 너무 큰 문제를 해결 가능한 사이즈로 줄이는 일
  • 그리고 그 결정에 끝까지 책임을 지는 일

이 기능은 기술이 대신해주기보다 오히려 기술이 강해질수록 더 선명하게 드러날 가능성이 크다. AI가 많은 중간 노동을 걷어낼수록 인간은 더 이상 분주함으로 자기 가치를 증명하기 어려워질 것이기 때문이다. 그때 남는 것은 결국 판단이다. 무엇을 먼저 붙들 것인가. 무엇을 버릴 것인가. 어디까지 단순화할 것인가. 어디서부터는 다시 사람의 손을 넣어야 하는가.

일을 오래 해보면 어느 순간부터 실력이란 대단한 답을 내는 능력보다, 틀린 질문에 오래 매달리지 않는 능력에 더 가까워진다. AI 시대의 실력도 아마 비슷할 것이다. 더 많은 것을 만들 수 있는 사람이 아니라, 무엇을 왜 만들어야 하는지 더 늦기 전에 알아차리는 사람이 오래 남을 가능성이 크다.

그래서 나는 여전히 이렇게 믿는다.

남는 일은 화면 한가운데가 아니라 고객 옆에 있다.
모든 것이 빨라질수록, 끝내 가치가 되는 것은 속도가 아니라 방향이다.
그리고 그 방향은 대개 가장 먼저 고객 쪽을 향해 고개를 돌리는 사람에게서 시작된다.

한동안은, 아마 그럴 것이다.
그리고 나는 그 한동안이 생각보다 꽤 길 거라고 본다.

다음 읽기

참고 링크

그래프 뷰