AI로 코드를 찍어내는 속도가 빨라질수록, 오히려 더 비싸지는 것이 생겼습니다. 틀린 문제를 빠르게 푸는 비용입니다.

소프트웨어 컨설팅 회사 Test Double의 엔지니어 Dave Mosher가 AI 시대에 개발자 역할이 어떻게 재정의되는지를 다룬 글을 발표했습니다. 핵심 주장은 간단합니다. AI가 코드 생성 비용을 사실상 0에 가깝게 만든 지금, 개발자의 레버리지는 코드 자체가 아니라 AI에 입력하는 제약과 판단의 질로 이동했다는 것입니다.

출처: Quality you can’t generate: AI is only as good as your constraints – Test Double

속도도, 품질도 목표가 아니다

소프트웨어 업계는 오랫동안 속도와 품질을 맞바꾸는 관계로 봐왔습니다. 빠르게 가거나, 제대로 만들거나. 그런데 저자는 이 프레임 자체가 틀렸다고 말합니다.

속도는 목표가 아니라 잘 작동하는 시스템의 부산물입니다. 품질도 마찬가지입니다. 품질을 목표로 삼는 순간 추상화를 다듬고 코드의 형식을 최적화하는 데 매몰되기 쉽고, 그 비용이 실제 결과로 이어지지 않으면 그건 품질이 아니라 낭비입니다.

AI는 이 선택을 더 이상 미룰 수 없게 만들었습니다. AI는 기존 프로세스를 증폭시키는 힘입니다. 규율이 있는 팀에게는 피드백 루프를 압축해주고, 규율 없는 팀에게는 그냥 엔트로피를 가속합니다. 출력물의 비용이 낮아질수록 틀린 방향으로 달리는 비용은 오히려 커집니다.

함수로 보는 AI 시대의 가치

저자는 소프트웨어 개발을 함수처럼 표현합니다. 과거에는 TDD, CI/CD 같은 좋은 실천이 입력값이면 좋은 소프트웨어가 출력됐습니다. 이 함수는 코드 품질을 높였지만, 결정적인 진실을 놓쳤습니다. 완벽한 품질을 갖춘 코드도 잘못된 문제를 풀면 실패합니다.

AI는 이 간극을 드러냈습니다. 코드가 상품화되면서, 더 이상 코드만이 유일한 변수가 아닙니다. 함수가 이렇게 바뀐 셈입니다.

과거 fn(TDD, CI/CD, 페어 프로그래밍…) → 소프트웨어

현재 fn(소프트웨어, 시장 맥락, 사용자 니즈) → 결과

출력물은 싸졌습니다. 결과는 여전히 비쌉니다.

AI를 정밀 도구로 만드는 것: 하네스

저자가 제안하는 개념이 하네스(harness)입니다. 모델이나 IDE가 AI의 정밀도를 결정하는 게 아니라, 개발자가 그 주변에 설계하는 구조가 결정한다는 관점입니다.

같은 AI 도구도 어떻게 다루느냐에 따라 전혀 다른 결과를 냅니다. 막연한 의도로 다루면 망치처럼 작동하고, 명확한 제약과 판단 기준을 입력하면 정밀 도구가 됩니다. 하네스는 그 판단 기준을 코드화하는 것입니다. 구체적으로는 아키텍처 경계와 네이밍 컨벤션, 린트 규칙과 타입 인터페이스, 테스트 전략, 피드백 루프와 리뷰 워크플로, 의사결정 로그 같은 것들입니다.

세션이 바뀌어도, 컨텍스트 창이 리셋되어도 일관된 품질을 유지할 수 있게 해주는 구조가 하네스입니다.

결과 품질은 출시 후에 평가하지 않는다

좋은 하네스가 작동하고 있다는 신호는 뭘까요? 저자는 ‘선행 지표’를 제시합니다. 채택률이나 매출 같은 후행 지표를 기다리지 않고도, 진행 중인 프로젝트에서 결과 품질을 가늠할 수 있다는 겁니다.

팀이 학습 결과를 바탕으로 방향을 바꿀 만큼 이해관계자가 신뢰하는가, 아키텍처 결정의 ‘왜’가 명시적인가, 새 코드를 만드는 속도보다 빠르게 모호함을 해소하고 있는가. 이런 질문들이 하네스가 제대로 작동하는지 보여주는 신호입니다.

AI 시대에 코드는 싸졌지만, 모호함과 나쁜 계획은 훨씬 비싸졌습니다. 개발자의 레버리지는 이제 무엇을 만드느냐보다 어떤 제약과 판단으로 AI를 다루느냐에 달렸다는 것이 이 글의 핵심 메시지입니다. 원문에는 TDD를 정밀 도구로 다루는 방법과 Product Engineering으로의 전환에 대한 구체적인 논의도 담겨 있습니다.

참고자료:

• Speed is a side effect of making the system work – Test Double
• Make the Other Mistake – Mark Rabkin
• Harness Engineering – Martin Fowler