서론

하루 종일 AI가 내 손을 떠나 내가 원하는 것을 계속 만들어준다면...

이 기사는 두 가지 이야기를 하나로 합친 것입니다.

만든 것: VS Code 상에서 Markdown을 WYSIWYG(What You See Is What You Get) 방식으로 편집[1]할 수 있는 확장 기능 -
만드는 방법: 평일에는 업무를 하고 휴일에는 놀러 나가면서, Claude Code를 /loop 2h /evolve 명령어로 2시간마다 실행하여, 1회당 1개 기능씩 「구현→테스트→리뷰→문서화→커밋→푸시」를 자율적으로 실행하게 함

그 결과가 이 커밋 로그입니다. 어느 평일 낮부터 밤까지, 제가 업무를 하는 동안 쌓인 것입니다.

08:31 feat: 태스크 리스트의 라이브 입력 대응 추가
10:30 fix: 굵게·취소선 라이브 변환이 분할 텍스트 노드에서 적용되지 않는 문제 수정
12:32 feat: 인용 내에서 "> " 입력을 통한 중첩 인용 생성
...

타임스탬프가 대략 2시간 간격으로 나열되어 있는 것을 알 수 있을 것입니다. 각각의 커밋에는 유닛 테스트(Unit Test)와 문서 업데이트가 포함되어 있으며, 저는 시간이 날 때 동작을 확인하고 반영합니다. 버그가 있다면 Claude Code에게 지적하도록 하는 운영 방식입니다.

이러한 「AI에 대한 프롬프트 입력을 인간이 하는 대신, AI를 돌리는 루프(Loop) 그 자체를 설계하는」 방식은 최근 루프 엔지니어링 (Loop Engineering) 이라고 불리기 시작했습니다. 이 기사에서는 그 실천 사례로서

• 루프 설계 (/evolve skill의 내용과 그 안에 담은 가드레일)
• 실제로 루프를 돌려 무엇이 일어났는가
• AI에게 맡기지 않고 인간(나)이 한 것 (디자인의 손맛 부분)
• 루프를 원활하게 돌리지 못한 반성점

을 소개합니다.

왜 직접 만들었는가 ― 「적당한 WYSIWYG Markdown 에디터」가 없었다

애초의 동기는 소박했습니다. 그저 VS Code에서 Markdown을 WYSIWYG 방식으로 편집하고 싶었을 뿐입니다. 하지만 찾아보니 의외로 좋은 방법을 찾을 수 없었습니다.

• VS Code 표준 Markdown 미리보기는 어디까지나 「소스와 미리보기의 분할 표시」일 뿐 WYSIWYG이 아니다
• Marketplace를 찾아봐도 WYSIWYG 편집이 가능한 확장 기능은 극소수다
• 설령 있다 하더라도, 출처를 알 수 없는 확장 기능을 일상의 메모나 문서 편집에 사용하는 것은 두렵다

특히 세 번째 동기가 개인적으로 큽니다. VS Code의 확장 기능에는 취약점이 있거나 공급망 공격(Supply Chain Attack)을 받을 수 있으며, 심지어 악의적인 것도 있습니다. 그렇다면 직접 만들어서 외부와 통신하지 않는, 악의 없는 것을 사용하자고 생각했습니다.

그리고 이 「기능을 세밀하게 분할할 수 있고, 성과가 눈에 보이며, 내가 매일 사용하는 것」이라는 성질이, 후술할 자율 개발 루프의 소재로서 매우 궁합이 좋다고 판단했습니다.

만들고 있는 것

Markdown WYSIWYG Editor의 주요 기능입니다.

• 제목·리스트·표·코드 블록·인용 등의 보이는 대로 편집 (Markdown 소스와 상시 양방향 동기화)
• Mermaid 다이어그램의 실시간 미리보기, 분할 표시, 고해解상도 PNG 내보내기, 클립보드 복사
• 코드 블록의 구문 강조 (Syntax Highlighting) (약 36개 언어 + 자동 판정), 언어 선택기, 복사 버튼
• 목차(TOC) 자동 생성 (Ctrl+Shift+O), 단어 수·글자 수 상태 표시
• VS Code의 컬러 테마에 자동 추종

