내 판단을 지키며 AI와 일하기

내 판단을 지키며 AI와 일하기

 

AI에게 바이브 코딩으로 AI 툴을 개발하게 합니다. 다른 창에서는 사용자 리서치를 정리하게 하고, 또 다른 에이전트에게는 경쟁사 분석을 맡깁니다. 세 가지 작업을 동시에 진행했으니 생산성도 마땅히 세 배가 되어야 할 것 같습니다. 하지만 막상 결과물을 받으면 어디부터 봐야 할지 막막해집니다. 결과물을 훑으며 “괜찮은데?”라고 생각하다가도 곧 불안해집니다. 정말 괜찮은 건지, 그저 그럴듯해 보여서 괜찮다고 느끼는 건지 구분하기 어려워집니다.

왜 AI에게 일을 맡기면 오히려 더 피곤하게 느껴질까요? 

 

AI는 생성 부담을 줄이지만 평가 부담을 남긴다

와이어프레임을 직접 그리면 왜 특정 요소를 그 위치에 놓았는지 알고 있습니다. 정보 구조를 생각하고, 시선의 흐름을 고려하고, 우선순위를 정하는 과정에 직접 참여했기 때문입니다.

반대로 AI가 완성된 레이아웃을 주면, 결과에서 출발해 그 의도를 역으로 추론해야 합니다. “왜 이 버튼이 여기 있지?”, “이 정보가 먼저 나와야 하는 이유는 뭐지?”를 하나씩 되짚어야 합니다. 같은 결과물이어도 맥락 정보가 부족하기 때문입니다. 

결국 AI가 만든 결과물을 이해하고 판단하는 데에도 별도의 인지적 노력이 필요합니다. 생성의 부담이 줄어든 자리에 생기는 평가의 부담은 AI와 협업하는 시대에 우리가 마주하는 새로운 어려움일 수 있습니다.

 

다섯 단계 워크플로우  

AI와 작업할 때는 생성 속도뿐 아니라, 그 결과를 이해하고 판단할 수 있는 속도도 고려해야 합니다. 작업은 AI에게 맡기더라도 자신의 판단력을 충분히 활용할 수 있도록 협업 과정을 설계하는 것입니다. 

판단 능력을 잃지 않는 AI와의 협업 워크플로우 

 

Step 1. AI에게 일을 맡기기 전, 의도를 먼저 적습니다.

AI에게 “○○ 해 줘”라고 요청하기 전에 기대하는 결과를 두세 줄로 적습니다. 완벽하지 않아도 됩니다. 핵심은 많은 시간을 들이는 것이 아니라, 자신이 무엇을 의도했는지 흔적을 남기는 것입니다. 이 과정이 나중에 결과물을 받았을 때 무엇을 기준으로 검토할지 정하는 출발점이 됩니다.

 

예를 들어 온보딩 화면 설계를 요청하기 전에는 이렇게 적어볼 수 있습니다.

이 온보딩에서 가장 중요한 것은 사용자가 두 번째 화면까지 ‘이 앱이 나에게 왜 필요한지’를 파악하는 것이다. 기능 소개보다 가치 제안을 먼저 전달해야 한다.

기능의 구상과 설계를 요청하기 전에는 다음과 같이 정리할 수 있습니다.

이 기능의 핵심 지표는 전환율이 아니라 재방문율이다. 한 번 사용하고 끝나는 기능보다 사용자가 다시 찾아올 이유를 만드는 기능이 필요하다.

 

Step 2. 기다리는 동안 합격 기준을 씁니다. 

AI가 작업하는 동안 곧바로 다른 프로젝트로 넘어가기보다, 지금 맡긴 작업의 합격·불합격 기준을 적어봅니다.

 

화면 설계라면 다음과 같은 기준을 생각해 볼 수 있습니다.

합격: 핵심 CTA가 스크롤 없이 보이고, 사용자가 다음 행동을 쉽게 이해할 수 있다.
불합격: 요소 간 위계가 불분명하거나, 빈 공간의 의도가 명확하지 않거나, ‘다양한’, ‘편리한’처럼 모호한 표현에 의존한다.

기능 기획이라면 다음과 같이 정할 수 있습니다.

합격: 주요 사용자 시나리오를 세 가지 이상 다루고, 결제 실패나 재진입 같은 예외 상황을 플로우에 반영한다.
불합격: 모든 과정이 정상적으로 진행되는 경우만 설명한다.

 

물론 기준은 나중에 바뀌어도 괜찮습니다. 작업 전에 모든 기준을 완성하기는 어렵기 때문입니다. 처음부터 완벽한 기준을 세울 수는 없지만, 기준이 바뀔 때마다 그 이유를 기록할 수는 있습니다. 이런 기록이 쌓이면 다음 작업에서 더 빠르게 판단하는 데 도움이 될 것입니다.

 

