프로덕트 소식은 넘쳐나지만 대부분 이런 게 나왔대에서 끝납니다. 그래서 뭘 어떻게 하라고? 내 작업에 어떻게 써먹지? 거기까진 연결이 잘 안 되죠. 따라서 요즘 프로덕트 메이커는 바로 쓸 수 있는 것, 그 중에서도 주목해볼 만한 것을 엄선해서 매주 금요일에 전달드리려 합니다.

요즘 프로덕트 메이커는 매주 세 가지를 골라 전합니다:

써볼 것: whichllm - 명령어 한 줄로 내 컴퓨터에 맞는 로컬 LLM 찾기
참고할 것: AI Agents for Beginners - 마이크로소프트가 공개한 무료 AI 에이전트 강좌
적용해볼 것: AI와 일하며 결과를 복리로 쌓는 법 - 앤트로픽 엔지니어의 5가지 원칙

1. 써볼 것: 명령어 한 줄로 내 컴퓨터에 맞는 로컬 LLM 찾기

whichllm은 내 컴퓨터에서 실제로 잘 돌아갈 로컬 LLM(컴퓨터에서 직접 돌리는 AI 모델)을 자동으로 찾아주는 CLI 도구입니다. 명령어 한 줄에, 모델 추천부터 다운로드, 채팅 시작까지 진행해주죠. Andyyyy64가 개인 프로젝트로 만들었고, 3월에 첫 정식 버전이 공개되면서 PyPI(파이썬 패키지 저장소)와 Homebrew를 통해 누구나 설치할 수 있게 됐습니다.

로컬 LLM에 한 번이라도 관심 가져본 사람이라면 매번 부딪히는 고민이 있어요. "이 모델이 내 노트북에서 돌아갈까?", "어떤 양자화(모델을 압축해 메모리를 덜 쓰게 만든) 버전을 골라야 할까?" whichllm은 이런 질문에 명령어 한 줄로 답을 줍니다.

무슨 문제를 해결해 주나요?

지금까지 로컬 LLM을 써보려는 사람의 과정은 대체로 이랬습니다. HuggingFace(오픈소스 AI 모델이 모여있는 플랫폼)에서 모델을 검색하고, 깃허브나 레딧을 뒤져 다른 사람들이 어떤 사양으로 어떤 모델을 쓰는지 비교하고, 양자화 옵션을 고르고, 그렇게 다운로드한 뒤에야 내 컴퓨터에서 안 돌아가는 걸 알게 되는 경우도 흔했죠.

whichllm은 이 과정을 꽤나 편리하게 줄여주는 도구입니다. 터미널에 whichllm을 입력하면 도구가 내 GPU(그래픽카드)와 RAM을 자동으로 감지해서, 거기서 잘 돌아갈 만한 모델을 점수순으로 나열해줍니다. 점수는 모델 크기(40점), 벤치마크 성적(10점), 예상 속도(20점), 소스 신뢰도(±5점), 인기도(3점)를 종합한 0~100점이고요.

어떻게 쓰나요?

설치 명령어는 환경에 따라 다음과 같이 입력하면 됩니다.

# 맥brew tap Andyyyy64/whichllmbrew install whichllm# 그 외 환경pipx install whichllm

설치 후 주요 명령어는 네 가지입니다.

whichllm - 내 하드웨어에 맞는 추천 모델을 점수순으로 출력
whichllm run - 점수가 가장 높은 모델을 다운로드하고 격리된 환경을 만든 뒤 채팅까지 시작
whichllm snippet "qwen 7b" - 그 모델을 쓰기 위한 파이썬 코드를 바로 출력해서 복사·붙여넣기로 쓸 수 있게 함
whichllm plan "llama 3 70b" - 반대로, 특정 모델을 돌리고 싶을 때 어떤 GPU가 필요한지 역으로 알려줌

