AI 도입 체크리스트: 도구 선정 전 확인할 5단계

AI 도구를 먼저 고르는 회의는 대체로 비슷한 결말로 간다. 이 글은 어떤 도구가 더 나은가를 가리는 글이 아니라, 도구 선정 앞에 놓여야 할 순서에 관한 글이다. 조직에 AI를 붙이는 일을 여러 해 해오면서, 도구의 성능 차이보다 도입 순서가 결과를 더 크게 갈랐다는 판단에 이르렀다.

왜 도구부터 고르면 실패하는가

도구를 첫 단추로 끼운 도입은 초기 사용률이 높아도 오래가지 않는 경우가 많다. 회의 첫머리에 “A와 B 중 뭐가 낫냐”는 질문이 나오면, 나는 그 질문 자체를 순서가 뒤바뀐 신호로 읽는다. 누가 쓸지, 어떤 업무에, 어떤 권한으로 쓸지가 정해지지 않은 상태에서 도구 이름부터 오가고 있다는 뜻이기 때문이다.

이런 도입은 계정은 살아 있는데 로그인 기록이 없는 상태로 수렴하곤 한다. 원인을 도구에서 찾기 쉽지만, 실제로 빠져 있는 건 대체로 다른 것이다. 그 도구가 만든 결과물을 누가 검증하고, 누가 다음 단계로 넘길 권한을 갖는지에 대한 합의다. 이 합의가 없으면 결과물은 만들어지되 아무도 책임지지 않는다. 책임지지 않는 산출물은 업무 흐름 안으로 들어가지 못하고, 그러면 도구는 자연히 쓰이지 않게 된다.

도구보다 먼저 정해야 하는 다섯 단계

이 실패를 막으려고 내가 쓰는 순서는 준비 → 도구 선정 → 시범 적용 → 역할 분담 → 정착이다. 각 단계에 배정하는 기간은 조직 규모에 따라 달라지지만, 순서 자체는 바꾸지 않는다.

• ① 업무 프로세스·역할 재정의 — 도구 이야기를 꺼내기 전에 현재 업무 흐름과 병목 지점을 문서화한다. 최소 1~2주는 잡는다.
• ② 요구사항 기반 도구 선정 — “무엇이 필요한가”를 먼저 정의하고 그다음 후보군을 좁힌다.
• ③ 소규모 시범 적용 — 팀 전체가 아니라 5~8명 규모 파일럿으로 4주가량 운영한다.
• ④ 역할·책임 분담 재설계 — 검증자, 승인자, 실사용자를 명시적으로 나눈다.
• ⑤ 운영 정착과 피드백 루프 — 월 1회 사용 로그를 열어 재조정한다.

핵심은 ①과 ②의 순서다. 이 둘을 뒤바꾸면 나머지 세 단계는 형식만 남는다. 요구사항이 정의되지 않은 채 고른 도구는 파일럿에서 무엇을 측정해야 하는지조차 정하지 못하게 만들기 때문이다. 측정 기준이 없으면 시범 적용은 “써봤더니 괜찮더라” 수준의 인상평으로 끝나고, 그 인상평으로는 역할 분담을 설계할 수 없다.

도구 비교: 기능이 아니라 결합도로 본다

아래 세 도구는 기능의 우열로 비교할 대상이 아니다. 팀의 워크플로우와 얼마나 결합되는가를 기준으로 봐야 한다. 같은 도구도 어디에 놓이느냐에 따라 결과가 갈린다.

ChatGPT Enterprise는 보안·거버넌스 요구가 큰 조직에서 강점이 뚜렷하다. SSO 연동, 데이터 잔류 정책, 관리자 콘솔의 사용 로그는 규제 산업에서 선택이 아니라 전제 조건에 가깝다. 대신 온보딩 비용을 낮게 잡으면 안 된다. 보안팀 검토와 사내 데이터 반출 정책 재검토, 부서별 권한 매트릭스 작성이 겹치면 준비 기간이 초기 계획보다 길어지는 쪽이 일반적이다.

