【AI 에이전트 시대의 SES·수탁 개발을 생각하며 ⑨】 SES나 다중 하청 현장에서는 AI만으로는 개발이 잘 풀리지 않는다

수탁 개발(受託開発)이나 SES, 프리랜서로 참여하는 것 자체를 부정하고 싶은 것은 아닙니다.

다만, AI를 도입했을 때 정보 단절이나 권한 단절이 더욱 눈에 띄게 나타나지 않을까 하는 이야기입니다.

지금까지 AI 에이전트(AI Agent)를 사용한 팀 개발에 대해 써왔습니다.

AI를 사용하면 코드를 작성하는 속도는 상당히 올라갑니다.

대표적인 구현 방식이나 규칙, CI, 리뷰 메커니즘을 정비한다면, 팀 개발에서도 어느 정도는 잘 사용할 수 있을 것이라고 생각합니다.

하지만 최근 또 다른 문제를 느끼고 있습니다.

그것은 자사 프로덕트나 자사 서비스 개발에서는 어떻게든 성립할 법한 방식이라도, SES나 다중 하청(多重下請け)과 같은 현장에 가져오는 순간 상당히 힘들어지는가 하는 점입니다.

이것은 SES만의 이야기는 아니라고 생각합니다.

수탁 개발은 물론, 프리랜서로서 외부에서 프로젝트에 참여하는 경우에도 비슷한 어려움이 나타날 것입니다.

AI가 나쁘다는 이야기가 아닙니다.

오히려 AI는 시스템 전체를 보거나, 사양(Specification)의 누락을 찾거나, 설계의 모순을 찾아내는 데 특기가 있습니다.

하지만 그 AI를 사용하는 현장의 구조가 기존과 같다면, AI의 장점이 거의 활용되지 않습니다.

이 기사에서는 SES나 다중 하청 현장에서 AI를 사용해도 왜 잘 풀리지 않는 경우가 있는지에 대해 생각해 보고자 합니다.

먼저, 자사 프로덕트나 자사 서비스 개발에서는 AI를 사용한 팀 개발이 비교적 하기 쉽다고 생각합니다.

이유는 정보가 사내에 모이기 쉽기 때문입니다.

예를 들어, 다음과 같은 것들을 할 수 있습니다.

• 사양의 배경을 확인할 수 있음
• 과거의 설계 판단을 물어볼 수 있음
• 프로덕트 전체의 우선순위를 공유할 수 있음
• 변경 범위를 팀에서 조정할 수 있음
• AI에게 읽힐 설계 자료를 정비할 수 있음
• 사양의 모순을 발견하면 그 자리에서 상담할 수 있음

물론 자사 개발에서도 문제는 있습니다.

AI가 멋대로 넓은 범위를 수정하거나, PR(Pull Request)이 커지거나, 기존 설계와 어긋나는 일은 있습니다.

하지만 적어도 "왜 이 사양인가", "어디까지 바꿔도 되는가", "누구에게 확인해야 하는가"가 비교적 명확하게 보입니다.

따라서 AI를 사용하기 위한 메커니즘을 만든다면 아직 개선의 여지가 있습니다.

반면, SES나 다중 하청 현장에서는 전제 정보가 단절되기 쉽습니다.

고객이 있고, 원청이 있고, 2차 하청이 있고, 3차 하청이 있습니다.

그 안에서 기능 단위나 화면 단위로 작업이 분리됩니다.

이 구조에서는 개발자가 가진 정보가 상당히 제한됩니다.

예를 들어, 다음과 같은 상태가 되기 쉽습니다.

• 고객의 진짜 고민(Pain Point)을 알 수 없음
• 사양의 배경을 알 수 없음
• 왜 그런 설계를 했는지 알 수 없음
• 다른 기능과의 관계를 알 수 없음
• 어디까지 변경해도 되는지 알 수 없음
• 누가 최종 판단을 하는지 알 수 없음

이 상태에서 AI를 사용해도, AI는 전달받은 정보의 범위 내에서만 생각할 수 있습니다.

AI는 똑똑하지만, 전달되지 않은 업무 배경이나 계약상 보이지 않는 정보까지는 읽을 수 없습니다.

즉, 정보가 단절된 현장에서는 AI도 단절된 전제 속에서 움직이게 됩니다.

