AI 에이전트 시대의 SES·수탁 개발을 생각하는 기사 정리

이 기사는 AI 에이전트 시대의 SES(System Engineering Service)·수탁 개발(受託開発)에 대해 쓴 기사들을 나름의 흐름으로 나열한 인덱스입니다.

AI를 사용하는 것 자체를 부정하고 싶은 것은 아닙니다.

오히려, AI는 상당히 쓸모 있다고 생각합니다.

다만, SES나 수탁 개발, 다중 하청 구조의 현장에서는 AI만으로는 해결할 수 없는 문제도 있는 것처럼 보입니다.

전제 정보, 판단 권한, 업무 지시 방식, 분담 방식에 따라 AI의 효용이 크게 달라지는 것이 아닌가 하는 이야기를 정리하고 있습니다.

AI 에이전트를 사용하면 구현 그 자체는 상당히 빨라집니다.

코드를 작성하게 한다.

에러를 수정하게 한다.

테스트를 추가하게 한다.

변경 내용을 정리하게 한다.

그러한 작업은 상당히 맡기기 쉬워졌습니다.

다만, SES나 수탁 개발 현장에서 생각하면 이야기는 조금 복잡해집니다.

코드를 쓰기 전의 전제가 갖춰져 있지 않다.

누가 판단하는지 알 수 없다.

배경이 전달되지 않는다.

기능별로 사람이 나뉘어 있어 전체적인 흐름을 보기 어렵다.

현장 담당자에게 책임은 있지만, 변경할 권한은 없다.

이런 상태라면 AI를 도입해도 생각만큼 개발이 잘 풀리지 않을 수도 있겠다는 느낌을 받고 있습니다.

이 기사는 그 부분을 고찰한 기사들을 모아놓은 페이지입니다.

단순한 링크 모음이라기보다, AI 에이전트를 SES·수탁 개발 현장에서 사용할 때 어디에서 막히기 쉬운가를 정리하기 위한 인덱스로 작성했습니다.

이 연재에서는 AI 에이전트 시대의 SES·수탁 개발을 대략 다음과 같은 흐름으로 살펴보고 있습니다.

회차	테마	포함된 내용
제1회	AI만으로는 개발이 잘 되지 않는다	SES·다중 하청에서 전제 정보가 단절되는 문제
...

처음에는 AI 에이전트를 현장에 도입하면 구현은 상당히 편해질 것이라고 생각했습니다.

그 자체는 틀린 말이 아니라고 생각합니다.

다만, 고민을 거듭할수록 SES나 수탁 개발에서는 "AI를 어떻게 사용하는가"뿐만 아니라, AI에게 무엇을 전달할 수 있는 상태인가가 더 중요하게 작용한다는 것을 알게 되었습니다.

AI 에이전트를 사용하면 자사 프로덕트처럼 전제 정보를 모으기 쉬운 환경에서는 개발을 상당히 수월하게 진행할 수 있습니다.

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

사양의 배경, 업무 흐름, 판단 기준, 고객과의 합의, 변경 가능한 범위.

이러한 정보가 현장 개발자에게까지 전달되지 않으면, AI에게 물어봐도 AI는 올바른 판단을 내리기 어려워집니다.

이 연재의 출발점으로서, AI뿐만 아니라 현장 구조 그 자체를 볼 필요가 있는 것 아니냐는 이야기입니다.

AI는 정보를 정리하거나, 빠져 있을 법한 관점을 제시하는 데 능숙합니다.

하지만 애초에 물어보지 못한 것은 AI도 알 수 없습니다.

잘못된 전제를 전달하면, AI는 그 전제 위에서 그럴듯한 답을 내놓고 맙니다.

히어링(Hearing) 미스는 구현 미스보다 찾아내기 어려울 때가 있습니다.

이 기사에서는 AI가 도울 수 있는 범위와, AI만으로는 채우기 어려운 전제의 괴리에 대해 정리하고 있습니다.

AI를 팀 단위로 사용한다면 공통 규칙이나 프롬프트(Prompt)를 준비하면 통일될 것처럼 보입니다.

하지만 같은 규칙을 보고 있더라도 사람에 따라 AI에게 부탁하는 방식은 달라집니다.

무엇을 생략할 것인가.

어디까지 맡길 것인가.

어디서 멈출 것인가.

어떤 출력을 좋다고 볼 것인가.

그곳에는 그 사람의 업무 방식이나 감각이 나타납니다.

