[클로드 코드 완독 챌린지] - 4주차 : LLM 엔진 최적화와 컨텍스트 관리

LLM 엔진의 특성과 동작 원리를 이해하고, 다양한 모델을 전략적으로 조합해 쓰는 방법을 살펴보자. 나아가 메모리와 컨텍스트 창을 어떻게 관리해야 불필요한 비용을 줄이고 원하는 답변을 빠르게 얻을 수 있는지도 알아보자.

LLM 엔진 최적화

• Opus
  • 최고 수준의 추론 능력과 문제 해결 능력을 가진 모델
  • 대규모 아키텍처 설계, 고급 알고리즘 최적화 처럼 높은 작업에 적합
  • 토큰 비용이 가장 높고 응답 속도는 다소 느림
• Sonnect
  • 코드 이해와 생성 능력이 균형 잡혀 있음
  • 복잡한 아키텍처 설계, 대규모 리팩토링, 심층 코드 분석에 적합
  • 프로젝트 초기화 단계에서 유용
• Haiku
  • 가장 빠른 응답 속도와 낮은 토큰 비용이 강점
  • 간단한 코드 수정, 문서화, 프로토타입 제작, 반복적 개발 작업에 효율적

전략적으로 다음처럼 선택해 사용

• Opus : 복잡하고 고난이도의 문제
• Sonnect : 초기 설계나 중요 코드 리뷰
• Haiku : 일상적 수정이나 대량 배치 작업

프롬프팅 전략과 사고 패턴

LLM 의 성능은 문제를 어떻게 쪼개고 사고 흐름을 설계하느냐에 따라 같은 모델이라도 결과가 크게 달라진다.

CoT(Chain of Thought)

가장 기본적인 사고 전개 방식으로, 문제를 단계별로 풀어나가도록 유도한다.

> API 응답 시간이 느린 문제를 단계별로 해결해줘
1단계 : 현재 응답 시간 측정 및 병목 지점 식별
2단계 : 데이터베이스 쿼리 성능 분석
3단계 : 네트워크 지연 요인 검토
4단계 : 캐싱 전략 검토 및 개선안 제시
5단계 : 최적화 솔루션 구현 및 검증

• 사용
  • 디버깅, 최적화 같은 복잡한 원인 추적
  • 분석 보고서나 사고 과정 기록이 필요한 상황

Sequential Thinking

CoT 보다 나아가, 작업을 작은 단위로 쪼개고 각 단계를 독립적으로 확인하면서 진행하는 방식이다. 중간 산출물을 점검하고 다음 단계로 이어지게 함으로써 장기적인 작업에도 안정성을 제공한다.

> 마이크로서비스를 단계별로 분리해줘
1. 먼저 서비스 경계 식별(완료 후 확인)
2. 데이터베이스 분리 계획(1단계 기반)
3. API 게이트웨이 설정(2단계 완료 필요)
4. 서비스 간 통신 구현(3단계 의존)
5. 트랜잭션 관리 구현(모든 서비스 준비 후)
각 단계의 산출물을 다음 단계의 입력으로 사용해

• 사용
  • 대규모 시스템 설계
  • 의존성이 많은 프로젝트 계획

ToT(Tree of Thought)

단순히 한 경로만 따라가지 않고, 여러 가능성을 동시에 탐색하면서 최적의 답을 고르는 전략이다. 다양한 대안을 검토하고 선택하는 상황에서 강력하다.

> 최적의 데이터베이스 설계를 찾아줘
경로1 : NoSQL(MongoDB)
	- 장점 분석
	- 단점 분석
	- 적합성 점수
경로2 : SQL(PostgreSQL)
	- 장점 분석
	- 단점 분석
	- 적합성 점수
경로3 : 하이브리드
	- 장점 분석
	- 단점 분석
	- 적합성 점수
모든 경로를 평가한 후 최종 추천

• 사용
  • 기술 선택, 아키텍처 의사결정
  • 복수의 솔루션을 비교,평가할 때

Reflective Thinking

한 번에 답을 내고 끝내지 않고, 자체 피드백을 거쳐 반복적으로 개선하는 방식

> API 엔드포인트를 구현하고 반복 개선해줘.
반복1 : 기본 기능 구현
	- 자체 평가 : 동작하지만 에러 처리 부족
반복2 : 에러 처리 추가
	- 자체 평가 : 안정적이지만 성능 이슈 가능
반복3 : 캐싱과 최적화 적용
	- 자체 평가 : 성능 좋지만 보안 고려 필요
반복4 : 보안 강화
	- 자체 평가 : 최종 평가 및 완료

• 사용
  • 코드 품질 개선, 리팩토일
  • 제품 설계안 검토 및 개선 사이클

