내가 겪은 AI를 도입했을 때 생겼던 문제들

AI가 업무 방식을 빠르게 바꾸고 있다. 기획서를 쓰고, 코드를 만들고, 문서를 정리하는 일까지 이제는 몇 분이면 끝난다. 예전에는 하루가 걸리던 일이 몇 시간, 때로는 몇 분으로 줄었다. 생산성은 분명 올라갔다.

그런데 여러 프로젝트에서 AI 도입을 지켜보면서 한 가지 공통된 현상을 발견했다.

AI를 잘 쓰자 보다, AI에게 일을 맡기자 하는 조직이 점점 많아지고 있다.

겉으로는 둘 다 AI를 쓰는 것처럼 보인다. 하지만 결과는 전혀 다르다.

AI는 뛰어난 도구다. Skill, Agent, MCP, Workflow 같은 기술도 계속 좋아지고 있다.

그런데 내 생각에는 그보다 더 중요한 원칙 하나가 빠져 있다. 그 원칙이 없다면, 차라리 AI를 쓰지 않는 편이 조직에는 더 나을 수도 있다고 생각이 들었다.

이 글에서는 실제 기업이 AI를 도입하며 겪는 문제들을 하나씩 짚어보려고 한다.

① AI는 답을 냈지만, 아무도 설명하지 못했다

첫 번째 문제는 여기서 시작한다.

AI는 학습된 일반적인 지식을 바탕으로 답을 만든다. 하지만 기업 내부의 도메인 지식, 조직 문화, 암묵적인 업무 규칙, 오래된 레거시 시스템은 기본적으로 알지 못한다.

결국 가장 중요한 맥락은 사람이 제공해야 한다.

그래서 나는 이렇게 생각한다. AI는 딱 나만큼만 똑똑하다. 내가 문제를 이해한 만큼, 내가 건넨 맥락만큼만 좋은 답을 낸다. 내가 이해하지 못한 문제를 AI가 알아서 대신 이해해 주지는 않는다.

그런데 이 맥락을 사람이 이해하지도, 제공하지도 않은 채 문제를 통째로 넘겨버리는 일이 자주 일어난다. "이런 도메인 문제가 있는데, 해결해서 기획서까지 써줘" 같은 식이다.

AI가 만든 해결책은 훌륭할 수도 있다. 문제는 그다음이다.

작성자가 그 해결책을 설명하지 못하면, 조직은 그 순간부터 더 많은 비용을 지불하기 시작한다.

회의에서 질문이 나온다.
"이 기능은 왜 이렇게 설계했나요?"
"어떤 요구조건, 어떤 문제 때문에 이렇게 만들어져야 하죠?"

사실 "AI가 그렇게 하라고 했습니다"라고 대놓고 답하는 경우는 거의 없다. 보통은 그 자리에서 그럴듯한 이유를 붙여 설명한다.

진짜 문제는 그다음이다. 그 이유에 아무도 온전히 납득하지 못하고, 회의는 결론에 닿지 못한 채 계속 겉돈다. 설명하는 사람조차 그 해결책을 완전히 이해하고 있지 않기 때문이다.

그렇게 설계 검토도, 위험 분석도, 대안 비교도 제자리를 맴돈다. 답은 나와 있는데, 그 답을 진짜로 책임지는 사람은 없다.

여기서 오해하지 말아야 할 게 있다. AI는 문제 해결 능력이 매우 뛰어나다. 문제 해결을 인간이 다시 가져와야 한다는 이야기가 아니다.

AI가 여러 해결책을 제안하는 것은 훌륭하다. 오히려 AI에게 "이 문제는 A, B, C 중 어떻게 푸는 게 좋을까"를 묻고, 사람이 그걸 이해한 뒤 하나를 고르는 방식은 아주 바람직하다.

문제가 되는 건 그 선택과 이해, 책임까지 통째로 넘길 때다.

개발자들은 이걸 코딩처럼 하네스(harness) 안에 두고, 통제된 범위의 일만 시키는 데 비교적 익숙하다. 하지만 이것도 사람과 조직마다 다르다. 특히 AI를 맹신할수록 이 현상은 더 자주 나타난다.

정리하면 이렇다.

AI에게 답을 요청하는 것은 문제가 아니다. 그 답을 설명할 사람이 없는 것이 문제다.

그리고 그 대가는 결국 커뮤니케이션 비용으로 돌아온다.

나는 커뮤니케이션 비용이 정말, 정말 비싸다고 생각한다. 서로 맥락이 통해서 굳이 길게 설명하지 않아도 무의식적으로 합이 맞는 환경. 그렇게 일할 수 있다는 건 생각보다 큰 자산이다. 그런데 설명되지 않는 답이 하나둘 쌓여 그 합이 한번 깨지는 순간, 그 비용은 천문학적으로 불어날 수밖에 없다.