Notion AI는 성격이 정반대다. 이미 Notion으로 기획 문서와 회의록을 관리하는 팀이라면 별도 온보딩이 거의 필요 없다. 문서 요약, 회의록 정리, 태스크 생성이 기존 흐름 위에 그대로 얹힌다. 반대로 복잡한 데이터 분석이나 코드 리뷰까지 범위를 넓히면 한계가 빨리 드러난다. 이 도구는 이미 문서 중심으로 일하는 팀에서만 강하다고 보는 편이 정확하다.

GitHub Copilot은 개발팀에서 체감 효과가 빠르게 나오는 편이다. 경계해야 할 건 그다음이다. 개발팀의 성과를 근거로 전사 확대를 결정하는 흐름이 흔히 나타나는데, 코드가 아닌 업무에 코드 자동완성 도구를 배치하면 “이게 왜 필요한지 모르겠다”는 반응이 나오기 쉽다. 이건 도구의 문제가 아니라 배치의 문제다.

도구	강점	적합한 상황
ChatGPT Enterprise	보안·거버넌스 통제, 조직 전체 지식 접근성	규제·보안 요구가 높은 조직의 전사 도입
Notion AI	기존 문서·협업 워크플로우에 자연스러운 통합	지식관리·기획 중심 팀의 문서 자동화
GitHub Copilot	코드 생산성 향상, 개발자 워크플로우 최적화	개발팀 단위의 국소적 파일럿

순서를 바꾸면 무엇이 달라지는가

도입이 정체됐을 때 도구를 교체하는 선택은 대개 같은 자리로 돌아온다. 사용률이 떨어졌다는 보고를 받으면 나는 추이 그래프보다 두 가지 질문에 답할 사람이 있는지를 먼저 확인한다. 이 결과물을 누가 검토하는가. 누가 다음 단계로 넘길 권한을 갖는가.

두 질문에 답이 없다면 도구를 바꿔도 결과는 반복된다. 이럴 때는 논의에서 도구 이름을 잠시 걷어내고 역할표부터 다시 그리는 편이 빠르다. 검증자와 승인자, 실사용자를 자리 단위로 채워 넣는 작업이다. 표를 채우다 보면 비어 있는 칸이 드러나는데, 대체로 그 빈칸이 정체의 원인이다.

이 작업은 도구 교체보다 효과가 크지만 눈에 덜 띈다. 새 도구에는 도입 발표가 있고 역할표에는 없기 때문이다. 그래서 조직 안에서 늘 뒤로 밀린다. 이 비대칭을 알고 있는 것만으로도 판단이 달라진다.

지금 도입을 맡는다면 먼저 하는 것

준비 단계에 배정하는 시간을 처음 계획보다 넉넉히 잡는다. 짧게 잡아 아낀 시간은 도입 후반부에 되돌리는 비용으로 돌아오는 경우가 많다. 업무 흐름 정리와 역할 정의는 눈에 보이는 산출물이 적어 압축하고 싶어지는 구간인데, 압축한 만큼 뒤에서 대가를 치른다.

도구 비교는 여전히 중요하다. 다만 비교의 기준이 “무엇이 더 좋은가”가 아니라 “이 팀의 워크플로우에 무엇이 결합되는가”여야 한다. 보안이 최우선인 조직, 문서 중심으로 일하는 팀, 개발팀 국소 파일럿 — 적합한 자리는 도구마다 다르다.

순서를 안다고 매번 지키게 되는 것도 아니다. 도구부터 고르고 싶은 압력은 대체로 조직 바깥에서 온다. 그럴 때 쓰는 방어선은 하나다. 도구 이름을 꺼내기 전에 검증자와 승인자를 먼저 적어보자고 제안하는 것. 이 한 줄을 회의 앞에 세우는 것만으로 논의의 순서가 바뀌는 경우가 적지 않다.

관련 글

• 경영진 설득에 실패했던 AI 도입 프로젝트 기획