CS146S: The Modern Software Developer 3주차 정리

README.md

CS146S: The Modern Software Developer Week 3: The AI IDE 정리

실습

스킵, 굳이 이미 있는 SDK 사용해서 간단한거 만드는거라 쉬워서 만들 필요 없다 생각함.

발표 자료

발표 영상이 공개된게 아니라, 그냥 PPT 보고 추측해서 부족한 부분은 채움. 뇌피셜이 좀 섞여있을 수 있음.

첫 프롬프트부터 최적의 IDE 설정까지

IDE의 탄생과 발전을 소개하면서 AI IDE가 발전의 최신 단계라고 설명함. 개발 작업의 대부분이 IDE 안에서 이루어지므로, AI 강화의 가장 자연스러운 접점이라는 논리.

AI IDE의 기능

1. 기본: 자동완성, 싱글/멀티 라인 수정 등
2. AI-Native: Background agents, MCP, PR review

AI IDE 내부 작동 원리

• Tab-complete (자동완성):
  1. 현재 코드 주변의 작은 컨텍스트 윈도우를 암호화하여 전송
  2. 서버에서 infilling LLM 실행 (코드의 빈 부분을 채우는 모델)
  3. 제안을 다시 전송하여 IDE에 표시
• Chat (채팅 모드):
  1. 코드 청크를 임베딩 벡터로 변환
  2. 서버의 시맨틱 인덱스에 저장 (파일명은 난독화)
  3. 사용자 쿼리 시 가장 관련 있는 청크를 검색 (RAG 패턴)
  4. 검색된 청크를 LLM 컨텍스트로 투입하여 응답 생성
  5. IDE가 정기적으로 코드 청크를 재인덱싱하고 임베딩 동기화
  6. Merkle tree로 청크 diff를 계산하여 변경분만 효율적으로 업데이트

Best Practices

1. 프롬프팅: (복잡한 작업을 수행하려면) PM처럼 스펙 문서 작성
   • 추천 템플릿 요소: Goal, Definitions, Plan, Test cases, Edge cases, Out-of-scope, Extensions
   • 템플릿 구글 드라이브 링크
2. 코드베이스 최적화: LLM-friendly 코드베이스 - 낮은 성능의 원인은 컨텍스트 오염 문제임
   • 모노레포 사용
   • 문서화: Repo 방향 지시, File 구조, 환경설정, 코딩 스타일, 접근 패턴, API와 규칙
3. 에이전트 설정 파일 활용: AGENTS.md, llms.txt 등

내 소감

AI IDE 동작 방식은 인상깊긴 한데, 요즘 하는걸 보면 아예 비동기 작업이 아닌 이상 Claude Code나 Codex CLI 같은 걸로 유행이 바뀐 듯 함.

그래도 AI 활용 방법에 대한 건 꽤 좋은거 같음.

Silas Alberti, Cognition 리서치 총괄

Cognition(Devin 개발사) 창업 멤버의 발표.

AI 코딩 도구에는 2가지 분류 축이 있다.

• 동기/비동기: 동기는 사람이 루프 안에서 결과를 즉시 확인(1분 이내). 비동기는 작업을 위임해두고 완료되면 확인(10분-수시간).
• 로컬/클라우드: LLM 자체가 아니라 에이전트의 실행 환경 기준. Claude Code나 Cursor 같은 IDE 도구는 로컬, Devin이나 GitHub 연동 봇(예: Copilot Workspace)은 클라우드.

AI 코딩 도구는 로컬·동기에서 클라우드·비동기로 이동하고 있다.

실전 워크플로우는 3단계로 구분된다 — Planning(sync, Windsurf/DeepWiki로 코드베이스 파악) → Coding(async, Devin에 위임) → Testing(sync, Windsurf에서 검증·수정). 데모에서는 Cognition 제품(Devin, DeepWiki)과 Windsurf의 조합을 보여줬을 것으로 추정.

주의할 점으로 "Semi-Async"(1~5분 대기) 구간을 지적한다. 플로우를 유지하기엔 너무 느리고, 멀티태스킹하기엔 너무 짧은 최악의 구간이므로 피해야 한다.

Planning과 Testing은 현재 동기(사람 주도)이지만, 미래에는 에이전트가 테스팅까지 자율 수행하는 방향으로 확장될 것. 엔지니어가 직접 코딩에 투자하는 시간은 줄어든다.