나는 AI 시대에도 끝까지 사람의 몫으로 남는 게 있다면, 그건 문제를 붙들고 사고하는 능력이라고 생각한다.
물론 언젠가는 이것마저 AI가 더 잘하게 될지도 모른다. 그건 나도 장담하지 못한다.
하지만 적어도 지금, 사람이 사고하는 방식과 지금까지 쌓여온 지식은 여전히 믿을 만하고, 충분히 쓸 만하다고 생각한다.
그래서 나에게 AI는 내 일을 도와주는 도구이지 나를 대신하는 존재가 아니다.

② 비개발 직군도 앱을 만든다 — 만드는 일과 굴리는 일은 다르다

요즘 이런 이야기가 자주 들린다. 해커톤 우승 팀을 보면 개발 직군보다 비개발 직군이 더 높은 순위에 오르더라는 것이다. 도메인과 맥락, 이야기를 더 잘 아는 사람이 AI로 직접 코딩을 하고, 그게 더 설득력 있는 결과물로 나온다는 것이다.

어느 정도는 맞는 말이다. 나도 비개발 직군이 AI로 의미 있는 제품을 만들어 내는 걸 여러 번 봤다. 화면이 돌아가고, 데모가 되고, 사람들이 "오, 이거 되네" 하는 순간까지는 분명히 간다.

문제는 그 순간 이후다.

앱은 화면만으로 돌아가지 않는다. 어딘가에 배포되어 있고, 데이터는 어딘가에 저장되고, 누군가는 그 접근 권한을 쥐고 있다. 개발자는 애초에 이 앱이 어떤 환경, 어떤 반석 위에서 돌아가는지를 같이 생각하면서 만든다. 인프라가 늘 머릿속 한켠에 있다.

반면 비개발 직군은 이 부분에 지식이 약할 수밖에 없다. 도메인만 바라보면 가장 잘 보이지만, 정작 그 아래에서 서비스를 떠받치는 인프라와 보안은 시야에서 빠진다. 그리고 하필 그게, 만든 것을 진짜 서비스로 올릴 때 가장 중요한 부분이다.

데모가 서비스로 넘어가려는 순간, 미뤄뒀던 질문들이 한꺼번에 올라온다.

이 앱은 보안이 괜찮은가. 인증과 권한, 개인정보는 어떻게 다루고 있나. 배포는 어디에 어떻게 하고, 장애가 나면 누가 대응하나. 트래픽이 몰리면, 비용은, 로그는 어디서 보나.

여기서 더 현실적인 문제가 이어진다. 이걸 해결하려면 결국 비개발자에게 인프라를 열어줘야 하는데, 그 순간 또 다른 고민이 시작된다.

인프라를 어디까지 열어줄 것인가. AWS 콘솔을 난생처음 보는 사람에게 무엇을, 어디서부터 알려줘야 하나. 우리 회사의 인프라·보안 컨벤션은 또 어떻게 설명하고, 어디서부터 맞춰 나가야 하나. 끝내 백엔드 개발자가 붙어야 한다면, 둘은 어떤 방식으로 손발을 맞춰야 하나.

이쯤 되면 답이 어느 정도 보인다.

서비스가 실제로 돌기 시작하면, 그 운영권은 대개 개발팀으로 넘어온다. 보안 점검도, 배포 파이프라인도, 인프라 관리도 결국 개발팀이 떠안는다. 처음에는 "개발 리소스를 아꼈다"고 생각했지만, 코어가 되는 일은 시간을 두고 다시 개발팀으로 돌아온다.

AI는 전문직의 진입 장벽을 낮추고 있다. 하지만 전문직의 허들까지 무너뜨렸다고 보기는 아직 이르다고 본다.
만드는 것과 운영하는 것은 여전히 다른 문제이고, 마지막 책임은 결국 그 분야의 전문성이 있는 사람이 지게 된다.

총평?~ 그런데 이 글이 다 맞는 이야기는 아니다

여기까지 쓰고 나니 스스로 짚어둬야 할 것이 있다. 이 글은 데이터가 아니라 관찰이다.

내가 본 것은 몇 개의 조직과 몇 개의 프로젝트다. 업계도 한정되어 있고 규모도 한정되어 있다. 세상에는 AI를 훨씬 잘 녹여낸 조직이 분명히 있을 것이고, 나는 그 사례를 충분히 보지 못했다. 그리고 나는 AI 도입 전략을 설계하는 위치에 있는 사람도 아니다. 옆에서 지켜본 개발자 한 명의 시점일 뿐이라, 개발자 특유의 편향이 섞여 있을 수밖에 없다.

그래서 내가 틀렸을 가능성이 가장 크다고 생각하는 지점을 세 개만 먼저 적어두려고 한다.

 

나는 앞에서 AI는 딱 나만큼만 똑똑하다고 썼다. 맥락은 사람이 넘겨야 한다는 전제 위에서 쓴 문장이다.

그런데 이 전제 자체가 지금 흔들리고 있다. 컨텍스트 길이는 계속 늘어나고 있고, 사내 문서와 코드베이스, 이슈 트래커를 직접 연결하는 방식도 빠르게 자리를 잡고 있다. 조직의 암묵적인 규칙과 오래된 레거시의 맥락까지 모델이 스스로 참조할 수 있게 되면, 내가 지금 문제라고 지적한 부분의 상당수는 자연스럽게 줄어들 것이다. 그 시점이 언제일지는 나도 모른다. 다만 내가 예상하는 것보다 빠를 수 있다고는 생각한다.

