POOOLING FOREST
CTO의 시선: 우리 회사에 AI를 도입할 때 가장 먼저 고민해야 할 것은 기술이 아닙니다 - 기술 스펙에만 몰두했던 CTO의 고백. AI 도입의 성공은 모델의 성능이 아니라 구성원의 '진짜 문제'를 해
Business Insight

CTO의 시선: 우리 회사에 AI를 도입할 때 가장 먼저 고민해야 할 것은 기술이 아닙니다

기술 스펙에만 몰두했던 CTO의 고백. AI 도입의 성공은 모델의 성능이 아니라 구성원의 '진짜 문제'를 해결하는 데 달려있습니다. 실전에서 얻은 4가지 체크리스트를 공유합니다.

송찬영

CTO

솔직히 고백하자면, 처음 회사 전체에 AI 도입을 결정했을 때 저는 기술적인 스펙에만 몰두해 있었습니다. 어떤 LLM(Large Language Model)이 가장 성능이 좋은지, RAG(Retrieval-Augmented Generation) 파이프라인을 어떻게 구성해야 지연 시간을 줄일 수 있을지 같은 것들 말이죠. 엔지니어 출신 CTO로서 너무나 당연한 반응이었을지도 모릅니다. 하지만 그 접근 방식이 얼마나 위험한 착각이었는지 깨닫는 데는 그리 오랜 시간이 걸리지 않았습니다.

오늘은 제가 풀링포레스트에서 AI를 활용해 일하는 방식을 혁신하면서 겪었던 시행착오와, 그 과정에서 얻은 뼈아픈 교훈들을 공유해 보려 합니다. 기술 리더뿐만 아니라 현장에서 고군분투하는 개발자분들에게도 도움이 되길 바랍니다.

가장 큰 문제는 '기술 과잉'에서 시작되었습니다. 작년 말, 우리는 사내 지식 관리 시스템에 AI를 붙이기로 했습니다. 모든 개발 문서와 슬랙 대화 내용을 학습시켜, 질문만 하면 척척 답해주는 봇을 만들겠다는 야심 찬 계획이었죠. 저는 팀원들에게 최신 벡터 데이터베이스를 구축하고, 비싼 GPU 인스턴스를 확보하라고 지시했습니다. 엔지니어들은 눈을 반짝이며 코드를 짰습니다. 기술적으로는 훌륭한 도전이었으니까요.

하지만 한 달 뒤, 결과물을 내놓았을 때 마주한 현실은 차가웠습니다. 봇은 기술적으로는 잘 작동했지만, 아무도 쓰지 않았습니다. 기획팀은 "답변이 너무 개발자스럽다"고 했고, 영업팀은 "내가 원하는 건 고객사의 미팅 히스토리인데, 왜 기술 문서 내용만 나오냐"며 불만을 토로했습니다. 심지어 개발팀 내부에서조차 "그냥 컨플루언스 검색하는 게 더 빠르다"는 말이 나왔습니다.

그때 머리를 한 대 맞은 것 같았습니다. 우리는 '문제를 해결하는 도구'를 만든 게 아니라, 그저 'AI 기술을 썼다'는 사실에 취해 있었던 겁니다. 기술 도입 자체가 목적이 되어버린 전형적인 실패 사례였습니다. 리소스는 리소스대로 낭비하고, 팀의 사기는 꺾여버린 상황. 저는 원점부터 다시 생각해야 했습니다.

"우리는 왜 AI를 도입하려고 했는가?"

이 질문에 답하기 위해 개발팀 모니터 뒤에서 나와, 기획팀과 운영팀의 자리로 갔습니다. 그들이 실제로 하루 종일 어떤 작업을 반복하고 있는지, 어디서 병목이 발생하는지 관찰했습니다. 놀랍게도 그들의 고통은 거창한 지식 검색이 아니었습니다. 고객 문의 이메일을 분류하고 초안을 작성하는 단순 반복 업무, 그리고 회의록을 요약해서 액션 아이템으로 변환하는 지루한 과정이 그들의 시간을 갉아먹고 있었습니다.