흥미로운 기능 하나가 GPU 시뮬레이션인데요. whichllm --gpu "RTX 4090"이라고 입력하면, 실제로 RTX 4090을 갖고 있지 않아도 그 GPU에서 어떤 모델이 잘 돌아갈지 미리 볼 수 있습니다. GPU를 사기 전에 검토할 때 유용할 기능같습니다.

참고로 벤치마크 점수는 Chatbot Arena ELO(사람들이 직접 모델을 비교하며 매긴 순위)와 Open LLM Leaderboard(공개 벤치마크 순위)에서 가져옵니다.

누구에게 좋을까요?

로컬에서 LLM을 돌려보고 싶은데 어떤 모델을 골라야 할지 막막한 사람
허깅페이스에서 모델 찾고 환경 세팅하는 데 시간 쓰기 싫은 사람
GPU 구매 전에 어떤 모델이 돌아갈지 미리 확인하고 싶은 사람
Ollama 같은 도구를 이미 쓰고 있고 모델 선택만 빠르게 자동화하고 싶은 사람

2. 참고할 것: 마이크로소프트가 공개한 무료 AI 에이전트 강좌

ChatGPT나 클로드처럼 질문에 답해주는 AI는 이제 누구나 한 번쯤 써봤을 거예요. 그런데 한 단계 더 나아가면 AI 에이전트라는 게 있습니다. 단순히 답만 주는 게 아니라, 목표를 받아서 여러 도구를 직접 활용해 작업을 수행하는 AI를 말하는 용어죠.

이런 AI 에이전트를 직접 만들어보고 싶은 사람을 위한 입문 자료가 나왔습니다. AI Agents for Beginners(초보자를 위한 AI 에이전트)는 Microsoft(마이크로소프트)가 GitHub에 무료로 공개한 학습 강좌입니다. 마이크로소프트가 공식 관리하는 프로젝트고, 깃허브에서 별 60,000개 이상을 받은 자료예요. 각 강의의 텍스트 자료는 한국어를 포함해 50개 이상 언어로 자동 번역되어 있어서, 영어가 부담스러운 사람도 부담없이 읽어볼 수는 있습니다(비디오 강의는 영어 원본이지만, 유튜브 자동 번역 활용 가능).

기존 학습 자료와 무엇이 다른가요?

AI 에이전트는 비교적 새로운 분야라서 체계적인 학습 자료가 많지 않습니다. 블로그 글이나 유튜브 영상은 많지만, 강의 흐름을 따라가며 직접 코드를 짜보는 형태는 드물었죠. 이 강좌는 그 빈자리를 메울 수 있는 자료로, 12강(추가 예정 강의 포함 최종 15강 이상)으로 구성된 정식 강좌 형태고, 각 강의마다 텍스트 자료, 짧은 유튜브 영상, 파이썬 코드 예제, 추가 학습 자료 링크가 함께 제공됩니다. 다만 텍스트 자료의 한국어 번역은 마이크로소프트의 자동 번역 도구로 만들어졌고, 페이지 하단에 그 사실이 명시되어 있습니다. 자동 번역이라 일부 어색한 표현이 있을 수 있고, 중요한 내용은 영어 원문을 함께 참고하는 게 안전합니다.

어떻게 시작하나요?

별도 회원가입 없이 깃허브에서 바로 확인할 수 있습니다. 코드 예제를 직접 돌려보려면 Azure(애저) 계정이 필요합니다. 강좌가 Microsoft Agent Framework와 Azure AI Foundry라는 마이크로소프트의 AI 에이전트 도구를 기반으로 만들어졌기 때문인데요. 일부 예제는 OpenAI(오픈AI) 호환 모델 공급자로도 대체할 수 있다고 합니다. 코드 실습 없이 개념만 익히는 건 계정 없이도 가능합니다.

어떻게 작동하나요?

12강 이상이 각각 독립된 주제를 다루기 때문에, 관심 있는 강의부터 골라서 들어도 됩니다. 주요 주제는 이런 것들입니다.

