안녕하세요, David입니다.

저는 소프트웨어 개발의 미래를 일주일 만에 발견한 척할 만큼 젊지 않습니다.

제가 실제로 한 일은 프로젝트의 이해도를 유지하려 노력하면서, AI 보조 (AI assistance)를 받아 작은 로컬 앱을 구축하는 데 진지하게 일주일을 보낸 것입니다.

그 결과는 제가 예상했던 것보다 더 어려웠고, 더 흥미로웠습니다.

코딩 에이전트 (coding agent)는 빠르게 움직일 수 있었습니다. 때로는 매우 빠르게 말이죠. 코드를 생성하고, 리팩터링 (refactor)하고, 보일러플레이트 (boilerplate)를 작성하며 프로젝트를 진전시키는 데 도움을 줄 수 있었습니다.

하지만 범위 (scope)를 넓히거나, 잘못된 가정을 유지하거나, 제가 지루하게 유지하고 싶었던 무언가를 "친절하게" 재설계하거나, 구현 작업이 될 의도가 전혀 없었던 컨텍스트 (context)에 따라 행동할 수도 있었습니다.

그 일주일 동안 얻은 주요 교훈은 간단했습니다:

AI 보조 개발은 단지 코딩의 문제만이 아닙니다.

그것은 컨텍스트 관리 (context management)의 문제입니다.

그래서 저는 가벼운 루프 (loop)를 사용하기 시작했습니다:

Task Brief      -> 문제를 깊이 생각하기
Codex Contract  -> 코딩 에이전트에게 제한된 지침 세트 제공
Final Review    -> 테스트, 검사, 패치 및 프로젝트 메모리 업데이트

그 결과는 완벽한 AI 코딩이 아니었습니다.

그 결과는 검토 가능한 (reviewable) AI 코딩이었습니다.

그 차이가 기록할 만큼 중요하다고 느껴졌습니다.

세 편의 기사

저는 그 첫 일주일 동안 세 편의 동반 기사를 게시했습니다.

각 기사는 독립적으로 존재하도록 의도되었지만, 함께 모이면 워크플로 (workflow), 메모리 시스템 (memory system), 그리고 제가 진지하게 받아들일 가치가 있다고 생각하는 반론들을 설명합니다.

1. 제대로 된 바이브 코딩 (Vibe Coding Done Right)

이것은 접근하기 쉬운 시작점입니다.

이 기사는 제가 ChatGPT, Codex, VS Code, PowerShell, 그리고 LM Studio를 통한 로컬 LLM (Large Language Model)을 사용하여 1인 개발자로서 어떻게 가벼운 사양 기반 (spec-driven) 워크플로를 사용했는지 설명합니다.

핵심은 정확한 스택 (stack)이 아닙니다.

핵심은 분리 (separation)입니다:

• 사고(thinking), 학습(learning), 리뷰(review)를 위한 하나의 장소;
• 경계가 정해진 구현(bounded implementation)을 위한 또 다른 장소;
• 다음 작업의 근거를 유지하는 기억으로서의 문서화(documentation).

2. AI 보조 개발에서 프로젝트 기억으로서의 문서화 (Documentation as Project Memory)

이 부분은 좀 더 기술적인 사례 연구(case-study)입니다.

저를 가장 놀라게 했던 부분은 문서화(documentation)였습니다.

다듬어진 매뉴얼로서의 문서화가 아닙니다.
끝나고 나서 하는 번거로운 작업으로서의 문서화도 아닙니다.
아무도 읽지 않는 문서화도 아닙니다.

프로젝트의 기억(project memory)으로서의 문서화입니다.

이 프로젝트는 아키텍처(architecture), 데이터 형태(data shapes), API 계약(API contracts), 그리고 기술 부채(technical debt)를 보존하기 위해 소수의 살아있는 문서(live documents) 세트를 사용했습니다.

해당 문서들은 작업이 끝난 후 언젠가 업데이트하는 것이 아니라, 구현 트랜잭션(implementation transaction)의 일부로서 업데이트되었습니다.

덕분에 다음 AI 보조 작업이 더 깨끗한 시작점을 가질 수 있었습니다.

