AI로 만드는 건 쉬워졌는데, 왜 API를 또 결제해야 하나 — 그리고 이걸 어떻게 나눌까

AI로 서비스 하나 만드는 건 이제 어렵지 않다. 대화하면서 코드를 얻고, 로컬에서 띄워 보고, 호스팅에 올리면 끝난다. 주말 하나면 된다.

그런데 그렇게 만든 걸 실제로 굴려 보면 곧 이상한 지점에 닿는다. AI 구독료를 이미 내고 있는데, 그 AI로 만든 서비스를 굴리려면 API 요금을 또 내야 한다.

만드는 비용은 내려갔는데 운영 비용은 그대로거나 오히려 올라간 셈이다. 이 글은 그 딜레마를 어떻게 피했는지에 대한 기록이다.

서비스를 만드는 절차는 원래 이렇다

혼자 서비스를 만들 때 밟는 순서는 대체로 정해져 있다.

1. 로컬 서버 셋팅 → AI와 대화하며 구축 → 로컬 테스트
2. 온라인 호스팅 마련 → 서버·저장소 구축, 도메인 연결 (AWS, 카페24, 가비아 같은 것들) → 로컬 데이터 업로드 → 확인·검증
3. 1과 2를 반복

여기까지가 흔히 '서비스를 만들었다'고 말하는 지점이다. AI가 빠르게 만들어 준 것도 딱 여기까지다.

그런데 서비스는 여기서 끝나지 않는다

만들어 놓기만 한 서비스는 빈 껍데기다. 그 안에 뭔가가 계속 채워져야 사람이 온다.

• 사용자가 데이터를 만들어 넣거나
• 운영자가 컨텐츠, 그러니까 볼거리를 만들어 넣고
• 홍보해서 활성화시키고
• 그 컨텐츠 소비에 대해 비용을 받으며 운영한다

만드는 건 한 번이지만 채우는 건 매일이다. 그리고 이 매일이 실제 비용이 발생하는 자리다. 서비스 제작이 쉬워졌다고 말할 때 보통 이 부분은 빠져 있다.

과금 방식은 이렇게 흘러왔다

돈을 받는 방식도 계속 바뀌어 왔다. 순서를 짚어 보면 나름의 논리가 있다.

처음에는 제품을 구입하는 형식이었다. 한 번 사면 내 것이 되는 방식이다. 다만 초기 비용이 부담스럽다.

그래서 구독으로 전환됐다. 초기 비용에 부담을 느끼는 소비자에게 어필하기 위해서였다. 월 얼마씩 나눠 내면 되니 진입 장벽이 낮아진다.

그다음은 제휴 마케팅이었다. 서비스가 다양해지면서 그 다양성을 하나의 서비스 안에 전부 마련하는 게 어려워졌기 때문이다. 내가 못 하는 건 남의 것을 붙여서 채우는 방식이다.

그런데 제휴에는 대가가 따랐다. 사람의 개입이 늘고 관리가 불편해졌다. 무엇보다 일이 잘못됐을 때 책임 소재가 불명확해진다. 내 서비스에서 벌어진 일인데 내 잘못이 아니고, 상대 잘못이라고 하기도 애매한 상황이 생긴다.

그래서 API로 넘어갔다. 사람이 개입하지 않으면서 독자 서비스의 한계를 넘기 위해서다. 사람의 개입은 불편할 뿐 아니라 일정하지도, 규칙적이지도 않다. 기계에 맡기면 그 둘이 해결된다.

여기까지가 AI 이전의 이야기다.

AI가 들어오면서 생긴 딜레마

AI가 들어오면서 두 가지가 동시에 일어났다.

하나, AI로 서비스 만들기가 쉬워졌다. 앞에서 말한 1번과 2번이 짧아졌다.

둘, AI는 개인 또는 팀 단위 구독 서비스다. 월정액을 내고 대화하면서 쓴다.

문제는 이 둘이 만나는 지점에서 생긴다. 만든 서비스가 서비스다워지려면 API가 필요한데, 그 API 요금은 내가 이미 내고 있는 구독과 별개다.

글을 자동으로 쓰게 하려면 API를 호출해야 한다. 이미지를 만들려 해도 마찬가지다. 구독으로 쓸 때는 정액이던 것이 서비스에 붙이는 순간 종량제가 된다. 그리고 그 비용은 서비스가 잘될수록 올라간다.

만드는 건 싸졌는데 채우는 건 비싸졌다. 이 딜레마를 어떻게 풀 것인가.

API를 쓰지 않으면 된다

답은 생각보다 단순한 데 있었다. API를 쓰지 않고 글을 발행하고 이미지를 만들면 된다.