이 기사에서는 공통 규칙만으로 AI의 출력을 통일하는 어려움과, 통일하려면 대화 방식보다는 경계나 책임 범위를 보는 것이 좋지 않겠느냐는 이야기를 하고 있습니다.

기능별로 사람을 할당하는 방식은 관리하기 쉬워 보입니다.

하지만 AI 에이전트는 본래 조금 더 횡단적으로 생각할 수 있습니다.

업무 플로우(Flow), 데이터의 흐름, 화면 간의 연결, 상태 전이, 영향 범위.

이런 것들을 보면서 구현할 수 있는 것이 AI의 강점 중 하나라고 생각합니다.

그것을 세세한 기능 단위로 단절시키면, 각 담당자의 AI가 국소 최적화(Local Optimization) 상태로 움직이게 되어, 나중에 전제의 충돌(Conflict)이 겉으로 드러날 수 있습니다.

이 기사에서는 AI 시대의 분담은 기능 단위뿐만 아니라 업무 플로우나 인터페이스 단위로 생각하는 것이 좋지 않겠느냐는 이야기를 하고 있습니다.

AI에게 맡긴다면 만드는 것뿐만 아니라 배경도 전달하는 것이 좋아 보입니다.

왜 그 기능이 필요한가.

누가 사용하는가.

어디까지 변경해도 되는가.

무엇이 미결 상태인가.

어떤 판단 기준을 우선하는가.

이러한 정보가 없으면 AI는 추측으로 진행하게 됩니다.

이 기사에서는 일을 맡기는 측이 '만들어 주었으면 하는 것'뿐만 아니라, '판단에 사용하는 배경'도 전달할 수 있는 상태로 만들어 두는 것이 AI 시대에는 더욱 중요해지는 것이 아닐까 하는 이야기를 하고 있습니다.

AI는 때때로 좋은 개선안을 제시해 줍니다.

하지만 현장 담당자가 그 안을 채택할 수 있다고 단정할 수는 없습니다.

책임은 있습니다.

하지만 변경할 권한은 없습니다.

SES나 수탁 개발 (Outsourcing Development) 현장에서는 이러한 상태가 발생하기 쉽다고 느끼고 있습니다.

이 기사에서는 AI의 제안을 '안(案)'으로 취급할 것, 판단자를 명확히 할 것, 권한이 없다면 변경 범위를 좁힐 것 등, AI의 제안을 현장에서 어떻게 다룰 것인가를 고민하고 있습니다.

AI에 전달하는 전제 조건이 AI의 출력을 상당히 좌우합니다.

업무 플로우 (Workflow).

용어 정의 (Terminology Definition).

데이터의 정답 (Ground Truth).

상태 전이 (State Transition).

변경해도 좋은 범위.

변경해서는 안 되는 범위.

미결 사항.

확인자.

이러한 것들이 갖춰져 있으면 AI를 상당히 사용하기 쉬워집니다.

이 기사에서는 SES 현장에서 AI를 사용하기 전에 최소한 갖춰두어야 할 전제 조건들을 정리하고 있습니다.

AI를 도입해도 개선하기 어려운 현장이 있습니다.

질문할 수 없다.

판단자를 알 수 없다.

배경이 나오지 않는다.

권한이 없다.

사람만 늘어난다.

리뷰할 수 있는 사람이 없다.

AI 이용이 '빨리 만들어라'라는 압박이 된다.

이러한 상태에서는 AI가 편리할수록 현장의 취약한 부분이 더 잘 드러나게 될 수도 있습니다.

이 기사에서는 AI를 도입하기 전에 살펴봐야 할 현장의 특징을 정리하고 있습니다.

AI 에이전트 (AI Agent)는 SES나 수탁 개발에서도 상당히 유용하게 쓰일 수 있다고 생각합니다.

다만, AI를 도입한다고 해서 자동으로 현장이 좋아질 정도로 단순하지는 않다는 느낌이 듭니다.

AI가 역량을 발휘하기 위해서는 전제가 필요합니다.

무엇을 만드는가.

왜 만드는가.

누가 결정하는가.

어디까지 변경해도 되는가.

어디서부터는 확인이 필요한가.

그러한 정보를 전달하지 못한 채로 두면, AI는 그럴듯하게 진행해 버립니다.

따라서 AI 시대의 SES·수탁 개발에서는 AI의 사용법뿐만 아니라, 일의 전달 방식, 판단을 남기는 방식, 권한을 설정하는 방식도 함께 살펴볼 필요가 있다고 생각합니다.

아직 정리 중이지만, 지금의 저에게는 그렇게 보입니다.