네트워크 서비스를 만들다 보면 가장 먼저 마주하는 벽이 있습니다. 바로 "어떻게 내 서비스를 외부에서 접속하게 만들 것인가?"이죠. 단순히 IP 주소를 알려줄 순 없으니까요.

오늘은 입문자가 쉽게 시작할 수 있는 DDNS 방식부터, Vercel이나 Firebase 같은 전문 플랫폼 연동을 위한 Cloudflare 기반 고유 도메인 확보까지 2단계로 나누어 정리해 보겠습니다.

1단계 전략: 가볍게 시작하는 '빌려 쓰는 주소', DDNS

처음 개인 서버(Mini PC, NAS)를 구축하거나 로컬 환경에서 테스트할 때 가장 만만한 방법은 DDNS(Dynamic DNS)입니다.

• 원리: iptime 공유기나 DuckDNS 같은 서비스가 제공하는 서브 도메인(예: myhome.duckdns.org)을 빌려 쓰는 방식입니다.
• 장점: 무료입니다. 공유기의 유동 IP가 바뀌어도 자동으로 추적해 주니 신경 쓸 게 없습니다.
• 한계: 하지만 치명적인 단점이 있습니다. '제어권'이 없다는 거죠.
  • example.com 같은 깔끔한 주소를 가질 수 없습니다.
  • 가장 큰 문제는 DNS 레코드(TXT, MX 등) 수정이 거의 불가능하다는 점입니다. 이 때문에 Resend 같은 외부 이메일 발송 서비스나 보안 인증이 필요한 플랫폼과는 연동할 수 없습니다.

💡 한 줄 요약: "내 방 안의 장난감이나 개인용 미디어 서버라면 DDNS로 충분합니다."

2단계 전략: 본격적인 내 집 마련, Cloudflare로 고유 도메인 확보하기

서비스를 Vercel, Firebase에 배포하고 프로젝트의 완성도를 높이고 싶다면, 이제는 나만의 고유 도메인이 필요합니다. 이때 가장 추천하는 조합이 바로 Cloudflare입니다.

왜 Cloudflare인가요?

1. 도매가 정책: Cloudflare는 도메인 판매 시 수수료를 붙이지 않는 '원가 제공'으로 유명합니다. 갱신 비용이 매우 저렴하죠.
2. 강력한 관리 도구: 단순 구매뿐만 아니라 전 세계에서 가장 강력한 DNS 관리 기능을 제공합니다.
3. 무료 보안(SSL/WAF): 클릭 몇 번으로 HTTPS 보안 설정을 끝낼 수 있고, 디도스(DDoS) 공격으로부터 내 서버 IP를 숨겨줍니다.

Vercel & Firebase 연동의 핵심

고유 도메인이 있으면 비로소 전문적인 설정이 가능해집니다.

• Vercel/Firebase 연결: 제공받은 CNAME 레코드를 Cloudflare DNS 설정에 입력하기만 하면 끝납니다.
• 외부 서비스 연동: Resend 같은 서비스에서 요구하는 TXT 레코드를 직접 등록할 수 있어, 내 도메인 이름으로 이메일을 보내는 '진짜 서비스' 운영이 가능해집니다.

한눈에 비교하기

마치며: 어떤 선택이 좋을까?

결국 '어디까지 제어하고 싶은가'의 문제입니다.

단순히 집 프로젝트를 밖에서 보고 싶다면 DDNS로 시작하세요. 하지만 Vercel이나 Firebase에 배포한 내 작품에 날개를 달아주고, Resend 같은 전문 API 서비스까지 붙여보고 싶다면 망설이지 말고 Cloudflare에서 도메인을 하나 마련하시길 추천합니다.

커피 두세 잔 정도의 연간 비용으로, 여러분 서비스의 신뢰도가 완전히 달라질 테니까요!

n8n은 https://n8n.io/ 에서 가입하면 일정 기간 무료로 사용할 수 있습니다. 하지만, 시간 제약이 있으니 고급 사용자들은 자신의 컴퓨팅 환경에 설치해서 사용합니다. 여기서는 Linux가 설치된 Mini PC에 설정하는 그 내용에 대해서 정리 합니다.

1. 사전 준비 (Prerequisites)

설치를 시작하기 전, Mini PC에 다음 요소들이 준비되어 있어야 합니다.

• OS: Ubuntu 22.04 LTS 또는 데비안 계열 리눅스 권장 (Windows/macOS도 가능)
• 사양: CPU 2코어, RAM 4GB 이상 권장
• Docker 설치: 도커와 도커 컴포즈(Docker Compose)가 설치되어 있어야 합니다.

2. Docker Compose를 이용한 설치 단계

Docker Compose를 사용하면 n8n 설정뿐만 아니라, 데이터를 저장할 데이터베이스까지 한 번에 관리할 수 있습니다.

단계 1: 작업 디렉토리 생성

터미널을 열고 n8n 설정 파일을 저장할 폴더를 만듭니다.

mkdir n8n-local && cd n8n-local

단계 2: docker-compose.yml 파일 작성

텍스트 에디터(nano 또는 vi)를 사용하여 설정 파일을 만듭니다.

nano docker-compose.yml

아래 내용을 복사해서 붙여넣으세요:

version: "3"
services:
  n8n:
    container_name: n8n-server
    # ... 기존 설정 ...
    image: n8nio/n8n:latest
    restart: always
    ports:
      - "5678:5678"
    environment:
      - N8N_HOST=my-n8n.duckdns.org
      - N8N_PORT=5678
      - N8N_PROTOCOL=https
      - N8N_EDITOR_BASE_URL=https://my-n8n.duckdns.org
      - WEBHOOK_URL=https://my-n8n.duckdns.org
      - N8N_PROXY_HOPS=1
      - NODE_ENV=production
      - GENERIC_TIMEZONE=Asia/Seoul
      - N8N_SECURE_COOKIE=false # (외부 https로만 쓸 거면 최종적으로 true 권장)
    volumes:
      - ~/.n8n:/home/node/.n8n

단계 3: 컨테이너 실행

설정을 마쳤다면 다음 명령어로 n8n을 실행합니다.

docker compose up -d

이 명령어는 백그라운드에서 n8n을 실행하며, 필요한 이미지를 자동으로 다운로드합니다.

3. n8n 접속 및 초기 설정

1. Mini PC의 브라우저(또는 같은 네트워크의 다른 PC)에서 다음 주소로 접속합니다.
   • http://localhost:5678 (Mini PC 본체인 경우)
   • http://[Mini-PC-IP주소]:5678 (외부 기기인 경우)
2. 처음 접속 시 관리자 계정(이메일 및 비밀번호)을 생성하는 화면이 나옵니다.
3. 계정 생성 후 n8n 대시보드에 진입하면 설치가 완료됩니다!

