AI 시대 개발자의 자리 (4/5) — 토큰이 원가가 되면서 기술 결정이 손익 결정이 됐다

3편에서 개발자 앞에 두 갈래가 있다고 썼다. 기술로 더 깊게 들어가는 방향과, 개발 경험을 들고 사업으로 나가는 방향.

그런데 왜 요즘 회사들이 오른쪽 사람을 점점 더 찾는 걸까. 조직 트렌드라는 설명은 부족하다. 더 딱딱한 이유가 있다. 원가 구조가 바뀌었다.

1. 예전 소프트웨어에는 없던 구조

예전에 토큰을 줄이는 방향으로 다시 돌아오는 이유라는 글을 썼다. 그때는 업계 흐름에 대한 관찰이었는데, 지금은 회계 이야기가 됐다.

	일반 소프트웨어	AI 제품
사용자가 늘면	서버비가 조금 늘어난다	요청 수만큼 원가가 늘어난다
많이 쓰는 사용자는	좋은 사용자	비싼 사용자
기능을 하나 더 쓰면	원가 변화 거의 없음	그만큼 돈이 나간다
규모가 커질수록	단위 원가가 내려간다	단위 원가가 거의 그대로다

마지막 줄이 핵심이다. 전통적인 소프트웨어 사업이 매력적이었던 이유는 규모의 경제였다. 한 번 만들면 복제 비용이 0에 가까웠다. AI 제품은 그 전제가 깨졌다. 요청 한 번이 곧 비용 한 번이다.

2. 인기를 얻으면 적자가 되는 구조

간단한 가정으로 계산해보자. 실제 요율이 아니라 구조를 보기 위한 예시다.

가정: 요청 1건 = 원가 30원
      유료 사용자 1명 = 월 10,000원

하루 3번 쓰면   → 월 90건  → 원가 2,700원   → 마진 73%
하루 10번 쓰면  → 월 300건 → 원가 9,000원   → 마진 10%
하루 15번 쓰면  → 월 450건 → 원가 13,500원  → 적자

제품이 사랑받으면 망하는 구조가 만들어진다. 전통적인 SaaS에서는 거의 없던 형태다. 헤비 유저가 손실을 내는 상황이 정상적으로 발생한다.

그래서 요즘 AI 서비스들이 요금제를 계속 바꾼다. 무제한을 걸었다가 사용량 제한을 붙이고, 크레딧 방식으로 옮기고, 비싼 모델은 상위 요금제로 빼낸다. 변덕이 아니라 원가 구조를 뒤늦게 반영하는 과정이다.

3. 그래서 기술 결정이 사업 결정이 된다

이게 3편에서 말한 갈림길과 연결되는 지점이다. AI 제품에서는 다음 판단들이 기술 판단이면서 동시에 손익 판단이다.

결정	기술 측면	사업 측면
어떤 모델을 쓸까	품질	건당 원가
컨텍스트를 얼마나 넣을까	정확도	요청당 비용
캐시를 어디에 둘까	응답 속도	중복 호출 제거 = 원가 절감
결과를 저장할까	재사용성	다시 계산하지 않아도 됨
몇 번까지 자동 재시도할까	성공률	실패마다 돈이 나간다
에이전트를 몇 단계로 돌릴까	자율성	단계마다 곱해진다

이 표의 왼쪽만 보는 사람은 좋은 엔지니어다. 문제는 왼쪽만 보고 내린 결정이 오른쪽에서 사고를 낸다는 것이다.

특히 마지막 줄이 무섭다. 에이전트가 스스로 판단해서 여러 번 도는 구조를 만들면, 한 번의 사용자 요청이 내부에서 열 번, 스무 번의 호출이 된다. 기능은 훌륭하게 동작하고 원가는 조용히 스무 배가 된다. 로그를 안 보면 며칠 뒤 청구서로 알게 된다.

양쪽을 같이 보는 사람이 필요해진 이유가 여기 있다. 그리고 그 사람을 부르는 이름이 아직 정해지지 않았다는 게 2편에서 쓴 내용이다.

4. 절약이 실력이 되는 순간

나도 작은 서비스를 운영하면서 이걸 겪었다. 여러 사용자가 같은 대상을 조회할 때 매번 새로 요청하던 부분이 있었다. 그걸 공유 캐시로 바꿨다.

코드로는 사소한 변경이었다. 어려운 건 구현이 아니라 "여기서 돈이 새고 있다"를 알아차리는 것이었다.

이게 1편에서 쓴 못과 망치 이야기와 정확히 같은 구조다. 망치를 정교하게 만드는 능력이 아니라, 어디에 못이 필요한지 보는 능력이다.

새는 곳을 찾는 방법은 대단하지 않다. 순서대로 보면 대개 나온다.

