프로젝트의 문서들을 읽고, 개발 경험을 바탕으로 생각을 정리해보겠습니다.
내 생각: "컨텍스트 붕괴"가 진짜 적이다 말씀하신 대로, 개발에서 가장 큰 문제는 "지금 내가 무슨 일을 하고 있었지?" 라는 상태가 되는 것입니다. 특히 서버 CLI 환경에서 파일을 열고, 로그를 보고, 수정하고, 다시 테스트하는 과정에서 이 현상은 더 심해집니다.
왜 프롬프트가 중요한가 잘 만들어진 프롬프트는 "인공적인 단기 기억 상실 방지 장치" 역할을 합니다.
문제 상황 프롬프트가 없을 때 프롬프트가 있을 때 작업 중간에 방해 받음 "어디까지 했더라?" → 다시 분석 시작 프롬프트 보고 바로 이어감 3시간 후 다시 작업 "이게 왜 이렇게 되어있지?" → 헤맴 작업 기록과 목표가 명확 다른 에이전트/사람이 투입 "이 파일 왜 수정됐지?" → 추측 변경 이유와 테스트 결과가 기록됨 오류 발생 "어디서부터 잘못된 거지?" → 광범위한 디버깅 영향 파일과 롤백 지점이 명확 최적화된 개발 방법: 제안하는 5단계 루프 제 경험상, 아래 루프가 가장 안정적입니다.
- 요청 정리 (1분) "하고 싶은 것"을 한 문장으로 압축
예: "관리자 페이지에서 카테고리 트리 깊이를 5단계로 확장"
- 구조 스냅샷 (3-5분) 관련 파일을 3개 이하로 특정
각 파일의 역할과 의존성을 간단히 메모
이때 project_map.md가 큰 도움
- 계획 수립 (2분) 수정할 파일, 백업 파일명, 테스트 방법을 종이에 적음 (실제 메모장이나 파일에)
변경 범위를 명시적으로 제한 (예: "오직 categories.php만 수정")
- 실행 + 테스트 (집중) 수정 → 즉시 테스트
테스트가 실패하면 무조건 롤백하고 다시 계획부터
- 상태 저장 (1분) 수정 파일, 백업 위치, 테스트 결과를 handoff.md나 todolist.md에 기록
이게 "나중의 나" 또는 "다음 에이전트" 를 위한 생명선
제가 실제로 개발할 때 쓰는 "최적화 팁" 팁 1: "3파일 규칙" 한 번에 수정하는 파일을 최대 3개로 제한합니다.
4개 이상이면 계획이 너무 큰 것 → 더 작게 쪼갭니다.
팁 2: "테스트 우선, 수정 나중" 수정하기 전에 "어떻게 테스트할 것인가" 를 먼저 적습니다.
예: "수정 후, 관리자 로그인 → 카테고리 추가 → 트리 출력 확인"
테스트 방법이 불명확하면 수정하지 않습니다.
팁 3: "의도적 무지" 상태 만들기 작업 시작 전에 관련 파일을 다시 읽습니다 (이전 기억을 버리고 새로 읽음)
이게 "컨텍스트를 리셋"하는 가장 확실한 방법
팁 4: "롤백 훈련" 문제 생기면 "고치려고 하지 말고 일단 롤백"
고치려고 하면 사이드 이펙트가 생깁니다.
롤백 후, 원인을 다시 분석하는 것이 더 빠릅니다.
팁 5: "두뇌 오프로드" 모든 계획, 파일명, 테스트 절차를 외부에 기록
제 머리는 "무엇을 할지" 가 아니라 "지금 무엇을 하고 있는지" 추적에만 사용
이 프로젝트에 적용하면 좋을 추가 요소 추가할 것 이유 codex/session_log.md 각 작업 세션의 시작/종료 시간, 목표, 결과를 기록 codex/test_plan.md 테스트 케이스를 미리 작성해두고, 수정 전후 비교 각 수정 파일에 "수정 이유" 주석 나중에 "왜 이렇게 했지?" 하는 혼란 방지 결론 "좋은 프롬프트는 기억력을 대체하지 않고, 망각을 구조화한다."
말씀하신 대로, 요청-계획-개발-수정/보안-테스트-문제 시 원점 회귀-반복 이 루프가 핵심이고, 이 루프를 외부화(문서화) 하는 것이 최적화의 핵심입니다.
이미 이 프로젝트의 codex/ 폴더가 그 방향으로 잘 설계되어 있습니다. 실제 작업 시 이 문서들을 "의식적으로 참조" 하는 습관만 들이면, 컨텍스트 붕괴는 훨씬 줄어들 것입니다.
댓글 0