4. 외부 접속을 위한 도메인 연결(SSL 설정)

외부 연결은 여기서는 상세히 다루지는 않습니다. 단지, 필요한 설정 내용만 언급합니다.

• Wireless AP에서 https를 위한 Port Forwarding 설정
• DDNS를 설정 (e.g. duckdns)
• Nginx Proxy Manager에 Domain 이름, SSL 그리고 내부 서비스 연결 설정

마무리 하며

같은 도메인명에 Custom Location으로 설정하는데 반나절 정도를 사용했었다. 주요 이슈는 2가지였습니다.

하나는 custom location에 n8n 명을 추가하면 인식이 되지 않는 것이었습니다. docker-compose.yml에 이 내용을 추가하는 것으로 local 테스트를 했지만, 성공하지 못하고 동작하지 않는 것을 확인하는 수준이었습니다. rewrite하는 방법으로 n8n 명을 추가하는 것까지는 성공하였다. 하지만 다른 문제가 있었습니다.

두 번째는 Supabase의 KONG과 충돌 난다는 것이었습니다. local에서 동작하는 부분을 확인하고 ChatGPT와 curl 명령을 이용해서 접근하는 방법을 디버깅했습니다. 이 때, Supabase와 KONG과 충돌을 파악하고 도메인을 분리 접근하는 방법으로 해결하였습니다.

최근 회사로부터 AI 토큰 사용량 경고 메시지를 받았다. 2월부터 비용 모니터링이 강화된 모양인데, 내 사용량이 사용자 월평균의 약 4배에 달한다는 내용이었다. 과거 다른 도구를 사용할 때도 누군가에게 내가 사용량 순위권에 있다는 이야기를 들은 적이 있으니, AI 도구를 적극적으로 활용하는 내 습관이 수치로 드러난 셈이다.

기업 입장에서 비용 관리를 고민하지 않을 수는 없을 것이다. 하지만 문득 의문이 든다. 과연 AI 사용량을 물리적으로 잠가 두는 것이 최선일까?

1. 토큰 사용량은 '성과'의 비례 지표다

토큰을 많이 사용한다는 것은 그만큼 AI와 치열하게 대화하며 문제를 풀고 있다는 증거다. 요즘 회자되는 '10x, 100x 개발자'는 단순히 타이핑이 빠른 사람이 아니다. 예전 같으면 복잡한 라이브러리를 학습하거나, 누군가의 도움을 기다리며 정체되었을 시간을 AI를 통해 돌파하는 사람들이다.

어렵고 복잡한 설계를 빠른 시간 내에 시뮬레이션하고, 개발자가 아닌 기획자나 운영자도 자신에게 필요한 도구를 척척 만들어내는 모습은 이제 주변에서 흔히 볼 수 있다. 즉, 많이 쓰는 만큼 더 빠르고 바쁘게 가치를 만들어내고 있을 가능성이 높다.

2. 바둑이 보여준 AI 리터러시의 격차

AI 도입 이후, 이를 활용하는 사람과 그렇지 못한 사람의 격차는 단순한 실력 차이를 넘어 '종의 분화' 수준으로 벌어지고 있다. 바둑의 사례가 이를 극명하게 보여준다. AI를 훈련에 적극적으로 활용하는 기사와 그렇지 않은 기사의 간극은 이미 돌이킬 수 없는 수준이라고 한다.

인재를 키우고 조직의 성장을 고민하는 입장이라면, 오히려 AI 활용을 적극적으로 독려해야 한다. 토큰 제한은 당장의 지출을 줄여줄지 모르지만, 장기적으로는 구성원들이 'AI 협업 지능'을 단련할 기회를 박탈하는 제약이 될 수 있다.

3. 기술의 역사는 '비용 하락'의 역사다

기술이 발전할수록 그 기술을 사용하는 비용은 반드시 낮아진다. 하드디스크 용량 당 가격, 무선 데이터 통신 비용의 변화를 돌이켜보라. AI 토큰 비용 역시 조만간 지금과는 비교할 수 없을 정도로 저렴해질 것이라는 게 중론이다.

미래의 관점에서 본다면, 지금 이 과도기적 시점에 개인의 활동량을 타이트하게 관리하는 것이 조직 전체의 미래 경쟁력보다 중요한 가치인지 고민해 볼 시점이다.

나가며: 나는 어디에 서 있을 것인가?

회사의 제약 속에서도 나는 나만의 방식을 찾기로 했다. 개인적으로 Claude Code MAX를 다시 결제해 사용하기 시작했고, 회사 시스템 안에서도 제약에 적응하며 최대한 효율을 뽑아낼 방법을 찾을 것이다. 지금 나는 내가 믿는 미래의 확률에 내가 가진 리소스를 투자하기로 한 셈이다.

작년 한 해의 변화 속도로 볼 때, 올해 상반기만 지나도 흥미로운 변화들이 쏟아질 것이다. 그 변화의 양과 속도가 무지막지하다 해도 과언이 아닐 것이다. 그 때, 우리가 어디에 서 있을지 궁금해지는 시간이다.

OpenClaw(과거 ClawdBot, MoltBot으로 불림)를 Windows에서 설정하는 가장 안정적인 방법은 WSL2(Windows Subsystem for Linux)를 사용하는 것입니다.

공식 문서와 커뮤니티에서는 Windows 네이티브(PowerShell) 설치도 지원하지만, 파일 시스템 성능과 도구 호환성 문제로 인해 WSL2 기반의 Ubuntu 환경에서 실행하는 것을 강력히 권장하고 있습니다.

사전 준비 (Prerequisites)

설치 전 아래 항목이 준비되어 있어야 합니다.

• WSL2 및 Ubuntu: Windows 10(버전 2004 이상) 또는 Windows 11.
• Node.js 22 이상: OpenClaw는 최신 Node.js 환경에서 작동합니다.
• Git 및 빌드 툴: 소스 관리 및 설치 스크립트 실행을 위해 필요합니다.

WSL2(Ubuntu) 환경에서 openclaw 설치 중 발생하는 이 오류는 주로 Node.js 버전 불일치나 권한 문제, 혹은 의존성 라이브러리(sharp 등)의 빌드 실패로 인해 발생합니다.

WSL 2 설치 단계별 절차:

1. 관리자 권한으로 터미널 실행: 윈도우 키를 누르고 'PowerShell' 또는 'cmd'를 검색하여 '관리자 권한으로 실행'을 클릭합니다.
2. 설치 명령어 입력: wsl --install -d Ubuntu-24.04을 입력하고 엔터를 칩니다.
   • 이 명령은 필요한 필수 구성 요소(가상 머신 플랫폼 등)를 활성화하고 최신 리눅스 커널을 설치합니다.
