우리가 자사부터 AI 전환한 방법 (실증 스토리)

AI 전환 배경

여우비가 자사 개발 방식을 먼저 바꾼 이유는 단순합니다. 고객에게 AI 전환을 권하기 전에, 우리 팀이 그 길을 직접 통과해야 했기 때문입니다. 하노이 개발자들의 일하는 방식을 바꾸는 일은 도구 교체가 아니라 직무 자체를 다시 정의하는 작업이었습니다.

전환을 시작하기 전, 우리 하노이 팀은 전형적인 개발 조직이었습니다. 기획이 위에서 내려오면 개발자는 받은 명세대로 코드를 작성하고, 완성된 결과를 다시 위로 올리는 구조였습니다. 이 방식은 익숙하고 안정적이었지만, 한 가지 한계가 분명했습니다. 개발자의 역할이 코드를 짜는 한 토막에 갇혀 있다는 점입니다. 요구사항을 누가 정했는지, 고객이 진짜 무엇을 원했는지, 만든 기능이 실제로 쓸 만한지는 다른 사람의 일이었습니다.

생성형 AI 도구가 코드 작성의 속도와 난이도를 빠르게 바꾸기 시작하면서, 이 구조가 오래가기 어렵다는 판단이 섰습니다. 코드를 손으로 한 줄씩 쓰는 일의 비중이 줄어들면, 개발자의 가치는 다른 곳에서 나와야 합니다. 무엇을 만들지 판단하고, AI가 만든 결과를 검토하고, 고객과 직접 소통하고, 그 모든 과정을 기록으로 남기는 능력입니다.

또 하나의 배경은 우리가 베트남 하노이에 개발팀을 두고, 의사 결정과 고객 접점은 다른 위치에 있는 분산 구조로 일한다는 점이었습니다. 이런 구조에서는 기획과 구현 사이에 사람과 단계가 많아질수록 정보가 새어 나가기 쉽습니다. 누군가의 머릿속에만 있던 맥락이 다음 사람에게 절반만 전달되고, 그 절반이 다시 절반으로 줄어드는 일이 반복됐습니다. AI가 코드 생산을 빠르게 해줄수록, 정작 병목은 코드가 아니라 이 소통과 판단의 손실이라는 점이 더 또렷해졌습니다.

그래서 우리는 외부 고객 프로젝트에 이 변화를 적용하기 전에, 우리 자신부터 실험 대상으로 삼기로 했습니다. 자사에서 검증되지 않은 방식을 고객에게 파는 것은 정직하지 않다고 봤습니다. 동시에 우리 팀은 실패해도 책임질 수 있는 가장 안전한 실험장이기도 했습니다. 고객 프로젝트에서 시행착오를 겪는 것과, 내부에서 먼저 부딪혀 보는 것은 무게가 다릅니다. 이 글은 그 전환의 배경과 실제로 일어난 변화, 그리고 우리가 얻은 교훈을 과장 없이 정리한 기록입니다.

개발팀 AI 오퍼레이터화

핵심 변화는 직무 명칭과 책임 범위를 바꾼 것입니다. 하노이 개발자들의 역할을 단순 개발자에서 AI 오퍼레이터로 재정의했습니다. 한 사람이 프로젝트 관리, AI 활용 개발과 휴먼 리뷰, 고객 대응, 전 과정 문서화의 네 가지를 함께 맡는 구조입니다. 코드 작성은 그중 하나일 뿐입니다.

AI 오퍼레이터라는 이름을 붙인 데에는 의도가 있습니다. 개발자가 AI 도구를 보조 수단으로 가끔 쓰는 것이 아니라, AI를 작업의 중심에 두고 그 출력을 운용하는 사람이라는 뜻입니다. 명세를 받아 그대로 구현하는 대신, 요구사항 단계부터 참여해 무엇을 만들지 판단하고, AI에게 일을 시키고, 나온 결과를 사람의 눈으로 검증하고, 고객에게 직접 설명하는 일까지 한 흐름으로 이어집니다.

