비엔지니어가 AI 도구로 화면이 움직이는 프로토타입을 만들고, 이것과 똑같은 것을 만들어 달라고 개발 팀에 전달한다. 얼마 전, 이와 유사한 일이 실제로 일어났다.

지금은 아직 단발적인 사건이다. 하지만 PoC (Proof of Concept, 개념 증명)를 만드는 비용이 계속 낮아지고 있는 이상, 가까운 미래에 이것은 당연한 일이 될 것이다. 그리고 그 너머를 상상하면 엔지니어의 미래가 상당히 어둡다.

의뢰하는 쪽에 악의는 없다. 오히려 사양의 해상도가 높아지기 때문에 도움이 되는 면도 크다. 문제는 전달한 쪽과 전달받은 쪽 사이에서, 남은 작업의 견적에 치명적인 차이가 있다는 점이라고 생각한다.

PoC가 완성된 시점에서 외관의 완성도는 80%에 달해 있다. 반면, 본방 시스템(Production System)으로서의 구현량으로 보면 10%에도 미치지 못하는 경우가 대부분일 것이다.

남은 90%는 전부 화면 바깥쪽에 있다. 데이터를 어떻게 가질 것인가, 어디서 움직일 것인가, 누구에게 무엇을 허용할 것인가, 고장 났을 때 누가 알아챌 것인가. 이런 종류의 질문에 차례대로 답해가는 작업에서, 답을 구현해도 화면에는 아무것도 나타나지 않는다. 몇 주에 걸쳐 견고하게 만들어도, 밖에서 보기에는 멈춰 있는 것처럼 보인다.

까다로운 점은, 이 80%와 10%의 차이가 규모에 비례하지 않는다는 것이다.

화면이 10장에서 30장으로 늘어나도 PoC 작성 비용은 거의 변하지 않는다. AI가 같은 기세로 양산할 수 있기 때문이다. 반면 본방 측은 화면 수에 대해 선형적으로 늘어나지 않는다.

• 권한 제어: 역할(Role) 수 × 기능 수
• 데이터 정합성 (Data Integrity): 엔티티(Entity) 간의 연관 수
• 상태 전이 (State Transition): 상태의 조합
• 이상계 (Exception Handling): 정상계 플로우별 분기 수

모두 곱셈으로 늘어난다. 작은 도구라면 PoC와 본방의 차이가 몇 배 수준에서 끝나지만, 업무 시스템 규모에서는 자릿수가 달라진다.

그럼에도 외관 80%라는 첫인상만은 규모와 관계없이 일정하다. 규모가 큰 안건일수록 격차가 벌어진다. 이 부분이 가장 위험한 지점이라고 생각한다.

이것이 이 기사에서 가장 말하고 싶은 부분이다. 같은 내용이라도 질문을 받은 뒤에 설명하면 변명처럼 들리고, 미리 제시하면 견적이 된다.

제시하는 것은 작업 체크리스트가 아니라, PoC와 본방의 차이 그 자체다. 1개 영역당 1행이면 충분하다.

안건에 따라서는 여기에 다국어화, 결제, 개인정보 취급 방침, 감사 대응 등이 추가된다.

가운데 열을 나열해서 보여주면, PoC가 다루고 있는 것은 외관뿐이라는 사실이 전달된다. 오른쪽 열은 통째로 이제부터 만들어야 할 것들이다. 여기에 오른쪽 끝에 공수(Man-hour) 열을 추가하면 그대로 견적이 된다.

PoC 코드는 검증용으로 최단 거리로 작성되어 있다. 다시 만드는 것을 전제로, 가치 있는 부분은 사양 정보로서 흡수해 올리는 것이 결국 빠르다.

테스트 커버리지 리포트, 모니터링 대시보드, 부하 테스트 결과. 결과물의 스크린샷이 한 장 있는 것만으로도 진척 상황이 전달되는 방식이 달라진다.

기능 목록으로 견적을 내면 PoC에서 보이는 기능만 공수에 포함된다. 독립된 항목으로 나열해 두면, 깎아낼지 여부를 상대방 측에서도 판단할 수 있게 된다.

동시 접속자 수, 응답 목표, 장애 시의 동작. 이 부분을 명확히 해두면, '왜 시간이 걸리는가'라는 질문이 '어디까지 할 것인가'에 대한 상담으로 바뀐다.

• PoC 코드를 그대로 연명시켜, 후반부에 다시 만들기(Rewrite)가 발생한다.
• 차이에 대한 설명을 구현 완료 후에 미루어, 변명으로 받아들여진다.
• 비기능 요구사항(Non-functional Requirements)을 암묵적으로 자신의 책임 범위로 떠안는다.

만드는 비용은 극적으로 낮아진 반면, 본방화(Productionization) 비용은 거의 낮아지지 않았다. 이러한 비대칭성이 존재하는 이상, 기술력과는 별개로 보이지 않는 업무를 설명하는 능력이 요구되고 있다고 느낀다.