3. 컴퓨터 재부팅: 설치가 완료되면 컴퓨터를 다시 시작하여 설정을 완료합니다.
4. 리눅스 설정: 재부팅 후 자동으로 열리는 우분투(Ubuntu) 창에서 사용자 이름(Username)과 비밀번호(Password)를 설정하면 설치가 완료됩니다.

Node.js 버전 확인 및 업데이트 (가장 중요)

OpenClaw 최신 버전은 보통 Node.js 18 이상(LTS 권장)을 요구합니다. Ubuntu 기본 저장소의 Node 버전은 낮을 수 있으므로 확인이 필요합니다.

업데이트 방법 (nvm 사용 권장):

• curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash
• source ~/.bashrc
• nvm install --lts
• nvm use --lts

아래 명령으로 버전을 확인합니다.

• 버전 확인: node -v

빌드 필수 도구 설치

npm install 과정에서 네이티브 모듈을 컴파일해야 할 때 git, python, make, g++ 등이 필요합니다.

sudo apt update
sudo apt install -y git cmake build-essential libvips-dev libvulkan-dev

OpenClaw 설치

이제 요구 사양을 충족했으므로 설치를 진행합니다. 아래 명령을 사용하는 것이 설치 및 설정 절차를 가이드 하므로 좋습니다.

curl -fsSL https://openclaw.ai/install.sh | bash

다음 절차에 따라 설정합니다.

1단계: 보안 경고 확인

◆ I understand this is personal-by-default and shared/multi-user use requires lock-down. Continue?
  ○ Yes / ● No

→ Yes 선택

설명: OpenClaw은 개인용(1인 사용) 기본 설정입니다. 개인 PC에서 혼자 쓸 거니까 Yes를 선택합니다..

2단계: 온보딩 모드

Onboarding mode
  ● QuickStart
  ○ Manual

→ QuickStart 선택

설명: 기본 설정으로 빠르게 설정합니다. 세부 설정은 나중에 openclaw configure로 변경 가능합니다. Manual은 항목별 직접 선택이라 비숙련자에게 불필요합니다.

3단계: 모델/인증 선택

Model/auth provider
  ● OpenAI (Codex OAuth + API key)
  ○ Anthropic
  ...

→ OpenAI 선택 (GPT/ChatGPT 사용자인 경우)

설명: ChatGPT의 계정을 통해서 사용할 수 있습니다. 다른 경우, api key를 넣어야 할 수 있습니다.

4단계: 채널 선택

Select channel (QuickStart)
  ● Telegram (Bot API) (recommended · newcomer-friendly)
  ...

→ Telegram 선택

설명: OpenClaw이 연결될 메신저로, Telegram이 비숙련자에게 가장 간단하다.

5단계: 텔레그램 봇 토큰 생성 (가장 많이 막히는 단계)

온보딩에서 토큰을 요구합니다:

구체적 절차:

1. 텔레그램 앱 열기 (스마트폰 또는 데스크톱)
2. 상단 검색바에서 @BotFather 검색
3. BotFather와 대화 시작
4. /newbot 입력
5. 봇 이름 입력 (표시 이름, 아무거나 가능. 예: "내 AI 봇")
6. 봇 사용자명 입력 (고유해야 함, _bot으로 끝나야 함. 예: jaeyoung_test_bot)
7. 토큰이 나온다: 123456:ABC-DEF... 형태
8. 이 화면을 캡처해두기 — 토큰과 봇 사용자명이 모두 나옴
9. 토큰을 터미널 온보딩 화면에 붙여넣기

비숙련자 주의사항:

• BotFather는 봇을 만드는 곳이지, 만든 봇과 대화하는 곳이 아님
• 봇 사용자명은 전 세계에서 유일해야 하므로 이미 사용 중이면 다른 이름 시도
• 토큰은 비밀번호와 같으므로 공유하지 않기

6단계: 스킬 설치

◆ Install missing skill dependencies
  ◻ Skip for now
  ◻ 📝 apple-notes
  ...

→ Skip for now 선택

설명: 추가 기능(노트 연동, 이메일 등)인데 초기 설치에는 불필요합니다. 나중에 openclaw configure로 개별 추가 가능합니다. 선택지가 40개 넘어서 비숙련자에게 혼란을 줄 수 있으니 스킵이 최선입니다.

7단계: API 키 설정 (전부 No)

◆ Set GOOGLE_PLACES_API_KEY for goplaces? → No
◆ Set NOTION_API_KEY for notion? → No

→ 나오는 API 키 질문은 모두 No

설명: 외부 서비스 연동용 API 키입니다. 기본 사용에는 불필요합니다.

8단계: Hooks 설정

◆ Enable hooks?
  ◻ Skip for now
  ...

→ Skip for now 선택

설명: 자동화 기능으로 초기 설치에서는 불필요합니다.

9단계: 설치 완료 + Health Check

설치가 끝나면 대시보드 URL이 표시됩니다:

Dashboard link: http://127.0.0.1:18789/#token=...

Health check 실패가 나올 수 있습니다:

Health check failed: gateway closed (1006 abnormal closure)

→ 당황하지 말 것. 게이트웨이가 아직 기동 중일 수 있습니다. 잠시 후 확인합니다:

openclaw status

Gateway 항목에 reachable이 보이면 정상입니다.

Telegram Pairing

OpenClaw에서 Channel을 Telegram으로 설정해 두고, Bot과 대화창을 열어 대화를 합니다. 아래와 유사한 메시지가 나오는데, wsl 창에 Paring을 해야 최종 마무리가 됩니다.

OpenClaw: access not configured.

Your Telegram user id: XXXXXXXXXX

Pairing code: ABCDEFGH

Ask the bot owner to approve with:
openclaw pairing approve telegram ABCDEFGH

현재 OpenClaw가 설치된 WSL2(Ubuntu) 터미널로 돌아가서 아래 명령어를 그대로 복사하여 입력하세요.

openclaw pairing approve telegram ABCDEFGH

대화를 시작하면, 여러 분의 AI 비서가 응답하기 시작합니다.

OpenClaw 설정

설치가 되고, 설정을 하는 도중 문제가 많이 있을 수 있습니다. 이 때에는 설정만 다시 해도 괜찮은 경우가 많습니다.

아래 명령을 통해서 다양한 설정을 할 수 있습니다. 최소한은 LLM 설정(Model)과 통신(Channels) 만 살펴 보면 기본 동작이 가능합니다.

openclaw configure

특정 설정만 하는 방법도 가능합니다. LLM API 연결 하는 방법은 다음 명령을 통해 할 수 있습니다. 다양한 LLM과 연계가 가능합니다. 버전마다 변화가 있지만, ChatGPT의 경우는 로그인으로도 가능하고, Gemini는 api key로 연계가 가능합니다.

openclaw configure --section model

리부팅시 서비스 자동 활성화

