YWBi
0%
YEOWUBIE.
//
← Studio Log
D. 기술 신뢰 (Uy tín)AI워크플로외주개발

외주 개발사가 내부 워크플로를 AI로 재설계한 기록

외주 개발사가 내부 워크플로를 AI로 재설계한 기록
글: Yeowubie

AI를 이야기하는 외주 개발사 대부분은 도구를 사는 데서 멈춘다. 라이선스 몇 개를 결제하고, 편집기에 코딩 보조를 붙인 다음, 전환을 끝냈다고 말한다. 이 글은 다른 길을 기록한다. 한 작은 스튜디오가 자리에 앉아 요청 접수부터 납품까지 전체 작업 흐름을 다시 그렸고, AI를 가장자리에 덧붙이는 대신 한가운데에 놓았다. 깨진 가정과 아직 끝나지 않은 일까지 솔직하게 담은 기록이다.

왜 도구 도입이 아니라 워크플로 재설계였나

워크플로 재설계는 누가 무엇을, 어떤 순서로, 각 단계에서 누가 책임지는지를 바꾸는 일이다. 도구 도입은 옛 방식 위에 소프트웨어 하나를 얹는 일에 그친다. 핵심 차이는 전자가 팀 전체에 구조를 다시 보게 만드는 반면 후자는 구조를 그대로 둔다는 점이다. AI를 제대로 쓰려는 스튜디오라면 앞쪽을 택해야 한다.

초기에 팀은 익숙한 함정에 정확히 빠졌다. 각자 자기 도구에 AI 보조를 붙였고 개인 생산성은 조금 올랐지만 프로젝트 전체는 크게 빨라지지 않았다. 이유는 차차 드러났다. 병목은 한 번도 타이핑 속도에 있지 않았다. 병목은 역할과 역할 사이의 빈틈, 즉 상담하는 사람에서 개발하는 사람으로, 개발하는 사람에서 검수하는 사람으로 정보가 넘어가는 지점, 그리고 고객 피드백이 들어오는 순간 흐름을 놓치는 자리에 있었다.

이 점을 보고 나니 질문이 통째로 바뀌었다. 어떤 도구가 가장 좋은가가 아니라, AI가 항상 곁에 있다는 전제로 작업 흐름을 처음부터 다시 설계하면 그 모양이 어떻게 될까였다. 이 질문은 훨씬 어렵다. 습관과 책임 분담, 심지어 견적 방식까지 건드리기 때문이다. 그러나 진짜 가치는 거기에 있다. 어지러운 흐름 위의 좋은 도구는 그 어지러움을 더 빨리 돌릴 뿐이다.

길잡이가 된 원칙은 꽤 단순하게 정리됐다. AI는 초안과 반복을 맡고, 사람은 판단과 책임을 맡는다. 이후의 모든 재설계 결정은 이 원칙으로 되돌아가 검증했다. 어떤 단계가 여전히 사람에게 순수한 초안 작업을 시키고 있다면, 그것은 흐름이 끝까지 다시 그려지지 않았다는 신호였다.

기획·견적 단계를 AI로 다시 짠 방법

기획과 견적 단계는 고객의 거친 요청을 구조화된 명세서와 견적 초안으로 같은 흐름 안에서 바꾸고, 사람이 검토해 최종 숫자를 정하는 방식으로 재설계됐다. 목표는 완전 자동화가 아니라, 모호한 설명 한 줄에서 논의 가능한 수준의 문서까지 가는 거리를 줄이는 것이었다.

전에는 메시지로 들어온 요청이 며칠씩 묵었다. 담당자가 직접 읽고, 범위를 추측하고, 단가표를 뒤지고, 제안서로 다시 써야 했다. 단계마다 늦을 수 있고 틀릴 수 있는 지점이었다. 다시 그린 뒤에는 거친 설명을 AI 단계에 통과시켜 기능 항목, 확인이 필요한 가정, 정보가 빠진 자리로 분해했다. 이 초안은 고객에게 바로 보내려는 게 아니다. 담당자가 백지에서 쓰는 것보다 훨씬 빠르게 손보기 위한 출발점이다.