아키텍처는 VS Code의 CustomTextEditor API를 사용하며, 확장 기능 측 (src/)과 Webview 측 (media/modules/)으로 나뉘는 구성입니다[2]. 가장 중요하게 생각한 점은 Markdown ⇔ HTML의 양방향 변환에서, 「HTML로 변환하여 편집하고 Markdown으로 다시 썼을 때 원래의 소스가 망가지지 않는 것 (Round-trip)」을 유지해야 한다는 점입니다.

루프 엔지니어링이란

루프 엔지니어링은 Google의 Addy Osmani가 블로그 기사를 통해 퍼뜨린 용어입니다. Claude Code 리드인 Boris Cherny의 「내 업무는 이제 모델에 프롬프트를 치는 것이 아니라, 루프를 쓰는 것이다」라는 발언에도 같은 사상이 나타나 있습니다.

마찬가지로 Anthropic의 Claude Code 책임자인 Boris Cherny는 “나는 더 이상 Claude에게 프롬프트를 입력하지 않습니다. Claude에게 프롬프트를 입력하고 무엇을 할지 결정하는 루프(loop)를 실행하고 있습니다. 내 업무는 루프를 작성하는 것입니다”라고 말했습니다.

loop-engineering에서 인용.

이 말에 대입해 보면, 다음과 같은 부품들로 루프를 구성하고 있습니다.

왜 「2시간마다」인가

2026년 7월 현재 Claude Code Pro 플랜에서는 이용 제한이 5시간의 윈도우(window) 단위로 적용됩니다. 에이전트를 계속 실행해 두면 사용량이 편중되어 금방 상한에 도달하지만, 1사이클을 작게 좁혀서 2시간마다 실행함으로써 사용량을 평준화하여 제한에 걸리지 않고 하루 종일 계속 돌릴 수 있다고 생각했습니다.

「장시간 계속 실행하기」가 아니라 「짧은 사이클 × 횟수」로 지속성을 갖게 했습니다. 이는 비용 측면뿐만 아니라 품질 측면에서도 효과적이며, 1사이클의 스코프(scope)가 작을수록 AI가 폭주할 수 있는 범위도 작아집니다.

다만 실제로는 Claude의 Pro 플랜에서 주간 제한이 더 엄격했습니다 [3]. 운 좋게 리셋이 되거나 다른 작업에도 사용하기 때문에 정확한 것은 모르겠지만, 앞으로 주간 제한에 걸릴 수도 있습니다. 개인적으로는 그것대로 괜찮다고 생각합니다 [4].

루프 구동 운영

/loop

명령어는 Claude Code의 세션 로컬(session-local) 기능입니다. 터미널(세션)을 열어두는 동안에만 계속 작동합니다. 집에서 노트북을 전원에 연결하고 슬립(sleep) 모드로 전환되지 않도록 설정한 뒤 [5], Claude Code의 세션을 계속 열어두고 있습니다. 영구적으로 클라우드에서 돌리는 선택지도 있지만, 이제 막 루프를 시작한 단계라 멈추는 일도 꽤 있어서 로컬로도 충분했습니다.

/evolve

명령어 설계

루프 엔지니어링(loop-engineering)의 본체는 여기입니다. .claude/skills/evolve/SKILL.md에 1사이클 분량의 절차를 약 80줄의 Markdown으로 정의하고 있습니다. 도입부는 다음과 같습니다.

Markdown WYSIWYG 에디터의 자동 개발 사이클을 **딱 1회만** 실행해 주세요.
1회 = 「기능 1개 선택 → 구현 → 테스트 → 코드 리뷰 → 문서 업데이트 → commit → push → 백로그 업데이트」입니다.

이하, 설계 판단을 하나씩 설명하겠습니다.

1사이클 = 1기능 = 1커밋

스코프의 폭주를 방지하는 가장 중요한 규칙입니다. 구현 중에 다른 개선점을 발견하더라도 수정하게 하지 않고, ROADMAP에 todo로 추가만 하게 합니다.

- **1사이클 1기능. 스코프를 넓히지 말 것.** 구현 중에 다른 개선점을 발견하면,
수정하지 말고 ROADMAP.md에 todo로 추가한다.

그리고 1사이클의 성과를 반드시 1개의 커밋(commit)으로 묶습니다. 이것이 후술할 리뷰 운영의 핵심이며, 마음에 들지 않는 사이클만 git revert로 개별적으로 되돌릴 수 있는 체크포인트가 됩니다.

main에서는 절대로 작업시키지 않음

각 사이클의 도입부에 사전 체크를 배치했습니다.