여러 분의 Windows PC에 Node.js 기반 서비스를 관리하는 PM2를 설치해 두시면 매우 편리합니다. 서비스가 죽으면 자동으로 살려주기도 합니다.

# PM2 설치
npm install -g pm2

# OpenClaw를 PM2로 실행
pm2 start openclaw --name "openclaw-agent"

# 부팅 시 자동 시작 설정
pm2 save

pm2를 이용해서 실행하는 스크립트를 만듭니다. 터미널에서 아래 단계들을 순서대로 따라하시면 됩니다.

wsl 화면에서 스크립트 파일 생성 하기 입니다. cat 명령어를 사용하면 복사 붙여넣기로 파일 내용을 한 번에 입력할 수 있어 편리합니다.

cat << 'EOF' > start_openclaw.sh
#!/bin/bash
# nvm 환경 로드 (nvm 경로가 다를 수 있으니 확인 필요)
export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"
# PM2로 저장된 리스트 복구
pm2 resurrect
EOF

역시, wsl 화면에서 추가한 파일에 실행 권한 추가 하기입니다. 파일을 실행할 수 있도록 권한을 수정합니다.

chmod +x start_openclaw.sh

스크립트 실행 확인해봅시다. 이제 아래 명령어로 스크립트가 정상적으로 작동하는지 테스트해 보세요.

./start_openclaw.sh

Windows가 부팅될 때 WSL2를 백그라운드에서 살짝 건드려 PM2를 깨우는 스케줄러를 등록해야 합니다.

1. Windows 키 + R을 누르고 taskschd.msc를 입력하여 작업 스케줄러를 엽니다.
2. 오른쪽 "기본 작업 만들기..." 를 클릭합니다.
   • 이름: WSL PM2 AutoStart (원하시는 이름)
   • 트리거: 컴퓨터 시작 시
   • 동작: 프로그램 시작
3. 프로그램/스크립트 칸에 아래 내용을 입력합니다.
   • wsl
4. 인수 추가(옵션) 칸에 아래 명령어를 그대로 복사해서 넣습니다.
   • -e bash -c "/home/blckt/start_openclaw.sh"
5. "마침을 클릭할 때 이 작업의 속성 대화 상자 열기"를 활성화 하고 마침을 엽니다. 여기서 일반 탭에서 "사용자의 로그온 여부에 관계 없어 실행"을 활성화 하고 조건 탭에서 "컴퓨터의 AC 전원이 켜져 있는 경우에만 작업 시작" 선택을 비활성화 합니다. 이렇게 해야 조건 없이 실행이 됩니다.

마치며

이번 설정을 진행하며 가장 크게 다가온 장점은 ‘장소의 제약이 사라진 AI 컴퓨팅 리소스의 활용’이었습니다.

단순히 클라우드 AI를 쓰는 것을 넘어, 집에서 24시간 깨어 있는 내 PC의 강력한 성능과 내부 데이터를 외부에서도 마치 곁에 있는 것처럼 자유롭게 꺼내 쓸 수 있다는 점이 정말 매력적입니다. 복잡한 네트워크나 원격 설정을 거쳐 구축한 이 환경은, 단순한 소프트웨어 설치가 아니라 어디서든 연결 가능한 '나만의 AI 기지'를 세우는 과정과 같습니다.

내 컴퓨팅 환경이 상시 대기하며 나를 보조한다는 든든함, 이것이야말로 우리가 지향하는 진정한 Personal AI Computing에 한 걸음 더 다가선 모습이 아닐까 싶습니다. 여러분도 이 설정을 통해 공간의 한계를 넘어선 스마트한 워크플로우를 꼭 구축해 보시길 바랍니다.

최근 EBS에서 방영된 신진서 9단의 다큐멘터리[1]를 보며 전율을 느꼈습니다. 인공지능(AI)이 인간을 압도한 첫 번째 영역인 '바둑'에서 일어난 변화들이, 현재 제가 고민하고 있는 소프트웨어 아키텍처와 개발 환경의 미래를 그대로 예고하고 있었기 때문입니다.

1. 바둑계가 던진 4가지 묵직한 시사점

AI가 일상이 된 바둑계의 모습은 우리에게 네 가지 핵심 질문을 던집니다.

• 상향 평준화가 아닌 격차의 심화: 도구가 평등해졌다고 실력이 평등해지지는 않습니다. AI를 깊이 이해하고 레버리지로 삼는 상위 1%는 이전보다 훨씬 더 빠르게 앞서 나갑니다.
• 기풍(개성)과 정답 사이의 갈등: 정답지(AI 추천 수)가 명확해질수록 인간 고유의 스타일은 희미해집니다. 효율성 앞에서 '인간적인 선택'의 가치를 어떻게 지킬 것인가가 숙제가 되었습니다.
• 스승의 역할 변화: 이제 지식 전수자로서의 스승은 힘을 잃었습니다. AI라는 정답지를 어떻게 해석하고 삶에 적용할지 가이드하는 '코치'의 시대가 왔습니다.
• 신뢰와 증명의 문제: AI 일치율로 치팅을 잡아내는 풍경은, 앞으로 우리가 만든 결과물이 '인간의 의도'인지 '기계의 생성물'인지 증명해야 하는 시대가 올 것임을 보여줍니다.

2. 바둑판과 코드: 놀랍도록 닮은 상황

바둑은 모두 '무한한 경우의 수'를 다루는 전문 영역입니다. 소프트웨어 개발도 많은 전문성을 요구 하는 바둑과 비슷한 분야입니다. 요즘 사용자가 소프트웨어 개발이 Agentic Coding툴에게 "그냥 알아서 진행해 줘" 라고 말해도 원하는 기능이 뚝딱하고 만들어지는 상황이 되었습니다.

알파고 이전의 한국, 중국, 일본에서만 인기 있었다고 하면 도리어 알파고 이 후에는 인기가 사그러지지 않고 세계적으로 관심이 많아 졌다고 합니다. 그리고, 비디오에서 조훈현 9단의 말 처럼 바둑을 예전에는 기사마다 다른 기풍이 있는 '인생의 철학이 담긴 예술'로 보았던 것이, AI가 모든 수에 승률(%)을 매기면서, 이제 바둑은 철저히 '승률 최적화 스포츠' 가 되었습니다.

많은 전문성을 요구하는 곳들이 변화가 급격하게 일어 날 것이라 보이고 기존과 다른 가치관이 자리 잡게 될 것이라 보여 집니다. 최근에 회계사들에 대한 이야기도 들었습니다. 합격하는 신규 합격자는 여전히 많지만, 자격을 유지하기 위한 인턴 기간을 가질 수 있는 기회가 많이 줄었다고 하더군요. 이는 바둑계에서 '기원'이라는 오프라인 학습 공간이 사라지고, 주니어 기사들이 사범님에게 직접 배우는 '도제식 교육'이 붕괴된 상황과도 일치합니다.

