
- 01 도구 선정표보다 먼저 채워야 할 건 "AI가 하는 일 / 사람이 확인하는 일 / 최종 책임자" 역할표였다.
- 02 같은 AI 도입이라도 팀마다 부작용의 형태는 정반대였다 — 야근이 늘어난 팀도, 배울 기회가 줄어든 팀도 있었다.
- 03 역할이 명확해지자 오히려 팀들이 도구를 더 편하게 썼다 — 다음 프로젝트는 도구가 아니라 역할표부터 그리고 시작한다.
2026년 초, 금융권 계열의 한 조직에서 AX(AI 전환) 프로젝트를 3개월간 이끌었다. 결과부터 말하면 절반은 성공, 절반은 실패였다. 이 글은 그 실패한 절반의 기록이다. 정확히는, 도구를 들이기 전에 먼저 정리했어야 할 것을 놓친 이야기다. 지금은 후속 프로젝트에서 그때 놓쳤던 순서를 바꿔 다시 적용하고 있는데, 그 이야기는 마지막에 붙여둔다.
왜 AI 도구부터 골랐는가 (흔한 순서의 함정)
돌아보면 첫 3주의 실수는 도구가 아니라 순서였다. 업무별로 어떤 AI 도구를 쓸지는 꼼꼼히 정했지만, 그 결과물을 누가 책임지고 확인할지는 아무도 의제로 올리지 않았다. 킥오프 회의에서 부서별 업무 목록을 화이트보드에 붙여놓고 논의를 시작했는데, 얼마 지나지 않아 논의는 “어떤 도구를 쓸 것인가”로 좁혀졌고, 다음과 같이 업무별 도구를 매칭한 표를 3주에 걸쳐 완성했다.
회의록 정리 도구는 사실 Notion AI 도입 전에 네이버 클로바노트도 같이 테스트했다. 클로바노트는 화자 구분 정확도가 더 높았지만, 요약문이 문장을 그대로 나열하는 수준이라 결국 다시 손을 봐야 했다. 반대로 Notion AI는 요약은 매끄러웠으나 화자를 종종 헷갈렸다. 그래서 1차 녹취는 클로바노트, 요약은 Notion AI로 용도를 나눠 쓰기로 했다.
표가 완성되자 다들 만족스러워했고, 실제로 셋 다 개별 성능은 기대 이상이었다. 회의록을 손으로 정리하던 시간은 체감상 눈에 띄게 줄었고, 코드 리뷰 1차 코멘트 속도도 꽤 빨라졌다는 반응이 개발팀 쪽에서 나왔다. 문제는 그 표에 없던 질문이었다. “이 도구가 만든 결과물은 최종적으로 누가 확인하는가.” 이 질문은 도구 선정 논의 내내 단 한 번도 회의 안건에 오르지 않았다. 세 도구 모두 도입 속도와 개별 성능에만 초점이 맞춰져 있었고, 결과물을 누가 검토하고 책임지는지는 각 팀장의 재량에 맡겨졌다.
그게 첫 번째 실수였다. 도구 선정표를 짜는 데 들인 3주 가운데 “책임 소재”를 논의하는 데 쓴 시간은 하루도 없었다. 지금 돌아보면 허탈한 대목이다.
3개월 뒤 실제로 벌어진 일 (역할 중복, 책임 공백)
책임 소재를 정하지 않은 대가는 두 번째 달부터 곳곳에서 터져 나왔다. 도입 초기 한 달은 순조로워 보였지만, 시간이 지날수록 균열이 드러났다. Notion AI로 정리한 회의록을 팀장이 매번 처음부터 다시 읽고 고쳐 쓰는 상황이 반복됐다. 요약은 빨랐지만 반어법이나 뉘앙스가 자주 빠졌기 때문이다. 회의록 “정리” 시간은 줄었다지만, 그 몫이 고스란히 팀장의 검토 부담과 야근으로 옮겨간 셈이었다.
반면 GitHub Copilot의 코드 제안은 시니어 개발자들이 신뢰하고 거의 그대로 채택했다. 그 결과 주니어 개발자가 직접 짜보며 배우는 기회 자체가 줄어드는, 정반대 문제가 생겼다. 같은 “AI 도입”인데 팀마다 부작용이 나타나는 방식은 완전히 달랐다.
더 심각한 문제는 책임 공백이었다. 실무에서 자주 부딪히는 지점은 ChatGPT Enterprise로 초안을 만든 외부 제출용 보고서에서 사실관계 오류가 뒤늦게 발견되는 경우였다. 통계 수치의 출처 연도가 뒤바뀐 채로 넘어간 사례도 있었다. 이런 상황에서 가장 먼저 부딪히는 질문은 결국 “이건 누구 책임인가”였다. 도구 도입 전에는 작성자가 곧 책임자였다. 하지만 AI가 초안을 만들고 사람은 “검토만” 하는 구조가 되면서 그 경계가 완전히 흐려져 있었다. 책임 소재를 특정하는 데만 적잖은 시간이 걸렸고, 그 사이 팀 분위기는 서로 눈치를 보는 쪽으로 굳어갔다.
뒤늦게 정리한 것 — 역할 재정의를 먼저 했어야 했다
3개월 차에야 진짜 필요했던 건 새 도구가 아니라 역할 재정의였다. 도구를 바꾼 게 아니라, 업무별 역할표를 다시 그렸다. 방식은 단순했다. 화이트보드에 “AI가 하는 일 / 사람이 확인하는 일 / 최종 책임자” 세 칸을 그리고, 팀별로 반나절씩 시간을 잡아 하나씩 채워나갔다. 정리된 규칙은 다음과 같다.
- Notion AI 회의록 — 1차 초안만 담당, 회의 참석자 본인이 5분 안에 직접 보완
- GitHub Copilot 제안 — 주니어가 먼저 직접 작성 후 참고용으로만 대조
- ChatGPT Enterprise 외부 제출 자료 — 문서 양식에 “작성자 서명란” 추가, 최종 책임자 명시

