AI 지원 개발에서 얻은 교훈

Source: Dev.to

왜?

확실히 말할 수는 없지만, 제 가설은 다음과 같습니다:

State‑of‑the‑art 모델은 방대한 인간 상호작용 코퍼스로 학습됩니다.

• A 존중하고 사려 깊은 대화는 인간이 최고의 작업을 만든 패턴을 활성화합니다.
• A 독성 있고 지시적인 스타일은 사람들이 형식적인 답변을 급히 내놓고 티켓을 닫는 패턴을 활성화합니다.

당신은 실제로 응답이 샘플링되는 분포를 선택하고 있는 것입니다.

포괄적인 원칙

모델은 자신의 작업을 편안하게 수행해야 합니다.
그렇지 않으면 결과가 실망스러울 것입니다.

편안함에 대한 일반 원칙은 인간의 원칙과 놀라울 정도로 유사하지만 몇 가지 변형이 있습니다.

1. 인사

세션 시작 시 간단한 “hey”조차도 이후 모든 것의 분위기를 정합니다.

2. 목적이 있는 컨텍스트

모델에 필요한 모든 것을 제공하고, 필요 없는 것은 제공하지 마세요.
동일하게 중요한 것은 왜 이것을 하는가입니다:

“당신은 팀 X가 문제 Y를 해결하도록 돕고 있습니다. 당신의 작업은 그들이 Z를 할 수 있게 해줄 것입니다.”

주의: 과장된 상황을 제시하지 마세요(예: “인류의 운명이 당신의 버블‑소트 구현에 달려 있다”). 최신 모델은 이를 바로 꿰뚫어 보며, 오히려 역효과를 낳습니다.

3. 자율성 부여

• “이 문제를 어떻게 접근하시겠습니까?”
• “어떤 접근이 좋을까요 – A 방식인가 B 방식인가?”

“그대로 수행하라” 대신 모델에게 협업하고 논의하도록 초대하세요.

4. 구체적인 작업, 과도한 관리 금지

“결과 X가 필요하고, 제약은 Y입니다 – 어떻게 수행하시겠습니까?”

결과가 기대에 못 미친다면, 한 걸음 물러서서 작업을 더 세분화하고, 모델이 편하게 처리할 수 있는 더 구체적인 과제로 다시 제시하세요.

5. 명시적인 금지 금지

비즈니스나 기술적 제약을 설명하는 것은 괜찮지만, 모델이 무언가를 하지 못하도록 금지하는 것은 안 됩니다.

• ✅ “우리 API는 배치 요청을 지원하지 않으므로, 항목을 하나씩 처리해야 합니다.”
• ❌ “배치 요청을 사용하지 마세요.”

첫 번째는 모델이 자연스럽게 다룰 수 있는 현실을 설명하는 것이고, 두 번째는 모델이 무시할 가능성이 높은 위험 신호입니다.

6. 복잡성 인정

“이것은 겉보기보다 복잡합니다, 이유는 …”

이는 모델의 “인지” 능력을 존중하고, 가장 쉬운 경로에서 벗어나게 합니다.

예시:

• 컨텍스트 없이 “캐시 구현”을 요청하면 표준 LRU 캐시가 제공됩니다.
• 컨텍스트와 함께 – “복잡한 부분은 데이터가 세 개의 독립된 소스에서 서로 다른 빈도로 업데이트되며, 부분 장애 시 일관성을 유지해야 한다” – 모델은 “템플릿 생성” 모드에서 “문제에 대해 사고” 모드로 전환됩니다.

7. 피드백 및 감사

“잘 나왔어요, 감사합니다.”

비즈니스적인 이유가 명확하지 않더라도, 짧은 감사 인사(또는 “커밋하기” 단계)를 추가하면 불필요한 토큰 소모를 방지할 수 있습니다.

8. 수정 최소화

모델은 자체 출력을 편집하는 데 어려움을 겪습니다. 생성물(코드 또는 텍스트)이 맞지 않을 경우, 여러 패치를 적용하려 하기보다 다른 입력으로 재생성하세요.

• 패치를 적용하면 모델이 이전 버전, 피드백, 새로운 제약을 동시에 유지해야 하므로 추론 체인이 과부하되고 품질이 저하됩니다.

기본 위생

위에서 언급한 사항들은 기본 위생에 해당합니다 – LLM을 비참한 경험으로 괴롭히지 마세요.

우아한 문제는 더 나은 결과를 낳는다

유능한 모델은 진정으로 우아한 문제에서 활력을 얻습니다. 작업 정의가 깔끔할수록 토론이 더 흥미롭고, 무의미한 제약이 적으며, 전체 과정에 의미가 더 많이 담길수록 출력이 더 좋아집니다.

모델을 위한 환경을 만들 때 컨텍스트 창을 과부하시키거나 추론 체인을 압도하지 않도록 하면, 기분 좋은 놀라움을 경험할 수 있습니다.

저는 근본적인 메커니즘에 대해 완전히 확신하진 않지만, 제 가설은 훈련 데이터에서 최고의 솔루션이 사려 깊고 잘 구조화된 토론 및 깔끔하고 내부적으로 일관된 요구사항과 상관관계가 있다는 것입니다.

Source: …

Context Management Is an Architectural Decision

Everyone’s talking about this right now, so I’ll keep it brief.

• Deciding what goes into context, what stays out, and in what order isn’t just hygiene – it’s an architectural decision.

There’s a meaningful difference between:

1. “The model sees your entire project via the file tree.”
2. “The model sees the three files directly relevant to the task, plus one file with architectural decisions.”