• 작업은 반드시 evolve/YYYYMMDD 브랜치에서 수행할 것.
• main에 있다면 최신화하여 브랜치를 생성할 것.
• 이전 사이클이 도중에 끝난 흔적(구현은 되었으나 테스트 미완료 등)이 있다면, 새로운 기능에 손대지 않고 이어서 재개할 것.
• 사용자의 수동 작업으로 보이는 변경사항이 섞여 있다면, 아무것도 하지 않고 보고 후 종료할 것 (자신의 작업과 loop의 작업이 충돌하는 것을 방지하는 운영 방식)

백로그 구동 — ROADMAP.md가 AI의 외부 기억

각 사이클은 docs/ROADMAP.md를 위에서부터 순서대로 읽고, 첫 번째 todo를 하나 선택합니다. ROADMAP에는 항목별로 사이즈(S/M/L)를 지정해 두었으며,

• 사이즈 L 항목에는 착수시키지 않는다. S/M 크기의 하위 항목으로 분할하여 ROADMAP을 다시 작성하는 것만으로도 1사이클로 간주합니다. todo가 다 떨어지면, 기존 기능이나 코드를 보고
  새로운 기능 제안을 스스로 3~5개 추가하여 그중 하나에 착수한다

라는 규칙을 세웠습니다. 실제로 PDF 내보내기(L)에 대해서는 "우선 인쇄 스타일 대응부터 착수하고, 요구사항이 강해지면 puppeteer 안을 검토한다"라는 분할 방침을 AI 스스로가 ROADMAP에 기록해 두었습니다.

테스트 필수

2. 다음을 순서대로 실행하여 모두 성공시킨다:
- `npm run check-types`
- `npm run lint`
...

포인트는 **철수 규칙 (Retreat Rule)**을 마련해 두었다는 점입니다. 무인 운전에서는 "AI가 동일한 에러와 끊임없이 싸우며 크레딧만 낭비하는 것"이 최악의 패턴이므로, 2회 연속 동일한 실패를 하면 포기하고 blocked로 기록한 뒤 철수시킵니다 [6]. 다음 사이클에서는 다른 todo로 넘어갈 수 있으므로 루프 전체가 멈추지는 않습니다.

자신의 구현을 스스로 리뷰하게 하기

테스트를 통과하면, 해당 사이클의 성과를 독자적으로 정의한 skill /local-review에 돌린 후 커밋하도록 하고 있습니다. 테스트는 "작성한 대로 동작하는가"는 지켜줄 수 있지만, "애초에 이 구현이 적절한가"까지는 봐주지 않습니다. 그래서 아직 커밋하지 않은 차이점(Working Tree)에 대해 객관적인 코드 리뷰를 한 단계 거칩니다.

## 4. 코드 리뷰 (서브 에이전트에 의한 객관적 리뷰)
... (중략) 테스트가 모두 통과된 상태에서, 아직 commit 하지 않은 차이점 (Working Tree, 신규 파일 포함)에 대해 실행한다.
... (이하 생략)

지적 사항(findings)이 돌아오면, AI가 다음 세 가지로 분류하게 합니다.

• 이번 변경이 원인인 결함 → 그 자리에서 수정하고, 테스트 세트를 재실행한 뒤 동일 사이클의 1개 커밋에 포함한다
• 스코프 외 / 기존의 별개 문제 / 우선순위가 낮은 개선 사항 → 수정하지 않고 ROADMAP.md에 todo로 추가한다 (여기서도 "1사이클 1기능" 원칙을 고수한다)
• 오탐지 / 대응 불필요 → 대응하지 않고, 사이클 종료 시 보고에서 해당 내용을 언급한다

loop 운영을 사수하기 위해, /local-review 자체를 사용할 수 없는 경우에는 리뷰를 스킵하고 사이클을 멈추지 않는다는 철수 규칙도 테스트와 마찬가지로 포함되어 있습니다.

실제 사례

⏺ Skill(local-review)
Done
The review found a genuine high-severity bug (A-1):
...

수식을 이미지로 저장하는 기능에서, 새로 추가한 "검은색" 배경에서 KaTeX가 currentColor를 상속(검은색)받은 채 검은 바탕에 그려져 수식이 보이지 않게 되는 버그를 발견해 주었습니다. 이는 이번 구현에서 치명적인 것이었기에 그 자리에서 바로 수정해 주었습니다.

왜 code-review를 사용하지 않는가

