Vibe Coding과 Spec Coding에도 「생산량의 한계」가 있다

Vibe Coding이나 Spec Coding을 사용하면, AI가 코드를 작성해 줍니다.

하지만, AI가 순식간에 무한히 코드를 생성할 수 있는 것은 아닙니다.

짧은 함수라면 금방 나옵니다.

하지만, 여러 파일의 수정, 테스트를 포함한 구현, 기존 설계에 맞춘 변경이 되면 보통 시간이 걸립니다.

즉, AI에게도 단위 시간당 생산할 수 있는 코드량의 한계가 있습니다.

AI 개발에서는 다음과 같은 시간이 발생합니다.

• prompt를 작성하는 시간
• AI가 코드를 생성하는 시간
• 생성된 코드를 읽는 시간
• 동작을 확인하는 시간
• bug를 고치는 시간
• 불필요한 코드를 깎아내는 시간
• 재생성을 기다리는 시간

AI는 빠릅니다.

하지만, AI의 출력에도 물리적인 대기 시간이 있습니다.

그렇기 때문에, Vibe Coding이나 Spec Coding은,

「순식간에 완성되는 개발」이 아니라,

「AI가 일정 속도로 코드를 생산하고, 인간이 확인하면서 진행하는 개발」

에 가깝다고 생각합니다.

AI를 사용하여 여러 가지를 하다 보면, 아무래도 대기 시간이 발생합니다.

코드 생성을 기다린다.

수정 결과를 기다린다.

조사 결과를 기다린다.

테스트 코드 생성을 기다린다.

이 대기 시간이 의외로 개발 리듬에 영향을 줍니다.

잠시 기다리는 사이에, 다른 작업을 연다.

Slack을 본다.

메일을 본다.

다른 issue를 읽기 시작한다.

그러면, 원래 작업으로 돌아왔을 때,

「무엇을 확인하고 있었더라?」가 되기 쉽습니다.

AI를 사용하면 작업이 빨라지는 한편,

대기 시간으로 인해 주의가 분산되기 쉽다는 문제도 있습니다.

이는 미미하지만, 실제 생산성에는 상당히 영향을 미칩니다.

AI는 필요한 코드만 작성한다는 보장이 없습니다.

예를 들어,

• 사용하지 않는 helper
• 사양에 없는 fallback
• 과도한 validation
• 불필요한 추상화
• 유사한 처리의 중복
• 기존 공통 처리를 사용하지 않는 독자적인 구현

이런 코드들이 섞일 수 있습니다.

코드량이 늘어나면, 진행되고 있는 것처럼 보입니다.

하지만, 실무(production)에 넣으려면, 불필요한 코드를 깎아낼 필요가 있습니다.

AI 개발에서는, 생성뿐만 아니라, 삭제도 중요합니다.

AI가 생성한 코드에도 bug는 있습니다.

타입이 맞지 않는다.

null 처리가 미흡하다.

비동기 처리에서 순서가 어긋난다.

기존 API의 사양을 오해한다.

실제 데이터(production data)에서만 망가진다.

이런 일은 흔히 일어납니다.

bug가 발생하면, 다시 조사하고, 수정하고, 테스트합니다.

그 시간까지 포함해서, AI 개발의 생산성을 생각할 필요가 있습니다.

복잡한 업무 로직, 인가(authorization), 배타 제어(mutual exclusion), 상태 관리, 성능 개선, 기존 시스템과의 통합 등은, AI에게 맡겨도 바로 정답이 나오지 않을 수 있습니다.

하루 동안 시도해도 고쳐지지 않는다.

며칠을 걸려도 올바른 구현에 도달하지 못한다.

그런 상황도 있습니다.

그 경우에는, 인간이 설계를 다시 읽거나, 공식 문서를 확인하거나, 다른 AI에게 조사를 시키거나, 최종적으로 인간이 직접 구현해야 할 필요가 있습니다.

Vibe Coding도 Spec Coding도, 코드를 생산할 수 있습니다.

다만, 그것은 「AI가 무한히 빠르게 코드를 작성한다」는 의미가 아닙니다.

실제로는,

• AI의 생성에도 시간이 걸린다
• 단위 시간당 코드 생산량에는 한계가 있다
• 대기 시간으로 인해 집중력이 끊기기 쉽다
• 불필요한 코드도 생성된다
• bug 수정이 필요해진다
• 어려운 구현은 며칠이 걸릴 수도 있다
• 필요에 따라 인간의 개입이 필요해진다

라는 현실이 있습니다.

AI는 강력한 개발 수단입니다.

하지만, 실무에 투입할 수 있는 코드를 만들기 위해서는, 생성, 확인, 삭제, 수정, 판단이 필요합니다.

앞으로 중요해지는 것은,

AI에게 코드를 쓰게 하는 것뿐만 아니라,

AI의 코드 생산을 어떻게 관리하고, 대기 시간을 포함하여 개발 리듬을 어떻게 유지할 것인가

라고 생각합니다.