말장난처럼 들리지만 방법이 있다. 요즘 AI 도구들은 API 말고 CLI 형태로도 제공된다. 클로드 코드나 코덱스 같은 것들이다. 이건 구독에 포함되어 있고, 터미널에서 프롬프트로 부린다.

그러면 이렇게 된다.

• 로컬 PC를 always on 으로 켜 둔다
• CLI 에이전트를 원격으로 제어한다
• 거기서 글과 이미지를 만들어 발행한다
• 깃에 푸시하면 클라우드로 배포된다

서비스 서버는 API를 부르지 않는다. 정적인 결과물만 받는다. 만드는 일은 내 구독 안에서 끝나고, 서버는 이미 만들어진 것을 보여 주기만 한다.

비용이 발생하는 지점을 구독 안쪽으로 옮긴 것이다. 서비스가 잘돼서 트래픽이 늘어도 생성 비용은 늘지 않는다. 늘어나는 건 호스팅 비용뿐이고, 그건 원래 감당하려던 것이다.

목표는 원천 소스를 만드는 쪽

여기까지가 방법이고, 방향은 조금 다른 데 있다.

목표는 글 발행의 원천 소스를 생산하는 것이다. 남의 것을 옮기거나 조합하는 게 아니라, 여기서 처음 나온 것을 만든다.

원천 소스가 있어야 퍼질 것이 있고, 퍼진 것이 다시 오리지널을 찾아온다. 그 순환의 가운데에 남는 것이 IP 다.

제휴 마케팅이 남의 컨텐츠를 빌려 오는 방식이었다면 이건 반대 방향이다. 빌려 오지 않고 만든다.

이 글도 그렇게 나왔다

이 사이트가 그 방식으로 돌아간다.

글은 로컬에서 마크다운 파일로 쓰이고, 깃에 커밋되고, 푸시하면 배포된다. 서버는 글을 만들지 않는다. 이미 만들어진 것을 보여 줄 뿐이다. 생성에 드는 비용은 이미 내고 있는 구독 안에서 끝난다.

여기까지는 잘 돌아간다. 문제는 그다음이다.

그런데 여기서 막힌다

이 방식은 나 혼자 쓸 때만 성립한다.

내가 내 구독으로, 내 컴퓨터에서, 내 글을 만든다. 비용이 안 늘어나는 이유가 그거다. 쓰는 사람이 나 하나니까.

그런데 서비스라는 건 혼자 쓰는 게 아니다. 다른 사람이 와서 뭔가를 얻어 가야 서비스다. 그 순간 질문이 처음으로 돌아간다. 남을 위해 뭔가를 생성하려면 그 비용은 누가 내는가.

딜레마를 푼 게 아니라 혼자 있는 자리로 피한 것에 가깝다. 그래서 지금 붙잡고 있는 질문은 이거다.

이 프로세스를 구축해 뒀는데, 이걸 어떻게 다른 사람들과 나눌 수 있을까.

나눌 수 있는 방법을 늘어놓아 보면

몇 가지가 떠오르는데 전부 어딘가에서 걸린다.

하나, 결과물만 나눈다. 지금 하고 있는 것이다. 내가 만든 글을 사람들이 읽는다. 비용 구조는 완벽하다. 다만 이건 서비스라기보다 매체에 가깝다. 읽는 사람은 소비자이지 사용자가 아니다. 그 사람이 무언가를 만들어 가지는 못한다.

둘, 프로세스를 나눈다. 파이프라인 자체를 남에게 준다. 각자 자기 구독으로 자기 컴퓨터에서 돌린다. 비용이 각자 안에서 끝나니 구조가 그대로 유지된다. 가장 그럴듯한데, 진입 장벽이 남는다. 터미널을 열고, 깃을 쓰고, 배포를 붙여야 한다. 그걸 대신 없애 주려면 결국 내가 돌려 줘야 하고, 그러면 첫 번째나 API 로 돌아간다.

셋, 각자 자기 키를 넣게 한다. 흔한 절충안이다. 비용이 쓰는 사람 몫이 되니 내 부담은 없다. 다만 남의 키를 다루는 책임이 새로 생기고, 키를 발급받을 줄 아는 사람만 쓴다. 진입 장벽이 사라진 게 아니라 형태만 바뀐다.

넷, 대신 돌려 주고 값을 받는다. 내 파이프라인으로 남의 컨텐츠를 만들어 준다. 되긴 된다. 그런데 사람의 개입이 다시 늘어난다. 앞에서 제휴 마케팅의 문제로 짚었던 바로 그 자리다. 일정하지도, 규칙적이지도 않은 자리.

한 바퀴 돌아 제자리다. 자동화하면 비용이 들고, 사람이 하면 흔들린다.

나눈다는 게 무엇을 나누는 것인가