3. Architect와 Coach의 관점에서 본 대응 전략

우리는 단순히 AI를 사용하는 사용자를 넘어, 시스템을 설계하는 아키텍트이자 성장을 돕는 코치로서 다음 두 지점을 치열하게 고민해야 합니다.

■ Architect: AI가 만든 구조를 통제하는 '가드레일'

바둑을 두는 AI는 어떻게 하면 승률을 높이는지 보여 주지만, 설명은 하지 않습니다. 소프트웨어를 도와주는 AI도 'How(구현)'는 잘하지만 'Why(맥락)'는 모릅니다. 기존의 Prompt Engineering에서 Context Engineering이 강조되는 이유도 이 부분일 수 있겠습니다. 우리는 AI가 뱉어내는 파편화된 코드들이 Living PRD(살아있는 요구사항 정의서) 와 Generative Sequence(생성적 시퀀스) 와 같은 우리가 가진 원칙을 벗어나지 않도록 '의도의 가드레일'을 설계해야 합니다.

■ Coach: 학습 피드백 루프를 통한 '동반 성장'

가장 중요한 것은 AI가 만든 결과물을 단순히 수용하는 것이 아니라 '학습 피드백 루프' 로 만드는 것입니다.

• 복기(Retrospective)의 자동화: 신진서 9단이 대국 후 AI와 복기하며 자신의 오판을 바로잡듯, 개발 환경에서도 AI가 제안한 코드의 아키텍처 결정 이유(Decision Log)를 사람이 검토하고 피드백하는 프로세스가 필수적입니다.
• 지능적 파트너십: 사용자가 "진행해 줘"라고 할 때, 시스템이 "이 부분은 기존 설계와 충돌할 수 있습니다. 어떤 방향을 선택하시겠습니까?"라고 질문하게 함으로써 사용자의 판단력을 계속 자극하고 성장시켜야 합니다.

마치며: 개발 공장의 진정한 가치

제가 구축 중인 'AI Software Development Factory(Beads + Gastown 기반)'의 진정한 목적은 단순한 자동화가 아닙니다.

사용자의 모호한 의도를 고품질의 아키텍처로 정제하고, 그 과정에서 인간 개발자가 AI를 스승 삼아 더 높은 차원의 아키텍트로 성장하는 '공존의 훈련장' 을 만드는 것입니다. 신진서 9단이 AI를 '동행자'라 부르듯, 우리도 AI를 통해 더 나은 아키텍처의 길로 나아갈 수 있기를 기대합니다.

참고링크

[1] https://www.youtube.com/watch?v=UU8OjKQohVY&t=1593shttps://www.youtube.com/watch?v=UU8OjKQohVY&t=1593s

익숙함의 안락함, 그리고 새로운 도전 개발 초기부터 제 메인 환경은 늘 Windows였습니다. 모바일 빌드 환경이 윈도우 기반인 경우가 많았고, 그 익숙함에 안주해왔죠. 대학원 시절 Linux 과제를 수행하고 Solaris System Admin을 경험하며 Unix/Linux가 낯설지는 않았지만, 늘 '서브'에 머물렀기에 배움은 더뎠고 익숙해질 만하면 잊어버리곤 했습니다. Mac은 그저 동료의 화면을 잠시 보거나 테스트용 구형 인텔 맥을 만져본 것이 전부였죠.

AI 시대, Linux가 메인이 될 수 있다는 확신 최근 AI 기술을 깊이 파고들면서 깨달았습니다. 이제 특수한 윈도우 전용 작업을 제외한 대부분의 개발 워크플로우가 Linux에서 더 효율적으로 돌아간다는 사실을요. 새로 산 노트북의 리눅스 설정이 불안정해, 결국 기존에 쓰던 노트북에 과감히 Ubuntu를 설치하고 하루 만에 다음의 세팅을 마쳤습니다.

• 시스템 최적화: Ubuntu 설치 및 nVidia 그래픽 드라이버 설정

• AI 개발 환경: Claude Code, Codex, Gemini CLI (with Node.js, NVM)

• 차세대 도구: Antigravity IDE, Beads, Gastown (with Go)

• 생산성 워크플로우: OneDrive 연동, Obsidian, Discord 설치

도구가 바뀌니 두려움이 사라졌습니다 오는 월요일에는 Mac Mini M2를 새로 들여올 예정입니다. 아마 오늘 했던 설정들을 똑같이 반복하게 되겠지요. 예전 같았으면 이 환경을 구축하는 데만 며칠, 혹은 몇 달이 걸릴까 봐 지레 겁부터 먹었을 텐데, 이제는 전혀 두렵지 않습니다.

제 곁에는 복잡한 설정을 순식간에 가이드해 주는 강력한 AI 에이전트들이 있으니까요. OS라는 벽이 무너지고, 오직 '무엇을 만들 것인가'에만 집중할 수 있는 시대가 왔음을 실감합니다.

3개월 전, AI로 내 문제 풀기라는 이름으로 AI라는 도구를 손에 쥔 비개발자 세 분과 함께 'AI로 직접 도구 만들기' 학습 시간을 가졌습니다. (이전 포스팅: AI로 내 문제 풀기-비개발자와 개발자가 함께 문제를 탐구한 실험)

당시에는 "과연 코딩을 모르는 분들이 AI의 도움만으로 실질적인 결과물을 낼 수 있을까?"라는 기대반 걱정반의 마음이었습니다. 그런데 최근, 그분들로부터 도착한 메시지들은 저를 깜짝 놀라게 했습니다. 단순히 '배웠다'는 수준을 넘어, 자신의 업무 현장에서 실제로 작동하는 'Product'를 만들어내고 계셨기 때문입니다.

메신저를 통해 공유된 세 분의 놀라운 근황을 정리해 봅니다.

1. 반적적인 업무를 자동화로 끊어내다: 이기림 님의 피그마 플러그인

PM 혹은 디자이너에게 가장 번거로운 작업 중 하나는 디자인 시안 속의 텍스트를 추출하고, 이를 다국어로 치환하며, 개발 환경에 맞는 'String Key'를 정의하는 일입니다.

기림 님은 AI를 활용해 이 과정을 한 번에 해결하는 피그마(Figma) 플러그인을 직접 만드셨습니다.

• 주요 기능: 텍스트 추출 → 15개국 언어 번역 → String Key 제안
• 의미: "도구가 없어서 불편해"라고 말하는 대신, "불편하니까 내가 도구를 만든다"는 메이커(Maker)의 마인드셋을 완벽히 보여주셨습니다.

2. 나만의 최적화된 개발 환경을 구축하다: 고경만 님의 CLI 연동 도구

