Refactoring English: 14개월 차
원문은 Michael Lynch님이 에 게재했습니다. 이 블로그 구독하기
한 줄 요약
AI 샌드박스의 힘을 발견하다
처음 방문하셨나요?
안녕하세요, 마이클입니다. 저는 소프트웨어 개발자이자 소규모 인디 테크 비즈니스를 운영하는 창업자입니다. 현재 Refactoring English: Effective Writing for Software Developers라는 책을 집필하고 있습니다.
매달 이렇게 한 달을 돌아보는 회고를 발행해 책 집필 과정과 전반적인 근황을 공유하고 있습니다.
하이라이트
- 책 독자를 찾는 새로운 전략이 긍정적인 성과를 내고 있다.
- AI 에이전트에 제한 없이 실행하도록 맡겨 돌파구를 경험했다.
- 후회하던 기술 스택 선택을 AI로 바로잡고 있다.
목표 점검
매달 초에 이루고 싶은 목표를 정합니다. 이번 달 결과는 다음과 같습니다:
Refactoring English 챕터 3개 발행하기
- 결과: 신규 챕터 2개 발행
- 평가: B-
지난달과 같은 문제가 반복되고 있다. AI 실험에 너무 몰두한 나머지 집필 시간을 잠식당했다.
2025년 연간 회고 발행하기 (8년 차)
- 결과: 발행 완료
- 평가: A
완료했다! 결과물에도 만족한다. 그동안 관성이나 시의성 때문에 특정 기한까지 발행해야 한다는 압박을 느꼈던 연재들을 이제 일단락했다.
Refactoring English 지표
| 지표 | 2025년 12월 | 2026년 1월 | 변화 |
|---|---|---|---|
| 고유 방문자 | 2,266 | 38,511 | +36,245 (+1600%) |
| 사전 예약 수익 | $492.55 | $1,132.75 | +$640.20 (+130%) |
| 스폰서 수익 | $48.25 | $0.00 | -$48.25 (-100%) |
1월 초에 “The Most Popular Blogs of Hacker News in 2025”를 발행했는데, 기대를 훨씬 뛰어넘는 성과를 거뒀다. 덕분에 1월은 지난해 킥스타터 이후 책 관련 사이트 중 방문자 수와 수익이 가장 높은 달이 됐다.
그 외 수익은 줄었다. 편집 의뢰가 없었고, TinyPilot의 현 소유주가 2025년을 끝으로 책 후원을 종료했기 때문이다. 기업들의 관심도 크지 않고 독자에게 집중하는 편이 더 수월해, 앞으로는 기업 스폰서를 더 유치할 계획은 없다.
다른 작가에 대해 쓰며 얻은 성과
“The Most Popular Blogs of Hacker News in 2025”는 약 6개월 전부터 시도해 온 전략의 연장선이다. 핵심은 단순하다. 다른 소프트웨어 작가들을 조명하는 것이다.
지난여름 한 파티에서 자가 출판으로 활동하는 로맨스 소설가를 만났다. 전혀 다른 분야를 쓰는데도 비슷한 고민을 하고 있다는 점이 흥미로웠다.
어떻게 독자를 찾느냐고 묻자 그녀는 “그게 바로 핵심 질문이죠!”라고 답했다.
그녀는 주로 인디 작가들의 로맨스 소설을 리뷰하는 뉴스레터를 시작해 큰 효과를 봤다고 했다. 이를 통해 선순환이 만들어졌는데, 과정은 다음과 같다:
- 독자들이 뉴스레터를 읽고 그녀의 책을 발견해 구매한다.
- 다른 인디 작가들은 자신의 작품 리뷰를 반가워하며 자신의 독자들에게 그녀의 뉴스레터를 소개하고, 이는 (1)을 더 늘린다.
- 구독자들은 뉴스레터를 통해 또 다른 흥미로운 소설들을 발견한다.
모두에게 인센티브가 맞아떨어지는 전략을 좋아해서, 이를 내 책에 어떻게 적용할 수 있을지 고민하기 시작했다. 내가 좋아하는 다른 블로거와 책 저자들을 소개하는 글을 써서 블로그에 올렸고, 반응은 좋았다:
| 글 | 고유 독자 | Hacker News 점수 | Lobsters 점수 |
|---|---|---|---|
| The Most Popular Blogs of Hacker News in 2025 | 33.8k | 692 | - |
| The Software Essays that Shaped Me | 25.6k | 308 | 85 |
| What Makes the Intro to Crafting Interpreters so Good? | 3.5k | - | 137 |
AI 샌드박스의 힘을 발견하다
1년 전 AI 에이전트를 처음 쓰기 시작했을 때 계시 같은 경험을 했다. 그때는 에이전트가 파일을 수정하는 모습을 옆에서 지켜보는 것만으로도 LLM에 너무 많은 권한을 주는 것 같아 아찔하게 느껴졌다.
지난 1년 동안은 주로 VS Code의 AI 에이전트 확장인 Cline으로 코딩했다. 작업 속도가 많이 빨라졌지만, 개발 머신에서 마음대로 동작하도록 신뢰할 수 없어 일일이 세세하게 관리했다.
몇 주 전 친구 okay가 OpenAI의 터미널 기반 AI 에이전트인 Codex를 활용한 자신의 AI 워크플로를 보여줬다. okay는 Codex가 직접 감독 없이 파일을 수정하고 명령을 실행하도록 둔다. 이를 보고 그동안 AI 에이전트를 일일이 챙기고 Cline이 멈추는 문제를 처리하느라 얼마나 많은 시간을 낭비했는지 깨달았다.
okay는 때때로 한 시간 이상 Codex를 무인으로 돌린다고 했는데, 믿기 어려웠다. Cline에 10분 이상 걸리는 작업을 맡기면 UI가 멈추거나 엉뚱한 방향으로 가거나 비용이 폭증하기 일쑤였다. 반면 Codex는 토큰당 과금이 아니라 정액제라 비용 걱정을 하지 않아도 된다.
그래도 여전히 어떤 AI 에이전트든 내 실제 컴퓨터에서 마음대로 날뛰도록 둘 수는 없어서, 내 머신에서 AI 에이전트를 실행하기 위한 커스텀 샌드박스를 만들었다. 프로젝트 디렉터리로 이동해 직접 만든 명령어인 sb를 실행한다. 그러면 로컬 네트워크에 접근할 수 없고 현재 작업 디렉터리만 볼 수 있는 rootless Podman 컨테이너가 생성된다. 컨테이너에는 Codex와 Claude Code가 미리 설치되어 있고 내 계정으로 인증까지 마쳐져 있다.
AI가 샌드박스 안에 있으니 파일을 수정하고 애플리케이션을 설치하는 등 모든 권한을 주는 것도 괜찮았다.
그리고 와, 정말 큰 차이였다!
완전한 권한을 가진 AI 에이전트가 동작하는 모습을 보는 것은 또 하나의 돌파구였다. 예전에는 “지난 8년간 내 수입을 막대 그래프로 만들어줘”라고 하면 30% 정도는 에이전트가 어딘가 어긋나게 구현했다. 내가 직접 결과를 확인하고 “아니, 막대가 어긋났어. 고쳐줘”라고 말해야 했다. 하지만 AI 에이전트가 자체 샌드박스에서 root 권한을 가지면 테스트 서버를 띄우고 브라우저에서 페이지를 확인하며 작업을 완료할 때까지 스스로 반복해 개선할 수 있다.
그러다 Ralph Loops에 대해 들었다. 아직 제대로 된 설명을 찾지 못해서 내가 하는 방식이 “공식” Ralph Loops가 맞는지 확신할 수 없지만, 내 방식은 이렇다. ralph-loop라는 bash 스크립트를 실행하는데, 내용은 아주 단순하다:
#!/usr/bin/env bash
rm ALL-DONE.txt || true
while true; do
cat AGENT-WORKFLOW.md | codex exec
if [[ -f "ALL-DONE.txt" ]]; then
echo "ALL-DONE.txt detected. Exiting."
exit 0
fi
done
그리고 AGENT-WORKFLOW.md는 이렇게 생겼다:
1. Pick the top task in TODO.md and begin work on it
- If no actions remain, write a file called ALL-DONE.txt to the current
directory, and exit.
1. Complete the task and delete the entry from TODO.md.
- If the task is unachievable, explain why in the commit message.
1. Commit the changes with a detailed commit message explaining what you
changed, why you changed it, and what impact it had.
그리고 할 일 목록이 담긴 TODO.md 파일을 만든다. 일부 작업은 후속 작업을 생성하는 내용을 포함하므로, 목록은 에이전트의 진행 상황에 따라 늘어나기도 줄기도 한다.
Ralph Loop 덕분에 AI 에이전트를 10시간 이상 무인으로 자율 동작시킬 수 있게 됐다. 아침에 컴퓨터로 돌아와 내가 자는 동안 에이전트가 맡긴 일을 모두 끝내 놓은 걸 보면 비현실적으로 느껴진다.
AI는 코드 포팅에 탁월하다
지난 몇 달간 AI를 실험하면서, AI가 가장 큰 효과를 발휘하는 경우는 다음과 같다는 걸 알게 됐다:
- 성공 기준을 객관적으로 정의할 수 있을 때.
- 예컨대 “이 크래시의 원인을 찾아줘”는 객관적이고 정의 가능하지만, “이 랜딩 페이지를 더 좋게 만들어줘”는 그렇지 않다.
- AI 에이전트가 성공 여부를 독립적으로 검증할 수 있을 때.
- 예컨대 “브라우저에서 페이지에 접속해 버튼을 눌렀을 때 배경이 파란색으로 바뀌는지 확인해줘.”
- 주니어 수준의 소프트웨어 지식을 가진 사람이라도 검색 엔진과 실험, 인내심으로 해결할 수 있는 문제일 때.
이런 기준을 충족하는 소프트웨어 작업 유형은 다음과 같다:
- 자동화된 테스트가 있는 코드 리팩터링
- 동작을 유지하면서 코드를 한 언어/기술에서 다른 언어/기술로 포팅하기
- 필요한 의존성을 설치해 소스에서 프로젝트 컴파일하기
- 테스트를 통과하도록 코드 수정하기
최근에는 AI를 활용해 코드를 포팅하고 있다. 기술 스택을 다르게 선택했으면 하는 코드베이스가 몇 개 있는데, 전부 다시 작성하자니 항상 너무 많은 시간이 들었다. 하지만 AI를 쓰면 스택의 일부를 교체하는 작업이 저렴하고 빠르게 끝난다.
여러 프로젝트에서 코드 포팅에 성공했다:
- Zestful 웹사이트를 Vue/Nuxt2에서 Hugo 기반의 바닐라 HTML로 전환
- 들어본 적도 없는 전이(transitive) Node.js 라이브러리를 통해 발생한 어이없는 취약점이 있다는 GitHub 알림을 받았다. “다시는 이런 알림을 보고 싶지 않다”는 생각이 들었고, AI에 사이트를 Hugo와 순수 HTML/JS/CSS로 다시 작성하도록 했다.
- PicoShare의 CSS 프레임워크를 Bulma에서 Bootstrap으로 포팅
- PicoShare를 만들 당시에는 CSS 프레임워크로 Bulma를 써보고 싶었다. 나쁘지 않았지만, 나는 Bootstrap을 더 선호해서 다른 곳에서는 계속 Bootstrap을 썼고, PicoShare를 작업할 때마다 매번 감을 다시 잡아야 했다.
- LogPaste의 e2e 테스트를 Cypress에서 Playwright로 전환
- e2e 테스트를 작성할 당시에는 Playwright를 알기 전이었고, 이제는 Playwright에 너무 익숙해져 Cypress로 돌아가는 게 어렵게 느껴진다.
- fusion RSS 리더를 Svelte에서 바닐라 HTML + Go 템플릿으로 전환
- fusion은 내 프로젝트가 아니라 단순한 개념 검증용이지만, 내가 선호하는 기술 스택으로 포크해서 쓰고 싶었다. AI는 모든 Svelte 코드를 바닐라 HTML과 Go 템플릿으로 변환하는 작업을 잘 해냈지만, 실제로 포팅하려면 테스트 인프라를 더 갖춰야 할 것 같다.
- MeshCore 웹 앱을 Vue.js에서 Flutter로 전환
- 이 작업은 “AI가 결과를 검증할 수 있다”는 단계가 빠져서 실제로는 잘 되지 않았다. Flutter가 웹 앱 결과물로 시맨틱 HTML을 생성할 줄 알았는데, 실제로는 어설픈 Flutter 중심의 HTML 방언을 만들어냈다. 게다가 MeshCore 앱은 외부 하드웨어 장치(LoRa 무전기)에 크게 의존하기 때문에 내가 계속 개입해야 했다.
사이드 프로젝트
StreamPreserve
휴대폰으로 꼭 기록하고 싶은 장면을 목격했는데, 누군가 휴대폰을 빼앗아 영상을 지우거나 휴대폰 자체를 파손할 가능성이 있는 상황이라면 어떻게 해야 할지 생각해 본 적이 있다.
그래서 중요한 영상을 원격의 안전한 서버로 빠르게 옮기는 웹 앱인 StreamPreserve를 만들었다.

