오늘날 AI를 활용하여 정말로 한 달에 단 20유로만 쓰고 애플리케이션을 구축할 수 있을까요?

저는 현재 두 가지 프로젝트를 개발하고 있습니다: Hakanai (정적 블로그용)와 6개월 만에 사용자 550명을 돌파한 **Writizzy**입니다. 하지만 이 둘을 합쳐도 저는 한 달에 250유로 이상을 벌지 못하며, 저의 원칙은 제가 버는 것보다 더 많이 쓰지 않는 것입니다.

그래서 저에게는 큰 제약 조건이 있습니다: 바로 예산입니다. 저는 토큰 (tokens)을 빛의 속도로 태워버리지 않으면서 애플리케이션을 구축하려고 노력합니다. 그리고 제가 어떻게 그렇게 하는지 여러분과 공유하고 싶었습니다.

Writizzy란 무엇인가요?

코드 측면에서, 우리는 세 가지 큰 구성 요소를 가지고 있습니다:

• Kotlin으로 작성된 API.
• Nuxt로 작성된 관리자 앱 (Admin App).
• 마찬가지로 Nuxt로 작성된 (콘텐츠를 제공하는) "블로그" 앱.

작업을 위해 저는 주로 Claude를 사용합니다. 왜일까요? 코드 벤치마크 (code benchmarks)에서 여전히 가장 높은 평가를 받는 모델이기 때문입니다.

Claude's ratings on the SWE leaderboard

하지만 저는 대안을 생각하고 있습니다. 이에 대해서는 마지막에 더 자세히 말씀드리겠습니다.

컨텍스트 엔지니어링 (Context Engineering): AI 제약하기

효과적으로 작업하기 위한 아이디어는 LLM (Large Language Model)에게 솔루션 공간을 제한할 수 있도록 필요하고도 충분한 컨텍스트 (context)를 제공하는 것입니다. 우리는 AI가 정해진 범위를 벗어나지 않도록 가이드라인과 스스로를 검증할 수 있는 방법을 제공하고자 합니다. 그렇게 하지 않는다면, AI가 존재하지 않는 API를 환각 (hallucinate)하거나 오래된 문서 버전을 사용하는 것을 보고 놀라지 마세요. 그것은 정상적인 현상입니다.

Claude.md 파일

이것은 진입점입니다. 여기에는 프로젝트 목표, AI가 모든 코드를 무작위로 탐색하는 것을 방지하기 위한 일반적인 구조, 그리고 특히 사양 (specs) 목록이 포함되어 있습니다.

list of writizzy specs

이 목록은 제 개발 프로세스에서 근본적인 역할을 하며, 나중에 다시 다루겠습니다. 또한 이는 Claude를 위한 인덱스 (index) 역할도 합니다.

하위 디렉토리에 다른 claude.md 파일들이 있다는 점에 유의하세요. Claude가 해당 디렉토리에 진입하면 이 파일들을 로드합니다. 저는 애플리케이션마다 하나씩(app, blog, api) 파일을 가지고 있습니다. 사용 가능한 기술들을 나열하는 데 사용하지만, 점점 더 규칙 (rules)을 사용하는 경향이 있습니다.

규칙 (.claude/rules)

이것들은 조건부로 로드될 수 있는 규칙들입니다. 예를 들어, 여기서는 Claude가 /app 디렉토리에 진입하면 Nuxt 규칙을 로드합니다.

header that defines loading conditions

이 규칙 파일에서 저는 사용되기를 원하는 패턴 (patterns)을 정의합니다. 예를 들어:
Nuxt UI 사용 의무화, 작업을 마치기 전에 typecheck 또는 eslint 패스를 실행할 것 등입니다.

이 규칙들은 경험적으로 구축했습니다. 즉, 원래 파일은 비어 있었으나, 발생하는 에러들을 바탕으로 규칙을 추가해 나갔습니다. 더 최근에는 Claude의 탐색 (exploration)을 제한하려고 노력하고 있습니다. 수많은 토큰 (tokens)을 탐색에 소비하는 것을 방지하기 위해, 규칙에 문서화해야 할 패턴을 발견했는지 체계적으로 질문합니다. 또한, Claude가 마주치는 코드에 기반해 추측하는 것을 별로 좋아하지 않습니다.

최근에 제가 질문했던 예시입니다:

