AI 멀티플렉싱 워크플로우: ADHD급 생산성 향상기 (2편)

공통 워크플로우 방법론

안녕하세요! 1편에서 AI 스택 소개와 전체 개요를 다뤘다면, 이번 2편에서는 모든 LLM에게 공통으로 적용하는 워크플로우 방법론을 구체적으로 파헤쳐보겠습니다.

이 방법론은 제가 AI 강의를 매주 하면서 + 실제 업무에서 매일 적용하면서 다듬어진 것들이라, 어떤 AI 도구를 쓰든 상관없이 적용할 수 있습니다.

🎯 6단계 워크플로우 전체 구조

graph LR
    A["1️⃣ Context Window<br/>새로 열기"] --> B["2️⃣ 정리된 Context<br/>제공하기"]
    B --> C["3️⃣ 답변 포맷<br/>생각하게 하기"] 
    C --> D["4️⃣ 명확한<br/>Request"]
    D --> E["5️⃣ Feedback<br/>과정"]
    E --> F["6️⃣ Context 문서<br/>업데이트"]
    F -.-> A
    
    style A fill:#e1f5fe
    style B fill:#e8f5e8
    style C fill:#f3e5f5
    style D fill:#ffebee
    style E fill:#fffde7
    style F fill:#fce4ec

경험상 어떤 AI든 상관없이 이 방식으로 일을 시키면 훨씬 좋은 결과가 나옵니다. 이제 각 단계를 실제 예시와 함께 자세히 살펴보겠습니다!

1️⃣ Context Window를 자주 새로 연다

왜 이게 중요한가?

AI들은 대화가 길어질수록 초기 맥락을 잃어버리는 경향이 있습니다. 특히 복잡한 코딩 작업이나 긴 문서 작업을 할 때 이 현상이 심해져요.

실전 적용법

❌ 나쁜 예시:

(50번의 대화가 이어진 후)
사용자: 아 그리고 처음에 말한 TypeScript 설정도 다시 봐줘
AI: 죄송합니다. 어떤 TypeScript 설정을 말씀하시는 건지...?

✅ 좋은 예시:

(새 창을 열고)
사용자: 다음 프로젝트 맥락을 참고해서 TypeScript 설정을 검토해줘:
[프로젝트 맥락 + 기존 대화 요약 + 구체적 요청]

언제 새 창을 여는가?

• 대화 횟수가 20번 넘어갈 때
• 주제가 바뀔 때 (코딩 → 문서화)
• AI가 맥락을 놓치기 시작할 때

2️⃣ 미리 정리된 Context를 던져서 생각하게 한다

이게 가장 중요한 단계입니다. 바로 답을 달라고 하지 말고, 먼저 상황을 파악하게 해야 해요.

Before & After 비교

❌ 개발자들이 자주 하는 실수:

코드 리뷰해줘.

class UserService {
  constructor(private db: Database) {}
  
  async createUser(userData: any) {
    return this.db.users.create(userData);
  }
}

✅ 개선된 방식:

다음 맥락을 먼저 파악해줘:

**프로젝트**: TypeScript + NestJS 기반 백엔드 API
**현재 상황**: User 도메인 서비스 레이어 구현 중
**요구사항**: 타입 안정성, 에러 핸들링, 유효성 검사 필요
**현재 이슈**: any 타입 사용으로 타입 안정성 부족

위 맥락에서 다음 코드의 문제점과 개선 방향을 먼저 분석해줘:

[코드]

그 다음에 구체적인 개선된 코드를 제안해줘.

제가 자주 쓰는 Context 템플릿

## 프로젝트 맥락
- **기술 스택**: [구체적인 기술 스택]
- **현재 작업**: [지금 하고 있는 일]
- **목표**: [달성하려는 것]
- **제약사항**: [고려해야 할 제약들]

## 현재 상황
[구체적인 현재 상황 설명]

## 요청사항
[구체적인 요청 + 원하는 결과물 형태]

3️⃣ 좋은 답변 포맷을 미리 제시하거나 생각하게 한다

핵심 아이디어

“이런 형태로 답변해줘” 보다는 “어떤 형태로 답변하는 게 좋을지 먼저 생각해봐”

실전 예시

❌ 지시적인 방식:

다음 형태로 답변해줘:
1. 문제점 3가지
2. 해결방안 3가지  
3. 코드 예시

✅ 사고하게 만드는 방식:

이 상황에서 가장 도움이 될 만한 답변 구조를 먼저 제안해봐.
어떤 순서로, 어떤 형태로 정보를 제공하는 게 좋을까?

그 다음에 제안한 구조에 따라 실제 답변을 해줘.

왜 이렇게 하는가?

AI가 스스로 생각하는 과정을 거치면 더 체계적이고 맥락에 맞는 답변을 합니다. 단순히 틀에 맞춰 답하는 것보다 훨씬 질이 높아져요.

4️⃣ 명확한 Request를 한다

애매한 요청의 문제점

❌ 애매한 요청들:

• “코드 좀 봐줘”
• “이거 어떻게 생각해?”
• “더 좋게 만들어줘”

✅ 명확한 요청들:

• “TypeScript 타입 안정성 관점에서 이 코드를 검토하고, 구체적인 개선 코드를 제안해줘”
• “성능 최적화 관점에서 이 React 컴포넌트의 리렌더링 이슈를 분석하고 해결방안을 제시해줘”
• “유지보수성을 높이기 위해 이 함수를 3개 이하의 작은 함수로 분리해줘”

좋은 Request의 구성요소

