AI 잘 쓰는 1%는 이걸 한다…

2025 DORA 보고서는 충격적인 숫자 하나를 던졌다. 조사된 조직의 90%가 이미 최소 하나 이상의 내부 플랫폼을 운영하고 있다는 것. 그런데 더 무거운 사실은 따로 있었다 — 플랫폼 품질이 AI 도구의 ROI를 직접 예측한다는 결론이다. 오늘 GeekNews TOP3는 정확히 그 교차점에서 만난다. Anthropic 엔지니어가 풀어쓴 AI 협업 복리 공식, 내 하드웨어에서 진짜 돌아가는 LLM을 골라주는 오픈소스 CLI, 그리고 플랫폼 엔지니어링의 처음부터 끝까지. 다섯 가지 원칙과 일곱 가지 실전 우선순위가 한 화면에서 정렬되는 자리다.

AI와 함께 일하며 복리처럼 쌓아 성장하는 법

컨텍스트·취향·검증·위임·피드백, 다섯 개의 톱니바퀴

Anthropic의 테크니컬 스태프 Eugene Yan(전 Amazon 추천·LLM 수석 사이언티스트)이 정리한 AI 협업 실무 가이드다. 그가 제시한 다섯 가지 원칙은 컨텍스트 제공, 취향 설정, 검증 자동화, 위임 확대, 피드백 루프 — 단순한 팁이 아니라 모든 작업 산출물이 다음 세션의 입력으로 누적되는 복리 구조를 설계하는 방법이다. 그는 모든 코드를 ~/src에, 지식 작업을 ~/vault에 정리해 모델이 grep과 glob으로 컨텍스트를 직접 검색할 수 있게 만들고, CLAUDE.md를 신입 온보딩 문서처럼 작성하라고 권한다.

핵심 트릭은 지연 로딩(lazy loading)이다. CLAUDE.md에 모든 규칙을 다 적으면 매 세션마다 전체가 토큰으로 환산되는 ‘컨텍스트 세금’이 발생한다. 대신 글로벌·레포·프로젝트 디렉터리별로 스코프를 나누고, 가이드 파일은 “관련 시 읽기” 형태로 경로만 명시한다. 주 1회 이상 반복되는 작업은 /polish, /write, /daily 같은 스킬로 전환한다. 검증은 사다리 구조로 — 가장 아래는 ruff format 같은 post-edit 훅(결정적, 토큰 0), 위로 갈수록 테스트·eval·LLM 리뷰가 쌓인다.

위임은 두 갈래의 드리프트를 견디는 설계여야 한다. 실행 드리프트(작업을 올바르게 하는지)는 자주 확인, 방향 드리프트(올바른 작업을 하는지)는 가끔 확인한다. 큰 작업을 위임하면 3~6개 세션을 병렬로 굴릴 수 있는데, 이 때 git worktrees로 독립 체크아웃을 만들고 tmux 타이틀에 상태 아이콘과 Haiku가 생성한 짧은 레이블로 각 패널을 식별하는 관찰 가능성 인프라가 병목이 된다. 그가 약 2,500개의 과거 사용자 턴을 스캔해 보니 상당수가 “did you check…”, “still wrong” 같은 표현이었다 — 자발적으로 했어야 할 작업의 누락 신호다. 이 패턴을 마이닝해 다시 CLAUDE.md와 스킬에 반영하는 게 피드백 루프의 완성이다.

whichllm — 내 하드웨어에서 진짜 최고 성능을 내는 로컬 LLM 찾기

파라미터 수가 아닌 ‘실측’으로 골라주는 CLI

로컬 LLM 시장의 가장 큰 함정은 “VRAM에 들어가는 가장 큰 모델”을 무작정 선택하는 것이다. whichllm은 그 함정을 정면으로 깨는 도구다. GPU·CPU·RAM을 자동 감지한 뒤 LiveBench, Artificial Analysis, Aider, Chatbot Arena ELO, Open LLM Leaderboard를 0–100 통합 점수로 병합해 시스템에 맞는 상위 모델을 랭킹으로 제시한다. RTX 4090 시뮬레이션에서 32B가 들어가는데도 신세대 27B(Qwen3.6-27B)를 1위로 추천한 사례는 이 도구의 사고방식을 단적으로 보여준다.