AI를 사용하며 느끼는 점은, AI는 "주어진 정보의 정리"에는 특기가 있다는 것입니다.

사양서를 읽히면 모순을 찾아줍니다.

요건(Requirement)을 전달하면 확인 사항을 뽑아줍니다.

화면 목록이나 API 목록을 전달하면 누락된 부분을 지적해 줍니다.

하지만 애초에 히어링(Hearing)이 잘못된 경우에는 어렵습니다.

예를 들어, 고객이 정말로 곤란해하는 것을 파악하지 못했거나,

업무 플로우(Workflow)의 예외 패턴을 확인하지 못했거나,

기존 운용에서 암묵적으로 이루어지는 작업을 잡아내지 못했을 경우입니다.

이 상태에서 AI에게 설계나 구현을 시켜도, AI는 잘못된 전제 위에서 열심히 노력해 버립니다.

잘못된 요건을 바탕으로 깔끔한 설계를 내놓습니다.

잘못된 사양을 바탕으로 동작하는 코드를 작성합니다.

잘못된 업무 이해를 바탕으로 그럴듯한 테스트를 작성합니다.

이것은 상당히 위험합니다.

AI를 사용하면 잘못된 전제에서도 작업이 빠르게 진행되어 버립니다.

그렇기 때문에 히어링 실수가 나중에 밝혀졌을 때의 재작업(Rework) 규모도 커집니다.

기존 개발에서는 기능별로 담당자를 할당하는 경우가 많습니다.

예를 들어, 다음과 같은 분담입니다.

• A님은 사용자 관리
• B님은 청구 관리
• C님은 알림 기능
• D님은 장표 출력

인간만으로 개발하던 시대에는 이러한 방식이 어느 정도 자연스러웠습니다.

작업을 병렬화하기 쉽고, 담당 범위도 명확하게 보이기 때문입니다.

하지만 AI를 사용하는 경우, 이러한 방식이 오히려 문제가 될 수 있습니다.

AI는 본래 시스템 전체를 횡단하여 생각할 수 있습니다.

사용자 관리와 청구 관리의 데이터 구조의 정합성(Consistency) 같은 것 말입니다.

알림 기능과 업무 상태(Status)의 관계.

장표 출력과 화면 표시 항목의 차이.

API, DB, 화면, 배치(Batch)의 책임 분담.

이러한 횡단적인 관점을 가질 수 있는 것이 AI의 강점 중 하나입니다.

하지만 인간 담당자를 기능별로 나누어 버리면, AI도 담당자별로 주어진 작은 상자 안에서 사용됩니다.

그 결과, 각 담당자의 AI는 각각의 기능만을 최적화합니다.

전체적으로는 설계가 조금씩 어긋나게 됩니다.

그리고 마지막에 결합하면 컨플릭트(Conflict)나 사양 불일치가 발생합니다.

AI를 사용한 팀 개발에서는 Git의 컨플릭트만이 문제가 아닙니다.

더 큰 문제는 전제의 컨플릭트입니다.

예를 들어, A 씨의 AI는 "이 상태는 사용자 관리 측에서 가져야 한다"라고 판단합니다.

B 씨의 AI는 "이 상태는 청구 관리 측에서 가져야 한다"라고 판단합니다.

둘 다 각각의 담당 기능만 보면 자연스럽게 보일지도 모릅니다.

하지만 시스템 전체로 보면 책임이 중복되거나 데이터의 정(Truth)이 무엇인지 알 수 없게 됩니다.

이것은 단순한 머지 컨플릭트(Merge Conflict)가 아닙니다.

사양 이해, 책임 분담, 데이터 설계, 업무 플로우(Workflow)의 컨플릭트입니다.

AI는 각 담당자 안에서는 그럴듯한 답을 내놓습니다.

하지만 담당자들 사이의 전제가 일치하지 않으면, AI들 사이의 출력도 일치하지 않습니다.

SES나 수탁 개발에서는 일을 주는 측과 받는 측 사이에 정보 차이가 있습니다.

일을 주는 측은 배경을 전부 알고 있다고 생각하기 쉽습니다.

일을 받는 측은 전달받은 사양이 충분하다고 생각하기 쉽습니다.

하지만 실제로는 상당한 정보가 누락됩니다.