Claude Code에 내장된 전용 skill인 /code-review가 존재하지만, 이는 사용자에 의한 수동 실행으로만 사용할 수 있는 것으로 보여 [7], 독자적인 skill을 사용하는 선택을 했습니다. 공식에서 제공하는 skill을 사용할 수 있다면 그것을 사용하는 것이 가장 좋겠지만 말입니다.

문서도 동일한 사이클 내에서 업데이트

changelog, README, 기능 문서의 업데이트를 동일 사이클 내에서 의무화하고 있습니다. 당초 예상하지 못했던 부분이었으나, 실제로 실행해 보니 sample.md (신규 기능을 실제로 테스트해 볼 수 있는 샘플 문서)의 업데이트도 수행해 주어, 시간이 날 때 이 파일을 열어보는 것만으로 그날 구현된 기능을 한 차례 모두 만져보며 확인할 수 있었습니다.

또한, 덧붙이자면 GitHub Actions와 GitHub Pages를 사용하여 기능 목록 등의 문서를 이번에 만든 확장 기능과 같은 모습으로 표시하고 있습니다.

금지 사항

마지막으로 명시적인 금지 목록도 소개합니다.

• main으로의 직접 commit / push / merge (가져오기는 사람이 리뷰한 후 수행)
• 이력 변경 (rebase -i, force push, reset --hard) — evolve 브랜치 상에서도 금지
• 테스트를 통과하지 못한 상태에서의 commit / push
• ROADMAP에 없는 대규모 리팩터링 (Refactoring)

실제로 돌려보았다 ― 어느 하루의 기록

서두에 올린 커밋 로그 날짜의 전체적인 모습입니다.

전야: ROADMAP.md에 아직 구현되지 않은, Markdown 에디터로서 필요한 기능들을 AI에게 제안하도록 하고, 생각나는 대로 나만의 요구사항을 기재했습니다.

주간 (본인은 업무 중): 2시간마다 사이클이 돌아가며, 태스크 리스트의 라이브 입력, 인용 블록(Quote block)의 Enter 동작, 단어 수 표시, TOC(목차) 생성 등 7번의 사이클 동안 7개의 기능 및 수정이 이루어졌습니다. 휴식 시간 등에 스마트폰으로 작동하고 있는 것을 확인하며 흐뭇한 미소를 지었습니다.

인간의 관여 포인트는 ROADMAP 작성: 제가 사용하면서 발견한 버그를 ROADMAP의 최우선 섹션에 3건 적어두었더니, 이후의 사이클이 일반 기능보다 그것을 먼저 포착하여 수정해 나갔습니다. AI와의 비동기 커뮤니케이션 채널이 백로그(Backlog) 그 자체가 되고 있다는 감각입니다.

## 버그 수정 (최우선 — 일반 기능보다 위에서부터 순차적으로 착수)
사용자 보고 (2026-07-15). 공통 배경: Webview로부터의 편집은 에코백(Echo-back) 억제
로 인해 재렌더링(Re-rendering)되지 않으므로, 파일 로드 시의 파서(Parser)에서 유효한 표기법이라도,
...

이런 식으로 똑똑한 모델을 통해 이슈를 발행하게 하면, "원인에 대한 추정"을 높은 정확도로 작성해 줍니다. 이렇게 되면 루프(Loop) 중에 수정해 줄 확률이 높아집니다.

AI에게 맡기지 않은 것 ― 디자인과 사용감

"전부 AI가 했다"처럼 보이지만, 실제로는 동작 확인을 통해서만 알 수 있는 버그나 요구사항이 많이 있었습니다. 루프(Loop, AI)가 잘하는 것은 백로그 소화, 테스트와 같은 기계적인 정확성입니다. 반면, "사용하기 불편하다"라거나 "특정 조작을 했을 때 예상과 다른 동작을 한다"는 점을 알아차리고 언어화하는 것은 인간의 일이었습니다.

헤딩 레벨을 구분할 수 없는 문제

WYSIWYG 에디터의 고전적인 문제로서, ###와 ####를 구분하기 어렵습니다. 소스 코드라면 기호의 개수로 명확히 알 수 있지만, 렌더링되면 폰트 크기의 미세한 차이(1.25em과 1em)만 남게 됩니다.

이 확장 기능에서는 헤딩의 # 마크를 지우지 않고 옅게 표시된 상태로 남겨두는 방식을 채택했습니다.