미래 전망 — 인간 엔지니어의 역할은 "에이전트 매니저"로 수렴. 미래 핵심 스킬은 코딩 자체보다 위임·멀티태스킹, 코드 리딩, 아키텍처 설계.

내 소감

자료에 Devin을 쓰면 12배 생산성이고 하는데, 많이 과장된 수치라고 생각한다.

Devin이나 DeepWiki가 작년 중반쯤에 떴던거 같은데, 요즘에도 잘 사용하는진 모르겠다.

오픈소스 등에서는 LLM 모델을 직접 만드는 회사(Goolge, OpenAI나 Anthropic)에서 이런 기능을 통합해간다고 생각하는데, Devin은 회사 내부에서 쓸만한거라 눈에 안 띄는 걸지도.

OpenClaw도 그렇고 비동기 + 클라우드 형태를 사람들이 최종 목적지로 보는건 맞는거 같음.

학습 자료

전체적으로 크게 3가지 주장으로 정리 가능함.

1. Spec(명세, 프롬프트, 문서 등)이 코드보다 중요해질 것.
2. 에이전트의 성능은 컨텍스트의 품질에 따라 달라짐. 컨텍스트 관리가 중요.
3. AI가 도구를 잘 사용할 수 있도록 설계해야 함.

AI 요약

컨텍스트 실패 진단과 해법

• How Long Contexts Fail

  • 큰 컨텍스트 윈도우(100만 토큰)가 더 나은 응답을 보장하지 않는다.
  • 4가지 실패 모드:
    1. Context Poisoning(컨텍스트 오염): 환각이 컨텍스트에 기록되면 이후 추론이 연쇄 오염.
    2. Context Distraction(컨텍스트 산만): ~100k 토큰 이상이면 훈련 지식 대신 히스토리의 과거 행동을 반복.
    3. Context Confusion(컨텍스트 혼동): 불필요한 도구/문서에도 모델이 주의를 기울여 무관한 도구 호출.
    4. Context Clash(컨텍스트 충돌): 멀티턴에서 초기의 부정확한 시도가 남아 최종 답변에 간섭.
  • 결론: (AI는 모든 컨텍스트를 판단에 사용하므로) 요약·사실 검색 외에는 컨텍스트를 최소화해야 한다. 후속 글 "How to Fix Your Context".
  • (메모: 2주차 "APIs don't make good MCP tools"의 도구 수 폭발 + 토큰 비효율이 여기서는 Context Confusion으로 정리됨. 같은 문제의 다른 렌즈.)

• Advanced Context Engineering for Coding Agents (ACE-FCA)

  • 주장: 최신 AI 코딩 모델은 복잡한 대규모 코드베이스 작업에 충분하며, 병목은 모델 지능이 아닌 컨텍스트 관리에 있다.
  • 방법: "Frequent Intentional Compaction" — 연구→계획→실행 워크플로. 컨텍스트 윈도우 사용률 40-60% 유지, 서브에이전트가 검색/읽기 처리하여 상위 컨텍스트 오염 방지. 각 단계 사이에 인간 검토(리뷰 대상은 코드가 아닌 계획/스펙, 테스트는 별도 리뷰).
  • 성과: BAML 버그 수정 PR 머지, 취소+WASM 지원 35k LOC를 7시간에 구현(기존 추정 각 3-5일). 인턴 첫날 PR 2건, 8일차 10건.
  • 한계: 몇 코드베이스의 일회성 사례, 통제 실험 없음. 미해결 사례도 존재. 코드베이스 전문가 최소 1명 필요. 월 $12k 토큰 비용(3인 팀). 자사 제품(CodeLayer) 홍보 포함.
  • (메모: 위의 Breunig 글이 "왜" 컨텍스트가 실패하는지 진단했다면, 이 글은 "어떻게" 해결하는지 처방. Context Poisoning → "리서치 읽고 틀리면 버리라", Context Distraction/Confusion → "사용률 40-60% 유지 + 서브에이전트 분리"에 각각 대응.)

AI 활용 개발 워크플로