AI 에이전트 소개 및 활용 사례 - AI 에이전트가 정확히 뭔지부터
AI 에이전트 설계 패턴 - 도구 사용, 에이전틱 RAG(외부 정보를 검색해 활용하는 방식), 계획 수립, 다중 에이전트 같은 핵심 패턴
신뢰할 수 있는 AI 에이전트 구축 - 안전성과 신뢰성 이슈
프로덕션에서의 AI 에이전트 - 실제 서비스에 배포하는 방법
에이전틱 프로토콜 - MCP, A2A 같은 에이전트 간 통신 표준
컨텍스트 엔지니어링 - AI 에이전트에게 어떤 정보를 어떻게 줄지

이외에도 컴퓨터 사용 에이전트(컴퓨터 화면을 직접 보고 조작하는 AI), 메모리 관리, 마이크로소프트 에이전트 프레임워크 활용 같은 심화 주제까지 다룹니다.

무엇을 얻어가야 하나요?

무료 오픈소스 강좌라 진입 장벽이 낮고, 마이크로소프트가 공식 관리하기 때문에 자료의 신뢰도가 일정 수준 보장됩니다. 깃허브에서 별을 누르거나 포크해두면 업데이트도 따라갈 수 있고요. AI 에이전트 개념을 체계적으로 이해하고 싶거나, 마이크로소프트 생태계에서 직접 에이전트를 만들어볼 계획이 있는 사람들에게는 유용한 자료입니다.

3. 적용해볼 것: AI와 일하며 결과를 복리로 쌓는 법 - 앤트로픽 엔지니어의 5가지 원칙

AI를 본격적으로 쓰는 사람이라면 한 번쯤 이런 상황을 겪어봤을 겁니다. 짧은 작업은 빠르고 편하게 처리되는데, 매번 배경부터 처음 다시 설명해야 합니다. 어제 한참을 알려준 내용도 오늘 새로 대화를 시작하면 AI는 당연히 기억하지 못합니다. 결과물의 품질도 작업마다 들쭉날쭉입니다. AI를 쓰는 횟수는 분명 늘었지만, 정작 내가 만드는 결과물의 평균 수준은 그만큼 올라간 것 같지 않습니다.

Eugene Yan(유진 얀)이 5월 3일 자신의 블로그에 이와 같은 비효율을 풀어가는 5가지 원칙을 정리했습니다. 글 제목은 "AI와 일하며 결과를 복리로 쌓는 법(How to Work and Compound with AI)"입니다.

저자는 현재 Anthropic의 기술 스태프(Member of Technical Staff)고, 그 전에는 아마존의 Principal Applied Scientist, 알리바바·라자다에서 머신러닝 팀 리드로 일했습니다. eugeneyan.com에서 11,800명 이상에게 뉴스레터를 발송하는, AI/ML 분야의 글쓴이로 잘 알려진 사람이기도 하죠.

무슨 문제를 해결하려 하나요?

핵심 키워드는 "복리(compound)"입니다. AI와 일을 마치고 나면 결과물(코드, 문서, 분석, 의사결정)이 남고, 매번의 수정 피드백이 어딘가에 누적되어야 한다는 거예요. 그래야 다음 작업에서는 더 적은 설명으로 더 좋은 결과를 받을 수 있게 되니까요. 이게 이 글이 말하는 복리의 의미입니다.

저자가 정리한 5가지 원칙을 각각 핵심 실천 2~3개씩 정리해보겠습니다.

원칙 1. 맥락을 인프라처럼

AI가 잘 작동하려면 우리 일의 맥락에 접근할 수 있어야 합니다. 매번 설명하지 말고, AI가 직접 찾아갈 수 있게 정리해두자는 원칙입니다.