가장 조심해야 할 곳은 견적 부분이었다. 팀은 일찍 실수를 깨달았다. AI가 단가를 스스로 추론하게 두면 숫자가 떠다니고 제안서마다 들쭉날쭉해진다. 해법은 두 가지를 분리하는 것이었다. AI는 구조를, 즉 작업을 잘게 나누고 상대적 작업량을 가늠하는 일을 맡는다. 단가는 언제나 사람이 관리하는 표준 단가표에서 가져오고, 모델이 추측하게 두지 않는다. 그 덕에 초안은 일관성을 지키면서도 빨라졌다.

또 다른 교훈은 시간 추정에서 나왔다. AI가 초안을 맡으면 전통적인 인시 기준 추정은 더 이상 현실을 제대로 반영하지 못한다. 팀은 두 숫자를 나란히 적어야 했다. 옛 방식 기준 시간과, AI 지원이 있을 때의 합리적 시간이다. 이렇게 하니 생산성 착각을 피하면서도 고객과의 약속을 실현 가능한 범위 안에 둘 수 있었다.

개발과 검수를 한 사람이 책임지는 구조로

큰 변화 하나는 개발과 검수를 여러 단계로 손에서 손으로 넘기는 대신, 프로젝트마다 같은 사람의 책임으로 묶은 것이다. 이 사람은 AI로 대부분의 코드를 생성하되 그 결과물을 직접 검토하고 최종 품질을 스스로 책임진다. 한 사람 한 프로젝트 구조는 책임을 분명하고 닫힌 것으로 만든다.

옛 모델은 라인 방식으로 역할을 나눴다. 한 사람이 쓰고, 다른 사람이 검사하고, 또 다른 사람이 고친다. AI가 끼어들자 그 라인이 새 문제를 낳았다. 코드가 너무 빨리 생성되어 검수 단계가 병목이 됐고, 검수하는 사람은 자기가 만들지 않은 것을 평가할 만큼의 맥락을 갖지 못하는 경우가 많았다. 책임은 흩어졌고 결함은 역할 사이의 빈틈으로 떨어졌다.

해법은 역할 분담의 논리를 뒤집는 것이었다. 공정별로 나누는 대신 프로젝트별로 나눴다. 한 사람이 처음부터 끝까지 한 프로젝트를 따라간다. 요건을 이해하고, AI를 부려 코드를 생성하고, 부분마다 다시 읽고, 테스트하고, 납품한다. 이 역할을 AI 오퍼레이터라 부르는데, 순수한 개발자와는 다른 역량 묶음을 요구한다. 가장 중요한 것은 AI가 만든 코드를 읽고 판단하는 능력, 언제 믿고 언제 손으로 다시 쓸지 아는 감각이다.

이 전환은 매끄럽지 않았다. 좁은 역할에 익숙하던 사람은 전 생애주기를 떠안는 데 불편해했다. 한동안 품질이 올라가기 전에 먼저 떨어지기도 했다. AI 코드를 검토하는 기술은 자리 잡는 데 시간이 걸리기 때문이다. 팀이 배운 것은 새 구조가 교육과 함께 갈 때만 힘을 낸다는 사실이었다. 조직도만 바꾸고 모든 것이 알아서 굴러가기를 바라는 것이 아니라.

고객 대응과 문서화를 같은 흐름에 묶기

고객 대응과 문서화는 코드가 끝난 뒤의 추가 작업이 아니라 개발과 같은 흐름 안으로 들어왔다. 프로젝트 담당자는 결정, 피드백, 변경을 일어나는 즉시 기록하고, AI로 거친 메모를 정돈된 문서로 바꾼다. 문서는 막판의 부담이 아니라 작업의 자연스러운 부산물이 된다.