3. 방어적 AI 엔지니어링 (Defensive AI Engineering): 프로젝트 기억 루프 강화하기

이 부분은 합리적인 회의론자들을 위한 것입니다.

명백한 비판들이 타당하기 때문입니다.

이것은 그저 문서화 부채(documentation debt)가 아닌가요?

IDE 에이전트(agents)가 저장소(repo)를 읽을 수 있는데, 왜 수동으로 컨텍스트(context)를 전달해야 하나요?

AI가 스스로의 문서를 업데이트하는 것을 신뢰할 수 있나요?

이 방식이 프로토타입을 만드는 단독 개발자 한 명을 넘어 확장(scale)될 수 있나요?

저는 이러한 질문들이 그냥 무시되어야 한다고 생각하지 않습니다.

세 번째 글은 이 워크플로(workflow)를 보편적인 정답으로 판매하려는 것이 아니라, 오히려 스트레스 테스트(stress-test)하려는 저의 시도입니다.

지원 리포지토리 (Supporting repo)

사례 연구에서 사용된 지원 파일들이 포함된 작은 GitHub 리포지토리(repo)도 공개했습니다.

이것은 프레임워크(framework)나 패키지(package)가 아닙니다.

그저 결과물의 흔적(artifact trail)일 뿐입니다: 프로젝트 기억(project-memory) 파일, 예시 Codex 계약(Codex Contracts), 그리고 개발 시퀀스(development sequence)에서 나온 지원 노트들입니다.

davidvk89 / ai-project-memory-loop

AI 보조 개발에서 살아있는 프로젝트 문서화를 기억으로 사용하는 가벼운 워크플로.

ai-project-memory-loop

AI 보조 개발 중 살아있는 프로젝트 문서화를 기억으로 사용하는 일주일간의 사례 연구를 위한 지원 파일들입니다.

이 저장소(repository)는 프레임워크, 패키지 또는 완전한 방법론이 아닙니다. 이는 AI 보조 개발(AI-assisted development)을 제한적이고(bounded), 검토 가능하며(reviewable), 인간 주도적(human-led)으로 유지하는 것에 관한 세 편의 동반 기사 뒤에 남겨진 결과물(artifact trail)입니다.

핵심 아이디어 (Core idea)

AI 보조 개발에는 컨텍스트(context) 문제가 있습니다.

코딩 에이전트(Coding agents)는 빠르게 움직일 수 있지만, 오직 주어진 컨텍스트를 바탕으로만 작동합니다. 긴 계획 대화에는 거부된 아이디어, 약어, 미래 계획, 일시적인 가정, 그리고 불완전한 결정들이 포함될 수 있습니다. 인간에게 이는 정상적인 설계 탐색 과정입니다. 하지만 코딩 에이전트에게 이는 의도치 않은 허가(accidental permission)가 될 수 있습니다.

여기에 기록된 워크플로우(workflow)는 가벼운 루프(loop)를 사용합니다:

Task Brief (작업 브리프)      -> 문제 탐색
Codex Contract (코덱스 계약)  -> 제한된 구현 정의
Final Review (최종 검토)    -> 테스트, 검사, 패치 및 프로젝트 메모리 업데이트

프로젝트 메모리 파일은 작업이 끝난 후 언젠가가 아니라, 작업의 일부로서 업데이트됩니다. 이는...

View on GitHub

이 글을 게시하는 이유

저는 AI 엔지니어링에 대한 권위를 주장하는 것이 아닙니다.

저는 AI와 함께 개발하며 일주일을 보냈고, 거의 즉시 컨텍스트 드리프트(context drift)를 경험했으며, 프로젝트를 덜 취약하게 느껴지도록 만드는 워크플로우를 우연히 발견한 사람일 뿐입니다.

그것이 공유할 가치가 있다고 생각했습니다.

어쩌면 다른 누군가도 프로젝트를 기술적으로는 실행되지만 더 이상 이해할 수 없는 신비로운 파일 더미로 만들지 않으면서, AI 코딩 도구를 사용하려고 시도 중일지도 모릅니다.

만약 그렇다면, 이 내용 중 일부가 도움이 되기를 바랍니다.