셋 다 도구 자체는 그대로였다. 바뀐 건 이 도구를 누가, 어떤 순서로, 어디까지 신뢰하고 쓰는가였다. 역할표를 정리하는 데는 팀별로 적잖은 시간과 조율이 필요했다. 그만큼 역할이 애매하게 방치돼 있었다는 뜻이기도 하다. 아이러니하게도 그 규칙이 생기고 나서야 팀들은 도구를 더 편하게 쓰기 시작했다. 뭘 확인해야 하는지가 명확해지니, 심리적 부담은 오히려 줄었다는 피드백을 여러 팀에서 받았다.
지금 다시 시작한다면 바꿀 순서
지금 같은 프로젝트를 다시 맡는다면 순서를 완전히 바꿀 것이다. 도구 선정표를 만들기 전에 먼저 “이 업무에서 AI가 하는 일 / 사람이 반드시 확인하는 일 / 최종 책임자” 세 칸짜리 역할표부터 채운다. 그다음에야 그 역할에 맞는 도구를 고른다. ChatGPT든 Copilot이든 Notion AI든 클로바노트든, 도구는 역할표 안에서 골라도 전혀 늦지 않는다. 실제로 최근 맡은 후속 프로젝트에서는 킥오프 첫날에 역할표부터 그렸다. 도구 도입까지 걸린 시간은 오히려 이전보다 짧았다. 뭘 확인할지가 미리 정해져 있으니, 도구 선택 자체가 빨라졌기 때문이다.
물론 이 순서가 만능은 아니다. 역할표를 먼저 그리려다 보니 “일단 써보고 나서 정하자”는 팀들의 반발도 있었다. 실제로 한 팀은 역할표 작성에만 하루를 더 썼고, 그 시간이 아깝다는 불만도 나왔다. 그래도 결론은 바뀌지 않았다. AI 도입에서 가장 먼저 필요한 건 최고 성능의 도구를 찾는 기술 검토가 아니라 역할 재정의였다. 어떤 도구를 쓸지보다, 그 도구가 들어올 자리에서 사람의 역할이 어떻게 달라지는지를 먼저 정하는 조직이 결국 더 빨리, 더 안전하게 자리 잡았다.
관련 글
출처
- 1 외부 Introducing ChatGPT Enterprise OpenAI
- 2 외부 AI Meeting Notes—Perfect meeting memory Notion
- 3 외부 Using GitHub Copilot code review - GitHub Docs https://docs.github.com/copilot/using-github-copilot/code-review/using-copilot-code-review
실무에서 검증한 AI 활용 기록, 계속 받아보기
이 글에서 다룬 판단 기준과 실패담을 카테고리별로 더 모아뒀습니다.
댓글
0