요청 수를 먼저 센다. 원가는 요청 수 곱하기 요청당 크기다. 어느 쪽이 큰지 모르면 엉뚱한 걸 줄인다
같은 입력이 반복되는지 본다. 반복되면 캐시가 답이다. 가장 싸고 효과가 크다
재시도 횟수를 본다. 실패가 잦은 지점은 원가를 두 배, 세 배로 쓰고 있다
컨텍스트에 안 쓰이는 게 들어가는지 본다. 습관적으로 넣은 데이터가 매 요청마다 돈이 된다
비싼 모델이 필요한 구간을 분리한다. 전부 최상위 모델로 돌리는 건 전부 최저 모델로 돌리는 것만큼 게으른 설계다

이 다섯 개는 기술 문서에 나오는 최적화가 아니다. 손익계산서를 보는 순서다.

5. 가격을 정하는 일이 기술 문제가 됐다

원가가 사용량에 따라 움직이면, 가격도 그 구조를 따라가야 한다. 그런데 어떤 가격 모델을 택하든 부작용이 생긴다.

가격 모델	장점	문제
월 정액 구독	고객이 이해하기 쉽다	헤비 유저가 손실을 낸다
사용량 과금	원가와 매출이 같이 움직인다	고객이 청구서를 예측 못 해서 불안해한다
크레딧 선불	매출이 먼저 들어온다	남은 크레딧을 아끼려고 덜 쓰게 된다
정액 + 사용량 상한	양쪽을 절충한다	상한선을 어디에 둘지가 매번 논쟁이 된다

네 번째가 요즘 가장 많이 보이는 형태다. 그런데 상한선을 정하려면 사용 패턴을 알아야 하고, 사용 패턴을 알려면 로그를 봐야 한다. 그러니까 이건 사업 결정인데 기술 데이터가 없으면 못 정한다.

세 번째 줄의 문제도 만만치 않다. 크레딧이 남았는지 신경 쓰는 순간 고객은 제품을 덜 쓴다. 덜 쓰면 습관이 안 생기고, 습관이 안 생기면 다음 달에 해지한다. 원가를 아끼려고 만든 장치가 이탈을 만든다.

그래서 이 판단은 어느 한 조직이 혼자 할 수가 없다. 개발팀만 보면 원가만 줄이려 하고, 영업팀만 보면 무제한을 팔고 싶어 한다. 양쪽 숫자를 같이 들고 있는 사람이 필요하다. 3편에서 말한 오른쪽 방향이 왜 조직에서 커지는지가 여기서 설명된다.

그리고 이걸 고객에게 설명할 사람도 필요하다

B2B에서는 한 단계가 더 있다. 고객사도 이 구조를 모른다.

"왜 지난달보다 비싸졌나요"라는 질문에 답해야 한다. 정답은 "쓰신 만큼 나온 겁니다"인데, 그렇게 말하면 관계가 상한다. 어디서 많이 썼고, 어떻게 줄일 수 있고, 줄이면 뭘 잃는지를 같이 설명해야 한다.

기술을 모르면 이 설명을 못 하고, 고객을 모르면 이 대화를 못 한다. 2편에서 쓴 FDE가 왜 고객 대면과 LLM 운영을 한 사람에게 붙여놨는지, 이쯤 보면 이해가 된다.

6. 회사가 찾게 될 사람

정리하면 앞으로 이런 사람이 값이 오를 것 같다.

같은 결과를 더 적은 토큰으로 만들어내고, 그 차이가 손익계산서에 어떻게 나타나는지 설명할 수 있는 사람.

두 부분으로 되어 있다는 게 중요하다. 앞부분만 하면 좋은 엔지니어고, 뒷부분까지 하면 3편에서 말한 오른쪽 방향이다.

그리고 뒷부분은 생각보다 배우기 어렵지 않다. 숫자를 한 번 계산해보면 된다. 어려운 건 그 계산을 해볼 생각을 하는 것이다.

7. 정리

AI 제품은 규모의 경제가 깨진 소프트웨어다. 요청 한 번이 원가 한 번이다
많이 쓰는 사용자가 비싼 사용자다. 인기를 얻으면 적자가 되는 구조가 실제로 있다
요금제가 계속 바뀌는 건 변덕이 아니다. 원가 구조를 뒤늦게 반영하는 과정이다
모델 선택, 컨텍스트 크기, 캐시, 재시도, 에이전트 단계 수는 전부 손익 결정이다
에이전트 단계는 곱해진다. 기능은 훌륭하게 동작하고 원가는 조용히 스무 배가 된다
새는 곳 찾기는 어렵지 않다. 요청 수부터 세면 된다. 어려운 건 세볼 생각을 하는 것이다

여기까지가 시장 이야기다. 직군의 지형, 두 갈래 길, 그리고 원가 구조.

그러면 마지막 질문이 남는다. 그 사람이 될 수 있는지 없는지를 무엇이 정하는가.

연차는 아니다. 내가 본 면접에서 연차 자체를 물은 곳은 거의 없었다. 학위도, 다룰 수 있는 언어 개수도 아니었다.

5편에서는 그게 호기심의 범위라는 이야기를 쓴다. 앞으로 한 사람의 능력의 범위는, 그 사람이 궁금해한 범위와 거의 같아질 거라고 생각한다.