디렉토리를 정리해 AI가 찾기 쉽게 만들기: 저자는 모든 코드를 ~/src, 모든 지식 작업을 ~/vault에 두고 그 안을 projects/, notes/, kb/ 같이 일관된 구조로 나눕니다. AI가 grep(텍스트 검색 명령어)이나 glob(파일 패턴 검색)으로 필요한 정보를 빠르게 찾을 수 있게 하기 위해서죠.
프로젝트마다 INDEX.md 만들기: 관련 문서와 채널의 링크를 모아두되, 각 항목에 짧은 설명을 붙입니다. "이 문서는 X에 관한 것이고, Y를 다룰 때 읽으면 좋다"는 식으로요. 링크만 모아두면 AI가 일일이 열어봐야 하니, 한 번에 정리해두면 효율이 올라간다는 겁니다.
새 세션을 신입사원 온보딩처럼: AI는 매 세션마다 백지에서 시작합니다. 프로젝트별 CLAUDE.md(클로드 코드 설정 파일)에 약어 사전, 프로젝트 코드네임, 같은 이름의 팀원 구분 같은 정보를 미리 적어두면 매번 설명할 필요가 없습니다.

원칙 2. 취향을 설정처럼

내 작업 스타일을 매번 말로 설명하지 말고, 파일로 저장해두자는 원칙입니다.

~/.claude/CLAUDE.md를 행동 계약서로 쓰기: 저자는 여기에 "확신 없으면 추측하지 말고 모르겠다고 말하기", "내 접근법에 문제가 있으면 직접 지적하기", "실패하면 재시도 전에 근본 원인 먼저 조사하기" 같은 자신의 선호를 정리해뒀어요. AI가 매 세션 시작할 때 이 파일을 읽고 그 기준대로 작동하게 됩니다.
일주일에 한 번 이상 하는 일은 스킬로 만들기: 저자는 /polish(코드 정리), /write(글쓰기), /daily(오늘 우선순위 정리) 같은 스킬을 만들어 씁니다. 스킬은 그냥 마크다운 파일이라 누구나 만들 수 있고, AI가 필요할 때 알아서 불러옵니다.
스킬은 일단 한 번 해보고 그걸 스킬로 만들어달라고 하기: 처음부터 완벽한 스킬을 짜려고 하지 말고, 일단 AI랑 같이 한 번 작업한 뒤 그 과정을 스킬 파일로 정리해달라고 하는 게 훨씬 빠릅니다. 부족한 부분은 다음 사용 때 피드백을 주면서 다듬어가면 됩니다.

원칙 3. 자율을 위한 검증

AI에게 더 많이 맡기려면, 그 결과를 빠르게 검증할 수 있는 구조가 먼저 있어야 합니다. 검증이 어려우면 안심하고 위임할 수도 없으니까요.

가능한 한 일찍, 싸게 검증하기: 저자는 검증을 사다리로 봅니다. 아래쪽은 싸고 빠르고(자동 포맷팅, 린트 같은 것), 위쪽은 비싸고 판단이 필요해요(테스트, 평가, LLM 리뷰). 가능한 한 낮은 단계에서 잡아내자는 거죠.
AI가 스스로 검증할 수 있게 만들기: 결과물이 숫자로 평가되면 AI가 직접 평가를 돌려 최적화하게 두고, 브라우저에서 렌더링되는 거면 AI가 직접 화면을 확인하게 합니다. 도커 이미지를 만들 때 AI가 빌드하고 에러를 읽고 도커파일을 수정한 뒤 다시 빌드하는 식입니다.
긴 작업은 다른 AI가 감시하게 하기: 한 세션이 길어지면 에러가 쌓이면서 방향이 흐려집니다. 저자는 터미널을 두 개 띄워두고, 한쪽은 작업하는 AI, 다른 한쪽은 그 작업을 주기적으로 검토하는 AI로 운영해요. 작업을 제대로 하고 있는지(실행 차원)와 옳은 작업을 하고 있는지(방향 차원)를 따로 점검합니다.

원칙 4. 위임으로 규모 확장

이제는 한 줄씩 지시하는 게 아니라, 한 번에 큰 작업을 통째로 맡길 수 있어야 한다는 원칙입니다.

