얼마 전 Codex에 디자인 시안을 맡겼다가 기대에 못 미치는 결과를 받았다. 당연히 불만이 생겼다. 그런데 무엇이 잘못됐는지 차근차근 설명하는 대신 ’퀄리티가 떨어진다. 다시 만들어 봐’라고 주문했다.
문제점을 구체적으로 설명하면 개선될 가능성이 높다는 것을 모르지 않는다. 그런데 그날은 그 설명 자체가 귀찮았다. 생각하는 수고를 피하고 싶었던 것이다.
이 경험을 바탕으로 먼저 바이브 코딩에서 인간의 불완전한 디렉션을 다룬 글을 썼다. 그러다 한 가지 궁금해졌다.
이런 문제를 나만 겪는 걸까?
인지심리학 논문과 인간–AI 협업 연구, 개발자 설문조사, Reddit·디시인사이드·중국 LINUX DO·일본 Zenn의 실제 경험담을 찾아봤다. 결론부터 말하면 AI가 귀찮은 일을 대신해 줘도, 사람이 해야 할 판단과 감독이라는 새로운 노동이 남는다. 사람의 사고 부담을 어떻게 다룰 것인가는 단순한 프롬프트 작성 요령을 넘어서는 문제였다.

AI가 결과물을 만드는 속도와 사람이 그것을 판단하는 속도는 같지 않다.
1. 인간은 정말 생각하기 싫어하는 존재일까?
인지심리학에는 ’인지적 구두쇠(Cognitive Miser)’라는 표현이 있다. 인간이 언제나 게으르다는 뜻은 아니다. 같은 목표를 이룰 수 있다면 정신적인 노력이 적게 드는 경로를 선택하려는 경향을 설명하는 개념이다.
2010년 학술지 Journal of Experimental Psychology: General에 발표된 《Decision Making and the Avoidance of Cognitive Demand》는 여섯 번의 행동 실험에서 참가자들이 인지적으로 덜 부담스러운 과제를 선호하는 경향을 확인했다. 시간 단축이나 실수 회피만으로 설명되지 않는 선택이었고, 참가자가 부담의 차이를 뚜렷하게 인식하지 못하는 경우에도 관찰됐다.
그렇다고 인간이 무조건 생각을 피하는 것은 아니다. 2023년 같은 학술지에 발표된 《Do humans prefer cognitive effort over doing nothing?》는 12개 연구에서 ’아무것도 하지 않는 것’과 ’생각해야 하는 것’을 비교했다. 이때는 노력을 회피한다는 증거가 약했고, 오히려 정신적 노력이 필요한 활동을 선호하는 경향도 관찰됐다.
두 연구를 함께 놓고 보면 내가 느꼈던 상황도 이해하기 쉽다. 인간은 생각 자체를 혐오한다기보다 노력에 드는 비용과 얻을 보상을 따지는 존재에 가깝다.
흥미로운 아이디어를 탐색하는 데에는 몇 시간씩 집중하면서도, 마음에 들지 않는 버튼의 위치와 여백을 분석하는 데에는 몇 분조차 쓰기 싫을 수 있다. 내가 코딩 프로젝트에서 겪었던 일도 그런 종류의 부담이었을지 모른다.
2. AI가 줄여 주는 노동과 새로 만들어 내는 노동
2025년 Microsoft Research와 카네기멜런대학교 연구진이 CHI 학술대회에 발표한 《The Impact of Generative AI on Critical Thinking》은 지식 노동자 319명에게서 AI 활용 사례 936건을 수집했다.
연구에서는 AI를 신뢰하는 정도가 높을수록 비판적 사고에 덜 참여하는 경향이 관찰됐다. 반대로 자신의 업무 수행 능력을 신뢰하는 정도가 높을수록 비판적 사고에 더 적극적으로 참여하는 경향이 있었다.
또 하나 인상적인 점은 사고의 역할이 이동한다는 사실이었다. 자료를 직접 찾고 답을 만드는 일에서, AI가 내놓은 답을 검증하고 여러 결과를 통합하며 작업 전체를 감독하는 일로 무게중심이 옮겨간다.
물론 이 연구는 설문과 자기보고에 기반한다. AI가 사람의 사고 능력을 실제로 퇴화시켰다고 입증한 인과 실험은 아니다. 그러나 사람의 역할이 바뀌고 있다는 중요한 단서를 제공한다.
2026년에는 이 문제를 ’AI Brain Fry’라는 이름으로 다룬 조사도 나왔다. Boston Consulting Group 연구진이 미국 대기업 근로자 1,488명을 조사하고 Harvard Business Review에 발표한 내용이다.
BCG가 공개한 연구 해설에 따르면 AI 결과물을 집중적으로 감독하는 근로자들은 감독 부담이 낮은 집단보다 정신적 노력은 14%, 정신적 피로는 12%, 정보 과부하는 19% 더 높다고 보고했다.
이 역시 관찰된 관련성이다. AI 감독만이 해당 차이를 일으켰다고 단정해서는 안 된다. 그리고 반복 작업을 AI에 맡길 때는 오히려 피로와 번아웃이 줄어드는 방향도 나타났다.
결국 이런 구분이 필요하다.
| AI가 줄여 주는 일 | 사람에게 새로 남는 일 |
|---|---|
| 코드와 문서 초안 작성 | 결과가 맞는지 검토 |
| 디자인 시안 생성 | 여러 시안 비교 및 선택 |
| 자료 수집과 요약 | 출처·논리·누락 확인 |
| 반복 수정 작업 | 우선순위와 완료 기준 판단 |
| 여러 작업 동시 실행 | 진행 상태와 충돌 관리 |
AI가 손의 노동을 줄여 준다고 해서 머리의 노동까지 같은 비율로 줄어드는 것은 아니다.
3. ’원하는 것을 아직 모른다’는 문제는 프롬프트 실력만으로 해결할 수 없다
이번 조사에서 특히 눈에 들어온 것은 2024년 스탠퍼드대학교 등의 연구진이 CHI에 발표한 《Bridging the Gulf of Envisioning》이다.
연구진은 사람이 자신의 목표를 AI가 이해할 수 있는 구체적인 지시로 바꾸는 과정에 간극이 있다고 설명한다. 세 가지 유형이다.
- 무슨 일을 해야 하는지 모른다. 아직 원하는 결과의 모습이 정해지지 않았다.
- 어떻게 지시해야 하는지 모른다. 마음속 생각은 있지만 적절한 문장으로 표현하기 어렵다.
- 어떤 결과를 기대해야 하는지 모른다. AI가 낸 결과를 좋고 나쁘다고 판단할 기준이 불명확하다.
이 셋은 비슷해 보이지만 다른 문제다.
내가 원하는 디자인을 분명히 알고 있으면서 설명만 못 하는 상황이라면 프롬프트를 더 잘 작성하는 것이 도움이 된다. 그러나 처음부터 어떤 디자인이 적합한지 탐색 중이라면 이야기가 달라진다.
원하는 것을 발견하기 위해 AI를 쓰는데, AI를 잘 쓰려면 먼저 원하는 것을 정확하게 설명해야 한다는 모순이 생긴다.