이미 설정해 둔 규칙들을 개선하고 싶습니다. 당신이 문맥 (context)과 패턴을 이해하기 위해 아주 많은 파일들을 읽어야 했다는 것을 알게 되었습니다. 왜 그런가요? 우리가 규칙으로 만들 수 있을지 확인하기 위해, 당신이 이해하려고 했던 패턴들을 요약해서 알려주세요.

사실, 이러한 규칙 파일들을 만드는 것은 일종의 **안전 장치 (safety harness)**입니다. 하지만 LLM (Large Language Models)은 규칙을 무시하는 경우가 빈번하기 때문에 이것이 보증 수표는 아니라는 점을 이해해야 합니다. 따라서 테스트 (tests), 린터 (linter), CI 품질 게이트 (quality gates) 등 제어 수단을 강화해야 합니다.

좋은 관행 (good practices)을 바탕으로 개발하는 데 익숙한 사람들은 AI와 올바르게 협업하기가 더 쉽다는 점을 주목합니다. 이러한 관행들은 안전장치 역할을 하지만, 많은 기업에서 이는 그저 보여주기식 (window dressing)이었을 뿐 실제로는 그리 효과적이지 않았습니다. 그리고 정확히 말하자면, 이러한 방법론이 성숙하지 않은 기업에서는 AI가 제대로 작동하지 않습니다. 왜 그런지 궁금해질 수도 있겠네요... 아니면 아닐 수도 있고요.

"Analyst" 명령어

명령어 (command)는 일종의 사전 프롬프트 (pre-prompt)입니다. 저는 브레인스토밍을 위해 analyst 명령어를 사용합니다. 저는 그에게 블로깅, IndieWeb, 그리고 탈중앙화 (decentralization) 전문가가 되어달라고 요청합니다. 또한 저의 요구사항에 이의를 제기하고, 불일치를 찾아내며, 무엇보다도 사양서 (specs)를 작성해달라고 요청합니다.

analyst command file

코드 작성 전 사양서 (Specs)

앞서 저는 claude.md 파일에 나열된 사양서 (specs)에 대해 이야기했습니다.

저의 개발 사이클 (dev cycle)에 대해 조금 이야기해 보겠습니다. 저는 중요한 코드 조각을 작성하기 전에 체계적으로 사양서 (spec)를 검토합니다.
(제가 Malt를 출시했을 때를 돌이켜보면, 처음에는 적힌 것이 별로 없었다는 점이 재미있네요…)

AI를 사용할 때, 사양서 (spec)는 두 가지 주요 이점이 있습니다:

1. 기대되는 결과의 틀을 잡습니다. 우리는 먼저 방향성, 사용자 흐름 (user flows) 등을 정의합니다.
2. 향후 토큰 (tokens)을 절약합니다: 사양서에 기술적인 진입점 (entry points)과 주요 파일들을 나열함으로써, Claude가 모든 곳을 뒤질 필요가 없게 만듭니다.

list of technical entry points

실제로 Claude가 이미 존재하는 기능을 재작업할 때, 그는 사양서 (spec) 파일을 사용하여 그것이 어떻게 작동하는지 이해하고 특히 주요 파일들로 쉽게 돌아갈 수 있습니다. 이러한 사양서 (specs)를 통해 그는 그 과정에서 많은 시간을 절약할 수 있으며, 특히 그에게 추측하게 만드는 것보다 훨씬 더 정확할 것입니다.

사양서 (spec)가 검증되면, 저는 **구현 계획 (implementation plan)**을 만듭니다 (사실, Claude가 계획을 만듭니다). 이를 위해 저는 저의 관행을 강제하는 기술 (skill)을 사용합니다. 즉, 각 단계는 배포 가능해야 하며, 필요한 경우 기능 플래그 (feature flags)를 사용해야 하는 등의 규칙입니다.

컨텍스트 윈도우 (context window)를 관리하는 기술

여기서 저는 컨텍스트 윈도우 (context window)의 개념으로 돌아가야 하는데, 이는 월간 예산을 최적화하는 데 매우 중요하기 때문입니다. 비용이 많이 발생하는 것은 끝없는 세션 (sessions)입니다. 매 교환마다 전체 이력을 다시 전송하게 됩니다. 시간이 지나면 단순한 "Ok" 한 마디가 수만 개의 토큰 (tokens) 비용을 발생시킬 수 있습니다. 이것만으로도 이미 비용이 많이 듭니다.

