AI tools를 추가한 후 디자인 팀이 길을 잃는 걸 본 사람 있나요?
Has anyone else watched their design team get lost after adding AI tools?
배경 및 소개
디자인·제품 조직이 급격히 AI 도구를 도입하면서 “어떤 AI를 쓸까?”가 화두가 됐지만, 정작 “우리 팀이 이 변화를 흡수할 준비가 돼 있나?”라는 질문은 뒷전으로 밀리고 있다. 게시글은 많은 팀이 AI를 추가해도 실질적 성과나 작업 방식의 개선이 거의 없고, 오히려 기록되지 않은 의사결정이 늘어나며 기존 업무 흐름 속에서 도구가 길을 잃는 현상을 관찰한다. 이는 단순한 툴 선택 문제가 아니라, 프로세스 이해·변경·정착을 포함한 변화흡수(absorption) 능력의 결핍일 수 있다는 문제의식에서 출발한다. 커뮤니티 논의는 AI 도입이 인지적 태만, 문서화 약화, 책임 공백을 유발할 위험과 함께, 명확한 사용 맥락·소유자·변경관리 없이는 ‘접근권=정착’으로 오해하는 조직적 착시가 빈번하다는 점을 드러낸다. 결국 주제의 맥락은 HCI/UX 실무 전반의 협업 구조, 의사결정 가시화, 도구 거버넌스 역량을 묻는 담론으로 확장된다.
주요 내용
핵심 논점은 AI 자체의 성능보다 팀이 이를 어디에, 어떻게, 무엇을 대체하며 쓸지 합의하고 책임을 질 수 있느냐에 달려 있다는 점이다. 상위 댓글은 도입 후 나타나는 공통 징후를 구체적으로 짚는다. 사람들이 더 적게 살피고, 파일도 덜 열고, 코드를 누가 어디에 썼는지 모른 채 팀·사용자와의 대화와 탐색 과정을 건너뛰고, 자신이 만든 조각이 없어 구성요소의 동작을 설명하지 못한다. 목표·도구와의 연결감이 약해지고, 일자리 불안 속에 ‘AI 배우기’에 시간을 쓰며 산만해진다. PM은 프로토타이핑에 쏠리고, 이해관계자는 ChatGPT로 만든 텍스트를 던지며, 리더는 더 많은 AI를 얹으려 한다. 이 모든 층위에서 의도와 맥락이 흐려지며 기록되지 않은 결정이 누적된다.
또 다른 관점은 “어떤 도구?”라는 질문이 실제로는 “우리 프로세스가 어디서 깨지는지 모른다”는 증상이라는 지적이다. 잘하는 팀은 화려한 데모보다 “우리가 일관되게 못 하거나 개선할 한 가지는 무엇이며, AI가 정말 그 문제를 해결하는가?”라는 지루하지만 정확한 질문으로 시작한다. 흡수 문제를 풀려면 초기에 통합을 ‘소유’할 사람이 필요하고, 어디에 끼우고 무엇을 대체하며 어떤 신규 의사결정을 낳는지까지 정의해야 한다. 단순히 접근권을 주는 것은 정착을 의미하지 않으며, 이런 설계가 없을수록 AI 출력이라는 비공식 결정층이 얹혀 혼란을 키운다.
개인·팀 수준의 사용 원칙도 제시된다. AI가 사고를 대리하면서 ‘브레인 오프’가 되는 위험이 있으므로, 특히 역량 밖의 작업을 맡길수록 의도성이 약화된다. 한 사례는 디자인에는 거의 쓰지 않고, 기획·리서치·분석에서 AI를 SME처럼 워크숍 파트너로 다루되, 일정 시간을 AI 없이 스스로 정리하며 주도권을 유지한다. 개발 쪽에서는 Claude Code가 태스크 분해, 견적, 코드 문제 정리에 도움을 주지만 표면적 사고로 흐르지 않도록 주의하며, AI가 끼워넣은 항목을 리드가 기억 못한 사례처럼 책임·추적성의 리스크가 드러난다. 구조가 없으면 문서화를 건너뛰고 출력물에 의존해 악화되므로, 의사결정의 간단한 워크스루를 정례화해 정렬을 유지하는 팀도 있다(runable 같은 비동기 정리 도구가 언급됨). BA 관점에서는 AI를 새로운 프로세스처럼 취급해, 기존 문제를 해결하는 최적 해법인지 검증하고, 이해관계자·비즈니스 요건 부합, 교육과 표준 운영절차를 포함한 change management로 통합해야 한다. 이는 Figma 도입 때도 보였던 문제로, 본질은 AI가 아니라 변화관리의 부재라는 결론으로 수렴한다.
결론 및 시사점
논의의 결론은 명확하다. 문제는 툴이 아니라 변화흡수와 거버넌스다. 명확한 문제정의 없이 접근권만 열면 채택은 일어나지 않고, 문서화 공백과 의사결정 추적성 상실, 표면적 사고와 의도성 약화가 누적된다. 이를 피하려면 문제-우선 접근으로 우선순위를 좁히고, 통합 소유자를 지정해 사용 지점·대체 범위·검토 기준을 설계하며, 사용 사례와 경계를 명확히 하고 결정 로그와 품질 기준을 통해 책임을 부여해야 한다. 또한 교육과 표준 운영절차, 정기적 워크스루와 AI 비개입 시간을 포함한 리듬을 마련해 인간의 판단이 주도권을 갖도록 해야 한다. 동시에 AI는 기획·리서치·분석·개발 보조 등에서 실제 생산성 이득을 줄 수 있으므로, 팀의 성숙도와 리스크를 고려해 점진적 파일럿과 측정으로 학습해 나가야 한다. 이 대화는 조직이 AI를 ‘툴 추가’가 아닌 ‘업무 시스템 재설계’로 다뤄야 함을 상기시키며, HCI/UX 맥락에서는 협업, 의사결정 가시화, 문서화, 책임소재라는 오래된 과제가 여전히 성패를 가른다는 점을 재확인한다.
💡 AI 도입은 ‘접근권 개방’이 아니라 문제-우선의 파일럿, 통합 소유자 지정, 명확한 사용 사례·경계, 결정 로그와 품질 기준을 갖춘 change management로 운영해야 한다. AI는 SME 같은 보조로 활용하되, 의도성과 책임을 유지할 구조와 리듬을 먼저 설계하라.
뉴스레터 구독
매주 금요일, 주간 HCI 하이라이트를 이메일로 받아보세요.