속도란

TL;DR

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

예전의 나

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

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

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

빠름의 가격이 폭락했다

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

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

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

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

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

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

빠름의 배출량이 늘어날수록, 조직과 고객이 진짜로 원하는 목록은 짧아진다. 올바른 문제를 골랐는가. 제품의 수준에 맞는가. 이것들은 만드는 속도와는 다른 능력이고, 이제 그쪽이 희소하다.

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

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

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

다만 반복에는 두 종류가 있다는 걸 알게 됐다. 배우기 위한 반복과 생산하기 위한 반복. 전자는 매 왕복마다 뭔가를 알아간다. 후자는 매 왕복마다 부채를 쌓는다. "나중에 고칠게"라는 말이 학습 계획이면 전자고, 그냥 넘어가는 말이면 후자다. AI 시대의 "나중에 고칠게" 뒤에는 십중팔구 slop이 숨어 있다.

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

그래서 이 세계의 실패는 종류가 다르다. 영업 시간에 결제가 한 번 멈추면 그 매장의 그 시간대 매출은 다음 버전에서 고쳐지지 않는다. 고쳐지는 것과 되돌려지는 것은 다른 문제다. 예전의 나가 믿던 "일단 만들고 보자"가 통하려면 모든 실패가 되돌릴 수 있는 실패여야 하는데, 생계와 맞닿은 제품에는 되돌릴 수 없는 실패가 섞여 있다. 내부 어드민은 대부분의 실패가 다음 왕복으로 되돌릴 수 있는 일이다. 그래서 거기에는 더 이상 프론트엔드 개발자가 필요하지 않다. 사람이 필요한 곳은 실패가 되돌려지지 않는 쪽이고, 나의 흥미도 이미 그쪽에 있었다.

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

속도란

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

학교 물리 시간에 속력과 속도를 구분해 배운다. 속력은 크기만 있는 값이다. 얼마나 빨리 움직였는지. 속도는 방향까지 있다. 어느 쪽으로 얼마나 움직였는지. 한 시간 내내 달려서 제자리로 돌아온 사람의 속력은 0이 아니지만, 속도는 0이다.

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

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

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

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

빠름이 slop이 되는지 진짜 속도가 되는지는 만들기 전에 세 가지 질문으로 가릴 수 있다. 이게 올바른 문제인가. 이게 우리 제품의 수준에 맞는가. '나중에 고칠 것'의 목록은 학습인가 부채인가. 세 가지 모두 예라고 답할 수 있을 때의 빠름은, 예전의 나가 믿던 빠름과 다르다. 희소한 빠름이다. 그리고 되돌릴 수 없는 왕복이 하나라도 섞여 있는 일에서는, 왕복을 줄이는 역량의 끝은 첫 왕복에 훌륭한 것을 내는 것이다.