속도란

TL;DR

• 예전의 나는 빨리 만들고 빨리 내는 것이 좋은 개발자라고 믿었다
• AI가 공짜로 만들어버린 것은 속력이다. 희소한 것은 방향이다 — 판단과 수준
• 속도와 품질 중 하나를 고르는 게 아니라, 그 선택 자체를 역량으로 지우는 것이 좋은 개발자의 끝모습이다

예전의 나

예전의 나는 이렇게 믿었다. 피처를 빨리 만들고, 빨리 내고, 고객에게 가치가 전달되는 속도가 곧 개발자의 실력이라고.

그 믿음에 근거가 없었던 건 아니다. 코드를 뽑아내는 데 드는 시간과 노력이 만만치 않았고, 그 병목을 잘 뚫는 사람이 팀에 주는 가치는 컸다. 희소한 것은 곧 실력이 된다. 적어도 그때는 그랬다.

그래서 "일단 만들고 보자"가 기본값이었다. 돌아가는 걸 눈앞에 보여주고, 피드백을 받고, 고치고, 다시 내고. 그 루프를 빠르게 도는 사람이 좋은 개발자라고 믿었고, 실제로 그렇게 일했다.

빠름의 가격이 폭락했다

그런데 어느 순간부터 이 믿음이 흔들리기 시작했다. 계기는 뻔하다. AI다.

우리 회사에는 자연어로 내부 어드민을 만들 수 있는 도구가 있다. 백엔드 개발자가 API만 제공하면 PO와 PD가 어드민을 직접 만든다. 화면이 필요하면 말로 하면 된다. 프론트엔드 개발자인 나는 내부 어드민을 만들기 위해 투입될 필요가 없어졌다.

솔직히 말하면 감흥이 없었다. 무섭지도 않았고 서운하지도 않았다. 나는 내부 어드민보다 외부 고객이 힘들어하는 문제를 푸는 쪽에 훨씬 오래 흥미를 느껴왔고, AI가 나온 시점에서 집중해야 할 일이 내부 어드민이 아니라는 것도 대략 알고 있었다. 내가 서고 싶은 자리는 이미 다른 곳에 있었다.

이건 남의 회사 이야기가 아니었다. "빠르게 만드는 능력의 가격이 폭락했다"는 문장이 뉴스가 아니라, 내가 맡던 일의 영역에서 실제로 일어난 일이 된 것이다.

AI는 코드 생산의 가격을 사실상 0으로 만들었다. 누구나 하루 만에 이전이라면 몇 주 걸렸을 분량을 뽑아낸다. 무언가를 빠르게 만드는 능력이 희소하던 시대는 끝났다.

문제는 그 반대편에 있다. 산출물이 넘쳐나면서, 산출물 말고 다른 것이 눈에 띄기 시작했다. 이게 정말 고객이 원하던 건가. 이게 정말 우리 제품의 수준에 맞나. 이 두 질문에 걸리는 결과물을 사람들은 AI slop이라고 부른다. 빠르게 만들어졌지만 아무도 원하지 않았거나, 아무도 유지하고 싶어 하지 않는 것들.

빠름이 쏟아내는 양이 늘어날수록, 조직과 고객이 진짜로 원하는 목록은 짧아진다. 올바른 문제를 골랐는가. 제품의 수준에 맞는가. 여기에 답하는 능력은 만드는 속도와 다르고, 이제 그 능력이 희소하다.

만들고, 고치고, 내는 것도 중요하다. 하지만

"그래도 만들고 고치고 내는 게 중요한 거 아니냐"는 반론은 맞다. 나도 지금도 반복의 가치를 믿는다.

일단 만들어야 피드백이 생기고, 피드백이 있어야 학습이 된다. 빈 화면 앞에서 완벽한 설계를 기다리는 것보다 돌아가는 것을 보여주는 게 대체로 낫다.

다만 반복에는 두 종류가 있다. 배우기 위한 반복은 매 왕복마다 뭔가를 알아가고, 생산하기 위한 반복은 매 왕복마다 부채를 쌓는다. "나중에 고칠게"라는 말이 학습 계획인지 그냥 넘어가는 말인지로 둘을 가린다. AI 시대의 "나중에 고칠게" 뒤에는 십중팔구 slop이 숨어 있다.

내가 일하는 제품은 오프라인 결제다. 소상공인과 자영업자가 매장에서 쓰는 포스와 결제단말기, 그 장비와 서비스를 이어주는 어드민, 브랜드 본사에 대한 지원까지가 우리가 만드는 것이고, 이 도구들은 고객에게 '있으면 좋은 서비스'가 아니라 '매출이 일어나는 지점' 그 자체다.