우리가 집중해야 할 곳은 화려한 기술적 아키텍처가 아니라, 바로 이 지루하고 반복적인 업무의 자동화였습니다.

방향을 틀었습니다. 자체 모델을 구축하려던 거창한 계획을 접고, 이미 잘 만들어진 상용 API를 활용해 아주 가벼운 툴부터 만들기로 했습니다. 고객 지원팀이 메일을 받으면 AI가 내용을 분석해 '환불 요청', '기술 문의', '제안' 등으로 태그를 달아주고, 기본적인 답변 초안을 슬랙으로 쏴주는 간단한 봇이었습니다. 개발 기간은 단 3일이었습니다.

반응은 폭발적이었습니다. 운영팀 리더가 제게 찾아와 "덕분에 하루에 2시간을 아끼게 됐다"며 고마워했습니다. 그제야 저는 깨달았습니다. 성공적인 AI 도입은 모델의 파라미터 개수가 아니라, 조직 구성원의 '진짜 문제'를 얼마나 정확하게 타격하느냐에 달려있다는 것을요.

이 경험을 통해 제가 정립한 '실패하지 않는 AI 도입 체크리스트'는 다음과 같습니다. 여러분도 새로운 프로젝트를 시작하기 전에 꼭 한 번 점검해 보셨으면 합니다.

  • 첫째, 기술이 아닌 고통(Pain point)에서 시작하고 있나요? "요즘 이 기술이 핫하니까 써보자"는 가장 위험한 발상입니다. "우리 팀 김 대리가 매일 엑셀 복사 붙여넣기로 3시간을 쓰고 있다"는 구체적인 고통이 출발점이 되어야 합니다.

  • 둘째, PoC(개념 증명)는 1주일 안에 끝낼 수 있나요? AI 기술은 너무나 빠르게 변합니다. 6개월짜리 거대 프로젝트를 계획하다가는 배포할 때쯤 이미 구식 기술이 되어있을 수 있습니다. Cursor나 Claude 같은 도구를 활용해 빠르게 프로토타입을 만들고, 실제 사용자(동료)의 피드백을 받아 수정하는 애자일한 접근이 필수적입니다.

  • 셋째, '휴먼 인 더 루프(Human-in-the-loop)'를 고려했나요? AI는 완벽하지 않습니다. 100% 자동화를 꿈꾸다 보면 할루시네이션(환각) 현상으로 인해 대형 사고가 터질 수 있습니다. AI가 80%의 초안을 만들고, 사람이 나머지 20%를 검수하고 결정하는 프로세스를 설계해야 합니다. 이것이 기술적 리스크를 줄이고 도입 거부감을 낮추는 핵심입니다.

  • 넷째, 보안과 비용 구조를 초기에 검토했나요? 토큰 기반 과금 모델은 트래픽이 늘어나면 비용이 기하급수적으로 증가할 수 있습니다. 또한 사내 민감 데이터가 외부 API로 전송되는 것에 대한 보안 가이드라인을 초기에 잡지 않으면 나중에 큰 부채가 됩니다.

지금 우리 회사는 개발자들뿐만 아니라 마케터, 디자이너까지 자신의 업무에 AI를 자연스럽게 녹여내고 있습니다. 중요한 건 거창한 시스템이 아니라, 개개인이 도구를 활용해 자신의 역량을 확장하는 경험을 하는 것입니다.

AI 도입은 단순히 새로운 소프트웨어를 설치하는 것이 아닙니다. 조직이 일하는 방식을 근본적으로 재설계하는 과정입니다. CTO로서, 그리고 기술 리더로서 우리는 코드 너머에 있는 사람을 봐야 합니다. 기술은 결국 사람을 돕기 위해 존재하는 것이니까요.

오늘 당장 옆자리 동료에게 물어보세요. "지금 당신을 가장 귀찮게 하는 일이 무엇인가요?" 그 대답 속에 혁신의 씨앗이 숨어있을 겁니다.

지금 읽으신 내용, 귀사에 적용해보고 싶으신가요?

상황과 목표를 알려주시면 가능한 옵션과 현실적인 도입 경로를 제안해드립니다.