Our News
Copyright 2023 © Wavebridge, Inc. All rights reserved.
Our News
Our News
편집자 Rebecca의 말: 2026년 초, 웨이브릿지 내부 개발 세션에서 에릭(Head of AI)은 실전에서 체득한 컨텍스트 엔지니어링 기법을 공개했다. 우리가 EP3에서 컨텍스트 윈도우의 함정을 이야기했다면, 이번에는 그 함정을 뛰어넘는 해법을 나누려 한다.
컨텍스트 윈도우를 다루며 흔히 듣는 말이다. “클로드 코드 쓰실 때 ‘API 사용량 한도 다 찼습니다, 잠시 쉬세요’라는 메시지가…” 귓가에 남을 법한 문장이다.
에릭이 뒤이어 말했다.
“저는 이거 쓰면서 한 번도 그런 소리 못 들었어요. 스텝을 나누니까.”
그 말은 단순한 경험담이 아니었다. 이날 세션의 도입부이자, 이 방법론이 탄생한 배경이기도 했다.
에릭은 종종 이런 말을 했다.
“PRD 어떻게 만들고, 세분화는 어떻게 해야 하냐. 말은 좋죠. 그래서 그것도 AI에게 시키면 돼요.”
AI가 작업을 대신 해주는 것과 AI에게 일을 시키는 구조를 디자인하는 것은 완전히 다른 문제다. 후자에는 고민과 설계가 필요하며, 이 방법론의 출발점이었다.
“이제부터는 모든 걸 .md로 작성하세요. 마크다운이 표준이라고 생각하세요. 백엔드와 프론트엔드가 JSON으로 대화하듯, 이제 LLM과 사람도 마크다운으로 대화합니다.”
에릭이 설면한 Markdown이 표준이 된 이유는 단순했다.
에릭은 웃으며 말했다. “Markdown 자체를 모른다고 해도, AI가 알아서 정말 잘 써줘요.”
에릭이 이날의 하이라이트라고 소개한 방법론은 두 개의 Markdown 파일로 압축됐다.
PRD는 헌법 같은 존재다. 무슨 기능을, 왜, 어떤 구성으로 만들 것인지 최상단에서 정의하는 문서다.
“책을 만든다고 생각하세요. 목차 있고, 1장 2장 3장 나가듯이… 정보를 구조화시키는 거예요. 컨텍스트를 구조화시키는 거죠.”
Tasks.md는 PRD를 실행 가능한 단위로 쪼갠 작업 목록이다. AI가 직접 읽어서 처리할 수 있도록 만든, 단계별 실행 지침의 집합이다.
개발 과정에서 축적된 정보들, 즉 설계 노트, API 문서, 기존 코드 설명들은 모두 별도 .md로 저장하고 링크로 연결한다.
이 세 가지가 모이면, AI는 “악보”를 받고 즉흥 연주를 넘어 설계대로 작동하게 된다.
에릭은 LLM의 한계도 잊지 않았다.
“라이브러리를 쓴다면, LLM은 보통 2024년 정도의 정보만 알게 됩니다.”
LLM의 학습 데이터는 과거 특정 시점까지만 포함되어 있기 때문이다. 이를 학습데이터의 컷오프라고 한다. 최신 라이브러리나 API가 등장했을 때, AI는 그 내용을 모를 수 있다.
“조금 자존심 상할 수도 있지만, 최신 버전의 라이브러리 URL을 AI에게 알려드려야 합니다. 마치 팀원한테 ‘이거 최근에 나온 거니까 참고해’라고 하는 것처럼요.”
LLM을 ‘동료’가 아니라 문맥을 가진 존재로 대하라는 의미였다.
에릭이 준비한 두 개의 파일을 내려받으면, 실제 워크플로우는 이렇게 시작됐다.
예를 들어,
“Node.js와 Vite로 OTC 작업 애플리케이션을 만들겠다”
…라는 시나리오가 주어지면, AI는 create-prd.md를 기반으로 PRD 문서를 자동으로 생성하고 docs 폴더에 저장한다.
중요한 건, 이 과정에서 AI가 스스로 질문을 제기하도록 설계돼 있다는 점이다.
"폴링 주기는 어떻게 할까요?" "시스템 큐 구조는 어떤가요?"
이런 질문을 던지며 PRD는 점점 완성된다. 일종의 핑퐁 대화처럼 말이다.
PRD가 자리 잡으면, 다음 단계는 Tasks 생성이다.
@generate-tasks.md 지시를 통해 AI는 Tasks.md를 만든다. 큰 단계부터, 다시 세부 서브 태스크까지 만들게 된다.
예를 들면 아래와 같다.
## Task Progress
### Step 0: Create Feature Branch
- [x] 0.1 브랜치 생성
### Step 1: Core Implementation
- [ ] 1.1 서버 초기화
- [ ] 1.2 연결 핸들러
- [ ] 1.3 메시지 파싱
이 구조는 제법 낯익다. 바로 Epic → Story → Task의 형태다.
AI는 Tasks를 읽고 스스로 플래닝을 하고, 사람은 Step 단위로 실행 → 검토 → 리셋을 반복한다. 3~4분 간격으로 작은 사이클이 돌아간다.
“이런 방식으로 하면, 서머라이즈도 거의 안 일어나요. 스텝을 2~3개 붙여도 문제가 없었어요.”
Tasks.md 최상단에는 항상 이런 참고 링크가 있다:
## References
- [PRD](./prd.md)
- [아크 서버 구조](./references/arc-architecture.md)
- [기존 REST API](./references/rest-api.md)
이제 과거 대화나 긴 채팅이 아니라, 링크로 연결된 문서들이 컨텍스트를 담고 있다. 이 방식 덕분에 세션을 나눠도, 작업의 중심은 잃지 않는다.
에릭은 다시 한 번 자신의 경험을 풀어놨다.
“처음엔 코드 생성이 좋아서 빨리빨리 했었어요. 근데 나중에 버그 때문에… 고생을 진짜 많이 했죠.”
설계와 문서화에 시간을 쓰기 시작하면서, 실행 단계에서 피드백과 수정은 크게 줄었다고 했다. 코드의 품질로 올라가기 까지 했다. 즉, AI는 코드를 쓰는 사람이 아니라, 일을 구조화한 사람의 능력을 증폭시키는 도구였다.
“Claude만이 아니라, Cursor, Gemini, OpenAI에서도 써봤어요.”
두 파일 시스템, 그 철학은 보편적이었다. 일을 잘게 나누고, 문서로 구조화하고, AI가 읽을 수 있게 제공하면 모델이 달라도 결과는 유의미했다고 밝혔다.
강의가 끝날 무렵, 그는 다시 한 번 주요 메시지를 꺼냈다.
“결국 프로세스예요. 어떤 프로세스로 일을 시킬 것인가, 컨텍스트는 어떻게 줘서 집중하게 할 것인가.”
AI 시대의 개발자는 타이핑 속도가 아니라 맥락 설계의 속도와 정합성으로 평가받는다.
PRD는 헌법이고, Tasks는 악보고, AI는 연주자다. AI시대가 왔다해도, 지휘는 여전히 사람의 몫이다.