경만 님은 이제 단순한 사용자를 넘어 '파워 유저'의 단계로 진입하셨습니다. 최근 핫한 에디터인 Zed를 중심으로 자신의 작업 환경을 재편하시면서, AI 코딩 도구인 Codex CLI와 에디터를 긴밀하게 이어주는 브릿지 도구를 직접 개발하셨습니다.

• 주요 기능: Zed 에디터와 Codex CLI의 유기적 연동 및 자동화
• 의미: 비개발자가 GitHub에 자신의 레포지토리를 만들고 코드를 관리하며, 본인만의 커스텀 워크플로우를 설계했다는 점이 정말 놀랍습니다. (GitHub: xsfire-camp)

3. 아이디어를 비즈니스 모델로 실체화하다: 김기은 님의 'GIZI Studio'

가장 확장성 있는 성과를 보여주신 기은 님은 아예 도메인을 사고 서비스를 런칭하셨습니다. 영상 제작 현장의 고질적인 문제인 '협업'을 쉽고 빠르게 하는 플랫폼입니다.

• 주요 기능: 유튜브 영상 및 SRT 자막 기반 피드백 수집 워크스페이스
• 의미: 단순히 코드를 짠 것이 아니라, 실제 타겟 사용자인 '영상인'들과 모임을 가지며 제품을 고도화하고 계십니다. AI를 통해 아이디어에서 런칭까지의 리드타임(Lead Time)을 극단적으로 줄인 사례입니다. (GIZI Studio Feedback)

"경계가 무너지고 있다"

이번 사례들을 보며 저는 확신했습니다. 이제 개발 역량은 '지식의 영역'에서 '의지의 영역'으로 옮겨가고 있습니다.

1. 도메인 지식의 승리: 세 분 모두 본인의 전문 분야(디자인, 영상, 기획)에서 가장 가려운 부분을 정확히 짚어내셨습니다. AI는 그 가려운 곳을 긁어줄 '손'이 되어주었을 뿐입니다.
2. AI는 지렛대다: 코딩 문법을 외우는 시간 대신 "무엇을 만들 것인가"에 집중할 때, AI는 그 실행력을 수십 배 증폭시켜 줍니다.
3. 꾸준함의 힘: 3개월이라는 시간 동안 포기하지 않고 각자의 프로젝트를 '내 것'으로 만들어가는 과정이 가장 큰 감동이었습니다.

처음 시작할 때 복잡계 3인방이 드렸던 작은 가이드가 이렇게 멋진 열매를 맺어 정말 뿌듯합니다. 앞으로 이분들이 써 내려갈 'AI 기반의 문제 해결기'가 더욱 기대됩니다.

1. 결핍의 심리학: "Scarcity"라는 렌즈

행동경제학자 센딜 멀레이너선(Sendhil Mullainathan)과 심리학자 엘다 샤피르(Eldar Shafir)의 공저 "왜 부족할 수록 마음은 더 끌리는가" (Scarcity)는 우리가 “부족한 상태에 놓일 때” 사고와 행동이 어떻게 변화하는지를 정밀하게 탐구한 책이다. 이 책은 단순한 경제학 서적이 아니다.

결핍은 물리적인 상태가 아니라 인지적 왜곡을 일으키는 강력한 심리적 상태이며, 이 왜곡은 일관되게 재현 가능한 패턴을 갖는다.

시간, 돈, 관심, 사회적 연결 중 하나라도 결핍되면 우리의 행동은 예측 가능한 방향으로 왜곡된다. 이 책의 중심 질문은 이것이다:

"왜 부족할수록 우리는 더 집중하지만, 더 나쁜 선택을 하게 되는가?"

2. Bandwidth란?

Scarcity의 핵심 개념 중 하나는 ‘대역폭(Bandwidth)’이다. 이 개념은 기술적 용어에서 빌려왔지만, 인간의 인지 시스템에 맞게 재해석된다.

대역폭이란?

• 주의력 (Attention)
• 작업 기억 (Working Memory)
• 자기 통제력 (Self-control)

이 세 가지는 우리가 일상에서 ‘잘 결정하고 행동할 수 있도록’ 도와주는 인지 자원이며, 총량이 한정돼 있다. 마치 하루치 배터리처럼, 여러 과업이 몰릴수록 빠르게 고갈된다.

그리고 결핍 상태에 빠지면 이 대역폭이 특정 문제(예: 당장의 돈 문제)에 ‘과하게 집중’되면서 다른 모든 것이 희생된다.

3. 터널 시야(Tunneling): 결핍이 만드는 좁은 집중

결핍은 인간의 인지 시스템에 터널 시야(tunneling) 를 유발한다. 즉, 다른 모든 걸 배제하고 오직 하나에만 초집중하게 만든다.

이 현상은 이중적이다:

• 단점: 단기적, 충동적인 선택을 유도한다. 예: 고금리 대출, 건강 무시, 미래 준비 미루기
• 장점: 집중을 만들어낸다. 예: 극한의 마감 상황에서의 생산성 폭발

이 딜레마는 결국 ‘결핍이 인지 자원의 배분 방식’을 변화시킨다는 점에서 리소스 스케줄링의 문제로도 볼 수 있다.

4. 대역폭을 지키는 방법

책에서는 결핍의 인지적 영향에 대한 해결책도 제시한다. 요지는 ‘여유 공간(Slack)’을 확보하라는 것이다.

주요 전략:

1. 슬랙(Slack): 여유 자원 확보 (시간, 돈, 감정적 여유)
2. 자동화: 반복 결정 제거 (예: 자동 저축, 루틴화)
3. 인지적 설계: 환경 조정으로 잘못된 선택 줄이기 (예: 유혹 피하기, 선택지 단순화)
4. 리마인더 & 점검 루틴: 현재 상황에서 빠져나와 메타인지 유지

그러나 여기에서 질문이 하나 떠오른다.

“이러한 대역폭의 회복과 유지에 AI를 어떻게 활용할 수 있을까?”

5. AI 시대에 대역폭을 바라보는 관점

우리는 지금 AI와 함께 일하는 시대에 살고 있다. ChatGPT, Claude, Gemini 같은 도구들은 단순 자동화를 넘어서 인지적 보조자(Cognitive Assistant) 로 진화하고 있다.

그렇다면 AI는 결핍 상태에서 인간의 대역폭을 어떻게 도와줄 수 있을까?

① 증폭기 (Amplifier)

• 정보 요약, 대안 탐색, 일정 정리 등에서 주의력과 작업 기억을 보완
• 집중할 주제를 좁혀주거나, 반대로 시야를 넓혀주는 가이드 역할

② 지킴이 (Guardian)

• 결정을 덜 하도록 도와주고, 유혹에서 벗어날 수 있도록 환경을 설계
• 예: 자동화된 리마인더, ‘이건 지금 하지 않아도 됩니다’라는 조언