• How we vibe code at a FAANG

  • AI SWE 10년+ 경력(절반 FAANG급)이 공유한 프로덕션 AI 코딩 워크플로:
  • 결과: 전체 주기에서 ~30% 속도 향상.
  • 댓글 반응: 다수가 "이건 vibe coding이 아니라 AI-assisted engineering"이라고 지적. "설계 문서, 코드 리뷰, TDD가 있는 구조적 프로세스를 vibe coding이라 부르면 엔지니어링의 가치가 절하됨." 바이브 코딩은 목표를 AI가 알아서 구현 방법을 고안하고 결과물을 생성하는 것.

• Coding Agents 101

  • Cognition(Devin 개발사)의 제품 무관 실전 가이드. 시니어~스태프가 더 빨리 적응한다는 관찰에서 출발.
  • 프롬프팅 4원칙: "what"이 아니라 "how"를 지시, 시작 지점(저장소·문서·컴포넌트) 제공, 방어적 프롬프팅(주니어가 혼동할 지점 선제 차단), CI/테스트/린터 접근 권한 부여.
  • 큰 태스크 위임(1-6h, 최고 ROI): PRD 공동 작성 → 체크포인트 단위 구현·검증 → 자기 검증 교육. 목표는 ~80% 시간 절감, 완전 자동화 아님.
  • 한계: 디버깅 근본 원인 추론 부족, 세밀한 시각 추론(Figma 매칭 등) 미흡.

• The spec is dead, long live the spec!

  • Ravi Mehta(전 Tinder CPO)와 Danny Martinez 공동 작성.
  • 핵심 주장: source of truth가 소스코드에서 Spec으로 이동한다.
  • 근거: 코드는 스펙의 "lossy projection" — 의도·맥락·판단이 소실되므로 별도 문서화가 필요했다. AI 코딩에서는 프롬프트(=스펙)가 코드를 생성하므로, 스펙 자체가 이 맥락을 보존한 채 source of truth가 된다.

에이전트용 도구 설계와 운영

• Writing effective tools for agents — with agents

  • Anthropic 엔지니어링 블로그. AI 에이전트에게 제공하는 도구를 잘 설계하고 개선하는 방법.
  • 핵심 전제: 도구는 "예측 가능한 프로그램"과 "예측 불가능한 AI 에이전트" 사이의 새로운 인터페이스. 개발자용 API 설계와는 다른 접근이 필요하다.
  • 개선 루프: 프로토타입 제작 → 실제 업무 기반 평가(단순 테스트 환경 지양, 에이전트의 사고 과정 관찰) → 결과 분석(수치 지표 + 에이전트가 언급하지 않은 부분에 주목) → 에이전트에게 평가 로그를 넘겨 도구를 자동 개선. 이 방식으로 만든 도구가 사람이 직접 만든 도구보다 정확도가 높았음.
  • 설계 원칙 5가지:
    1. 도구 수는 적게, 목적은 명확하게 — 전체 목록 반환(list_contacts)보다 검색(search_contacts), 여러 단계를 하나로 통합(list_users + list_events + create_event → schedule_event).
    2. 이름에 소속 표시 — 도구가 수백 개일 때 서비스별·자원별 접두어(asana_search, jira_search)로 구분해야 에이전트가 올바른 도구를 고른다.
    3. 응답에 맥락을 담되 잡음은 빼기 — 암호 같은 ID(uuid) 대신 사람이 읽을 수 있는 이름 반환. 상세/간결 모드를 파라미터로 전환 가능하게.
    4. 토큰 절약 — 페이지네이션·필터링·잘림 적용, 에러 메시지에는 "무엇이 틀렸고 어떻게 고치라"를 구체적으로 포함.
    5. 도구 설명문이 곧 프롬프트 — 설명문의 문구가 에이전트의 도구 선택 정확도를 직접 좌우함. 예: 웹 검색 도구에서 에이전트가 쿼리에 불필요하게 2025를 붙이는 문제 → 설명문 수정으로 해결.

• Coding Agents 101 — 커스터마이제이션 파트

  • Devin 가이드 후반부. "만들어진 도구를 팀 환경에서 어떻게 배치·운영할 것인가"에 초점.
  • 환경 일치(언어 버전·시크릿·pre-commit), 커스텀 CLI/MCP(티켓 조회·테스트 필터링 등 간단한 도구가 성공률 크게 향상), 지식 베이스(.rules/.md에 아키텍처·테스트 방법·반복 실수 기록), 워크플로 자동화(반복되는 작업 유형 playbook화, 예: feature flag 제거·의존성 업그레이드 등).