실패한 경험을 돌아보며, AI와 일하는 방식을 다시 본다

왜 이 글을 쓰게 되었나

팀에서 성과가 잘 났던 경험과, 반대로 일이 잘 안 풀렸던 경험을 공유해달라는 요청을 받았다. 내가 겪었던 경험이 지금의 팀이 더 잘 일하는 데 참고가 될 수 있다고 생각한 것 같다.

하지만 나는 연속된 실패로 인해 위축된 상태이다. 올해 초에는 그 감각을 떨쳐내려고 매일 강아지와 산책을 나갔다. 이런 상태에서 잘하는 방법을 이야기할 자신이 없다.

돌이켜보면, 일이 잘됐을 때보다 잘 안됐을 때 배우는 게 더 많았다. 베스트 프랙티스를 읽고 따라 하는 것보다, 직접 부딪히며 겪은 실패가 더 오래 남는 경우가 많다. 그래서 이번에는 내가 겪었던 잘못된 방식들을 다시 돌아보고, 같은 일이 반복되지 않도록 정리해보려 한다.

사람과 일하는 방식과 AI와 협업하는 방식은 닮았다고 생각한다. 일을 어떻게 나누고, 어떻게 요청하고, 어디서 확인하느냐에 따라 결과가 달라진다는 점에서 그렇다. 지금은 AI와 더 잘 협업하는 방법을 익혀가는 중이기도 해서, 이번에 정리하는 내용들을 그 관점에서도 함께 생각해보려 한다. 그래서 각 항목마다 AI 협업에서 어떻게 나타나는지를 함께 적었다.

1. 비난하기

결과가 기대에 못 미치면 사람부터 탓하게 된다. "왜 이것밖에 못 해?", "이 정도는 알아서 해야 하는 거 아냐?" 이런 말이 먼저 나온다.

하지만 조직에서 생기는 문제를 개인의 문제로만 돌리기는 어렵다. 전달이 충분히 되지 않았거나, 일하는 데 필요한 정보·역할·절차가 갖춰지지 않았거나, 지원하는 방식 자체가 잘못된 경우가 많다. 사람을 탓하는 순간 이런 원인은 가려진다.

AI한테도 이걸 한다. 맥락과 기준 없이 시켜놓고 결과가 마음에 들지 않으면 모델 탓으로 돌리기 쉽다. 하지만 많은 경우 문제는 불명확한 지시, 빠진 맥락, 없는 기준에 있다.

2. 마이크로매니징

사람을 믿지 못하는 조직은 목표를 명확히 주기보다 과정마다 개입한다. 이건 이렇게, 저건 저렇게, 중간중간 계속 확인한다. 실행자는 점점 수동적으로 변한다. 스스로 판단하지 않고 시키는 것만 하게 된다. 그리고 리더 자신이 병목이 된다.

AI에게 일을 시킬 때도 다르지 않다. 배경과 목적은 설명하지 않고 눈앞의 작업만 잘게 쪼개 지시하거나, 맥락 없이 짧은 지시와 수정 요청만 반복하면 결과는 계속 흔들린다. 겉으로는 꼼꼼히 챙기는 것처럼 보인다. 하지만 실제로는 맥락 없는 지시와, 나중에 와서 고치라고 하는 일만 늘어날 뿐이다.

좋은 위임은 과정 통제가 아니라 목표, 맥락, 제약, 기대 결과를 분명히 주는 것이다.

3. 의견을 말할 수 없는 분위기

팀이 조용하다고 해서 합의가 잘 된 것은 아니다. 말해도 안전하지 않기 때문인 경우가 많다. 문제가 보여도 드러내지 못하면 병목은 계속되고, 결국 몇몇 사람만 끌고 가게 된다. 나머지는 시키는 일만 한다.

AI에게도 일방적으로 지시만 하면 시키는 대로만 답한다. 불확실한 부분을 질문하게 하거나, 결과물의 문제를 스스로 점검하게 하면 결과가 달라진다.

4. 데이터 없이 판단하기

목적과 기준 없이 일하면 무엇이 잘되고 있는지 판단할 수 없다. 판단 근거가 없으면 결과에 대한 확실한 판단도, 그로부터의 학습도 얻기 어렵다.

이 문제는 AI 협업에서 특히 "평가 기준 없이 반복 수정하기"로 자주 나타난다. "좀 더 좋게", "더 자연스럽게", "더 세련되게" 같은 말만 반복하면 수정은 많아도 품질은 안정되지 않는다. 무엇이 좋아진 것인지 판정 기준이 없기 때문이다.

숫자뿐 아니라 성공 기준, 비교 기준, 합격 조건처럼 무엇으로 판단할지도 미리 정해둬야 한다. 그래야 감이 아니라 기준으로 판단할 수 있다.

5. 검증 없는 실행

배포를 자주 한다고 검증이 되는 것은 아니다. 가설과 확인 없이 실행만 반복하면 많이 만든 것 같아도 실제로는 아무것도 배우지 못한다.