③ 동반자 (Dialogic Partner)

• 감정적/인지적 메타인지를 일깨워주는 대화형 파트너
• “왜 이 선택을 하려고 하시나요?” 같은 질문으로 터널 시야에서 탈출 가능

6. 결론: 우리가 어떤 선택을 하느냐보다, 어떤 대역폭 상태에서 하느냐가 중요하다

"왜 부족할 수록 마음은 더 끌리는가"는 결핍 상태에 놓인 인간이 얼마나 예측 가능하게 인지적 오류를 범하는지를 보여준다. 흥미로운 것은, 이 오류가 개인의 ‘능력 부족’ 때문이 아니라, 리소스(대역폭)의 부족에서 기인한다는 점이다. 이는 개인뿐 아니라 팀, 조직, 사회 전체에 적용된다. 팀의 협업 실패, 개인의 번아웃, 정책 실패의 이면에는 항상 '터널 시야'에 갇힌 결정 구조가 있다.

이제 우리는 AI와 함께 일하는 시대에 살고 있다. 그래서 두 가지 질문이 중요해진다:

• AI는 인간의 인지적 웰빙을 위한 설계 도구가 될 수 있을까?
  단순히 생산성을 높이는 것을 넘어서, 결핍 상태에서 인지적 여유와 선택 가능성을 회복시켜줄 수 있을까?
• 우리는 ‘대역폭 중심 UX’를 설계하고 있는가?
  사용자에게 기능을 더 많이 주는 것보다, 무엇을 ‘덜 하게 만들 것인가’를 중심에 둘 수 있을까?

이 글의 마지막 문장은 질문으로 남기고 싶다.

"AI는 우리에게 더 많은 것을 하게 해줄까? 아니면 덜 잘못되게 도와줄까?"

그 사이 어딘가에 진정한 대역폭의 회복이 있을지도 모른다.

AI로 PoC를 많이 하다 보면, 여러 Cloud 기능을 쓰게 되는데 요즘은 Supabase와 Vecel을 많이 쓰게 되는 것 같다. Supabase는 개발자가 백엔드 인프라를 직접 구축하는 수고를 덜어주는 오픈소스 서비스형 백엔드(Backend as a Service, BaaS) 플랫폼이다. 'Firebase의 오픈소스 대안'으로 불리며, 다음과 같은 핵심 기능을 제공한다

• Database (PostgreSQL): 모든 프로젝트에는 전용 PostgreSQL 데이터베이스가 제공되며, SQL을 직접 작성하거나 편리한 대시보드를 통해 데이터를 관리할 수 있습니다.
• Authentication: 이메일, 비밀번호 기반 로그인뿐만 아니라 Google, GitHub 등을 이용한 소셜 로그인(OAuth) 기능을 쉽게 연동할 수 있습니다.
• Storage: 이미지, 비디오, 문서와 같은 대용량 미디어 파일을 저장하고 관리할 수 있는 환경을 제공합니다.

이 기능을 Web에서 Free 플랜으로 사용하면 프로젝트를 2개까지 사용가능하다. 다행히, Supabase를 Mini PC에서 사용할 수 있어 여기서 설정해 보자.

1. 기본 가정 및 공통 인프라 설정 (0단계)

본격적인 설치 전, 서버의 기초 뼈대를 잡는다. 이 설정은 한 번만 수행하면 된된다.

• Linux OS: Ubuntu 24.04 등 안정적인 배포판 권장.
• Docker 환경: docker-ce, docker-compose-plugin 설치 완료.
• 보안 (VPN & UFW):
  • VPN: 내부망 접속을 위한 안전한 통로 확보 (ipTIME VPN 등).
  • UFW: 기본 방화벽 활성화 및 기본 포트 허용 (sudo ufw allow ssh, sudo ufw enable).
• 주소 (DDNS): 외부 접속용 고정 주소 확보 (예: my-home.iptime.org).

2. 첫 번째 Supabase 프로젝트 구축 (Project A)

웹에서 '프로젝트 하나'를 만드는 것과 동일한 과정이이다.

1) 파일 준비 및 기본 설정

여기서 DDNS와 supabase의 port는 다르게 하면 된다.

# 프로젝트 A 전용 폴더 생성
mkdir -p ~/supabase/project-a && cd ~/supabase/project-a
git clone --depth 1 https://github.com/supabase/supabase .
cd docker
cp .env.example .env

2) .env 디테일 수정

• URL 설정:
  • API_EXTERNAL_URL=http://my-home.iptime.org:8000
  • GOTRUE_EXTERNAL_URL=http://my-home.iptime.org:8000
• 보안 키: JWT_SECRET, ANON_KEY, SERVICE_ROLE_KEY를 고유한 문자열로 변경.
• DB 암호: POSTGRES_PASSWORD를 강력한 비밀번호로 변경.

experimental이기는 하지만, 다음 명령을 사용하면 바로 .env의 주요 값을 생성해서 업데이트 해주는 명령도 있다.

sh ./utils/generate-keys.sh

3) 서비스 기동 및 포트 개방

• Docker 실행: docker compose up -d
• UFW 허용: sudo ufw allow 8000/tcp
• 포트 포워딩 (공유기): 외부 8000 -> 미니 PC 8000 (TCP) 설정 추가.

3. 두 번째 Supabase 프로젝트 추가 (Project B)

동일한 장비에서 완전히 분리된 별도의 프로젝트를 운영한다.

1) 인스턴스 격리 복제

# 프로젝트 B 전용 폴더 생성 (데이터와 설정의 완전한 분리)
mkdir -p ~/supabase/project-b && cd ~/supabase/project-b
git clone --depth 1 https://github.com/supabase/supabase .
cd docker
cp .env.example .env

2) 충돌 방지를 위한 디테일 수정

• 포트 차별화: 중복을 피하기 위해 다른 포트(e.g. 8001) 를 사용한다.
  • .env 내 KONG_HTTP_PORT=8001 수정.
  • 모든 외부 URL 끝을 :8001로 변경 (예: http://my-home.iptime.org:8001).
• 프로젝트 이름 지정: docker-compose.yml 파일 최상단에 name: supabase-b 추가.
  • 이렇게 해야 컨테이너 이름(예: supabase-b-db)이 첫 번째 프로젝트와 겹치지 않는다.

3) 서비스 기동 및 포트 개방

• Docker 실행: docker compose up -d
• UFW 허용: sudo ufw allow 8001/tcp
• 포트 포워딩 (공유기): 외부 8001 -> 미니 PC 8001 (TCP) 설정 추가.

🔒 4. 마무리 및 통합 관리

두 인스턴스가 독립적으로 운영되는 상태에서의 관리 포인트입니다.