정리하다 보니 질문이 하나 더 갈라진다.

결과물을 나누는 것과 능력을 나누는 것은 다르다.

결과물을 나누면 내 것이 하나 남는다. 사람들은 내가 만든 것을 본다. 확산은 내가 만든 만큼만 일어난다.

능력을 나누면 각자의 원천 소스가 생긴다. 내 것이 아니라 그 사람 것이. 확산의 크기는 비교가 안 된다. 대신 나는 무엇으로 남는지가 흐려진다. IP 를 만들자고 시작했는데 나눠 주고 나면 IP 는 각자에게 간다.

물고기를 주느냐 낚시를 가르치느냐는 오래된 비유인데, 여기서는 낚싯대 값을 누가 내느냐가 실제 문제다.

지금 서 있는 자리

아직 답이 없다.

지금은 첫 번째를 하면서 두 번째를 준비하는 중이다. 글을 쌓아 원천 소스를 만들고, 그 과정을 만드는 데 쓴 구조를 기록해 둔다. 언젠가 프로세스를 넘길 수 있는 형태가 되면 그때 방법이 보일 거라고 생각한다.

이 글을 쓴 이유도 절반은 그거다. 비슷한 자리에 서 있는 사람이 있다면 어떻게 풀었는지 듣고 싶다.

자주 묻는 질문

API를 아예 안 쓰면 못 하는 게 뭔가? 사용자의 요청에 그때그때 응답해야 하는 기능은 못 한다. 챗봇, 실시간 번역, 사용자가 올린 사진을 즉석에서 분석하는 것 같은 일이다. 반대로 미리 만들어 두고 보여 주기만 하면 되는 것 — 글, 이미지, 정리된 정보 — 은 전부 이 방식으로 된다. 서비스 성격을 먼저 나눠 봐야 한다.

로컬 PC를 계속 켜 두는 게 서버를 빌리는 것보다 나은가? 싸다는 점에서는 그렇다. 전기료 정도다. 다만 안정성은 떨어진다. 정전이나 인터넷 문제로 멈출 수 있고, 집을 비운 사이 문제가 생기면 손을 쓰기 어렵다. 발행이 몇 시간 늦어도 되는 일이라면 감당할 만하고, 몇 분도 멈추면 안 되는 일이라면 맞지 않는다.

그럼 서버는 왜 따로 두나? 글을 보여 주는 일과 글을 만드는 일을 나눈 것이다. 보여 주는 쪽은 항상 켜져 있어야 하니 클라우드에 둔다. 만드는 쪽은 가끔 돌면 되니 로컬에 둔다. 둘을 깃이 이어 준다. 깃에 푸시하면 배포가 도는 구조라 별도의 연결 장치가 필요 없다.

CLI 로 쓰는 것과 API 로 쓰는 것은 결과물이 다른가? 같은 모델이라면 결과물 자체는 크게 다르지 않다. 다른 것은 호출 방식과 과금이다. CLI 는 사람이 앉아서 쓰는 도구라는 전제로 구독에 포함되고, API 는 프로그램이 자동으로 부르는 것이라 쓴 만큼 낸다. 그래서 이 방식은 사람이 개입하는 자리를 일부러 남겨 두는 구조이기도 하다.

앞에서 사람의 개입이 문제라고 하지 않았나? 맞다. 그래서 개입의 성격을 바꿨다. 제휴 마케팅에서 문제가 된 개입은 매번 판단이 달라지는 개입이었다. 여기서 남긴 개입은 발행 버튼을 누르는 정도이고, 판단은 미리 정해 둔 규칙과 프롬프트가 한다. 사람이 하는 일을 줄인 게 아니라, 사람이 흔들릴 수 있는 자리를 줄였다고 보는 편이 정확하다.

그냥 API 비용을 사용자에게 받으면 되지 않나? 정액을 받는데 비용이 종량으로 나가는 게 문제다. 많이 쓰는 사람 한 명이 여러 명의 구독료를 다 먹는 일이 생긴다. 그래서 사용량 상한을 걸게 되고, 상한을 걸면 서비스가 답답해진다. 요금을 올리면 진입 장벽이 생긴다. 금액의 문제라기보다 정액으로 받고 종량으로 나가는 구조의 문제에 가깝다.

프로세스를 나눈다면 무엇부터 열어야 하나? 아직 정하지 못했다. 다만 순서는 기록 → 템플릿 → 실행 도구 라고 본다. 어떻게 굴리는지를 먼저 글로 남기고, 따라 할 수 있는 형태로 정리하고, 그다음에 도구를 만든다. 도구부터 만들면 쓰는 사람이 왜 그렇게 굴러가는지를 모른 채 쓰게 되고, 막히는 순간 그만둔다.