• 왜 그 기능이 필요한가
• 어떤 업무가 가장 중요한가
• 무엇을 바꿔서는 안 되는가
• 현장에서 어떤 예외 케이스가 많은가
• 과거에 실패했던 설계는 무엇인가
• 이번에는 무엇을 포기하고 있는가

이러한 부분은 사양서에 깔끔하게 적혀 있지 않은 경우가 많습니다.

그리고 AI는 이렇게 누락된 정보를 마음대로 채울 수 없습니다.

오히려 AI는 부족한 정보를 매우 그럴듯하게 보완해 버릴 수 있습니다.

그 보완이 맞다면 다행이지만, 틀렸을 경우에는 위험합니다.

따라서 일을 주는 측이 충분히 전달하지 못하는 상태에서는 AI를 사용하더라도 근본적인 문제는 남습니다.

완전한 해결책은 간단하지 않습니다.

다만, AI를 사용한다면 적어도 기존의 "기능을 나누어 사람에게 할당하는" 방식의 진행법은 재검토하는 것이 좋다고 생각합니다.

예를 들어, 다음과 같은 고안이 필요해집니다.

• 구현 전에 AI로 사양의 모순이나 확인 사항을 도출
• 기능 단위가 아니라 업무 플로우 단위로 설계 확인
• 데이터의 정(Truth), 책임 경계, 상태 전이를 먼저 결정
• 각 담당자의 AI에 동일한 전제 자료를 읽힘
• 변경 범위뿐만 아니라 변경해서는 안 되는 범위도 결정
• 횡단적으로 설계를 보는 역할 배치
• PR(Pull Request) 전에 기능 간의 정합성 리뷰 수행

특히 중요한 것은 횡단적으로 보는 역할입니다.

AI를 각 담당자의 작업 도구로만 사용하면 국소 최적화(Local Optimization)가 늘어납니다.

그것이 아니라 시스템 전체의 정합성을 보기 위해서도 AI를 사용할 필요가 있습니다.

AI 시대에 필요한 것은 단순히 "개발자가 AI를 사용할 수 있게 되는 것"이 아니라고 생각합니다.

일하는 방식 그 자체를 바꿀 필요가 있습니다.

기존처럼 모호한 사양을 전달하고, 기능별로 사람을 할당한 뒤, 나머지는 각 담당자가 노력한다.

이 방식 그대로 AI를 도입해도 문제는 크게 해결되지 않습니다.

오히려 작업 속도만 올라가서, 잘못된 것을 빠르게 만들 가능성이 있습니다.

AI를 사용한다면 처음에 다음과 같은 정보를 갖추어야 합니다.

• 업무 플로우 (Workflow)
• 용어 정의
• 데이터의 정 (Truth)
• 상태 전이
• 변경해도 좋은 범위
• 변경해서는 안 되는 범위
• 판단자
• 미결 사항
• 확인 대기 사항

이것들을 갖춘 상태에서 AI에게 설계나 구현을 돕게 한다.

그렇게 하지 않으면 AI는 부족한 전제를 보완하며 진행해 버립니다.

조금 비관적인 이야기가 되겠지만, AI를 도입해도 어쩔 수 없는 현장이 있다고 생각합니다.

예를 들어, 다음과 같은 상태입니다.

• 사양의 배경을 확인할 수 없음
• 고객에게 질문할 수 없음
• 원청에서 정보가 막힘
• 판단자를 알 수 없음
• 설계 변경 권한이 없음
• 하지만 납기만은 엄격함
• 기능별로 사람만 추가됨

이 상태에서는 AI를 사용해도 근본적인 개선은 어렵습니다.

AI는 정보가 없는 곳에서 올바른 업무 이해를 만들어낼 수 없습니다.

권한이 없는 사람에게 전체 설계의 판단을 맡길 수도 없습니다.

단절된 계약 구조를 AI만으로 다시 연결할 수도 없습니다.

그런 의미에서 AI는 개발 현장의 문제를 마법처럼 해결해 주는 것이 아닙니다.

오히려 현장의 구조적인 문제를 더 명확하게 보이게 만드는 것이라고 생각합니다.

이렇게 생각하면, 최근 자주 들리는 내제화 (In-house development) 흐름과도 연결되어 있다는 느낌을 받습니다.

물론 모든 회사가 같은 이유로 내제화를 추진하고 있는 것은 아니라고 생각합니다.