Step 3. 중요한 부분은 직접 대안을 만듭니다.

AI가 만든 결과물에서 중요한 부분 하나를 골라, 어떻게 구성하면 좋을지 직접 생각해 봅니다. 전체를 다시 만들 필요는 없습니다.

 

예를 들어 AI가 온보딩을 ‘기능 소개 → 회원가입 → 서비스 체험’ 순서로 제안했다면, 회원가입 시점에 주목해 봅니다. “사용자가 서비스의 가치를 충분히 알기 전에 가입부터 요구하는 것은 아닐까?”를 묻고, 먼저 체험한 뒤 가입하는 흐름을 직접 구성해 보는 것입니다.

 

직접 만든 대안과 AI의 제안을 비교하다 보면 각 구성의 장단점이 더 잘 보입니다. 결과를 그대로 받아들이기 전에 핵심적인 선택을 직접 해보는 것이 중요합니다. 

 

Step 4. 무엇을 왜 바꿨는지 적어둡니다.

AI와 작업하다 보면 처음 생각했던 방향이 달라지기도 합니다. 이때 최종 결과만 저장하지 말고, 무엇을 왜 바꿨는지도 짧게 적어둡니다.

 

앞의 온보딩 사례라면 이렇게 정리할 수 있습니다.

처음 생각: 회원가입을 먼저 하고 서비스를 체험하도록 구성했다.
검토하면서 든 생각: 사용자가 서비스의 가치를 알기 전에 가입부터 요구하면 부담을 느낄 수 있다.
바꾼 방향: 먼저 서비스를 체험하고, 계속 사용하고 싶을 때 가입하도록 순서를 바꿨다.

 

이렇게 적어두면 나중에 “왜 가입 화면을 뒤로 옮겼지?”라는 질문에도 답할 수 있습니다. 다음에 비슷한 작업을 할 때도 이전에 어떤 고민을 했는지 참고할 수 있고요.

프로젝트가 끝날 때까지 기다릴 필요는 없습니다. AI와 한 차례 작업을 마친 뒤 “이번에 바꾼 내용과 그 이유를 정리해 줘”라고 요청하고, 자신의 생각과 맞는지 확인하면 됩니다. 중요한 것은 대화 전체를 보관하는 것이 아니라, 그 안에서 자신이 내린 판단과 이유를 남기는 것입니다.

 

Step 5. AI에게 동시에 일을 맡길 때만 서로 관련된 작업을 묶어 맡깁니다. 

AI에게 여러 작업을 동시에 맡길 수는 있지만, 그 결과를 검토하는 데에는 여전히 사람의 집중력이 필요합니다. 따라서 결과를 충분히 검토할 수 있는 환경을 만드는 것도 중요합니다. 

만약 쇼핑 앱의 온보딩을 검토하면서 병원 예약 서비스의 인터뷰 분석까지 함께 진행하면 어떨까요? 결과를 번갈아 볼 때마다 사용자가 누구인지, 어떤 문제를 해결하려 했는지, 무엇을 중요하게 봐야 하는지 다시 떠올려야 해서 인지부하가 생길 것입니다. 

가능하면 서로 관련된 작업을 함께 진행하고, 다른 프로젝트로 넘어가야 한다면 짧은 메모를 남겨둡니다.

 

마치며

작업을 판단하고 기준을 세우는 데에는 나의 전문성이 필요합니다.

AI가 기준을 제안하고 정리를 도울 수는 있지만, 프로젝트의 맥락에서 그 기준을 적용하고 수정하는 데에는 사람의 판단과 책임이 필요합니다. AI를 활용하면서도 “왜 이렇게 만들었는지” 설명할 수 있는 능력이 쌓이는 것, 그것이 AI 시대에 우리가 추구할 생산성이라고 생각합니다.

위에서 제시한 워크플로우는 당장의 속도를 늦출 수 있습니다. 대신 결과에 대한 확신과 다음 판단의 출발점이 되는 노하우를 남길 것입니다. 

 

---

 

참고 자료

• Lee et al. (2025). “The Impact of Generative AI on Critical Thinking.” Microsoft Research & CMU. CHI 2025.
• Reicherts, Zhang et al. (2025). “AI, Help Me Think—but for Myself.” Microsoft Research & UCL. CHI 2025.
• Shankar et al. (2024). “Who Validates the Validators?” UC Berkeley. UIST 2024.
• Slamecka & Graf (1978). “The Generation Effect: Delineation of a Phenomenon.” Journal of Experimental Psychology.
• Simkute et al. (2024). “Ironies of Generative AI.” Microsoft Research.
• Leroy (2009). “Why Is It So Hard To Do My Work?” Organizational Behavior and Human Decision Processes.
• O’Reilly (2026). “Comprehension Debt: The Hidden Cost of AI-Generated Code.”