개발이란 무엇인가 — 실행 비용이 0원이 된 시대에

“이 기능이 왜 필요한가요?”

회사에서 이 질문을 던졌을 때 제대로 된 답을 들어본 기억이 별로 없다. 요구사항은 어딘가에서 내려오고 나는 그것을 만들고 다음 요구사항이 내려온다. 오랫동안 이게 답답했는데 최근에야 그 답답함의 정체를 언어로 정리할 수 있었다. 나는 개발을 다르게 정의하고 있었던 것이다.

기능을 만드는 일이 아니라면

내가 생각하는 개발은 요구사항대로 기능을 만드는 일이 아니다. ’이 개발이 무엇을 해결하는가’에 가깝다. 돈을 벌거나 유저의 불편을 없애거나, 어떤 목적이 있고 그 목적에 비추어 요구사항이 타당한지 따져보는 과정. 불완전한 요구는 되묻고 반복하면서 본질에 다가간다.

문제는 이 정의가 조직의 ‘개발자’ 역할보다 크다는 데 있다. 요구사항의 타당성을 따지는 건 기획의 영역처럼 보이고 “왜요?“라고 묻는 건 월권처럼 느껴진다. 그래서 사이드 프로젝트에서는 자연스럽게 하던 일을 회사에서는 멈추게 된다. 개인 프로젝트의 나와 회사의 내가 나뉘는 것이다.

하지만 개발자라는 직업의 역사를 길게 보면 본질이 코드였던 적은 사실 한 번도 없었다. 어셈블리 시절의 개발자는 기계를 아는 사람이었고, 프레임워크 시대의 개발자는 로직을 짜는 사람이었고, 지금의 개발자는 에이전트에게 스펙을 주는 사람이 되어가고 있다. 매체는 계속 바뀌었지만 변하지 않은 것이 하나 있다. 모호한 인간의 의도를 받아 실제로 작동하는 현실로 변환하고 그 결과를 책임지는 사람. 코드는 그 변환의 한 시대적 수단이었을 뿐이다.

실행 비용이 0원에 수렴할 때 남는 것

AI 에이전트 덕분에 코드를 만드는 비용은 급격히 떨어지고 있다. 실행이 거의 공짜가 되면 개발자에게 남는 것은 무엇일까. 나는 세 가지라고 생각한다.

문제를 고르는 안목. 만들 수 있는 것이 무한해지면 희소해지는 능력은 “무엇을 만들지 않을지” 아는 것이다.

검증. 에이전트가 무엇이든 만들어주는 세상에서 “이게 정말 문제를 풀었나”를 판정할 수 있는 사람은 여전히 시스템과 유저를 아는 사람뿐이다.

책임. AI는 결과에 이름을 걸 수 없다. “이건 내가 판단했고 틀리면 내가 고친다”는 끝까지 인간의 몫이다.

가운데의 실행은 점점 에이전트의 몫이 된다. 양 끝의 정의와 판단이 사람의 몫으로 남는다. 재밌는 건 에이전트에게 좋은 스펙을 쓰는 능력이 곧 요구사항을 변환하는 능력 그 자체라는 점이다. 내가 회사에서 하고 싶었던 그 일이 AI 시대의 핵심 스킬과 정확히 같은 근육이었다.

따지기에는 두 종류가 있다

여기서 스스로 모순처럼 보이는 대목을 하나 짚어야 한다. 나는 요구사항을 따져야 한다고 말하면서 동시에 실행 비용이 제로에 가까워졌는데 이것저것 따지느라 속도가 늦어지는 게 누구보다 답답한 사람이다. 모순일까.

아니라고 생각한다. 따지기에는 두 종류가 있다. 결정을 미루는 따지기는 회의하고 합의하고 보고하느라 아무것도 빼지 못한 채 시간만 쓴다. 빼기 위한 따지기는 5분의 질문으로 기능의 절반을 삭제하고 그래서 더 빨리 출시한다. 전자는 낭비고 후자는 속도다.

복잡도도 마찬가지다. “요구사항이 늘면 복잡도가 올라가는 건 당연하다”는 말을 자주 듣는데 나는 이 당연함이 답답하다. Fred Brooks는 복잡도를 문제 자체가 가진 본질적 복잡도와 우리가 만들어낸 우발적 복잡도로 나눴다. AI가 죽여준 것은 구현에 있던 우발적 복잡도다. 그렇다면 이제 코드베이스에 남는 복잡도의 대부분은 검증되지 않은 요구사항이 들여온 복잡도, 즉 우리가 선택한 낭비다. 저 말은 요구사항을 따지지 않는 조직에서만 참이다.

그래서 내 정의는 이렇게 다듬어졌다.

개발이란 목적에서 출발해, 요구사항을 따져서 불필요한 것을 삭제하고, 남은 최소한을 최고 속도로 실현하며, 결과로 검증하는 과정이다. 따지는 이유는 신중하기 위해서가 아니라 빨라지기 위해서다.

회사 안에서 이 정의로 사는 법

이 정의를 갖고 조직에서 일하는 건 별개의 문제다. 처음부터 “왜요?“를 물을 권리가 주어지는 사람은 없다. 내가 정리한 순서는 이렇다.

먼저 실행으로 신뢰를 쌓는다. 빠르고 정확하게 만드는 사람의 질문은 검토로 들리고 느린 사람의 질문은 핑계로 들린다. 다음으로 숫자를 가진 사람이 된다. 요구사항이 내려오면 관련 데이터를 먼저 뽑아본다. 회의실에서 유일하게 데이터를 들고 온 사람이 되는 경험이 몇 번 반복되면 직급 없이도 발언권이 적립된다. 그다음은 삭제로 증명한다. “이 기능은 빼도 목적이 달성됩니다. 대신 2주 빨리 나갈 수 있어요.” 단, 빼자는 말만 하면 태클 거는 사람이 된다. 삭제와 대안과 시간 이득을 항상 한 세트로 말해야 “이 사람을 거치면 빨라진다”는 평판이 된다. 그 평판이 생기는 순간 따지는 일은 월권에서 역할로 바뀐다.

마지막은 작은 루프 하나를 통째로 소유하는 것이다. 기능 하나를 목적 정의부터 출시 후 지표 확인까지 책임지겠다고 제안하는 것. 목적을 정의하고 만들고 검증하고 반복하는 이 루프는 예전엔 기획자와 개발자와 분석가로 쪼개진 팀의 일이었지만 이제는 한 사람이 다 돌 수 있다. 그리고 개발자의 길은 여기서 갈린다고 생각한다. 남의 루프 안에서 실행 파트만 맡아 에이전트와 직접 경쟁하게 되는 사람과, 자기 루프를 통째로 소유하는 사람.

나는 후자로 가고 싶다. 회사에서든 사이드 프로젝트에서든 언젠가의 1인 사업에서든, 같은 방향의 다른 보폭일 뿐이다.

질문을 던지고, 낭비를 삭제하고, 최소한을 최고 속도로 만들고, 결과 앞에 이름을 거는 개발자로 —

AI 시대에 살아남길 기대하며.