/* 헤딩의 # 마크 */
#editor .heading-hash {
color: var(--vscode-descriptionForeground);
...

겉모습은 WYSIWYG을 유지하면서, 레벨의 단서는 소스 표기법을 사용하는 방식은 Obsidian의 Live Preview 등에서도 채택하고 있어 베스트 답변이라고 생각합니다.

VS Code 기본 Markdown 프리뷰. 나란히 놓으면 구분이 가긴 하지만, "텍스트 장식"이 어느 정도 레벨인지 그것만 보고 판단할 수 있을까요?

이번에 만든 확장 기능에 의한 헤딩의 모습. 레벨에 대한 혼란이 사라졌네요.

다크 모드에서 굵은 글씨(Bold)가 강조되어 보이지 않는 문제

다크 테마에서는 가는 글자가 밝게 떠오르기 때문에, 굵은 글씨와의 대비(Contrast)를 만들기 어렵습니다. 저는 많은 소프트웨어(채팅 앱이나 브라우저, 이번에 만들고 있는 Markdown 에디터 등)에서 계속 불만을 느껴왔습니다. 최종적으로 4가지 수단을 중첩하여 시인성을 확보했습니다. 게다가 그중 3가지는 다크 테마일 때만 적용되도록 구분해 두었습니다.

더 굵게 만들었다. 우선은 솔직하게, 굵은 글씨의 웨이트(Weight)를 본문과 확실히 차이가 날 정도로 높였습니다. 다크 테마에서는 그래도 가라앉는 경향이 있어 한 단계 더 굵게 만들었습니다.

폰트 크기를 약간 키웠다. 웨이트만으로는 차이가 충분하지 않기에, 굵은 글씨 부분을 아주 조금 더 크게 만들었습니다. 헤딩 안의 굵은 글씨가 "헤딩보다 작아지지" 않도록 상대적인 지정 방식을 사용했고, 행 높이가 어긋나지 않도록 보정도 했습니다.

대비(Contrast)를 높였다. 여기서부터는 다크 테마 한정의 기교입니다. 굵은 글씨의 색상을 본문의 회색보다 밝은 순백색에 가깝게 만들어, 배경과의 명암 차이 자체를 크게 만들었습니다.

윤곽을 만들었다. 그래도 결정적인 한 방이 부족했기에, 글자 자체에 얇은 윤곽을 주어 획을 굵게 만들었습니다. 사이즈를 더 키우지 않으면서 "시각적인 굵기"만 확보하려는 의도입니다.

이러한 기교들을 통해 굵은 글씨를 상당히 보기 쉽게 만들었다고 생각합니다.

굵은 글씨의 모습.

이렇게까지 여러 가지를 할 바에는 차라리 과감하게 굵은 글씨에 대응하는 색상을 부여할 수도 있었겠지만, "어디까지나 굵은 글씨여야 하며, 색상 강조가 아니다"라는 신념이 있었습니다.

「복사했으면 좋겠다」 「저장했으면 좋겠다」

표나 Mermaid 도표는 채팅 앱으로 보내거나 자료에 붙여넣는 경우가 꽤 많습니다. 이를 위해 굳이 화면 크기를 조절하고, 네 군데의 지점에 신경을 쓰며 스크린샷을 찍는 것은 비생산적이며 화질도 좋지 않습니다. 그래서 Mermaid 도표를 고해상도(4x 스케일) PNG로 내보내기(Export)하거나 클립보드에 복사할 수 있는 기능을 넣었습니다. 도표를 그리는 데 사용된 HTML에서 깨끗한 HTML을 추출하여 html2canvas로 이미지화하는 흐름입니다.

Mermaid 도표 위에서 우클릭하면 복사하거나 파일로 저장할 수 있습니다. 참고로 오른쪽 상단의 눈 모양 아이콘 오른쪽을 클릭하면 Mermaid 편집 화면으로 전환됩니다.

이러한 요구사항은 매일 직접 사용하고 있기 때문에(도그푸딩(Dogfooding)[8]하고 있기 때문에) 나올 수 있는 것입니다. 알아차린 불만 사항을 ROADMAP에 적으면 AI가 구현해 주지만, 알아차리는 것 자체는 인간만이 할 수 있다는 것이 이 프로젝트를 통해 가장 실감한 역할 분담입니다.

리뷰와 롤백(Rollback) 운영