그래서 이 세계의 실패는 종류가 다르다. 점심 장사 도중에 결제가 한 번 멈추면, 들어왔다가 그냥 나간 손님과 손님이 냈어야 할 돈은 다음 버전에서도 돌아오지 않는다. 고치는 것과 되돌리는 것은 다른 문제다.

예전의 내가 믿던 "일단 만들고 보자"가 통하려면 모든 실패가 되돌릴 수 있는 실패여야 하는데, 생계와 맞닿은 제품에는 되돌릴 수 없는 실패가 섞여 있다. 내부 어드민은 대부분의 실패를 다음 왕복으로 되돌릴 수 있는 일이다. 그래서 거기에는 더 이상 프론트엔드 개발자가 필요하지 않다. 사람이 필요한 곳은 실패를 되돌릴 수 없는 쪽이다.

클로드 코드를 만든 보리스 처니는 팀이 직함이 아니라 다섯 개의 역할로 다시 짜이고 있다고 관찰했다. 프로토타이퍼, 빌더, 스위퍼, 그로어, 메인테이너. 제품이 성숙할수록 팀의 무게를 받는 건 다듬고 단순화하고 필요 없어진 걸 내려놓는 스위퍼와, 시스템이 안전하고 안정적으로 굴러가게 지키는 메인테이너다. 내부 어드민에서 AI가 가져간 것은 프로토타입을 실제 제품으로 만드는 빌더의 자리다. 내가 필요 없어진 자리는 정확히 거기였다. 제품의 끝모습을 두고 PO, PD와 이야기를 나누고 AI와 함께 그 모습을 가꿔가는 일이라면, 나는 이미 그쪽에 서 있고 싶었다.

이건 우리 제품만의 사정은 아니다. 생계와 직접 맞닿지 않은 제품을 만나더라도 퀄리티 기준은 높다. 우리는 어느 쪽이든 고객에게 가치를 제공하고 그 대가로 돈을 받는 회사의 개발자다. 돈을 받는 순간 퀄리티는 배려가 아니라 거래의 전제가 된다. 고객은 우리가 얼마나 빨리 만들었는지 기억하지 않는다. 제품이 어느 수준이었는지만 기억한다.

속도란

그래서 요즘은 이렇게 정리한다.

학교 물리 시간에 속력과 속도를 구분해서 배운다. 속력은 크기만 있는 값이다. 반면 속도는 방향까지 있다. 한 시간 내내 달려서 제자리로 돌아온 사람의 속력은 0이 아니지만, 속도는 0이다.

돌아보면 예전의 내가 재고 있던 값은 속력이었다. 얼마나 많이 만들었는지, 얼마나 자주 내보냈는지. 크기는 있는데 방향이 없는 값이다. AI가 공짜로 만들어버린 것이 정확히 속력이다. 그런데 우리가 정말 알고 싶었던 것은 언제나 속도였다. 이 제품은, 이 팀은, 나는, 출발한 곳보다 훌륭한 곳에 가 있는가. 이 질문은 시계로 잴 수 없다. 제품이 훌륭해지는 일은 물리적인 공간이 아니라 추상적인 공간에서 일어나고, 그 공간에서의 속도는 방향이 정해지기 전에는 값조차 없다.

개발자에게 방향은 두 가지다. 하나는 올바른 문제, 하나는 제품의 수준이다. 만들고 고치고 내는 것도 중요하지만 좋은 전술이지 이상형은 아니다. 내가 도달하고 싶은 이상형은 수준 높은 역량으로 훌륭한 제품을 빨리 내는 것이다. 속도와 품질 사이에서 하나를 골라야 하는 상황 자체를 역량으로 지워버리는 것.

만든 양은 속력의 세계에 있다. slop을 치우는 왕복은 거리만 쌓을 뿐, 변위는 깎는다. 한 줄로 내리면 이렇다.

속도란 만든 양이 아니라, 훌륭한 것에 도달하는 데 필요한 왕복의 횟수다. 그 횟수를 줄이는 것이 역량이다.

빠름이 slop이 되는지 진짜 속도가 되는지는 만들기 전에 세 가지 질문으로 가릴 수 있다. 이게 올바른 문제인가. 이게 우리 제품의 수준에 맞는가. '나중에 고칠 것'의 목록은 학습인가 부채인가. 세 질문에 모두 예라고 답할 수 있을 때의 빠름은 예전의 내가 믿던 빠름과 다르다. 희소한 빠름이다.

그리고 되돌릴 수 없는 왕복이 하나라도 섞여 있는 일에서, 그 역량의 끝모습은 첫 왕복에 훌륭한 것을 내는 것이다.