모호한 취향을 억지로 문장으로 확정하기보다, 비교할 수 있는 대안을 통해 발견하는 과정이 필요하다.
이 문제를 해결하려는 연구도 있다. Google DeepMind가 ICML 2025에 발표한 《Proactive Agents for Multi-Turn Text-to-Image Generation Under Uncertainty》에서는 사용자의 요구가 불명확할 때 AI가 질문하고, 자신이 이해한 의도를 편집 가능한 구조로 보여주는 방식을 실험했다. 인간 대상 연구에서는 참가자의 최소 90%가 이 방식이 이미지 생성에 도움이 된다고 평가했다.
이 결과를 일반적인 코딩 프로젝트의 성공률로 착각해서는 안 된다. 다만 중요한 설계 방향을 보여준다. AI는 완벽한 프롬프트를 기다리기보다 사람이 요구사항을 발견하도록 도울 수 있다.
4. 바이브 코딩이 빠른데도 피곤한 이유
2025년 Stack Overflow 개발자 설문조사에서 AI 도구와 관련해 응답자들이 꼽은 대표적인 불만은 다음과 같았다.
- 66%: AI의 답이 거의 맞지만 완전히 맞지는 않는다.
- 45%: AI가 생성한 코드를 디버깅하는 데 시간이 더 오래 걸린다.
이 수치가 모든 개발자에게 똑같이 적용되는 것은 아니다. 그러나 AI가 만들어 준 결과물을 고치는 일이 얼마나 중요한 문제인지 보여준다.
더 흥미로운 것은 2025년 METR의 개발 생산성 무작위 실험이다. 기존 오픈소스 프로젝트를 잘 아는 숙련 개발자 16명이 실제 작업 246건을 수행했다. 일부 작업에서 2025년 초반 수준의 AI 도구 사용을 허용하고, 다른 작업에서는 허용하지 않았다.
참가자들은 사전에 AI가 작업 시간을 줄여 줄 것이라고 예상했고, 실험이 끝난 뒤에도 평균적으로 약 20% 빨라졌다고 느꼈다. 하지만 실제 측정된 작업 완료 시간은 AI를 사용한 조건에서 평균 19% 더 길었다.
이 실험을 ’AI 코딩은 항상 느리다’는 뜻으로 받아들일 필요는 없다. 숙련자, 대규모 기존 코드베이스, 2025년 초 도구라는 조건이 분명하다.
그럼에도 내 관심을 끄는 대목은 따로 있다. 빠르게 전진하고 있다는 느낌과 실제로 작업을 끝내는 속도는 다를 수 있다는 점이다.
바이브 코딩에서는 코드가 순식간에 생성된다. 하지만 사람이 검토해야 할 양도 빠르게 늘어난다. 내가 제대로 이해하지 못한 코드가 쌓이면 다음 수정 요청은 더 어려워지고, 다시 고친 결과가 다른 기능을 깨뜨리기도 한다.
5. 실제 사용자들도 비슷한 피로를 이야기한다
논문만으로는 일상적인 사용 경험을 이해하기 어렵다. Reddit, 디시인사이드, LINUX DO, Zenn에 올라온 사례를 함께 살펴봤다. 아래는 글 작성자들의 경험담이며, 일반적인 발생률이나 검증된 성능 수치를 뜻하지 않는다.
Reddit: AI가 빠르게 쓰지만 사람은 계속 지켜봐야 한다
2025년 9월 r/vibecoding에 올라온 한 시니어 개발자의 글은 코딩 생산성이 높아졌다고 평가하면서도, AI가 만들어 낸 보안 문제나 유지보수하기 어려운 코드를 계속 감시해야 한다고 지적했다. 일일이 설계와 패턴을 지시하지 않으면 만족스러운 코드가 나오지 않는다는 경험이었다.
2026년 3월에는 프롬프트를 반복하다가 ’수정을 고치는 수정’의 반복에 빠졌다는 글도 있었다. 댓글에서는 코드를 이해하고 변경사항을 직접 검토하는 방식이 이런 악순환을 줄이는 데 도움이 됐다는 반응이 나왔다.
반대로 반복 구현을 AI에 맡기니 귀찮은 타이핑에서 벗어나 설계에 집중할 수 있었다는 긍정적인 경험담도 확인된다.
한국 디시인사이드: 계획·구현·검수를 나눠 맡기는 방식
2026년 3월 특이점이 온다 갤러리의 한 글에서는 ChatGPT로 계획을 세우고 Claude Code로 구현한 뒤 다시 ChatGPT로 결과를 검수하는 방식을 소개했다. 작성자는 도구와 역할을 어떻게 조합하는 것이 좋을지 질문했다.
이 사례는 피로를 입증하는 글은 아니다. 다만 실제 사용자들이 이미 계획·코딩·검수라는 역할을 분리하며 협업 구조 자체를 고민한다는 사례로 볼 수 있다.
중국 LINUX DO: 문서보다 먼저 화면을 보자는 접근
2026년 5월 LINUX DO에는 UI를 먼저 만들고 그 화면을 바탕으로 요구사항 문서를 역으로 정리하자는 제안이 올라왔다. 참가자들은 문서만으로 서로의 기대를 맞추기 어렵고, 실제 화면이 있어야 사람이 무엇을 고쳐야 할지 빠르게 이해할 수 있다는 취지로 의견을 나눴다.
앞서 설명한 ’원하는 것을 아직 모르는 문제’를 실무적으로 해결하려는 시도다.
일본 Zenn: 구현보다 관리와 판단이 병목이 된다
2026년 3월 Zenn의 한 개발 경험담에서는 Claude Code나 Codex 덕분에 구현 속도는 빨라졌지만, 각 작업의 진행 상황을 확인하고 결과를 리뷰하며 다음 일을 결정하는 부담이 커졌다고 설명했다.
또 다른 2026년 7월 글은 AI 에이전트를 일곱 개까지 병렬로 실행해 봤지만 혼자 코딩할 때보다 훨씬 피로했다고 기록했다.
서로 다른 문화권의 경험담이지만 공통점은 분명하다. AI가 직접 작성하는 시간을 줄이면서 사람의 역할이 작성자에서 감독자·검토자·의사결정자로 옮겨가는 것이다.
6. 디자인 아이디어를 많이 생성하는 것이 반드시 더 창의적인 것은 아니다
나는 처음부터 완성된 시안을 머릿속에 갖고 있지 않았다. 그래서 AI에 여러 디자인을 탐색하도록 맡겼다. 그런데 시안을 많이 받으면 좋은 방향을 찾기가 쉬워질까?
항상 그렇지는 않을 수 있다.
2024년 CHI의 《The Effects of Generative AI on Design Fixation and Divergent Thinking》은 60명을 대상으로 시각적 아이디어 탐색을 실험했다. AI 이미지 생성기의 도움을 받은 참가자들은 초기 예시에 더 강하게 고착됐고, 대조 조건보다 아이디어 수와 다양성, 독창성이 낮았다.
이 실험은 특정 조건의 시각적 아이디어 탐색에 대한 결과다. 모든 AI 디자인 도구가 창의성을 떨어뜨린다는 뜻은 아니다. 하지만 AI가 초반에 제시하는 예시가 사람의 상상 범위를 오히려 좁힐 수 있다는 경고로 읽힌다.
그렇다면 AI는 사람의 아이디어를 직접 고쳐 줘야 할까, 아니면 질문을 던져야 할까?
2026년 CHI에 발표된 《Partnering With Generative AI》에서는 486명 대상 실험과 별도의 640명 대상 검증 연구로 협업 방식을 비교했다.
- AI 주도 방식: AI가 아이디어를 직접 다시 작성한다. 품질은 높아졌지만 아이디어 다양성과 사용자가 느끼는 소유감은 줄었다.
- 인간 주도·성찰 지원 방식: AI가 질문과 제안으로 사용자의 생각을 발전시키도록 돕는다. 품질을 개선하면서 다양성과 소유감을 유지했다.
실제 프로젝트나 모든 디자인 업무에서 똑같은 결과를 보장하지는 않는다. 그러나 내 경험에 적용해 보면 의미가 크다.
AI가 내 대신 전부 결정하는 것보다, 내가 더 나은 결정을 내리도록 도와주는 방식이 필요할 수 있다.
7. 생각하기 싫은 날에는 협업 방식을 바꿔야 한다
여기서 ’인간은 항상 훌륭한 디렉터여야 한다’는 전제에 다시 의문이 든다.
집중이 잘되는 날에는 요구사항을 자세히 쓰고 AI가 제시한 대안을 분석할 수 있다. 반면 잠을 못 잤거나 몸이 아픈 날, 다른 일로 기분이 좋지 않은 날에는 똑같이 깊은 사고를 요구받는 일이 부담스러울 수 있다.
이는 단순한 기분 탓으로 치부할 문제가 아니다. 2025년 Sleep Medicine Reviews에 발표된 79개 논문 메타분석에서는 수면 손실이 작업기억, 억제 통제, 인지적 유연성과 관련된 수행에 불리하게 작용할 수 있다는 결과가 나왔다.
물론 내가 특정 날에 모호한 프롬프트를 쓴 이유를 이 논문만으로 설명할 수는 없다. 그렇지만 사람의 컨디션이 사고 수행에 영향을 줄 수 있다는 점은 충분히 고려할 필요가 있다.
그렇다면 협업 방식도 나눌 수 있지 않을까?
| 상황 | 사람이 집중할 일 | AI가 먼저 해 줄 일 |
|---|---|---|
| 원하는 결과를 잘 모르겠을 때 | 예시를 보고 취향 발견 | 확실히 구분되는 여러 방향 제시 |
| 결과가 마음에 안 들지만 분석하기 싫을 때 | 문제 가설에 동의·반박 | 현재 결과 자체 평가와 원인 가설 작성 |
| 방향이 확정됐을 때 | 목표와 완료 기준 확인 | 구현·테스트·회귀 확인 |
| 위험이 큰 변경을 앞뒀을 때 | 최종 승인 | 영향 범위·실패 가능성·복구 방법 제시 |
여기서 중요한 전제는 사람의 컨디션에 따라 협업 방법은 달라져도 프로젝트의 품질 기준은 낮아지면 안 된다는 것이다.
8. 내가 바이브 코딩에 적용하고 싶은 다섯 단계
앞서 찾아본 연구들을 실무에 적용한다면 다음과 같은 구조가 가능할 것 같다. 특정 논문에서 이 절차 전체의 우수성을 검증한 것은 아니고, 여러 연구와 사례에서 얻은 시사점을 조합한 제안이다.
- 첫 반응을 그대로 전달한다. ’디자인이 마음에 들지 않는다’는 감정도 출발점으로 인정한다.
- AI가 먼저 현재 결과를 진단한다. 시각적 위계, 여백, 타이포그래피, 사용성, 기존 요구사항과의 충돌을 검토한다.
- 문제 진단을 가설로 제시하게 한다. AI가 사용자의 취향을 이미 안다는 듯 단정하지 않는다.
- 서로 다른 개선 방향을 비교한다. 사용자는 세부 지시를 처음부터 작성하기보다 선택하고 보정한다.
- 결정한 방향으로 구현하고 검증한다. 기능 회귀, 오류, 접근성, 품질 기준을 확인한 뒤 완료를 판단한다.