실제 현업에서는 조합해서 쓰는 경우가 많다. 예를 들어 시스템 설계 시 ToT 로 후보안을 고르고, Sequential Thinking 으로 구현 단계를 밟으며, Reflective Thinking 으로 품질을 높이는 식이다.

Ultra Thinking

클로드 코드가 제공하는 고급 사고 모드로, 앞서 설명한 여러 프롬프팅 전략을 복합적으로 활용한다.

클로드 코드에서는 문제의 복잡도에 따라 3단계 Thinking Budget 을 제공한다.

• think : 기본 수준 사고
• megathink : 심화 사고
• ultrathink : 최고 난도 사고

이 모드는 클로드 코드 터미널 인터페이스에서만 사용 가능하다.

1. 문제의 복잡도가 감지되면 자동으로 활성화되거나
2. 사용자가 명시적으로 요청할 수 있다.

# 명시적 요청
> 이 문제를 ultrathink 모드로 분석해줘.
레거시 모놀리스를 클라우드 네이티브 마이크로서비스로 전환하는 완전한 전략을 수립해

토큰 최적화와 컨텍스트 관리

효율적인 프롬프팅의 핵심은 토큰을 아껴 쓰면서도 필요한 맥락을 충분히 전달하는 것이다.

> src/auth 모듈의 주요 문제만 요약해줘

즉, 전체를 한 번에 다루려 하기보다는 먼저 큰 그림을 잡고, 이후에 점진적으로 필요한 부분을 깊게 탐구하는 방식이 효과적이다.

> 먼저 프로젝트 구조만 파악해줘
> 이제 핵심 모듈만 상세 분석해줘
> 문제가 있는 부분만 깊에 들어가줘

이러한 프롬프팅 습관을 일회성으로 끝내지 않고 프로젝트 차원에서 재사용 가능한 규칙으로 정리하는 방법도 있다. 바로 프로젝트 루트에 CLAUDE.md 파일을 두고, 그 안에 ‘이 프로젝트에서 클로드와 상호작용할 때 지켜야 할 프롬프트 전략’을 기록하는 것이다.

예상치 않은 토큰 소모를 방지하기 위해 클로드 코드에서 설정으로 한계치를 설정할 수 있다.

// .claude/settings.json
{
	"env":{
			"CLAUDE_CODE_MAX_OUTPUT_TOKENS":"4096",
			"MAX_MCP_OUTPUT_TOKENS":"25000"
		}
}

또한 프로젝트 폴더 내 불필요하게 과도한 데이터를 읽지 않기 위해 예외 처리를 할 수 있다.

$ echo "node_modules/" >> .claudeignore

요약하자면 효율적 전략 선택 → 고급 모드 → 실전 최적화 습관 3단계 프레임을 사용하면 똑똑하고 경제적으로 활용할 수 있다.

---

메모리 시스템 활용

실무에서는 용도별로 메모리를 분리하는 것이 효율적이다.

메모리 파일 분리 전략

.claude/
  memory/
    00-brief.md              # 프로젝트 개요, 목표
    10-architecture.md       # 아키텍처 결정(ADR)
    20-glossary.yaml         # 용어집
    30-standards.md          # 코딩 규칙, 리뷰 체크리스트
    40-runtime.md            # 성능/리소스 제약
    90-known-issues.md       # 반복되는 문제 & 우회책		

이렇게 나눠진 메모리는 CLAUDE.md 에 인덱스처럼 레퍼런스 링크를 두어 클로드가 필요 시 참조하도록 만든다.

이 프로젝트에서 참고할 메모리 파일 목록:
- 프로젝트 개요: memory/00-brief.md
- 아키텍처 결정: memory/10-architecture.md
- 용어집: memory/20-glossary.yaml
- 코딩 규칙: memory/30-standards.md
- 성능 제약: memory/40-runtime.md
- 알려진 문제: memory/90-known-issues.md

• 프로젝트 초반 → brief(프로젝트 개요), glossary(용어집),standard(코딩 규칙) 세 파일만으로 시작
• 진행 중 → 필요에 따라 architecture(아키텍처 결정) 와 runtime(성능 제약) 으로 확장
• 운영 단계 → known-issues(알려진 문제)를 추가해 반복 문제를 기록

대화 프롬프트에서는 전체 메모리를 불러오기보다, 현재 작업에 필요한 파일만 선택해서 사용하는 방식이 이상적이다.

> 이 작업엔 memory/10-architecture.md 와 memeory/30-standards.md 를 참고해

요약하자면 단일 CLAUDE.md → 모듈화된 메모리 시스템 → 필요시 선택적 사용 이라는 흐름으로 관리하면, 팀 혐업에서도 충돌을 최소화하고, 장기 프로젝트에서도 확장성과 유지보수성을 확보할 수 있다.