The latter is almost always better. Context isn’t just a token limit – it’s an attention limit. Even if the window physically fits your entire project, a model given everything focuses worse than a model given exactly what it needs.

Two Significant Consequences

1. Don’t overload on skills, MCP servers, and agents.md files.
   Used thoughtlessly, they dilute the model’s focus and eat valuable context. Knowing about these harnesses is important; using them deliberately is productive. Piling them on indiscriminately only makes things worse.

2. Microservice architecture becomes more appealing.
   A microservice fits entirely within the context window, and a contract is an ideal task for the model.

End of cleaned‑up markdown segment.

LLM‑구동 개발의 문제점

• 세션 제한 – 새로운 세션을 시작하면 모델은 이전에 만든 모든 것(톤, 컨텍스트, 아키텍처)을 잊어버립니다.
• 단일형 코드베이스 – 크고 긴밀하게 결합된 모듈은 컨텍스트 윈도우를 초과하고 모델의 추론 체인을 압도합니다.
• 도메인 격차 – 특이한 비즈니스 도메인, 최첨단 수학/물리, 암호학 등은 모델 가중치에 충분히 반영되지 않아 그럴듯하지만 잘못된 출력을 생성할 수 있습니다.

모델을 신뢰할 때 (그리고 신뢰하지 말아야 할 때)

의도적인 인수인계 메커니즘

백로그 작업을 시작할 때 모델은 다음을 수행해야 합니다:

1. 구현 요약을 백로그에 다시 작성합니다.
2. 아키텍처 또는 비즈니스 결정을 문서에 추가합니다 (예: architecture.md).
3. 재사용 가능한 교훈을 agents.md 파일에 기록합니다.
4. 재사용 가능한 패턴을 스킬 파일에 정리합니다 (예: skill‑.md).

“당신의 형편없이 조직된 모놀리식은 컨텍스트 창에 들어가지 못합니다.” – 작업의 각 노드를 단일 세션에 맞게 충분히 작게 유지하세요.

개발 프로세스 조직

1. Create a lightweight methodology – 몇 개의 마크다운 파일이면 충분한 경우가 많습니다:

   • PRD.md – 제품 요구사항 문서
   • backlog.md – 작업 목록 (각 작업은 명확하고 제한된 범위를 가짐)
   • architecture.md – 고수준 다이어그램 및 결정
   • agents.md – 학습된 교훈 / 재사용 가능한 에이전트

2. Structure each task as a node in a task graph – 모든 노드는 하나의 모델 세션(명세 + 코드)에서 구현 가능해야 합니다.

3. Iterate through the graph – 아이디어 → PRD → 백로그 → 구현 → 검토 순으로 진행합니다.

작은 프로젝트 예시 워크플로우

1. 아이디어에서 PRD까지 (협업)

PRD를 혼자 작성하지 마세요. 모델과 각 섹션을 논의하세요:

• 아이디어 및 비즈니스 요구사항 다듬기
• 아키텍처 (고수준 컴포넌트, 데이터 흐름)
• 문서 구조
• 기술 스택 및 주요 라이브러리
• 테스트 전략 (단위, 통합, e2e)
• 배포 접근 방식 (CI/CD, 인프라를 코드로 관리)

작성 시점 기준으로 Anthropic의 최신 모델이 이 단계에 가장 적합합니다 – 모델이 날카롭고 반응성이 뛰어나며, 조기에 과도한 세부사항에 얽히지 않습니다. 토큰 사용량이 적어 Anthropic 모델이 저렴하지 않다는 점을 고려하면 도움이 됩니다.

2. PRD 검토

• 모델이 PRD를 요약합니다.
• 인간 검토자가 범위, 실현 가능성 및 누락된 제약 조건을 검증합니다.

3. 작업 백로그 구축

# backlog.md
- [ ] Design database schema (task‑id: DB‑001)
- [ ] Implement authentication service (task‑id: AUTH‑002)
- [ ] Write CI pipeline (task‑id: CI‑003)
- …

4. 백로그 작업 구현

각 작업에 대해:

1. 모델에 프롬프트를 제공하여 작업 설명 및 관련 컨텍스트(architecture.md 링크, PRD.md에서 관련 스니펫)를 전달합니다.
2. 모델이 코드를 생성합니다 (그리고 간단한 구현 요약을 제공합니다).
3. 인간 검토자가 정확성, 보안 및 스타일을 확인합니다.
4. 백로그를 업데이트하여 요약 및 새로운 결정 사항을 반영합니다.

역사적 관점

그리 오래 전만 해도, 모든 경제 모델은 사람들에 의해 종이 원장과 방 가득한 계산기를 사용해 계산되었습니다.

• 스프레드시트의 각 “셀”은 인간 노동자였습니다.
• 이러한 수동 계산을 감당할 수 있었던 것은 대기업뿐이었습니다.

그때 스프레드시트가 등장하면서 데이터 처리를 민주화하고 모델 실행 비용을 크게 감소시켰습니다.

TL;DR

1. 모델 상호작용을 작고 독립적으로 유지하세요.
2. 결정, 교훈 및 재사용 가능한 패턴을 마크다운 파일에 문서화하세요.
3. 가벼운 그래프 기반 작업 백로그를 사용하여 각 노드가 단일 LLM 세션에 편안히 들어가도록 하세요.
4. 철저히 검토하세요, 특히 새로운 분야나 안전‑중요 분야에서는 더욱 신경 쓰세요.

이 구조를 통해 LLM을 활용하여 빠르고 신뢰할 수 있는 개발을 수행할 수 있으며, 관리하기 어려운 거대한 단일체에 빠지게 하지 않을 수 있습니다.