네 가지 책임을 일상 업무로 풀어보면 이렇습니다. 프로젝트 관리는 일정과 범위를 본인이 쥐고 가는 것입니다. 누가 시켜서 마감을 지키는 것이 아니라, 무엇을 언제까지 어디까지 할지를 스스로 잡고 고객과 합을 맞추는 일입니다. AI 활용 개발과 휴먼 리뷰는 생성된 코드를 그대로 신뢰하지 않고 반드시 사람이 검토해 책임지는 것입니다. AI에게 작업을 지시하는 일 자체도 기술이라, 무엇을 어떻게 시키느냐에 따라 결과의 질이 갈립니다. 그리고 나온 코드가 실제로 의도대로 동작하는지, 빠뜨린 예외는 없는지, 보안상 허술한 곳은 없는지를 사람이 끝까지 확인합니다. AI는 빠르지만 틀릴 수 있고, 틀린 코드를 거르는 일은 여전히 사람의 몫이기 때문입니다. 고객 대응은 중간에 다른 사람을 거치지 않고 담당자가 직접 소통하는 것입니다. 요구사항을 듣고, 모호한 부분을 되묻고, 진행 상황을 알리고, 변경을 협의하는 일을 코드를 만드는 사람이 직접 합니다. 전 과정 문서화는 착수부터 중간, 최종까지 무엇을 왜 그렇게 결정했는지 기록으로 남기는 것입니다. 단순한 작업 일지가 아니라, 다음 사람이 읽고 맥락을 이어받을 수 있을 정도의 기록을 의도했습니다.

이 네 가지를 한 사람이 동시에 한다는 것은, 솔직히 쉬운 요구가 아닙니다. 코드만 잘 짜면 됐던 사람에게 갑자기 고객과 영어나 한국어로 소통하고, 일정을 협상하고, 문서를 쓰라고 하는 것은 분명한 부담입니다. 특히 언어와 커뮤니케이션은 하노이 팀에게 코드보다 더 큰 진입장벽이었습니다. 그래서 우리는 이 전환을 한 번에 완성형으로 밀어붙이지 않고, 역할을 단계적으로 넓혀가는 방식을 택했습니다.

이 전환은 일방적인 지시가 아니라 합의 위에서 진행됐습니다. 개발자들이 새 역할에 동의한 뒤 본격적으로 자리를 잡았습니다. 직무를 넓힌다는 것은 동시에 기대치를 높이는 일이기도 했기에, 당사자들의 수용이 전제 조건이었습니다. 합의 없이 책임만 늘리면 그것은 전환이 아니라 떠넘기기가 됩니다. 우리는 새 역할이 단순히 일을 더 하라는 요구가 아니라, 개발자 개인의 경쟁력을 키우는 방향이라는 점을 설명하는 데 시간을 들였습니다.

실제 변화

가장 눈에 띄는 변화는 개발자가 고객과 작업 사이에서 사라지지 않게 된 점입니다. 예전에는 중간 관리 단계를 거쳐야 했던 소통이 담당자에게 직접 연결되면서, 요구사항이 오역되거나 전달 과정에서 깎여나가는 일이 줄었습니다. 단, 이 변화는 한 번에 완성되지 않았고 지금도 다듬는 중입니다.

문서화 습관이 자리 잡은 것도 실질적인 변화입니다. 착수, 중간, 최종 시점마다 보고서를 남기는 흐름을 만들었습니다. 처음에는 추가 부담으로 느껴졌지만, 결정의 근거가 글로 남으니 나중에 같은 논의를 반복하지 않게 됐고, 담당자가 바뀌어도 맥락이 끊기지 않았습니다. 기록은 그 자체로 품질 관리 장치가 됐습니다.

휴먼 리뷰를 명시적 책임으로 못 박은 것도 중요했습니다. AI가 만든 코드를 사람이 반드시 검토한다는 원칙을 세우자, 속도와 안전 사이의 긴장이 관리 가능한 형태로 들어왔습니다. AI의 생산성을 취하되 그 한계를 사람이 메운다는 합의가 분명해진 것입니다.

한 가지 정직하게 밝힐 점이 있습니다. 우리는 이 전환의 효과를 정밀한 수치로 측정하지는 않았습니다. 생산성이 몇 퍼센트 올랐다는 식의 단정적인 숫자를 내세우는 것은 우리가 실제로 확인한 범위를 넘어서는 일입니다. 대신 우리가 확실히 말할 수 있는 것은, 개발자 한 사람이 책임지는 범위가 넓어졌고, 일하는 방식이 코드 한 토막에서 문제 해결 전체로 옮겨갔다는 사실입니다.

마찰이 없었다고 말하면 거짓일 것입니다. 가장 큰 마찰은 적응 속도의 차이였습니다. 같은 변화를 두고도 누군가는 빠르게 새 역할을 자기 것으로 만들었고, 누군가는 코드 바깥의 일, 특히 고객과 직접 부딪히는 소통을 어려워했습니다. 이것은 능력의 문제라기보다 익숙함의 문제였고, 시간이 필요한 일이었습니다. 또 하나의 마찰은 AI를 과신하는 초기 경향이었습니다. AI가 그럴듯한 코드를 빠르게 내놓으니, 처음에는 검토를 가볍게 넘기고 싶은 유혹이 있었습니다. 이 부분은 휴먼 리뷰를 명시적 책임으로 못 박고서야 정리됐습니다.

