처음 프로그램을 만들기 시작했을 때는 이렇게 여러 개발환경을 구성하게 될 줄 몰랐다.
Windows에서 Linux 개발환경을 만들고 AI에게 코드를 작성하도록 요청하는 것이 시작이었다. 이후 GitHub에 소스를 보관하고 Cloudflare로 자동 배포하기 시작했다. 프로젝트가 늘어나면서 Android 앱까지 개발하게 됐고, 그 과정에서 WSL2의 메모리 부족으로 작업이 중단되는 일도 겪었다.
지금은 Codex Cloud를 주 개발환경으로 사용하면서 기존 WSL2 Ubuntu를 별도의 개발 경로로 유지한다. GitHub Actions는 개발 세션과 독립적으로 빌드와 테스트를 수행하고, Cloudflare는 Git 연동을 통해 웹서비스를 배포한다.
개발환경이 복잡해진 것 같지만 기본 웹 인프라는 여전히 무료 요금제를 중심으로 구성할 수 있다. 앞선 기록에서 처음의 WSL2 개발환경과 실제 OOM 장애, Codex Cloud 이전까지 다뤘다면, 이 세 번째 글은 그 이후에 완성된 운영 구조와 비용에 집중한다.
1. 개발환경은 어떻게 변해왔을까?
| 단계 | 주요 환경 | 변화의 목적 |
|---|---|---|
| 초기 개발 | Windows + WSL2 + Codex CLI | Linux 기반 개발환경 |
| 소스·배포 분리 | GitHub + Cloudflare | 컴퓨터와 배포의 종속성 줄이기 |
| 클라우드 전환 | Codex Cloud | 로컬 자원 부족과 장애에 대응 |
| 개발·빌드 이중화 | Codex Cloud + WSL2 + GitHub Actions | 독립된 개발·빌드 경로 확보 |
Windows 안에 Linux 개발환경을 만들다
처음에는 Windows PC에 WSL2 Ubuntu를 구성했다. 일상적인 작업은 Windows에서 하고 실제 개발은 Ubuntu에서 진행했다. Node.js, Git, Codex CLI를 설치하고 필요한 프로젝트를 하나씩 만들었다.
이 방식을 선택한 이유 중 하나는 AI 코딩 도구에 Windows의 모든 파일과 권한을 불필요하게 넓게 허용하고 싶지 않았기 때문이다. 다만 WSL2가 Windows와 완전히 분리된 보안 경계는 아니다. 실제 접근 범위는 파일 권한, 마운트와 도구 설정에 따라 달라진다.
프로젝트가 늘어난 뒤에는 GitHub를 소스 관리의 기준점으로 삼고, Cloudflare의 Git 기반 자동 배포를 연결했다. 노트북이 꺼져 있어도 공개된 사이트는 계속 운영되고, 소스가 다른 컴퓨터에서 이어질 수 있는 기반이 만들어졌다.
이 초기 개발환경과 GitHub 활용 경험은 첫 번째 개발 Story로 남겼다. 여기서는 그 이후에 바뀐 운영 방식에 집중한다.
WSL2 메모리 부족이 전환점이 되다
웹 개발에 Android 앱 개발까지 추가되자 Gradle, Android SDK, 브라우저와 여러 개발 도구가 함께 메모리를 사용했다. 실제로 WSL2에서 OOM(Out of Memory)이 발생했고 Swap이 소진된 상태에서 프로세스가 종료된 로그를 확인했다. 메모리 부족은 확인했지만 WSL의 최종 재시작 주체까지 단정할 수는 없었다.
단순히 메모리를 더 할당하는 방법도 있었겠지만 다른 질문이 생겼다.
개발하던 컴퓨터가 멈춰도 다른 곳에서 이어서 작업할 수 있을까?
이렇게 Codex Cloud를 본격적으로 활용하기 시작했다. WSL2의 파일 시스템을 통째로 옮긴 것은 아니다. GitHub의 소스와 프로젝트 설정을 바탕으로 Node.js, JDK, Android SDK 등 필요한 도구를 클라우드에 다시 구성했다. 앞서 로컬 환경을 만들어 본 경험이 도움이 됐다.
개발뿐 아니라 빌드도 분리하다
클라우드 개발환경도 하나의 실행 환경에 불과하다. 그래서 WSL2를 제거하지 않았고, GitHub Actions를 별도의 빌드·검증 경로로 구성했다.
현재 Codex Cloud는 주 개발환경이고, WSL2는 로컬 개발·Android 실기기 테스트·정식 서명 APK 빌드에 활용할 수 있다. GitHub Actions는 개발 세션과 무관하게 정해진 테스트와 Release 빌드를 실행한다.
Android 앱인 ONSEMO Connect는 기존 서명 인증서를 사용한 Release APK 빌드 및 서명 검증을 수행하는 수동 워크플로를 구성했다. APK를 만드는 작업과 공식 다운로드 주소에 게시하는 작업은 별도의 절차다. 승인과 검증을 거친 결과물만 공식 경로에 반영한다.
이 구조가 완전한 무중단 시스템은 아니다. GitHub와 Cloudflare라는 공통 의존성도 남아 있다. 그래도 한 대의 컴퓨터에만 개발과 빌드를 맡기던 초기 구조와는 분명히 달라졌다.
2. 현재 ONSEMO의 개발·배포 인프라
현재 개발환경의 중심에는 GitHub가 있다. Codex Cloud와 WSL2는 서로 다른 실행 환경이지만 동일한 GitHub 저장소의 변경 이력을 기준으로 작업한다. GitHub Actions는 별도로 빌드를 검증하고, 웹 배포는 Cloudflare의 Git 연동을 통해 진행한다.
| 시스템 | 맡은 역할 |
|---|---|
| ChatGPT | 기획·설계·기술 검토 |
| Codex Cloud | 주 개발환경 |
| WSL2 Ubuntu | 보조 개발, 실기기 테스트, APK 빌드 |
| GitHub | 소스·버전 관리 |
| GitHub Actions | 독립 빌드와 테스트 |
| Cloudflare Workers Builds | Git 기반 웹 빌드·배포 |
| Cloudflare Workers | 필요한 서버 기능 |
| Cloudflare D1 | 경량 SQL 데이터 관리 |
| Cloudflare Durable Objects | 상태 기반 기능 관리 |
| Cloudflare Web Analytics | 서비스 운영 지표 확인 |
모든 프로젝트에 데이터베이스를 만드는 것은 아니다. 정적 웹으로 충분하면 정적 파일 위주로 구성하고 서버나 데이터 처리가 필요할 때만 Workers, D1, Durable Objects를 선택적으로 사용한다.
Web Analytics는 쿠키에 의존하지 않는 방식으로 기본적인 운영 지표를 확인하는 데 활용한다. 보안 측면에서는 Cloudflare의 DNS, HTTPS 및 필요한 보안 기능을 서비스 특성에 맞게 설정한다.
3. 연간 기본 웹 인프라 비용
여러 서비스를 운영하려면 반드시 여러 대의 유료 서버가 필요할 것이라고 생각했다. 하지만 ONSEMO의 기본 웹 인프라는 GitHub와 Cloudflare의 무료 한도를 중심으로 구성할 수 있다.
| 항목 | 기준 | 연간 기본 비용 |
|---|---|---|
| GitHub Private 저장소 | Free | $0 |
| GitHub Actions | Free 할당량 내 | $0 |
| Cloudflare Workers·Builds | Free 할당량 내 | $0 |
| Cloudflare D1·Durable Objects | Free 할당량 내 | $0 |
| Cloudflare DNS·SSL·Web Analytics | 기본 무료 기능 | $0 |
| .com 도메인 1개 | 갱신 비용 약 $10.46 기준 | $10.46 |
| 합계 | 위 조건을 충족할 경우 | 연 $10.46 |
도메인 하나에 여러 서브도메인을 연결하면 서브도메인마다 도메인 등록비를 따로 낼 필요는 없다. 예를 들어 BLOG, CART, CONNECT를 각자의 주소로 분리할 수 있다.
이 금액은 개발 전체 비용이나 실제 모든 청구액을 의미하지 않는다. 기존 컴퓨터·인터넷 환경을 사용하고 무료 할당량을 초과하지 않는다는 가정이다. 장비, 전기, 통신, 세금, 추가 도메인 및 유료 기능은 제외했다. 도메인 가격도 갱신 시점에 달라질 수 있다.
AI 개발 도구는 별도의 선택 사항
ONSEMO 개발에서 AI는 중요하다. 하지만 처음부터 유료 AI 도구를 사용한 것은 아니다. 나 역시 ChatGPT 무료 요금제로 시작했다.
작은 프로그램을 만들고 여러 가지를 시험하면서 필요에 따라 도구를 선택하게 됐다. 따라서 AI 서비스 구독료는 웹 인프라 유지비와 분리해 생각하는 편이 적절하다. 무료 요금제에도 기능과 사용량 제한이 있고, 특정 개발 기능은 별도의 이용 조건이 있을 수 있다.
도메인도 개발 자체를 시작하기 위한 필수 조건은 아니다. 작게 시작하고 실제로 필요한 시점에 비용을 추가하면 된다.
4. 무료 요금제는 어느 정도까지 사용할 수 있을까?
다음은 2026년 10월 기준으로 살펴본 주요 무료 할당량이다.
| 서비스 | 대표적인 무료 한도 |
|---|---|
| Cloudflare Workers | 하루 100,000요청 |
| Workers Builds | 월 3,000분 |
| Cloudflare D1 | 하루 읽기 500만 행·쓰기 10만 행, 전체 저장 5GB |
| Durable Objects | 하루 100,000요청, 실행 13,000 GB·초 |
| GitHub Actions | 월 2,000분, Artifact 500MB |
| Web Analytics·DNS·Universal SSL | 기본 무료 기능 |
모든 항목이 프로젝트별 독립 한도는 아니다. 일부는 계정 전체에서 공유하고 실행 환경에 따른 제한도 있다. 특히 GitHub Actions와 Cloudflare Workers Builds의 빌드 사용량은 서로 별도로 계산된다.
현재 사용량이 무료 할당량 범위에 머무르는 동안에는 유료 서버를 추가하기보다 작은 서비스부터 검증할 수 있다. 실제 이용량이 늘어나면 측정 결과를 바탕으로 확장하면 된다.
5. 앞으로 어떤 기술을 활용할 수 있을까?
개발환경을 정리하면서 현재 사용하는 기능 외에도 무료 범위에서 시험할 수 있는 Cloudflare 서비스가 많다는 사실을 알게 됐다.
CART에서는 개인 스크린샷의 상품 정보를 읽는 OCR을 검토했고, INVEST에서는 공개 시장 데이터를 수집해 활용할 방법을 고민했다. 두 사례는 필요한 데이터의 성격과 개인정보 보호 원칙에 따라 기술 선택이 달라져야 한다는 점을 보여준다.
아래는 향후 로드맵의 일부를 고민하며 살펴보는 기술 후보다. 확정된 개발 일정이나 이미 구현한 기능을 의미하지 않는다.
| 프로젝트 | 검토 기술 | 적용 가능성을 살펴볼 방향 |
|---|---|---|
| BLOG | Workers AI, Vectorize | 공개 글 분류·의미 기반 검색 |
| INVEST | D1, 규칙 기반 처리 | 공개 시장 데이터 관리·지표 정리 |
| CART | 브라우저 OCR, 선택적 AI | 상품 정보 추출·정형화 |
| CONNECT | Durable Objects, Queues | 전달 상태·비동기 처리 검토 |
| WEB TOOLS | Browser Run, Workers | 소규모 웹 자동화·화면 검사 |
| HOME | 로컬 처리, 선택적 클라우드 기능 | 기기 상태·알림 연결 |
BLOG의 글이 충분히 쌓인다면 의미 기반 검색이 유용할 수 있다. 반면 CART의 개인 스크린샷이나 CONNECT의 암호화 메시지처럼 민감한 데이터를 다루는 경우에는 기존의 로컬 처리·암호화 원칙을 먼저 지켜야 한다.
기술을 사용할 수 있다는 이유만으로 바로 도입하기보다 실제로 해결할 문제가 있는지를 우선 살펴보려 한다.
6. 개발환경을 바꾸면서 달라진 생각
처음에는 AI로 프로그램을 만드는 것 자체가 목표였다. 그러다 소스 관리가 필요해지고 자동 배포가 필요해졌으며, 개발환경이 멈췄을 때도 작업을 이어갈 방법까지 고민하게 됐다.
지금은 새 기능을 만들 때마다 서버와 데이터베이스를 추가하기보다 기존 인프라 안에서 해결할 수 있는 방법부터 찾는다.
무료 인프라를 활용하는 것은 비용을 줄이는 방법이기도 하지만, 작은 규모로 다양한 아이디어를 실험할 수 있는 기회이기도 하다.
작게 시작하고, 직접 경험하고, 필요할 때 확장한다.
ONSEMO의 개발환경은 그 과정에서 조금씩 변화하고 있다.
---
2026년 10월 15일 기준 공개된 요금과 한도를 바탕으로 작성했다. 무료 기능의 범위와 가격은 변경될 수 있으며 실제 청구액은 서비스 대시보드에서 확인해야 한다.