하지만 두 번째로 멋진 부작용은, 윈도우가 가득 찰수록 AI가 더 "멍청해진다"는 것입니다. 그래서 저는 절대 50% 용량을 초과하지 않으려 노력합니다. 이것이 구현 계획 (implementation plans)을 세우는 핵심 이유입니다. 아이디어는 작업을 작고 자율적인 태스크 (tasks)로 나누고 세션을 정기적으로 교체하는 것입니다.

기술 (Skills) vs MCP: 효율성 전쟁

앞서 기술 (skills)에 대해 언급했습니다. 저는 더 효율적으로 일하기 위해 이를 적극적으로 사용합니다. 그리고 효율성과 비용 사이에는 실질적인 평행 관계가 있으므로 여기서 이 이야기를 해야 합니다.

**기술 (Skill)**이란 필요할 때 로드되는 역량입니다. 예를 들어, 저의 Nuxt 기술은 Claude가 오래된 학습 데이터에 의존하는 대신 온라인에서 문서 (doc)를 직접 읽도록 (Markdown 형식으로) 강제합니다.

저는 다양한 용도의 기술을 가지고 있습니다:

• 저의 디자인 패턴 (design patterns)을 지정하는 API들: api-design, db-migration, write-spec

이것은 때때로 단순히 패턴을 지정하는 것 그 이상입니다. 예를 들어, db-migration 기술은 어떤 도구(Flyway)를 사용할지, 마이그레이션 파일의 위치는 어디인지, 파일 형식은 무엇인지를 정확히 나열합니다. 그리고 패턴 측면에서는 저의 핵심적인 배포 전략 원칙(rolling update 등)이 포함되어 있습니다.

• 문서를 가져오는 방법을 지정하기 위한 bento, nuxt, nuxt-content, nuxt-ui
• CLI 사용법을 설명하는 기술들, 예를 들어 정보를 얻고, 진단하고, 문제를 해결하기 위해 sentry CLI를 사용하는 방법을 설명하는 sentry-fix-issues

반면에, MCP (Model Context Protocol)가 있습니다. 이것 역시 강력하지만, MCP의 각 메서드(method)가 컨텍스트 윈도우(context window)에 포함되기 때문에 컨텍스트 공간을 더 많이 차지합니다. 반면 스킬(Skill)의 경우, 스킬 설명(skill description)만 포함됩니다.

그래서 저는 다음을 제외하고는 스킬(Skills)을 선호합니다:

• MCP IntelliJ: 코드를 제대로 탐색하고 컴파일하기 위해.
• MCP Stripe: 설정을 디버깅하기 위해.
• Claude-mem: 세션 간의 주요 결정 사항을 기억하기 위해 (아직 테스트 중이며, 이득이 명확하지는 않습니다).

디자인은 어떻게 하나요?

최근에 저는 Claude Design으로 전환했습니다. 이것이 제가 선택한 도구가 되었습니다. 저는 브리핑을 하고, 특정 영역에 코멘트를 남기며, 즉석에서 수정합니다. 그리고 HTML이 깔끔해지면, 구현을 위해 Claude 에이전트(agent)에게 전달합니다. 이는 이전에 단순한 프롬프팅(prompting)으로 했던 것보다 훨씬 뛰어납니다. 결과가 정말 놀랍습니다.

대차대조표: 예산을 어떻게 지키나요?

요약하자면, 이 모든 것을 통해 저는 한 달에 20€로 버텨내고 있지만, 몇 가지 추가적인 요령이 더 있습니다:

• 토큰 압축 (Token compression): 압축 전략(예: rtk)을 사용하거나, LLM에 꼭 필요한 것만 보내기 위해 저만의 도구를 만듭니다.
• 온라인 AI:

다음 단계: 저는 로컬 모델 (local models)을 테스트하고 있습니다. 핵심 아이디어는 작은 구현 작업들은 제 컴퓨터에 위임하고, Claude는 전략적 기획을 위해서만 사용하는 것입니다. 이제 정말 시작 단계일 뿐이라, 나중에 이에 대해 더 자세히 이야기하겠습니다.

저는 이 주제들에 대해 가능한 한 고도화된 수준과는 거리가 멀며, 특히 1인 개발 (solo context) 환경에 있습니다. 하지만 공유하고 싶은 여러분만의 팁이 있다면 댓글로 주저 말고 남겨주세요. 주의 깊게 읽어보겠습니다.