StreamPreserve는 중요한 영상을 캡처해 가능한 한 빠르게 원격 서버로 옮긴다.
작동 방식은 다음과 같다:
- StreamPreserve 앱을 열고 녹화를 시작한다.
- 앱은 가용 대역폭에 맞춰 스트림 품질을 조절하며 저해상도 영상을 백엔드 서버로 스트리밍한다.
- 앱은 고해상도 영상을 브라우저 저장소에 조각 단위로 나누어 기록한다.
- 여유 대역폭이 있으면 스트리밍을 계속하면서 고해상도 영상 조각을 서버에 업로드한다.
- 녹화가 끝나면 앱은 고해상도 영상을 로컬 기기에 다운로드 파일로 저장한다.
- 앱이 열려 있고 녹화 중이 아닐 때는 기기에 있는 모든 고해상도 영상을 서버로 동기화한다.
즉, 무언가를 녹화하다 누군가 내 휴대폰을 부숴도 StreamPreserve 서버에는 영상의 저해상도 복사본이 남아 있게 된다. 누군가 녹화를 막으려고 휴대폰을 빼앗더라도, 웹 앱은 백그라운드에서 고해상도 영상을 계속 업로드한다.
몇 가지 결함을 깨닫고 나서는 이 아이디어에 대한 열정이 식었다:
- 수 시간 분량의 영상을 녹화하기에는 적합하지 않은 방식이다.
- 웹 앱으로 구현하면 복잡도가 높아지고 영상을 손실할 가능성이 생긴다. 네이티브 모바일 앱으로 만들어야 하는데, 나는 모바일 개발을 좋아하지 않는다.
- 브라우저 카메라 API에 의존하는데, 이를 AI 샌드박스에서 가짜로 구현하는 과정이 까다로워 AI에 맡기기 좋은 작업도 아니다.
마무리
무엇을 했나?
- 부트스트랩 창업자 8년 차 회고를 발행했다
- Refactoring English 신규 챕터 2개를 발행했다
- 크래시를 수정했다 — PoDoFo PDF 리더에서 내 PDF 퍼징 워크플로로 발견한 문제였다
배운 점
- 다른 소프트웨어 작가들을 조명하는 것이 새로운 독자를 찾는 데 도움이 된다.
- AI 에이전트는 root 권한으로 애플리케이션을 설치하고 웹 검색을 할 수 있는 환경에서 실행될 때 훨씬 더 유용하다.
- 성공 기준을 객관적으로 정의할 수 있고, 에이전트가 성공 여부를 검증하며 반복을 통해 스스로 교정할 수 있을 때 AI는 문제 해결에 강하다.
- AI는 코드를 한 기술에서 다른 기술로 포팅하는 데 탁월하다.
다음 달 목표
- Refactoring English 챕터 2개 발행하기.
- Refactoring English 독자를 위한 라이브 이벤트 일정 잡기.
글을 무작위로 읽기
댓글
로그인하고 댓글 남기기