• 상태 모니터링:
  • docker compose -p supabase-a ps: 첫 번째 프로젝트 상태 확인.
  • docker compose -p supabase-b ps: 두 번째 프로젝트 상태 확인.
• 로그 관리: 특정 프로젝트의 에러 확인 시 -p 옵션 사용 (docker compose -p supabase-b logs -f realtime).
• 리소스 배분: 미니 PC의 사양에 따라 docker stats로 메모리 점유율을 확인하며 운영하자.

핵심 요약

1. 하나의 인스턴스 = 하나의 프로젝트: 폴더별로 docker-compose를 실행하여 독립적인 환경을 구축한다.
2. 포트 포워딩은 건별로: 인스턴스마다 사용하는 KONG_HTTP_PORT가 다르므로, 공유기 설정도 그에 맞춰 하나씩 추가해야 한다.
3. 이름 격리의 중요성: yml 파일에 프로젝트 name을 명시해야 컨테이너 이름 충돌로 인한 실행 실패를 막을 수 있다.

이 가이드는 로컬 개발 환경을 넘어, 실제 여러 서비스를 한 대의 서버에서 운영할 때 가장 표준적인 방법이다.

개발자 커뮤니티에서 beads와 gastown에 대해서 들었다. 제작자인 Steve Yegge의 Medium을 보고, github repository를 보고 몇 가지 아이디어가 떠올랐다. 하지만, 컨셉을 모두 이해하지 못한 상태에서 좀 큰 아이디어에 뛰어 들다 보니, 다시 작게 해보자는 생각이 들었다.

1. Beads/Gastown 개요 및 Mini-Journal 프로젝트 연계

Beads & Gastown이란?

• Beads (bd): 에이전트 전용 '구조화된 기억 엔진'이다. 일반적인 이슈 트래커와 달리, 에이전트가 이해하기 쉬운 형태로 태스크 간의 의존성(Graph)을 관리하고, 개발 문맥(Context)을 보존한다.
• Gastown (gt): 여러 에이전트가 협업할 수 있는 '가상 워크스페이스(공장)'를 조율합니다. 원본 코드를 보호하면서 에이전트가 안전하게 코드를 수정하고 테스트할 수 있는 독립된 작업 공간(Crew/Hooks)을 제공한다.

Steve Yegge의 Agentic coding tool이 docker이면, GasTown은 Kubenettes라는 비유가 찰떡같다는 생각이다.

Mini-Journal 프로젝트 사례 연계

이번 프로젝트는 단순히 "일기 앱을 만드는 것"이 목적이 아니다. "사용자가 설계(PRD)를 던지면, AI 에이전트가 Beads에서 할 일을 찾고 Gastown 공장에서 스스로 코드를 생산하는 워크플로우"를 검증하는 사례이다. Node.js를 이용해 날짜별로 저널을 기록하는 간단한 기능을 구현하며 이 시스템의 개념, 동작 그리고 실효성을 확인했다.

2. 관련 툴 설치 가이드 (Environment Setup)

프로젝트 시작을 위해 필요한 핵심 도구들의 설치 과정이다. 나는 Mini PC/Unbutu 환경에서 확인했다. Mac 혹은 Windows/WSL2에서도 가능하다고 한다.

Go & 관련 바이너리 설치

Beads와 Gastown은 Go 언어로 작성되었다.

# Go 설치 (Ubuntu 기준)
sudo apt update && sudo apt install golang-go

# Beads/Gastown 설치 (다른 프로젝트 연동으로 소스 코드가 있는 경우)
cd ~/prj/Livo/apps/beads && go install ./cmd/bd
cd ~/prj/Livo/apps/gastown && go install ./cmd/gt

# 환경 변수 등록 (~/.bashrc)
export PATH=$PATH:$(go env GOPATH)/bin

tmux 설치

Gastown은 에이전트 세션을 격리하고 유지하기 위해 tmux를 필수적으로 사용한한다.

sudo apt install tmux

3. Workspace 설정 및 Beads 준비

공장 부지를 닦고 작업 목록을 만드는 과정입니다.

Workspace(공장) 초기화

# 1. 중앙 워크스페이스 생성
gt install ~/gt --git

# 2. 프로젝트(Rig) 등록
gt rig add journal /home/blcktgr/prj/mini-journal

# 3. 개발자 전용 작업장(Crew) 생성
gt crew add blcktgr --rig journal

# 4. 작업 공간으로 이동 (이곳이 실제 전장입니다)
cd ~/gt/journal/crew/blcktgr

Beads 이슈 생성

에이전트에게 시킬 일을 정의한다.

# Beads 초기화
bd init

# 첫 번째 작업 생성 (PRD의 US-001 대응)
bd create "US-001" -p 0

# 준비된 작업 확인
bd ready

4. 개발 실행 및 테스트

실제로 AI 에이전트(Mayor)를 깨워 개발을 진행하고 로컬에서 검증하는 단계이다.

에이전트 가동 (Mayor Start)

안정적인 개발을 위해 Claude를 메인 에이전트로 설정하여 접속한다.

# 1. 에이전트 설정 및 실행
gt config default-agent claude
gt mayor start

# 2. 세션 접속 (tmux 인터페이스 진입)
gt mayor attach

에이전트 지시 및 코딩

세션 내부에서 에이전트에게 PRD.md와 CLAUDE.md를 읽게 한 뒤, bd ready에 있는 이슈를 처리하도록 명령한다. 에이전트는 이 과정에서 journal.js 파일을 생성하고 Docs/transformations/에 설계 기록을 남긴긴다.

로컬 테스트

에이전트가 작성을 완료하면, 로컬 터미널에서 즉시 검증한한다.

Bash

# 오늘 날짜의 저널 기록 테스트
node journal.js "블로그 포스팅 준비 중"

# 결과 확인
ls entries/
cat entries/2026-01-24.md

💡 마무리

Agentic Coding은 정말 빠르게 발전하고 있다. 단순히, Agent에게 요구 사항 문서를 주고 개발하라고 하는 단계에서, 문맥(Context)을 설계하고 에이전트의 워크플로우를 관리하는 오케스트레이션으로 진화하고 있는 것을 살펴 볼 수 있다.

개인적으로는 이제 baby step을 해보았기에, dashboard를 만들거나 여러 프로젝트를 한꺼번에 돌려보거나, 여러 agent (claude, codex, gemini, opencode)를 활용해 보고자 한다.

사실, 어려웠던 점은 gemini와 연계가 안되어서 시간을 사용했다. LLM, github issues, googling으로는 아직 힌트를 얻지는 못했다. 하지만, claude만으로도 훌륭했다.

참고 링크

Welcome to GasTwon, https://steve-yegge.medium.com/welcome-to-gas-town-4f25ee16dd04

mini-journal, https://github.com/blcktgr73/mini-journal