진짜 차별점은 ‘근거 등급화 5단계’다. 모든 점수는 direct / variant / base_model / line_interp / self_reported로 태그되고, 업로더가 띄운 허위 자체 보고나 작은 포크가 큰 베이스 점수를 빌려오는 크로스 패밀리 상속은 차단된다. 파라미터가 패밀리 dominant member에서 2배 이상 차이나면 점수 상속을 거부하는 식이다. VRAM도 가중치 + GQA KV 캐시 + 활성화 + 오버헤드를 모두 계산하고, 속도는 MoE active vs total을 분리해 통합 메모리 vs PCIe 부분 오프로드까지 반영한다.

실사용도 단순하다. whichllm run 한 줄이면 uv로 격리 환경을 만들고 모델 다운로드, 채팅까지 자동 처리한다. --gpu "RTX 5090"으로 구매 전 시뮬레이션, plan "llama 3 70b"으로 역방향 GPU 조회, upgrade로 현재 vs 후보 GPU 비교까지 가능. --json | jq로 Ollama 파이프라인에 꽂아 쓰는 것도 자연스럽다. NVIDIA·AMD·Apple Silicon·CPU-only를 모두 지원하고 GGUF / AWQ / GPTQ / FP16 / BF16 어떤 포맷도 OK. MIT 라이선스다.

플랫폼 엔지니어링의 모든 것 — 왜, 어떻게, 성공은 어떤 모습인가

‘과잉 일반화 늪’에서 플랫폼이 자라는 이유

Luca Vallin이 짚은 핵심 진단은 ‘과잉 일반화 늪(over-general swamp)’이다. 클라우드와 OSS가 큐, 오브젝트 스토어, DB, CI 러너 등 무한한 프리미티브를 제공하면서 각 팀이 제각각 파이프라인을 만들고, 1년 뒤 모든 서비스가 자체 배포 로직과 미묘하게 잘못된 IAM 바인딩의 ‘글루 코드 늪’에 빠진다. 실제 한 랜딩존 프로젝트에서는 20개 팀이 VPC·IAM·예산 알림용 거의 동일한 Terraform 모듈을 각자 재발명하며 각기 다른 버그를 안고 있었다. 플랫폼 엔지니어링은 이 늪을 빼내기 위한 사회기술적 규율이다 — DevOps의 리브랜딩이 아니다.

다섯 가지 기둥이 있다 — 큐레이션된 제품 접근(거절도 업무), 소프트웨어 기반 추상화(CNCF Score 같은 선언적 워크로드 스펙), OSS 커스터마이징과 메타데이터 레지스트리(Backstage는 270개 이상 조직이 운영 중), 광범위한 사용자 기반 서비스(엘리트가 아닌 중간값 개발자 대상), 파운데이션으로 운영(24/7 온콜·SLO·변경 관리). 시기도 중요한데, 엔지니어 10명일 때는 ‘협력’이면 충분하고 50명 이후 다수 배포 대상이 생기는 시점에 플랫폼 팀 구성이 적절하다고 본다. 너무 일찍 만든 1~2명 팀은 단순한 티켓 큐로 전락한다.

팀 구성은 Software / Systems / Reliability / Specialist 네 역할의 균형이며, 채용 1순위는 ‘고객 공감’이다. 좌절한 앱 개발자와 통화 후 문제를 명확히 이해하지 못하는 엔지니어는 적합하지 않다. 마이그레이션 비용은 항상 예상의 2~3배가 되며, ‘명령(mandate)’은 한두 번만 효과 있다 — 그 뒤엔 소음이 된다. 그래서 새 경로를 충분히 좋게 만들어 구 경로가 자연히 시들도록 하는 것이 최선이다. 그의 실전 우선순위 8단계는 지원 범위 결정·문서화 → 소프트웨어 추상화 투자 → 메타데이터 레지스트리 → 중간값 팀 우선 → 운영을 일급 기능으로 → 공감 기반 채용 → 무자비한 소통 → 종료·통합·거절 순.

관련 글

• AI 맹신 회사들 곧 터진다 — 미첼 하시모토 경고와 Rust DB 실전 비교
• Claude Code가 grep 쓰는 이유 — 대규모 코드베이스 모범 사례
• 앤트로픽 또 사고 쳤습니다 — 가치 9000억 달러 돌파
• AI가 사람 말 끊기 시작했다 — Thinking Machines 인터랙션 모델
• ERP가 통째로 갈렸다 — SAP Autonomous Enterprise 224개 에이전트

출처

1. Eugene Yan — Working with AI: Five Compounding Principles (eugeneyan.com)
2. whichllm — Local LLM benchmark-based recommender (GitHub)
3. Luca Vallin — Platform Engineering End-to-End (lucavall.in)
4. GeekNews — 5/18 인기 글 TOP3 (news.hada.io)