git을 운용하고 있기 때문에, AI가 멋대로 개발을 계속하더라도 그렇게 무섭지 않습니다. 1 사이클 = 1 커밋이므로 git log --oneline main..HEAD를 살펴보면 커밋 단위 = 기능 단위로 그날의 성과 목록이 되고, git diff main...HEAD로 전체 차분(Diff)을 읽을 수도 있습니다. 다만, 솔직히 말하면 저는 차분을 읽지 않습니다. 실제로 하는 것은 roadmap-done.md를 보면서 하나씩 손으로 만져보는 동작 확인뿐입니다. 문제가 없으면 머지(Merge), 이상한 부분이 있으면 그 자리에서 고쳐달라고 하거나 ROADMAP에 추가할 뿐입니다.

확인(하고 싶은 사람은): git log --oneline main..HEAD로 사이클 목록을, git diff main...HEAD로 전체 차분을 확인한다 (1 사이클 = 1 커밋이므로, 커밋 단위 = 기능 단위로 읽을 수 있음)

가져오기: 괜찮다면 git switch main && git merge evolve/YYYYMMDD (또는 PR을 만들어 머지)

일부만 다시 하기: 마음에 들지 않는 사이클만 git revert <hash>

전부 다시 하기: 브랜치째 삭제. main은 무사하므로, 다음 루프는 새로운 브랜치에서 처음부터 다시 시작할 수 있음

즉 최악의 경우에도 잃는 것은 "해당 브랜치의 AI 작업 크레딧"뿐입니다. 이러한 안전성 덕분에 낮에는 본업에 집중하고, 밤에는 마음 편히 잠을 잡니다.

빠지기 쉬운 함정과 배움

AI가 작성한 자동 테스트는 의미가 있다. 몇 번인가 Claude Code의 콘솔 화면에서 테스트에 실패하여 수정하는 것을 관찰한 적이 있습니다.

1 사이클로 고쳐지지 않는 버그를 분할하여 해결해 주었다. 편집 중에 캐럿(Caret)[9]이 맨 앞으로 돌아가 버리는 버그를 발견하여 ROADMAP.md에 기입만 해두었는데, 루프(Loop) 안에서 응급처치(cb86e8c) → 노드 기준 앵커(225ca19) → 블록 기준(132bd22) → 서명에 의한 인덱스 밀림 내성(8750ec2) → 오래된 에코 무시 1/2·2/2(e60bee2/1aca68d) → Mermaid 비동기 렌더링 대응(e877965)과 같이, 7 사이클 이상을 들인 근본적인 대책으로 해결해 주었습니다 (괄호 안은 커밋 해시)[10]. 문제의 난이도에 따라 적절하게 문제를 분리하여, 1회의 루프로 해결할 수 있는 크기로 만드는 운용 방식은 강력하다고 느꼈습니다.

루프의 주기. 2시간은 임시 설정입니다. 사용하는 모델(Sonnet을 쓸 것인지, Opus를 쓸 것인지)에 따라서도 달라집니다. 주간 제한에 맞춰 5시간 주기로 해도 좋을 것 같습니다.

코드는 읽을 수 없다. (제가 의도적으로 멈추지 않는 한) 24시간 쉬지 않고 2시간마다 코드를 계속 수정합니다. 도저히 차분이라 할지라도 코드를 다 읽고 있을 수는 없습니다. 믿을 수 있는 것은 동작(Behavior)뿐입니다.

브랜치 이름의 고안. 사소한 부분이지만, 브랜치 이름을 날짜로 정한 것은 실수였습니다. main에서 새로운 브랜치를 만들어 직접 작업하여 앞으로 나아가 버리면, 오래된 날짜 이름이 붙은 브랜치에 루프가 커밋을 해버려서 복잡해진 적이 있습니다. 이 운용을 돌리는 데 있어 브랜치 이름에 특별한 의미는 없으므로, 단순히 일련번호를 붙여도 좋을 것 같습니다. 혹시 더 좋은 운용 방법이 있을까요?

마치며

이러한 운용 방식은 다음과 같은 조건이 갖춰진 프로젝트에 적합하다고 생각합니다.

• 기능을 깔끔하게 분할할 수 있다
• 자동 테스트 (Automated Test)로 품질 게이트 (Quality Gate)를 만들 수 있다
• 자신이 일상적으로 사용하고 있어, 백로그 (Backlog)의 소재(불만 사항)가 자연스럽게 떠오른다

