2026. 8. 6. 07:50ㆍAI 이야기
들어가며
AI에게 바이브 코딩으로 AI툴 개발을 시킵니다. 또 하나의 창에서는 사용자 리서치 정리도 시켰습니다. 또 다른 에이전트에게는 경쟁사 분석도 시킵니다. 작업물 3개를 세 개를 동시에 돌렸으니 생산성은 마땅히 3배가 되어야 합니다. 하지만, 막상 결과물을 받으면 어디부터 봐야 할지 멍하니 고민이 됩니다. 결과물을 훑으며 "괜찮은데?" 했지만, 곧 불안해졌습니다. 이게 진짜 괜찮은 건지, 그냥 그럴듯해 보여서 괜찮다고 느끼는 건지, 구분이 안되기 시작했습니다.
왜 AI에게 일을 시키면 오히려 더 피곤하게 느껴질까요? AI와 함께 일하는 상황이 늘어나는 지금,
AI와 협업하면서 발생하는 어려움을 해결해 나가는 최선의 워크플로우는 무엇일지 고민해 보았습니다.
왜 우리는 AI 결과물 앞에서 판단이 흐려지는가?
우리가 경험적으로 걱정하는 문제들에 대한 기존 연구들을 하나씩 살펴보겠습니다.
Microsoft Research와 CMU 연구진들이 진행한 연구에서, 우리는 왜 AI 결과물을 받아보면서 발생하는 현상들을 확인할 수 있었습니다.
Microsoft Research와 CMU 연구진은 319명의 지식노동자로부터 생성형 AI를 사용한 실제 업무 사례 936개를 수집했습니다. 연구 결과, AI에 대한 신뢰가 높을수록 비판적 사고를 덜 했다고 보고한 반면, 해당 과업을 스스로 수행할 수 있다는 자신감이 높을수록 더 많은 비판적 사고를 했다고 보고했습니다.
자신이 작업에 관한 자신감을 가지고 과업에 참여할수록 AI 결과를 더 적극적으로 검토할 가능성이 있다는 것입니다. 실무에 대입해서 생각해 봅니다. “AI가 대충 잘 뽑아주겠지”라고 생각하며 화면 설계를 시키면 결과물을 검토하기보다 수락하는 태도에 가까워지는 반면. 내가 작업에서 “이 플로우에서는 사용자가 이탈하는 지점이 있을 수 있다”는 가설을 가지고 요청했다면 똑같이 AI가 만들어준 결과물을 보더라도 더 깊게 비판적으로 들여다보게 된다는 것입니다.
우리의 문제는, 위험이 낮은 일상적 작업에서 점점 전자 쪽으로 기울게 된다는 것입니다. 매일 반복되는 작은 판단들에서 AI를 믿고 활용하다 보면, 검증을 건너뛰는 습관이 자연스럽게 쌓이게 되고, 정작 중요한 결정 앞에서 "이 결과물이 정말 맞나?"를 묻는 습관이 점점 사라지게 되겠죠. 그 점을 경계해야 합니다.
AI는 생성 부담을 줄이지만 평가 부담을 남긴다
우리는 직접 와이어프레임을 그리면 왜 이 요소를 여기에 놓았는지 알고 있습니다. 정보 구조를 생각하고, 시선 흐름을 고려하고, 우선순위를 정하는 과정이 내 안에서 일어났기 때문입니다. 반대로 AI가 완성된 레이아웃을 주면 나는 결과에서 출발해 그 의도를 역으로 추론해야 합니다. “왜 이 버튼이 여기 있지?”, “이 정보가 먼저 나와야 하는 이유는 뭐지?”를 처음부터 복원해야 합니다. 같은 결과물이어도 내가 가지고 있는 맥락의 양은 다를 수밖에 없습니다. 따라서, 우리가 작업물을 직접 만들면 맥락을 이해하기가 쉬운데, 완성된 걸 받으면 유독 더 검수하기가 힘이 듭니다.
Microsoft Research는 "생성형 AI가 사람의 역할을 직접 만드는 사람에서 결과를 평가하는 사람으로 이동시킨다" 라고 설명합니다.
이를 production-to-evaluation shift, 즉 생성에서 평가로의 이동이라고 부릅니다. AI를 활용한 작업이 늘어날 수록 기존 맥락에 맞는지, 빠진 조건은 없는지를 판단하는 일이 중요해진다는 것입니다.
문제는 직접 만드는 역할에서 평가하는 역할로 바뀌면서, 역설적으로 평가에 드는 인지 부하 또한 함께 늘어난다는 것입니다. AI의 생성 속도만큼 사람의 이해와 판단 속도가 빨라질 수는 없기 때문입니다. 또한, 비슷한 이유를 이미 1978년 Slamecka와 Graf가 발표한 연구에서 발견된 Generation effect에서도 찾을 수 있습니다. "~"라는 의미로, 이 연구에서는 참가자가 직접 생성한 단어는 같은 단어를 읽기만 했을 때보다 이후 기억 검사에서 더 잘 회상된다고 합니다. 나중에 떠올리기 쉬워서가 아니라, 만드는 순간 자체가 더 깊은 인지 처리를 일으키기 때문입니다.
결국, 우리가 직접 만들지 않는 AI의 결과물을 이해하고 판단하는 일에는 더 많은 인지적 부담이 늘어나게 되고, 이는 AI와 협업하는 지금의 시대에 맞이할 우리의 새로운 어려움으로 나타날 수 있습니다.
판단력을 유지하려면 생성 과정에 관여해야 한다
더 깊게 들어가보면, 작업에 얼마나 관여했는지에 따라 사람의 인지 결과도 달라집니다. 개발 분야에서 이루어진 선행 연구에서 52명의 소프트웨어 개발자가 새로운 라이브러리를 학습하는 무작위 실험을 진행했습니다. 그 결과, AI 사용 집단과 비사용 집단의 과제 완료 시간은 비슷했습니다. 그러나, 후속으로 진행된 작업 이해도 평가에서 AI를 사용한 집단의 후속 이해도 점수는 평균 50%로, 직접 코딩한 집단의 67%보다 낮았습니다.
흥미로운 점은, AI 사용 집단 안에서도 결과는 사용 방식에 따라 크게 달랐다는 것입니다. AI에게 코드 생성을 전적으로 맡기거나 오류 해결을 반복적으로 위임한 참가자 유형은 이해도 평가에서 24~39%를 기록했습니다. 반면 코드를 생성한 뒤 작동 원리를 질문하거나, 코드와 함께 설명을 요청하거나, 개념만 AI에게 묻고 직접 구현한 참가자 유형은 65~86%를 기록했습니다.
따라서, 우리에게 중요한 것은 AI를 좋은 프롬프트로 얼마나 잘 사용했느냐보다, AI의 작업 과정에 내가 어떤 방식으로 관여했느냐? 가 될 수 있습니다. 결과만 받는 것과, 중간에 “왜 이렇게 했어?”, “다른 선택지와의 트레이드오프는 뭐야?”라고 묻는 것은 전혀 다른 방식으로 AI를 활용하는 방식이며, 작업의 이해도 또한 달라질 수 있다는 것입니다.
먼저 생각을 표현하면 AI는 답변자가 아니라 피드백 도구가 된다
그렇다면 실제로, AI에게 시키기 전에 내 생각을 먼저 꺼내놓으면 결과가 달라질까요? CHI 2025에서 발표된 실험이 이 질문을 직접 검증했습니다. 참가자 21명에게 투자 포트폴리오를 짜는 과제를 주고, 두 종류의 AI 보조 도구를 비교 사용하게 했습니다.
1. RecommendAI : 버튼을 누르면 AI가 바로 추천 안을 제시한다.
2. ExtendAI : 사용자가 먼저 자기 논리를 글로 쓰면, AI가 그 위에 피드백을 얹어준다.
예를 들면, RecommendAI는 "AI야 이 화면 디자인해줘"이고, ExtendAI는 "나는 이 화면에서 이런 걸 중요하게 생각하는데, 이 방향으로 만들어주고 빠진 거 알려줘"라고 하는 식입니다.
결과에서 가장 눈에 띈 건 자신감과 만족도의 관계입니다. RecommendAI를 쓴 그룹은 결정 직후 자신감이 86%로 높았는데, 실제 결과를 본 뒤 만족도는 43%로 급락했습니다. AI가 해준 추천을 믿고 따라갔는데, 막상 결과를 보니 내 판단이 맞지 않았던 것입니다. ExtendAI 그룹은 자신감 67%, 만족도 67%로 거의 일치했습니다. 내 논리를 먼저 세운 쪽은 결과가 어떻든 자기 판단 수준을 정확히 인지하기 때문입니다. 또한, ExtendAI를 사용한 참가자들은 특히 지역적 포트폴리오 다각화 측면에서 더 나은 결과를 보였습니다. 연구진은 사용자가 자신의 계획을 먼저 세운 뒤 피드백을 받는 방식이 포트폴리오 전체의 약점을 더 잘 이해하는 데 도움이 된 것으로 해석했습니다.
실무에서 이 차이가 드러나는 순간이 있습니다. 디자인 리뷰에서 팀원이 "왜 이 레이아웃이에요?"라고 물었을 때, AI 추천을 그대로 쓴 사람은 "AI가 이렇게 뽑아줬는데 괜찮아 보여서요"밖에 할 말이 없습니다. 먼저 자기 논리를 세운 사람은 "첫 진입 시 핵심 가치를 3초 안에 전달하려면 이 구조가 맞다고 생각했고, AI 피드백에서 CTA 위치만 조정했어요"라고 말할 수 있습니다. 이 차이는 결과물의 퀄리티뿐 아니라 협업에서의 신뢰에도 직결됩니다.
그래서 어떻게 일해야 할까? : 생성-지연-재현 워크플로우
그래서, 우리는 AI와 어떻게 일하면 좋을까요? 제 생각에는, AI와 작업을 하는 과정에서 단순히 속도에 집중하기보다는 나의 작업 속도에 맞게, 작업은 AI가 하되 나의 판단 능력을 최적화하는데 집중해야 한다고 생각했습니다. 그래서 AI 활용 워크플로우를 아래와 같이 고민해 보았습니다.
Step 1. AI에게 일을 맡기기 전, 나의 의도를 먼저 적습니다.
AI에게 "OO 해줘"를 보내기 전에, 내가 기대하는 결과를 2~3줄로 적습니다. 완벽하지 않아도 됩니다. 핵심은 시간이 아니라 내 머릿속에 의도의 흔적을 남기는 것입니다. 이 과정을 통해 나중에 AI에게 결과물을 받았을 때 "뭘 기준으로 볼 것인가"를 만듭니다.
'온보딩' 화면을 설계해 달라고 요청하기 전
→ 이 온보딩 플로우에서 가장 중요한 건 사용자가 '이 앱이 나한테 왜 필요한지'를 두 번째 화면에서 파악하는 것. 기능을 소개하기보다, 가치 제안을 먼저 진행해야 한다.
기능을 구상하고 설계해달라고 요청하기 전
→ 기능의 핵심 지표는 전환율이 아니라 재방문율이다. 한 번 쓰고 마는 기능은 의미가 없다. 사용자가 다시 찾아올 이유가 생기는 기능을 설계해야 한다.
Step 2. 기다리는 시간에 합격 기준을 씁니다.
AI가 도는 동안 다른 프로젝트로 넘어가지 않습니다. 대신, 지금 돌아가고 있는 작업의 합격/불합격 기준을 적아봅니다. EvalGen 연구에서 실제로, "기다려야 하는 시간에 채점 기준을 세우게 하자"는 작업 설계가 효과가 있었다고 합니다.
화면 설계를 시키는 동안 판단해보는 합격 기준
→ 합격 : 핵심 CTA가 스크롤 없이 보이고, 사용자가 다음 행동을 고민하지 않아도 된다.
→ 불합격 : 요소 간 위계가 불분명, 빈 공간이 의도 없이 존재, "다양한", "편리한" 같은 모호한 카피.
기능을 기획하는 동안 판단해보는 합격 기준
→ 합격 : 유저 시나리오 3개 이상을 충분히 커버하고 예외 상황(결제 실패, 재진입 등)이 플로우에 반영되어있어야 한다.
→ 불합격 : 해피 패스만 기술해 놓는다.
물론 기준은 나중에 바뀌어도 괜찮습니다. 기준은 작업 전에 한 번에 완성되기 어렵기 때문입니다. UC Berkeley 연구진이 UIST 2024에서 발표한 EvalGen 연구에서는 criteria drift라는 현상으로 설명합니다. 결과물을 채점하려면 기준이 필요하지만, 실제 결과물을 채점하다 보면 기준 자체가 수정된다는 것입니다.
실제로 이런 경험이 있을 것입니다. "카드 UI는 모서리 라운딩 8px로 통일한다"는 기준을 세우고 작업합니다. 그리고 실제로 다양한 화면을 만들다 보니, "콘텐츠 밀도가 높은 카드는 4px가 맞다"로 기준을 바꾸기도 합니다. 또는 "온보딩은 3단계 이내"라고 정했다가, 실제 사용자 플로우를 그려보니 "단계 수보다 각 단계의 인지 부하가 더 중요하다"로 생각이 바뀌기도 합니다.
결국 내가 기준을 세워 AI에게 전달하더라도, 어차피 그 기준을 한 번에 완벽하게 세울 수는 없습니다. 대신, 기준이 바뀔 때마다 왜 바뀌었는지를 기록해 볼 수는 있겠죠. 경험치가 쌓일수록 그 일이 익숙해지듯, 그 기록이 쌓인다면 다음 판단이 더 빨라질 수도 있을 것 같습니다.
Step 3. 결과물의 핵심적인 부분은 직접 재현해 봅니다.
전체를 다시 작업할 필요는 없습니다. 작업에서 판단이 가장 중요한 부분 하나만 골라서, 나의 버전을 짧게라도 만들어봅니다.
예를 들면, 아래와 같이 해보는 것입니다.
AI가 정리해 준 온보딩 플로우 전체 화면 구성 중, 사용자가 가장 먼저 이탈할 것 같은 구간을 골라
핵심 시나리오를 나의 생각으로 다시 써본다.
"이 화면에서 사용자가 뭘 보고, 어떤 판단을 내려야 하는지"를 직접 문장으로 옮겨봅니다. 내 머릿속에 "이 부분이 왜 이래야 하는지"의 맥락을 심어 보는 것입니다. 중요한 것은, 적어도 작업의 핵심 과정에 관여하여 나의 작업에 대한 소화를 제대로 시켜보아야 한다는 것입니다.
Step 4. 기준의 변화를 로그로 쌓는다
작업 중에 기준이 바뀔 때마다 AI에게 추가로 요청하게 됩니다. 최종적으로 원하는 결과물을 얻기 위해 기준을 수정하며 추가적인 요청을 합니다. 이 대화는 프로젝트가 끝나고 정리하는 게 아니라, 대화를 종료한 시점에 대화의 내용을 요약하여 정리해 봅니다.
v1: 온보딩은 3단계 이내로 끝낸다.
v2: 단계 수보다 각 단계에서 느끼는 인지 부하가 더 중요하다. (사용자 테스트에서 3단계인데도 이탈이 나오면서 수정)
v3: "가치 제안이 두 번째 화면까지 전달되는지가 기준. 단계가 몇 개든 상관없다. (Step 1에서 세운 의도로 다시 연결)
이 부분은 AI가 정리해 주고 읽어볼 수도 있습니다. 이 대화 로그의 목적은 두 가지입니다. 하나는 다음에 비슷한 작업을 시킬 때 프롬프트에 넣어서 시행착오를 줄이는 것, 다른 하나는 내 판단이 어떻게 진화하는지 나 스스로 추적할 수 있게 되는 것. AI와 함께 한 작업이 오롯이 내 역량이 됩니다.
Step 5. 병렬은 "일" 단위가 아니라 "콘텍스트" 단위로 제한한다
같은 프로젝트 안에서 서로 이어지는 작업들(e.g. 온보딩 플로우를 설계하고 생길 수 있는 예외 상황(결제 실패, 재진입 등)을 정리하고, 사용자가 이탈하는 지점을 리서치해서 다시 플로우에 반영하는 일 등)은 동시에 진행해도 전환 비용이 적습니다. 어차피 같은 사용자, 같은 맥락을 계속 들여다보고 있기 때문입니다.
그러나 이번 주 온보딩 기획을 하면서 동시에 전혀 다른 프로젝트의 유저 시나리오까지 검토한다면, 두 개만으로도 판단력이 무너질 수 있다는 점을 기억해야 합니다. 이 상태에서 다른 맥락으로 넘어가면, 나중에 결과가 돌아왔을 때 "내가 뭘 기대했더라"를 머릿속에 다시 떠올려야 하죠. 바로 이 복귀 비용이 생각보다 큽니다.
Sophie Leroy의 연구가 밝힌 attention residue의 개념이 그러한 현상을 증명합니다∙ 이전 작업이 끝나지 않은 채 다른 작업으로 넘어가면, 주의력의 일부가 이전 작업에 남아서 오히려 다음 작업 성과가 떨어진다고 합니다. 주의를 복귀하는 데 드는 비용은 탭을 전환하는 물리적 행위가 아니라, "내가 이 작업에서 뭘 기대했는지"를 재구성하는 데서 발생하는 것입니다.
따라서, 여러 작업 각각에 내가 어떤 의도를 가졌는지를 전부 다시 떠올리는 비용만으로도 판단의 질이 떨어질 수도 있습니다. 그래서 Step 1에서 나의 의도와 기대하는 결과를 메모해 두는 건 바로 복귀 비용을 줄이는 장치가 되기도 합니다.
마치며
“작업을 판단하고 기준을 만드는 건 AI의 능력이 아니라 나의 전문성이다”
지금까지 인용한 연구들을 다시 보면, 하나의 패턴이 있습니다. AI 활용에서 중요한 것은 기술적 능력이 아닌 본업에 대한 사람의 판단력과 역량이 변수라는 것입니다. MS/CMU 연구에서 비판적 사고를 더 많이 한 사람은 AI를 잘 다루는 사람이 아니라, “자기 분야에 대한 자신감이 높은 사람”이었습니다. ExtendAI 실험에서 더 나은 결과를 낸 사람도 AI 피드백이 좋아서가 아니라, “먼저 자기 논리를 세운 사람”이었습니다. 이해도가 상대적으로 높았던 개발자도 프롬프트를 잘 짜서가 아니라, AI의 작업물에 "왜?"를 물을 줄 아는 사람”이었습니다.
이 역량은 프롬프트 잘 쓰는 법을 공부해서 생기는 게 아니라, UX 업무를 해오던 경험에서 나오는 것입니다. 사용자가 어디서 막히는지를 관찰한 경험, 정보 구조를 잡을 때 무엇을 먼저 보여줘야 하는지에 대한 감각, "이 플로우는 왜 이래야 하는가"를 설명할 수 있는 논리, 이런 것들이 AI 결과물 앞에서 "이건 괜찮고 이건 아니다"를 가르는 기준을 만듭니다. 기준을 만들고, 바꾸고, 왜 바꿨는지를 판단하는 건 AI가 할 수 없습니다. 그건 사용자를 관찰하고, 맥락을 이해하고, "이건 아닌데"라고 느낄 수 있는 사람의 일입니다.
앞선 연구가 보여줬듯, 물론 판단 기준이 순수하게 내 머릿속에서만 나오지는 않습니다. AI 출력물을 보고 나서야 "아, 이건 안 되는구나"를 깨닫고 기준이 생기기도 합니다. 이렇듯, 판단 능력은 단순히 빈 종이에서 완성되는 게 아니라 AI와 부딪히면서 다듬어지기도 합니다.
이 워크플로우는 느릴 수 있습니다. 대신 결과물에 대한 확신과, 다음 판단의 출발점이 되는 노하우를 남깁니다. 화면 세 개를 동시에 뽑아내기보다, 그중 하나를 붙잡고 "왜"에 끝까지 답할 수 있는 능력. 이게 쌓이면 리뷰에서 막히는 시간과 재작업이 줄고, 비슷한 판단은 다음 프로젝트에서 더 빨라집니다. 빠르게 많이 만들었지만 뭐가 좋고 뭐가 나쁜지 모르는 상태는 진정한 의미의 생산성이 아니라고 생각합니다.
AI를 쓰더라도 "왜 이렇게 만들었는지"를 설명할 수 있는 능력이 복리로 쌓이는 것이 AI 시대의 진정한 의미의 생산성이라고 생각합니다.
참고 자료
1. Lee et al. (2025). "The Impact of Generative AI on Critical Thinking." Microsoft Research & CMU. CHI 2025.
2. Reicherts, Zhang et al. (2025). "AI, Help Me Think—but for Myself." Microsoft Research & UCL. CHI 2025.
3. Shankar et al. (2024). "Who Validates the Validators?" UC Berkeley. UIST 2024.*
4. Slamecka & Graf (1978). "The Generation Effect: Delineation of a Phenomenon." Journal of Experimental Psychology.
5. Simkute et al. (2024). "Ironies of Generative AI." Microsoft Research.
6. Leroy (2009). "Why Is It So Hard To Do My Work?" Organizational Behavior and Human Decision Processes.
7. O'Reilly (2026). "Comprehension Debt: The Hidden Cost of AI-Generated Code.