비용, 속도, 채용, 사업 이해도, 보안, 기술 자산 등 이유는 여러 가지가 있을 것입니다.

다만, AI 시대의 개발이라는 관점에서 보면 내제화를 추진하고 싶어지는 이유는 충분히 이해가 갑니다.

AI를 잘 활용하기 위해서는 코드뿐만 아니라, 업무 배경, 판단 기준, 과거의 경위, 향후 방침까지 포함된 전제 조건이 중요해집니다.

그 전제 조건을 외부의 다단계 구조로 세세하게 나누어 전달할수록 정보는 누락되기 쉽습니다.

질문도 멀어집니다.

판단도 늦어집니다.

책임의 소재도 모호해지기 쉽습니다.

그렇게 되면, AI를 사용하여 개발 속도를 높이고 싶은 회사일수록 중요한 부분은 사내에서 장악하고 싶어 하는 것은 자연스러운 흐름으로 보입니다.

또한, 사람을 늘리면 해결된다는 사고방식도 AI 시대에는 조금 변할지도 모릅니다.

기존에는 납기가 엄격해지면 인원을 늘린다는 판단이 있었습니다.

하지만 AI를 사용하면 단순한 구현량뿐만 아니라, 전제를 맞추는 것, 설계의 정합성 (Integrity)을 확인하는 것, 판단을 빠르게 내리는 것이 더욱 중요해집니다.

이런 상태에서 정보가 충분히 전달되지 않은 채 인원만 늘린다면, 각 담당자의 AI가 저마다 국소 최적화 (Local optimization)된 방향으로 나아갈 가능성이 있습니다.

그렇다면 적은 인원이라도 업무 배경과 설계 판단을 보유한 팀으로 진행하는 편이 낫다는 판단이 나오는 것도 이해할 수 있습니다.

외부의 힘을 빌리는 것 자체가 나쁜 것은 아닙니다.

다만, 외부로 작업을 세세하게 쪼개어 전달하면서 배경을 충분히 전달하지 않은 채 구현만을 의뢰하는 형태는 AI 시대에는 더욱 어려워질 것이라고 생각합니다.

AI 에이전트 (AI Agent)는 강력합니다.

코드를 쓰는 속도도 올라갑니다.

사양의 누락도 찾아내기 쉬워집니다.

설계안도 제시해 줍니다.

테스트나 문서 작성도 도와줍니다.

하지만 SES나 다중 하청처럼 정보와 책임이 분단되기 쉬운 현장에서는 AI만으로는 잘 풀리지 않습니다.

히어링 (Hearing)이 잘못되어 있다면 AI도 잘못된 전제하에 움직입니다.

기능별로 담당자를 나누면 AI도 기능별로 국소 최적화됩니다.

일을 맡기는 쪽에서 배경을 다 전달하지 못하면, AI는 부족한 정보를 스스로 보완해 버립니다.

AI를 잘 활용하기 위해서는 AI의 사용법뿐만 아니라, 일의 전달 방식, 정보 공유 방법, 책임의 소재를 바꾸어야 합니다.

이는 도구의 문제라기보다 개발 체제의 문제입니다.

AI 시대가 되어도 일본 개발 현장의 오래된 문제들은 그대로 남습니다.

그리고 그 문제를 방치한 채 AI만 도입하면, 오히려 파탄이 더 빨라질 가능성이 있습니다.

그렇기에 내제화를 추진하거나, 외부에 맡기는 범위를 좁히거나, 소수 인원이 전제를 파악할 수 있는 체제로 모으는 움직임이 나타나는 것은 자연스러운 일일지도 모릅니다.

AI가 강력해질수록 단순히 작업을 분배하는 능력보다, 전제를 파악하는 능력, 판단하는 능력, 전체를 볼 수 있는 체제가 더 중요해진다고 느낍니다.

AI를 사용한다면 코드를 쓰기 전에 먼저 전제를 맞춘다.

기능을 사람에게 할당하기 전에 시스템 전체의 정합성을 본다.

받는 쪽뿐만 아니라, 일을 주는 쪽의 전달 방식도 바꾼다.

그 정도까지 바꾸지 않는다면, AI 시대의 팀 개발은 진정한 의미에서 좋아지지 않을 것이라고 생각합니다.