이 과정에서 내부 운영 데이터가 쌓인 것도 사실입니다. 다만 분명히 해두자면, 데이터를 보유하는 것과 그것으로 별도의 API 사업을 한다는 것은 다른 이야기입니다. 우리가 쌓은 기록은 우리 팀의 일하는 방식을 개선하기 위한 자산이지, 외부에 판매하는 데이터 상품이 아닙니다. 이 구분을 흐리면 정직하지 않은 마케팅이 되기에, 일부러 분명히 적어 둡니다.

교훈

가장 큰 교훈은, AI 전환의 진짜 어려움이 도구가 아니라 사람과 역할에 있다는 점입니다. 어떤 AI 도구를 쓰느냐보다, 직무를 어떻게 다시 정의하고 그 변화를 당사자가 받아들이게 하느냐가 성패를 갈랐습니다. 도구는 며칠이면 바꾸지만, 일하는 방식은 그렇지 않습니다.

두 번째 교훈은 휴먼 리뷰를 절대 생략해서는 안 된다는 것입니다. AI가 그럴듯한 코드를 빠르게 내놓을수록, 사람이 검토하는 단계를 건너뛰고 싶은 유혹이 커집니다. 하지만 검토되지 않은 속도는 부채로 돌아옵니다. 책임의 주체를 사람으로 분명히 해두는 것이 전환의 안전장치였습니다.

세 번째는 문서화가 부담이 아니라 자산이라는 점입니다. 기록을 남기는 일은 당장은 느려 보입니다. 그러나 같은 실수를 반복하지 않고, 맥락을 잃지 않고, 결정을 추적할 수 있게 해주는 효과는 시간이 지날수록 커졌습니다. 분산된 팀일수록 이 효과는 더 큽니다. 사람이 같은 사무실에 있지 않을 때, 글로 남은 맥락은 자리를 비운 사람을 대신하는 유일한 연결 고리가 되기 때문입니다.

네 번째 교훈은 전환에는 적응 기간을 반드시 셈에 넣어야 한다는 것입니다. 직무를 넓히면 단기적으로는 오히려 속도가 떨어지는 구간이 있습니다. 익숙하지 않은 일을 새로 떠안았으니 당연한 일입니다. 이 구간을 실패로 오해하고 되돌리면 전환은 영영 자리 잡지 못합니다. 우리는 이 적응 비용을 미리 인정하고, 단계적으로 역할을 넓히는 쪽을 택했습니다.

마지막으로, 자사부터 적용한 것이 옳은 선택이었습니다. 검증되지 않은 방식을 고객에게 권하지 않는 것은 기본적인 정직함의 문제입니다. 우리가 직접 겪은 시행착오가 있기에, 고객에게 AI 전환을 이야기할 때 추상적인 약속이 아니라 실제 경험을 근거로 말할 수 있게 됐습니다.

고객 의미

고객 입장에서 이 변화의 의미는, 여우비가 AI 전환을 이론이 아니라 자기 경험으로 이야기한다는 점입니다. 우리는 우리 팀에 먼저 적용했고, 그 과정에서 무엇이 어렵고 무엇이 효과 있었는지 직접 확인했습니다. 그래서 같은 변화를 고민하는 조직에 현실적인 조언을 드릴 수 있습니다.

실무적으로 고객이 얻는 것은 두 가지입니다. 하나는 담당자와의 직접 소통입니다. 여러 단계를 거치지 않고 실제로 일을 하는 사람과 이야기하므로, 요구사항이 정확히 전달되고 변경에 빠르게 대응할 수 있습니다. 다른 하나는 기록으로 남는 과정입니다. 착수부터 마무리까지의 결정이 문서로 남으므로, 프로젝트가 끝난 뒤에도 무엇을 왜 그렇게 만들었는지 확인할 수 있습니다.

다만 과장하지 않겠습니다. AI 전환이 모든 문제를 자동으로 풀어주지는 않습니다. AI가 만든 결과는 여전히 사람의 검토가 필요하고, 직무를 넓히는 일에는 적응 기간이 듭니다. 우리가 드릴 수 있는 약속은 마법 같은 효율이 아니라, 우리가 직접 통과한 길에서 얻은 정직한 경험입니다.

AI 네이티브 개발팀 전환을 고민하는 조직이라면, 우리가 자사에서 겪은 이야기가 출발점이 될 수 있습니다. 여우비는 그 경험을 바탕으로 함께 길을 찾는 파트너가 되겠습니다.