성과를 속도로만 측정하지 않기

AI 도입의 성과를 얼마나 빨리 만들었는가로만 측정하면, 조직은 반드시 그 방향으로 최적화된다. 사람은 측정되는 것을 잘하게 되어 있다.

문제는 이해도나 설명 가능성 같은 것은 측정하기가 어렵다는 점이다. 그래서 자연스럽게 지표에서 밀려난다. 그리고 밀려난 것은 시간이 지나면 조직에서 중요하지 않은 것으로 취급된다.

완벽하게 측정할 방법은 나도 모르겠다. 다만 측정이 어렵다는 이유로 아예 보지 않는 것과, 거칠게라도 보려고 하는 것은 결과가 꽤 다르다고 생각한다. 산출물이 올라왔을 때 이거 누가 설명할 수 있나요라는 질문을 회의에서 습관처럼 던지는 것만으로도 분위기는 달라진다.

무엇을 맡기고 무엇은 맡기지 않을지 정해두기

개발자들은 코딩할 때 통제된 범위 안에서만 AI를 쓰는 데 비교적 익숙하다. 그런데 이건 대체로 개인의 습관이지 조직의 규칙이 아니다. 개인의 판단에 맡기면 사람마다 기준이 달라지고, 그 차이는 결국 협업 지점에서 부딪힌다.

거창한 가이드라인이 필요하다는 뜻은 아니다. 설계 결정과 그 근거는 사람이 쓴다, 외부로 나가는 문서는 작성자가 모든 문장을 설명할 수 있어야 한다. 이 정도의 짧은 합의만 있어도 서로 어디까지 기대해도 되는지는 알 수 있다.

도구 도입이 아니라 일하는 방식의 변경으로 다루기

가장 자주 본 오해가 이것이다. 툴을 계약하고 계정을 나눠주면 도입이 끝났다고 생각하는 것.

실제로 바뀌어야 하는 것은 도구가 아니라 리뷰 방식, 문서 작성 방식, 책임이 놓이는 위치 같은 것들이다. 그런데 이런 것들은 도구보다 훨씬 느리게 바뀐다. 도구가 들어오는 속도와 조직이 적응하는 속도가 벌어지고, 그 간극에서 앞의 문제들이 생기는 것 같다.

개인 차원에서는

조직 이야기만 하다 보니 정작 나는 어떻게 하고 있는지도 적어두는 게 맞을 것 같다.

나는 요즘 한 가지 기준만 지키려고 한다. 내가 설명할 수 있는 만큼만 커밋한다는 것이다. 이해가 안 되면 이해될 때까지 되묻는다.

시간을 아끼려고 도입한 도구인데 되묻느라 시간을 더 쓰는 게 손해처럼 느껴질 때도 있다. 그런데 지금까지 보면 그 시간은 대체로 나중에 회수된다 무조건. 설명하지 못한 채 넘어간 것들이 몇 배의 시간이 되어 회의실로 돌아가게될 것이다.

AI는 사람을 대체하는 것이 아니라, 사람을 증폭시키는 도구다

AI는 분명 업무 방식을 바꾸고 있다.

예전보다 더 빠르게 만들고, 더 많이 만들고, 더 적은 비용으로 시도할 수 있게 됐다. 이 변화는 앞으로도 계속될 것이다.

하지만 지금까지 여러 프로젝트를 보며 느낀 것은 하나다.

AI를 도입했다고 생산성이 올라가는 것이 아니라, AI를 어떤 방식으로 조직에 녹여냈는지가 생산성을 결정한다.

문제를 이해하지 않은 채 AI에게 답을 맡기면 커뮤니케이션 비용이 늘어난다. 전문성이 필요한 영역까지 AI에게 맡기면, 결국 그 책임은 다시 전문가에게 돌아온다.

결국 AI가 대체하는 것은 '생각'이 아니라 반복 작업에 더 가깝다.

그래서 나는 AI 시대에도 사람에게 가장 중요한 능력은 여전히 같다고 생각한다.

• 문제를 정의하는 능력
• 맥락을 이해하는 능력
• 여러 선택지 중 무엇을 선택할지 판단하는 능력
• 그리고 그 선택에 책임지는 능력

이 네 가지는 아직까지 AI가 대신해 주지 못한다.

물론 몇 년 뒤에는 이 글이 틀렸다고 증명될 수도 있다. AI는 지금도 놀라운 속도로 발전하고 있고, 앞으로 어디까지 갈지는 누구도 장담할 수 없다.

하지만 적어도 지금의 AI는 사람을 대신하는 존재라기보다, 사람의 능력을 증폭시키는 도구에 가깝다.

그래서 내가 생각하는 좋은 조직은 AI를 많이 쓰는 조직이 아니라, AI를 통제할 줄 아는 조직이다.