더 큰 단위로 위임하기: 저자가 드는 예시는 이런 식이에요. "이 평가 묶음 전부에 대해 격리된 컨테이너를 만들어 빌드 테스트하고, 본 실행을 돌리고, 결과를 분석하고, 신뢰구간을 계산하고, 리포트를 생성해서 슬랙으로 보내줘." 이 정도 작업을 한 번에 위임하려면 의도, 제약조건, 성공 기준을 미리 명확히 정리해야 합니다.
여러 세션을 동시에 돌리기: 저자는 평소에 3~6개 세션을 동시에 돌린다고 합니다. 병목이 "작업을 하는 것"에서 "명확한 명세 쓰기와 빠르게 결과를 검토하기"로 옮겨가는 거죠. 같은 코드 저장소에서 여러 세션을 돌릴 때는 git worktree(같은 코드의 여러 작업 공간을 만드는 깃 기능)로 분리합니다.
세션 상태를 한눈에 보기: 여러 세션을 돌리려면 어느 세션이 일하고 있고 어느 세션이 끝났는지 빠르게 알아야 합니다. 저자는 작업이 끝나면 알림 소리가 나게 설정해두고, 터미널 창 제목에는 작업 진행 중인지 완료됐는지가 자동으로 표시되게끔 해뒀다고 합니다.

원칙 5. 루프 닫기

매번의 작업이 다음 작업의 맥락이 되도록 만드는 마지막 원칙입니다.

공개적으로 작업하기: 작업 내용을 공유 문서, 코드 저장소, 채널에 남기면 다른 사람도, AI도 그 맥락을 다음 작업에서 가져다 쓸 수 있습니다. 저자는 자신의 CLAUDE.md에 "큰 작업을 끝낼 때마다 워크로그 채널에 짧은 업데이트 남기기"를 자동화해뒀어요.
과거 대화 기록에서 설정 업데이트 거리 찾기: 저자가 자신의 과거 사용자 입력 2,500개를 분석해보니 "이것도 확인해줘", "이거 빠뜨렸어", "여전히 틀렸어" 같은 표현이 상당 부분을 차지했다고 합니다. 이런 표현이 자주 나오는 부분은 AI가 알아서 했어야 하는 일이라는 신호고, CLAUDE.md나 스킬에 추가해야 할 항목이라고요.
주기적으로 정리하고 가지치기: 설정 파일이 쌓이면 서로 충돌할 수 있습니다. 한 가지 규칙은 한 곳에만 두고, 안 쓰는 항목은 제거하는 게 좋습니다.

5가지가 공통으로 가리키는 것

이 5가지 원칙이 가리키는 방향은 AI를 단순한 도구로 쓰는 게 아니라, 같이 일하는 동료처럼 키워나가는 시스템을 짜는 것입니다. 저자도 글 끝에서 "어떻게 보면 이 원칙들은 인간 팀과 일하는 방법과 똑같다"고 언급하죠. 새 팀원이 들어왔을 때 우리가 자연스럽게 하는 일들이 있을 겁니다. 필요한 문서를 모아주고, 우리 팀이 일하는 방식을 알려주고, 작업을 검토하면서 피드백을 주고, 점점 더 큰 일을 맡기는 것 같은 것들이요. 그 과정을 AI에게도 똑같이 적용해 보자는 겁니다.

Eugene Yan의 원문: https://eugeneyan.com/writing/working-with-ai/
저자의 SETUP.txt(원문에서 제공하는 적용 가이드): https://eugeneyan.com/assets/SETUP.txt

다음 주에도 여러분이 놓치지 말아야 할 프로덕트 메이커 소식을 정리해서 찾아뵙겠습니다. 요즘 프로덕트 메이커 콘텐츠가 도움이 되셨다면, 꼭 작가 알림 설정과 좋아요를 부탁드립니다. 콘텐츠 내용 중 잘못된 정보나 정정이 필요한 부분이 있다면 댓글로 알려주세요. 빠르게 수정하겠습니다. 다음 주에 또 만나요!

콘텐츠가 마음에 드셨다면, 꼭꼭 작가 알림 설정과 좋아요를 부탁드립니다!