AI가 생각을 통째로 대신하기보다, 사람의 선택과 검증을 돕도록 역할을 나눌 수 있다.
예를 들어 내가 실제 프로젝트에서 다시 디자인이 마음에 들지 않는 상황을 만난다면 이렇게 요청해 볼 생각이다.
현재 디자인이 마음에 들지 않지만 무엇이 문제인지 직접 정리하기 어렵다.
지금 바로 전면 재작업을 시작하지 말고, 프로젝트 목적과 기존 요구사항을 기준으로 현재 결과물을 먼저 분석해 줘.
문제점을 확정 사실처럼 말하지 말고 가설로 구분해 줘. 그런 다음 서로 다른 개선 방향 세 가지를 제시하고 각 방향의 장단점, 유지할 요소, 변경할 요소를 비교해 줘.
내가 선택하기 전에는 기존 구현을 전면 변경하지 마. 선택한 다음에는 회귀 검증까지 수행해 줘.
여기서 중요한 것은 프롬프트가 길어졌다는 사실이 아니다. AI에게 ’다시 만들어’가 아니라 ’내가 결정할 수 있도록 문제를 구조화해 줘’라는 역할을 준 것이다.
물론 모든 변경에서 이런 절차를 거칠 필요는 없다. 쉽게 되돌릴 수 있는 시각적 실험은 빠르게 비교하면 된다. 반대로 데이터 삭제, 권한, 결제, 주요 기능 변경처럼 위험이 큰 작업에는 명확한 승인과 테스트가 필요하다.
9. AI에 사고를 맡기면 정말 생각하는 능력이 약해질까?
AI 사용이 사람의 사고 능력에 미치는 장기적 영향은 아직 조심스럽게 해석할 문제다. 모두에게 똑같이 사고 능력이 약해진다는 결론을 내릴 수는 없다.
다만 도구를 어떻게 설계하는지가 중요하다는 실험은 있다.
2025년 PNAS의 《Generative AI without guardrails can harm learning》은 고등학생 약 1,000명을 대상으로 수학 학습 실험을 했다. 일반적인 AI 도구를 사용할 때는 문제 수행이 개선됐지만, 이후 AI를 사용하지 못한 시험에서는 해당 집단의 성적이 AI를 쓰지 않았던 집단보다 약 17% 낮았다. 반면 학습을 보호하도록 설계된 AI 튜터에서는 부정적인 영향이 크게 완화됐다.
수학 학습과 코딩 프로젝트를 같다고 볼 수는 없다. 그래도 분명한 질문을 남긴다.
AI를 이용해 지금 당장 결과물을 잘 만드는 것과, AI를 사용하면서 인간 자신의 판단 능력을 유지하고 발전시키는 것은 다른 목표다.
10. 그래서 무엇을 바꿔야 할까?
처음에는 생각하기 싫어서 AI에 모호한 지시를 내린 내 행동이 문제의 전부라고 생각했다. 조사 후에는 조금 다르게 보인다.
물론 나는 내가 불만을 느낀 이유를 더 잘 설명하려고 노력할 수 있다. 하지만 사람은 늘 같은 컨디션이 아니고, 때로는 자신이 원하는 것이 무엇인지조차 모른다. AI가 처음부터 완벽한 지시를 요구한다면, 그런 순간마다 협업은 막힐 수밖에 없다.
반대로 AI에게 모든 판단을 통째로 넘겨도 문제는 남는다. 빠른 결과물이 실제 완성도를 보장하지 않으며, 사람의 검증 능력은 점점 더 중요해지기 때문이다.
내가 찾고 싶은 것은 두 극단의 중간이다.
사람은 목표와 가치, 최종 선택에 대한 책임을 갖고, AI는 탐색·분석·구현·검증을 통해 그 선택을 더 잘할 수 있도록 돕는 관계.
AI가 더 많은 코드를 작성하고 더 많은 시안을 생성하는 것만으로는 충분하지 않다. 좋은 협업이라면 사람이 피곤할 때에도 판단의 핵심을 놓치지 않게 도와줘야 한다.
결국 가장 중요한 질문은 AI가 얼마나 많은 일을 대신할 수 있느냐만이 아니다.
인간이 불완전한 상태에서도 AI와 함께 어떻게 좋은 판단에 도달할 수 있을까?
이것이 앞으로 바이브 코딩을 하면서 계속 고민해 보고 싶은 문제다.