작은 외주사의 고질적 약점은 문서가 늘 맨 뒤로 밀리다 결국 아무도 쓰지 않는다는 것이다. 어떤 결정이 왜 내려졌는지 고객이 물으면 기억은 이미 흐릿하다. 인계나 유지보수가 필요할 때 따라갈 흔적이 없다. 옛 방식에서 문서 작성은 따로 떨어진, 시간이 드는 일이라 일정이 빠듯해지면 가장 먼저 희생됐다.

다시 그린 뒤에는 프로젝트의 각 마디마다 가벼운 기록 단계가 붙었다. 담당자가 완결된 문서를 쓸 필요는 없다. 무엇이 왜 바뀌었는지 빠르게 적으면 AI가 그것을 매끄러운 문서 조각으로 세운다. 같은 논리를 고객 피드백에도 적용했다. 한국 고객과 베트남 고객을 함께 상대할 때, 중요한 모든 교신은 양쪽이 동시에 파악하도록 양국어로 보관해 시간이 지나며 오해가 쌓이는 것을 막았다.

지켜야 할 선이 하나 있다. AI는 문서 초안은 세워주지만, 고객에게 나가는 내용은 언제나 사람이 다시 읽어야 한다. 기계가 만든 요약 하나가 의미를 비껴 표현해 범위에 대한 오해를 부를 뻔한 적이 있었고, 그때 배웠다. 이후 원칙은 고정됐다. AI가 초안을 쓰고, 사람이 밖으로 나가기 전에 검수한다. 고객과의 소통에서 속도가 정확성을 대신하는 일은 결코 허용되지 않는다.

재설계하며 깨진 가정과 남은 숙제

재설계 과정은 몇 가지 잘못된 가정을 드러냈고 적지 않은 미완의 일을 남겼다. 가장 크게 깨진 가정은 좋은 도구가 알아서 생산성을 가져다주리라는 믿음이었다. 진실은, 구조와 사람이 결정하고 도구는 이미 있는 것을 증폭할 뿐이라는 것이다. 완벽한 이야기로 꾸미는 것보다 남은 미완을 솔직히 말하는 편이 더 중요하다.

흔들린 두 번째 가정은 측정에 관한 것이었다. 팀은 깔끔한 생산성 증가 수치를 금세 내놓을 수 있으리라 생각했다. 현실에서는 AI가 가져온 몫을 다른 요인과 떼어내기가 무척 어렵고, 단단한 데이터 없이 확정적인 숫자를 내미는 것은 자기기만이 된다. 그래서 이 단계에서 팀은 변화를 정성적으로 서술하기로 했다. 떨어지는 인계 지점이 줄었고, 문서가 더 충실해졌고, 책임이 더 분명해졌다는 식으로. 믿을 만한 수치가 생기면 그 수치가 서술을 대신할 것이다.

남은 숙제도 작지 않다. AI 코드 검토 기술은 여전히 구성원 간 편차가 있고, 교육은 한 번의 세션이 아니라 긴 과정이다. AI 검토 후 사람이 승인하는 이중 게이트는 새로운 병목이 되지 않도록 아직 다듬는 중이다. 단가표와 표준 명세 묶음을 늘 최신으로 유지하는 일은 꾸준한 규율을 요구한다. 낡은 표준 하나가 자동화된 흐름 전체를 잘못 끌고 가기 때문이다.

교훈은 한 문장으로 묶인다. AI를 둘러싼 워크플로 재설계는 소프트웨어의 일이 아니라 조직의 일이다. 이를 구매 프로젝트로 여기는 스튜디오는 실망할 것이고, 끊임없는 학습 과정으로 여겨 잘못된 가정을 인정하고 고칠 준비가 된 스튜디오는 점차 더 단단한 일하는 방식을 쌓을 것이다. 진짜 보상은 더 빨리 쓰인 코드가 아니라, 품질과 책임이 더 이상 역할 사이의 빈틈으로 떨어지지 않는 팀이다.