1. 관점/목적 (성능? 가독성? 보안?)
2. 구체적 작업 (분석? 구현? 리팩토링?)
3. 결과물 형태 (코드? 문서? 가이드?)
4. 제약조건 (기존 코드 유지, 특정 라이브러리 사용 등)

5️⃣ Feedback 과정을 통해 계속 생각하게 만든다

핵심 철학

한 번에 완벽한 답을 기대하지 말고, 피드백을 통해 점진적으로 개선하는 것이 훨씬 효과적입니다.

실전 Feedback 패턴

1차 답변 후:
"좋은 방향이야. 그런데 [구체적 피드백]. 
이 부분을 고려해서 다시 개선해줄 수 있을까?"

2차 답변 후:
"거의 다 됐는데, [세부 조정 요청].
실제 프로덕션에서 사용할 때 [구체적 상황]도 고려해서 마지막으로 다듬어줘."

효과적인 Feedback 방법

1. 좋은 점 먼저 인정: “접근법은 좋은데…”
2. 구체적인 개선점 제시: ”○○ 부분에서 ××를 고려하면…”
3. 맥락 추가: “실제로는 ○○한 상황도 있어서…“

6️⃣ Context 문서들을 지속적으로 업데이트한다

왜 이게 필요한가?

AI들이 들쭉날쭉하는 이유 중 하나가 프로젝트 맥락을 매번 새로 설명해야 하기 때문입니다. 이를 해결하기 위해 체계적인 Context 문서를 관리해야 해요.

제가 관리하는 Context 문서들

📁 .ai-context/
├── project-config.md          # 프로젝트 기본 정보
├── tech-stack.md             # 기술 스택 상세 정보  
├── coding-standards.md       # 코딩 컨벤션
├── current-tasks.md          # 현재 진행 중인 작업들
├── common-issues.md          # 자주 발생하는 이슈들
└── prompt-templates.md       # 자주 쓰는 프롬프트 모음

project-config.md 예시

# 프로젝트 설정

## 기본 정보
- **프로젝트명**: Service Interface Mock
- **기술 스택**: Node.js + TypeScript + Express
- **목적**: 마이크로서비스 개발시 의존성 Mock 서버

## 현재 아키텍처
- REST API 기반
- JSON 설정 파일로 응답 정의
- Docker 컨테이너로 배포

## 개발 철학
- 타입 안정성 최우선
- 간단하고 직관적인 설정
- 개발 생산성 중심

## 제약사항
- 기존 API 호환성 유지
- 성능보다는 유연성 우선
- 외부 의존성 최소화

업데이트 시점

• 새로운 요구사항 추가될 때
• 기술 스택 변경될 때
• 반복되는 질문이 생길 때
• 프로젝트 방향성이 바뀔 때

🚀 실전 적용 사례

전체 워크플로우 적용 예시

실제로 제가 새로운 API 엔드포인트를 개발할 때 이 워크플로우를 어떻게 적용하는지 보여드릴게요:

1단계: 새 창 열기

(Claude Code에서 새 대화 시작)

2단계: Context 제공

다음 프로젝트 맥락을 파악해줘:

[project-config.md 내용 첨부]

현재 상황: 사용자 인증 API 엔드포인트 추가 필요
요구사항: JWT 토큰 기반, 입력 유효성 검사, 에러 핸들링 포함

3단계: 답변 포맷 생각하게 하기

이런 API 엔드포인트 개발 요청에 대해 
어떤 순서와 구조로 답변하는 게 가장 도움이 될까?

4단계: 명확한 Request

제안한 구조에 따라서:
1. TypeScript 타입 안정성을 고려한 엔드포인트 설계
2. 입력 유효성 검사 로직
3. JWT 토큰 처리 로직
4. 통합된 최종 코드
를 제공해줘.

5단계: Feedback

좋은 방향이야! 그런데 실제 운영환경에서는 
rate limiting도 고려해야 할 것 같아. 
이 부분도 추가해서 개선해줄 수 있을까?

6단계: Context 업데이트

# current-tasks.md에 추가
- [x] 사용자 인증 API 구현
- 다음: rate limiting 미들웨어 구현

💡 각 AI 도구별 적용 팁

Cursor Pro에서

• 프로젝트 전체 맥락을 Chat에서 제공
• 파일 단위로 구체적인 요청

Claude Code에서

• 복잡한 로직은 단계별로 나누어서
• 3시간 제한 고려해서 핵심만 집중

Gemini에서

• 문서화 작업시 이 워크플로우가 가장 효과적
• Research 단계에서 Context가 특히 중요

ChatGPT에서

• 감정노동 관련 작업에도 이 구조 적용
• 이메일 작성시 Context = 상대방 정보 + 목적

🔚 마무리하며…

이 6단계 워크플로우는 어떤 AI든 상관없이 적용할 수 있는 범용적인 방법론입니다.

가장 중요한 건 AI를 단순한 답변 기계로 쓰지 말고, 함께 생각하는 파트너로 활용하는 것입니다.

다음 3편에서는 워크스페이스 운영 실전기를 다뤄보겠습니다. 실제로 5~8개의 Cursor 인스턴스를 어떻게 효율적으로 관리하는지, Remote SSH vs Native 환경을 어떻게 구성하는지 상세히 공유할 예정입니다!

여러분은 AI와 대화할 때 어떤 패턴을 사용하고 계신가요? 댓글로 공유해주세요!

---

이 시리즈의 다른 글들:

• 1편: AI 스택 소개와 전체 개요
• 3편: 워크스페이스 운영 실전기 (곧 공개)