AI를 쓸 때 이게 더 쉽게 드러난다. 큰 작업을 한 번에 통째로 맡기고 중간 점검을 하지 않으면, 마지막에 그럴듯하지만 쓸 수 없는 결과가 나온다. 초안은 빠르게 얻을 수 있지만, 초안이 곧 정답은 아니다. 얼핏 맞아 보인다고 해서 확인 없이 바로 쓰는 건 위험하다.

실행은 산출물로 끝나지 않는다. 검증하고, 거기서 얻은 것을 다음 실행에 반영해야 한다.

6. 원인을 실행으로 잘못 짚기

성과가 나지 않으면 실행이 느리다고 보기 쉽다. 하지만 실행이 왜 안 되는지를 들여다보면, 원인은 대부분 그 앞에 있다. 실행을 탓하기 전에, 막혀 있는 곳을 찾아 푸는 것이 먼저다.

AI는 실행 자체는 빠르게 해준다. 그래서 무엇이 막고 있는지 찾고 푸는 데도 AI를 써야 한다.

7. 틀린 판단을 수정하지 않기

많은 실패는 한 번의 오판보다, 틀렸다는 신호가 나온 뒤에도 계속 밀어붙일 때 커진다. 중요한 것은 실수하지 않는 것이 아니라 수정하지 못하는 상태에 빠지지 않는 것이다.

AI한테 이걸 하면 결과가 바로 보인다. 잘못된 지시 방식, 잘못된 기준, 잘못된 접근인데도 계속 같은 방식으로만 요청하면 결과는 계속 비슷하게 틀린다. 이때 필요한 것은 더 강한 압박이 아니라 가설과 접근 자체를 수정하는 것이다.

실패를 줄이는 핵심은 처음부터 틀리지 않는 것이 아니라, 틀렸을 때 빨리 수정하는 것이다.

마치며

이런 문제는 개인이 최선을 다한다고 해서 다 풀리지는 않는다. 그래도 무엇이 문제였는지 빨리 정리하고, 어디까지가 내 몫인지 나눠보면서 할 수 있는 일은 해봐야 한다고 생각한다. 너무 어려운 일이라 AI가 이런 데서도 도움이 되면 좋겠는데, 아직은 나도 잘 모르겠다. 라고 한 건 지쳐서 더 생각하기 싫어서 그랬다.

(2026-03-15 추가) 오늘 트위터에서 이걸 보고, 위의 6번에서 쓴 문제가 다시 떠올랐다.

제품 개발 방향을 제시하고, 일하는 과정에서 막히는 지점을 조율하는 역할이 먼저 작동해야 하는데, 다른 팀에 보일러플레이트 바이브코딩을 부탁한 결과물이 개발팀에 전달되는 경험을 한 적이 있다.

AI 이후에는 실행 속도가 크게 빨라졌고 비용도 낮아졌다. 그런데 전체 결과가 나오는 시간은 그만큼 줄지 않았다. 그래서 사람들은 답답함을 느끼고, AI를 활용해 더 많은 실행을 시도한다. 하지만 실제 병목은 실행이 아니라, 함께 방향을 맞추고 일을 연결하는 방식에 있다.

AI를 적극적으로 활용해 일하게 되면서, 나는 세 가지 환경을 경험했다.

  1. 혼자 하는 사이드 프로젝트
  2. 만드는 사람이 나 하나뿐인 팀
  3. 여러 명이 협업하는 프로덕트 팀

혼자 일할 때는 이런 병목이 상대적으로 없었다. 책임과 결정이 모두 내게 있었고, 내가 직접 전체를 보며 조율했기 때문이다. 반면 여러 주체가 함께 움직일 때는 조율이 필요하다. AI 시스템은 그래서 오케스트레이터가 있고, 여러 에이전트가 동시에 움직인다.

제품팀도 비슷하다. 다만 사람 조직에서는 한 명의 오케스트레이터가 아니라, 팀 전체가 그 역할을 나눠 가져야 한다고 생각한다. 이런 행동이 가능하려면 조직이 어느 정도의 자율성과 심리적 안전을 보장해야 한다.

그렇지 않으면 사람들은 결국 가장 안전한 방식으로 일하게 된다. 자기 역할만 수행하고, 그 밖의 문제는 건드리지 않는다. 병목을 지적하지도 않고, 흐름을 바꾸는 데도 관여하지 않는다.

조직이 자율성과 심리적 안전을 보장해야 한다면, 개인도 자기 영역에만 머무르지 않고 전체 일이 더 잘 되도록 기여해야 한다. 특히 AI라는 도구로 각자의 실행력이 커진 지금은, 자기 파트의 생산성만이 아니라 팀 전체의 생산성이 어디에서 막히는지도 함께 살피고 책임지려는 태도가 더 중요해진다.

올해는 팀에서 일하면서 답을 찾아보려고 한다. 아직은 모르겠다.