사내 실험용으로 만든 작은 위젯 하나가 회사 업무 포털 프로젝트가 됐습니다.
원대한 계획이 있었던 것은 아니라고 합니다. 사내 콘테스트에 제 부서의 팀원은 가벼운 마음으로 참여했습니다.
그가 만든 것은 사내 정보를 한눈에 볼 수 있게 만든 작은 위젯이었습니다. 처음에는 흩어진 정보를 정리하는 정도로 생각했다고 합니다.
그런데 동료의 한마디를 거치며 실제 업무에서 쓸 수 있는 화면으로 바뀌었습니다.
자료의 구조를 손으로 정리하고, 그 흐름을 AI에게 설명해 화면으로 만들었습니다.
작은 기능 하나였습니다.
그런데 작은 기능이라고 방심하면 안 됩니다.
회사에서는 가끔 이런 일이 벌어집니다. “이거 괜찮은데?”라는 말이 나오고, “조금만 더 해보면 되겠는데?”가 이어집니다.
그러다 어느 날 정신을 차려보면, 작고 귀여웠던 위젯은 더 이상 위젯이 아닙니다.
사내 업무 포털 프로젝트라는 이름표를 달고 회의실 한가운데 앉아 있습니다.
그렇게 회사 업무 포털 프로젝트가 시작됐습니다.
흩어져 있던 업무 도구와 자료, 소통 기능을 한곳에 모으는 일이었습니다.
매일 쓰는 기능에 빠르게 닿고, 한 사람의 작업 결과가 다음 사람의 출발점이 되도록 만드는 것이 목표였습니다.
말은 단정하지만, 실제로는 꽤 복잡합니다.
회사 안의 여러 물건을 정리하는 일은 책상 위를 치우는 일과 닮았습니다.
처음에는 펜 하나만 옮기려 했는데, 어느새 서랍 전체를 열고 있습니다. 열어보면 안쪽에서 오래된 영수증, 출처 모를 케이블, 언젠가 필요할 것 같아 넣어둔 무언가가 나옵니다. 회사의 업무 도구도 크게 다르지 않습니다.
이 프로젝트의 PM은 사내 정보 위젯을 만든, 이 회사가 첫 회사인 3년차 구성원이었습니다.
아직 경력의 초반부에 있는 사람이, 회사 전체가 쓰게 될 도구의 앞단에 선 셈입니다.
이 이야기를 들으며, 저는 AI가 장벽을 낮춘다는 말을 다시 생각했습니다.
맞는 말입니다. 예전 같으면 개발자에게 부탁해야 했을 작은 웹페이지를 이제는 몇 문장으로 만들어볼 수 있습니다.
코드를 잘 모르는 사람도 화면을 만들고, 기능을 붙이고, 수정 요청을 할 수 있습니다.
문장으로 웹사이트를 만드는 일이 더 이상 농담처럼 들리지 않습니다.
하지만 옆에서 과정을 들여다보면, 그렇게 쉬운 일이 아닙니다.
AI가 일을 대신해준 것처럼 보이지만, 그 전에 사람이 해야 하는 일이 있습니다.
무엇을 만들고 싶은지, 누구를 위해 필요한지, 어디까지 만들고 어디서 멈출지 먼저 정리해야 합니다.
나온 결과가 괜찮은지 아닌지를 판단하는 일도 사람에게 남습니다.
AI에게 일을 맡기려면, 먼저 내 일을 설명할 수 있어야 합니다. 이건 생각보다 무거운 일입니다.
“업무 포털을 만들어줘”라고 말하는 것만으로는 부족합니다.
어떤 정보가 필요한지, 기능은 어떻게 연결되는지, 보는 사람은 무엇을 먼저 알아야 하는지 알려줘야 합니다.
AI는 천재처럼 보일 때가 있습니다. 하지만 우리 회사의 일하는 방식까지 마음으로 헤아리는 천재는 아닙니다.
회사 업무 포털을 만들 때도 마찬가지였습니다. 시중에는 이미 많은 업무용 솔루션이 있습니다.
버튼도 많고, 기능도 많고, 설명서도 두껍습니다.
다만 모든 회사의 하루가 같은 모양은 아닙니다. 기능이 많다고 해서 우리 회사에 맞는 것도 아닙니다.
오히려 너무 많은 기능은 사람을 멀어지게 만들 수 있습니다.
사람은 생각보다 쉽게 지칩니다. 특히 내가 찾는 버튼만 빼고 다 있을 때 그렇습니다.
결국 질문이 바뀝니다. 무엇을 많이 넣을 것인가가 아닙니다.
우리에게 정말 필요한 것은 무엇인가.
구성원이 하루를 시작할 때 가장 먼저 열어야 하는 화면은 무엇인가.
흩어진 업무 도구를 어디까지 한곳에 모아야 하는가.
이 질문에 답하려면 조직의 일하는 방식을 알아야 합니다.
어떤 문서가 자주 쓰이는지, 어떤 기능을 찾느라 사람들이 시간을 쓰는지, 처음 입사한 사람이 어디에서 막히는지 알아야 합니다.
AI는 화면을 빠르게 만들어줄 수 있지만, 우리 조직의 하루를 대신 살아보지는 않았습니다.
그래서 AI 시대의 일은 더 쉬워지는 동시에 더 까다로워집니다.
실행은 빨라집니다. 하지만 기준이 없으면 빠르게 엉뚱한 곳으로 갑니다.
말하자면 AI는 속도가 빠른 쪽이고, 사람은 방향을 잡아야 하는 쪽입니다.
둘이 헷갈리면 일이 조금 우스워집니다. AI는 열심히 달립니다. 사람은 뒤늦게 외칩니다. 아니, 그쪽 말고.
그러면 AI는 다시 열심히 달립니다. 이번에도 조금 다른 방향입니다.
문제는 AI의 속도가 아닙니다. 출발 전에 지도를 제대로 줬는가입니다.
이 과정에서 흥미로웠던 것은, 이번 프로젝트의 PM이 바이브코딩을 하며 배운 것과 SOW를 작성하며 배운 것이 닮아 있었다는 점입니다. SOW는 프로젝트의 범위와 책임을 정리하는 문서입니다. 무엇을 할 것인지도 중요하지만, 실제로는 무엇을 하지 않을 것인지가 더 중요할 때가 많습니다. 그 선을 정하지 않으면 모든 요청이 프로젝트 안으로 들어옵니다. 그러면 책임도 함께 밀려옵니다.
프롬프트도 비슷합니다. 어떤 기능이 핵심인지, 어떤 표현은 피해야 하는지, 이번에는 어디까지 구현할 것인지, 어떤 판단은 사람이 다시 확인해야 하는지 알려줘야 합니다. 프롬프트는 마법 주문이 아닙니다. 작은 SOW에 가깝습니다.
마법 주문이라면 좋았을 겁니다. 그럴듯한 문장 하나를 입력하면, 화면이 생기고, 기능이 붙고, 오류는 알아서 사라지고, 요청자는 감동하고, PM은 정시 퇴근합니다. 하지만 대체로 그런 일은 일어나지 않습니다.
“알아서 해줘”라는 말은 여전히 위험합니다. 대체로 “알아서”의 빈칸은 나중에 누군가의 야근으로 채워집니다.
이 프로젝트의 PM이 바이브코딩을 하며 느낀 어려움도 여기에 가까웠습니다.
AI가 한 번에 의도를 정확히 알아듣지 못했고, 자잘한 실수나 빠진 부분이 계속 따라왔습니다.
그래서 방식이 바뀌었습니다. 수정사항을 먼저 정리한 뒤, 그것을 프롬프트로 다듬어 전달하는 식으로요.
이건 AI에게 명령을 내리는 일이 아니라, 내가 원하는 결과를 먼저 구조화하는 일입니다.
그러니 AI가 등장했다고 작성이 사라진 것은 아닙니다.
작성의 위치가 바뀐 것입니다. 손으로 코드를 짜던 자리에서, 무엇을 어떻게 만들지를 설명하는 자리로 옮겨간 것입니다.
코드를 아는 사람의 가치가 사라졌다는 뜻은 아닙니다. 복잡한 문제일수록 전문성은 더 중요합니다.
다만 코드를 모르는 사람도 아이디어를 화면으로 시험해볼 수 있는 길이 열렸습니다.
이쯤에서 사람이 겸손해져야 하는 부분이 있습니다. AI에게 일을 시킨 결과가 엉뚱하다면, 정말 AI만의 문제였을까.
물론 AI가 헛소리를 했을 수도 있습니다. 꽤 자주 그럽니다. 하지만 애초에 일을 흐릿하게 설명했을 가능성도 있습니다.
프로젝트에서 애매함은 사라지지 않습니다. 예전에는 회의실에 남아 있었고, 이제는 프롬프트 창에 남습니다.
그래서 주니어에게도 이 변화는 중요합니다.
예전에는 도구를 몰라서, 코드를 몰라서 시작 자체가 어려운 일이 많았습니다.
AI는 그 장벽 일부를 낮춥니다. 하지만 장벽이 낮아진다고 책임까지 가벼워지는 것은 아닙니다. 오히려 더 빨리 마주하게 됩니다.
무엇을 만들 것인가.
무엇은 만들지 않을 것인가.
나온 결과를 어떤 기준으로 판단할 것인가.
AI가 실행을 빠르게 만들수록, 판단의 순간은 더 빨리 옵니다.
그 점에서 AI는 단순한 생산성 도구가 아닙니다. 사람에게 자기 일을 설명하게 만드는 도구입니다.
그리고 그 설명이 흐릿하면, AI는 아주 빠르게 엉뚱해집니다.
끝.