반대로, 큰 설계 판단이 연속되는 페이즈(Phase)나, 테스트로 방어할 수 없는 품질(디자인의 질감, 화면 표시 및 전환)이 중요한 시기에는 솔직하게 인간이 루프 (Loop) 안에 개입해야 합니다. 이 기사의 구성 자체가 그러하듯, **AI의 루프와 인간의 관여 포인트를 어떻게 배선(Wiring)할 것인가를 고민하는 것이 루프 엔지니어링 (Loop Engineering)**이라고 생각합니다.

앞으로는 추가적인 버그 수정[11]이나 이미지 클립보드 붙여넣기 등 백로그 소화를 계속하면서, 자신이 사용하기 편한 최강의 확장 기능을 목표로 하겠습니다.

VS Code의 Marketplace 공개는 현재로서는 고려하고 있지 않습니다. 공개한다 한들, "어디서 온지도 모를 확장 기능"이 세상에 하나 늘어날 뿐이니까요.

저에게 악의가 없음을 믿을 수 있는 분들만이 자기 책임하에 이용해 주시기 바랍니다. 저는 소스 코드를 단 한 줄도 읽지 않았습니다[12].

참고 링크

• Loop engineering: Getting started with loops
• Loop Engineering — Addy Osmani

• "What You See Is What You Get"의 약자입니다. Markdown이나 HTML의 소스 코드를 의식하지 않고, 실제 표시를 확인하며 직관적으로 편집할 수 있는 기능. ↩︎

• Claude 선생님이 정했습니다. 저는 이 분야에 문외한이라 믿을 수밖에 없습니다. ↩︎

• Opus를 사용하고 있다는 점이 엄격함을 가속화하고 있을지도 모릅니다. ↩︎

• 루프를 만들어 두는 또 다른 동기 중 하나는, 유료 결제 중인 Claude를 별로 사용하지 않고 방치하는 것이 아깝다는 마음이 있었습니다. 어차피 안 쓸 분량이라면 루프에서 최대한 다 써준다면 기분이 좋을 것 같습니다. 통상 업무에서는 회사에서 부여받은 계정을 사용하고 있기 때문에, 개인적으로 계약한 계정의 크레딧은 남는 경우가 많습니다. ↩︎

• 화면은 잘라냈습니다. ↩︎

• 실제로 1주일 정도 돌려보았지만, 한 번도 blocked 상태가 되지 않았습니다. 운이 좋았을 뿐일지도 모릅니다. 조금 더 지켜보겠습니다. ↩︎

• 원래는 자동으로 호출할 수 있을지도 모르지만, 저는 설정할 수 없어서 회피했습니다. 명시적으로 설정 파일에서 allow 하도록 설정했다고 생각했는데 말이죠. ↩︎

• 개발 중인 제품 등을 정식 출시 전에 자사 직원이 이용하며, 사용자 관점에서 품질이나 사용성을 확인하는 것입니다. ↩︎

• 문자 입력 화면에서 문자가 삽입되는 위치를 나타내는 깜빡이는 세로 막대(텍스트 커서)를 말합니다. ↩︎

• 어떻게 해결했는지는 나중에 Claude에게 물어보고, 그것을 기사에 썼을 뿐입니다. ↩︎

• 솔직히 사용하면서 "응?" 하게 되는 동작은 아직 많이 남아 있습니다. ↩︎

• "읽지 않은 코드가 무섭지 않느냐"고 생각하실 겁니다. 한 줄도 읽지 않는 대신, 당초의 동기였던 "외부와 통신하지 않는다"는 점만은 구조적으로 담보하고 있습니다. Webview에는 CSP로 default-src 'none'을 지정하여 connect-src를 허용하지 않았기 때문에, 에디터 화면으로부터의 fetch도 XHR도 WebSocket도 브라우저 레벨에서 차단됩니다. Mermaid나 KaTeX 등의 라이브러리도 모두 동봉되어 있으며, CDN 로드는 없습니다. 직접 작성한 코드에 네트워크 API 호출이 단 한 건도 없다는 점은, 이 글을 쓰면서 Claude에게 grep으로 검사시켜 확인했습니다. 하지만 이 검사를 매 사이클의 CI에 포함하는 단계까지는 이르지 못했습니다. "정말로 지키게 하고 싶은 것은 프롬프트가 아니라 기계 검사로 만든다"는 원칙이므로, 이는 향후의 과제입니다. ↩︎

Discussion