AI 워크플로우 설계: 개인 위키에서 팀 프로젝트까지

AI 리터러시는 이제 “AI에게 질문을 잘하는 능력”만으로는 부족합니다. 좋은 질문은 출발점일 뿐이고, 실제 차이는 AI와 함께 무엇을 만들고 어디에 남기는가에서 생깁니다.

AI 활용은 보통 아래 세 단계로 깊어집니다.

단계	중심 질문	결과
도구로 사용	무엇을 물어볼까	번역, 요약, 아이디어
작업으로 설계	어떤 결과가 좋은가	기준, 절차, 검토 방식
워크플로우로 운영	어떻게 반복하고 공유할까	위키, 자동화, GitHub 협업

처음에는 AI를 더 잘 쓰는 사람이 앞서갑니다. 하지만 시간이 지나면 자신의 일을 설명하고, 결과물을 정의하고, 맥락을 남기는 사람이 더 멀리 갑니다.

이 과정은 세 번째 관점에 가깝습니다. AI와 나눈 대화를 일회성 답변으로 끝내지 않고, 개인 위키와 팀 프로젝트에 남길 수 있는 작업 구조로 바꿉니다.

AI 초기에 가장 많이 언급된 것은 GPU였습니다. 더 큰 모델을 학습시키고, 더 좋은 모델을 만들기 위한 시기였기 때문입니다.

이제는 메모리와 실행 환경의 중요성이 커지고 있습니다. 여기서 말하는 RAM은 PC 부품 하나만 뜻하지 않습니다. HBM, 서버 D램, SSD, 스토리지, 네트워크까지 포함한 메모리 계층을 뜻합니다.

이미 좋아진 모델을 더 많이 쓰고, 더 긴 맥락을 다루고, 여러 도구와 에이전트를 동시에 운영하려면 연산 장치만으로는 부족합니다. 필요한 데이터를 어디에 두고, 어떻게 가져오고, 얼마나 빠르게 연결할지가 중요해집니다.

이 변화는 질문을 바꿉니다.

시기	관심	질문
모델 성능 향상 시기	GPU, 학습, 더 좋은 모델	얼마나 똑똑한 모델을 만들 것인가
모델 활용 확산 시기	메모리 계층, 컨텍스트, 실행 환경	좋아진 모델로 무엇을 만들 것인가

모델이 충분히 좋아졌다면 다음 병목은 모델 그 자체가 아닙니다. 다음 병목은 결과물, 맥락, 검증, 협업 구조입니다.

시장 신호로 읽는 변화

주가 사례는 투자 판단이 아닙니다. 여기서는 시장이 어떤 병목을 중요하게 보는지 확인하는 신호로만 다룹니다.

시기	시장 신호	읽어야 할 변화
2023년 GPU의 시기	엔비디아 주가 급등, GPU 부족, AI 학습 인프라 경쟁	더 큰 모델을 만들기 위한 연산 자원이 병목이었다
2026년 메모리 계층의 시기	삼성전자, SK하이닉스, HBM, D램, SSD 수요 주목	추론과 에이전트 운영에서 기억과 데이터 이동이 병목이 되고 있다

함께 볼 기사

‘AI 산업의 쌀’ GPU 시장 독점한 엔비디아는 2023년 엔비디아가 GPU 부족과 AI 붐의 상징으로 부상하던 장면을 보여줍니다. 이 시기에는 더 큰 모델을 만들기 위한 연산 자원 경쟁이 강했습니다.

“칩플레이션 시대… 메모리는 AI 시대 가장 경쟁 치열한 자원”는 서버용 D램과 기업용 SSD 수요, 그리고 SK하이닉스 재평가 흐름을 함께 다룹니다. AI 활용이 넓어질수록 메모리와 스토리지 수요도 함께 커진다는 점을 확인할 수 있습니다.

기사 1. GPU 절반은 HBM 값

EBN산업경제의 2026년 5월 11일 기사는 AI 인프라 투자가 커지고, AI 서버용 GPU에 HBM이 필수 부품으로 붙는 흐름을 다룹니다. GPU를 확보하는 문제는 곧 HBM과 데이터 이동 구조를 확보하는 문제로 이어집니다.

기사 2. 메모리 월을 넘기 위한 패키징 변화

지디넷코리아의 2026년 5월 22일 기사는 GPU 성능이 높아져도 메모리 속도와 용량이 따라가지 못하면 전체 성능이 막히는 메모리 월 문제를 다룹니다. AI 활용의 병목은 모델의 지능만이 아니라 데이터를 공급하고 연결하는 구조에서도 생깁니다.

기사 3. 더 큰 GPU보다 오케스트레이션

매일경제의 2026년 6월 4일 기사는 추론과 에이전틱 AI 단계에서는 더 큰 GPU만이 아니라 시스템 전체를 어떻게 움직일지가 중요해진다는 관점을 제시합니다. 워크플로우, 위키, 자동화, GitHub 협업도 결국 AI 시스템을 움직이는 오케스트레이션에 가깝습니다.

사용자 화면에서는 질문 하나와 답변 하나만 보입니다. 하지만 업무형 AI 시스템에서는 의도 파악, 맥락 검색, 도구 호출, 초안 생성, 검토, 기록 같은 여러 하위 단계가 이어질 수 있습니다. 여기서 오케스트레이션은 더 큰 장치 하나로 모든 문제를 해결하는 것이 아니라, 필요한 판단과 작업을 어떤 순서로 연결할지 설계하는 일입니다.

내부 흐름은 다음처럼 나눠서 볼 수 있습니다.

단계	하는 일
의도 파악	사용자의 요청에서 목적과 완료 기준을 확인한다
맥락 검색	문서, 위키, 이전 결정, 관련 자료를 다시 불러온다
도구 호출	검색, 파일 읽기, API, 자동화 도구를 필요한 순서로 사용한다
초안 생성	모은 맥락과 도구 결과를 바탕으로 중간 결과를 만든다
검토와 검증	출처, 기준, 예외 상황, 누락된 정보를 확인한다
기록과 공유	위키, 커밋, PR, 보고 문서처럼 다시 읽을 수 있는 곳에 남긴다

모든 AI 호출이 항상 이런 구조로 동작한다는 뜻은 아닙니다. 에이전트형 업무 시스템을 만들 때 이런 흐름을 명시적으로 설계할 수 있다는 의미입니다.

기사 5. SSD는 자주 펼쳐 보는 참고서

주간동아의 2026년 5월 15일 기사는 추론형 AI가 HBM, SSD, HDD, 클라우드 스토리지를 계층적으로 쓰면서 문맥과 장기 지식을 다루는 구조를 설명합니다. 개인 위키와 팀 저장소도 같은 관점에서 볼 수 있습니다. 사람과 AI가 함께 다시 읽을 수 있는 외부 기억을 만드는 일입니다.

한 장으로 정리하기

AI Agent 사례는 계속 화려해지고 있습니다.

“AI Agent로 200명의 직원을 만들었습니다. 이 직원들이 가상의 오피스에서 움직이고 말하고 토론합니다.”

처음에는 신기합니다. 하지만 곧 질문이 바뀝니다.

그래서 그 200명의 직원으로 무엇을 만들었습니까?

AI 활용은 점점 결과물로 평가됩니다. 어떤 모델을 썼는지, 어떤 에이전트를 몇 개 만들었는지가 아니라, 무엇을 완성했고, 그 결과가 어디에 남았는지가 중요해집니다.

예전 질문	지금 필요한 질문
더 좋은 모델은 언제 나오나	우리는 무엇을 만들 것인가
어떤 AI 도구가 제일 좋은가	그 도구로 어떤 결과물을 남길 것인가
프롬프트를 어떻게 잘 쓰나	좋은 결과의 기준은 무엇인가
에이전트를 몇 개 만들 수 있나	그 에이전트가 실제로 만든 것은 무엇인가

모델과 에이전트가 충분해질수록 사람이 먼저 정해야 하는 일이 더 중요해집니다. AI가 처리할 작업은 많아질 수 있지만, 어떤 결과를 좋은 결과라고 부를지는 사람이 정해야 합니다.

정해야 할 것	질문
완료 기준	언제 끝났다고 볼 것인가
범위	어디까지 만들고 어디서 멈출 것인가
사용자	누구에게 쓸모 있어야 하는가
근거	어떤 출처와 맥락이 필요한가
검증	무엇을 확인해야 공개할 수 있는가
남길 위치	결과를 어디에 저장하고 공유할 것인가

AI에게 일을 많이 맡기는 것의 핵심은 명령 수가 아니라 기준의 선명도입니다. 기준이 흐리면 에이전트가 많아질수록 혼란도 빨라지고, 기준이 선명하면 여러 작업이 같은 방향으로 모입니다.

결과물의 기준을 세우려면 결국 자신의 일을 설명할 수 있어야 합니다. 이 지점에서 도메인 전문성이 필요해집니다.

AI에게 일을 맡길 때 필요한 도메인 전문성은 직함이나 경력만을 뜻하지 않습니다. 핵심은 내 일을 설명할 수 있는가입니다.

여기서 먼저 job과 task를 구분해야 합니다. AI는 한 사람의 역할 전체를 한 번에 대신하기보다, 역할 안에 들어 있는 작은 업무 단위를 바꾸고 가속합니다.

구분	의미	AI 활용에서의 질문
job	사람이 책임지는 역할과 성과	무엇을 완성해야 하는가
task	결과를 만들기 위해 쪼갤 수 있는 업무 단위	어떤 단계는 AI에게 맡길 수 있는가

도메인 전문성은 job의 책임을 이해하고, 그 안의 task를 나누는 능력입니다. 이 구분이 있어야 AI에게 맡길 일과 사람이 판단해야 할 일을 분리할 수 있습니다.

AI에게 일을 맡기려면 다음을 설명할 수 있어야 합니다.

• 어떤 입력이 좋은 입력인지
• 어떤 결과물이 쓸 만한 결과물인지
• 틀린 결과를 어떻게 알아차릴지
• 어떤 예외 상황에서 멈춰야 하는지
• 완료 기준이 무엇인지

예를 들어 “자료를 요약해줘”는 누구나 말할 수 있습니다. 하지만 아래 기준을 설명하는 것은 해당 업무를 아는 사람만 할 수 있습니다.

• 누구에게 공유할 요약인가
• 원문 저자는 누구로 기록해야 하는가
• TLDR은 몇 개가 적당한가
• 어떤 표현은 빼야 하는가
• 출처가 없으면 공유해도 되는가

도메인 전문성은 AI를 대체하는 능력이 아니라, AI가 제대로 일하게 만드는 조건입니다.

도메인 전문가라고 해서 바로 AI를 잘 활용할 수 있는 것은 아닙니다. 전문가는 좋은 판단 기준을 갖고 있지만, 그 기준이 항상 문장으로 정리되어 있지는 않기 때문입니다.

많은 업무 지식은 문서가 아니라 사람의 기억, 감각, 반복 경험에 들어 있습니다.

• 이 자료는 제목보다 맥락 설명이 먼저 필요합니다.
• 이 고객에게는 이런 표현을 쓰면 안 됩니다.
• 이 문서는 출처가 없으면 공유하지 않습니다.
• 이 판단은 팀장 확인 후 공개해야 합니다.

전문가는 이런 기준을 상황을 보며 자연스럽게 적용합니다. 하지만 AI는 사람의 기억과 감을 그대로 읽을 수 없습니다. 그래서 “알아서 잘 해줘”라고 말하면 결과가 흔들리고, 매번 같은 설명을 다시 하게 됩니다.

AI를 잘 쓰기 위한 첫 단계는 암묵지를 명시지로 바꾸는 일입니다. 내 머릿속 기준을 문장, 표, 예시, 체크리스트로 꺼내야 AI와 팀원이 같은 기준을 다시 읽을 수 있습니다.

명시지로 바꿀 때는 아래 여섯 가지를 적습니다.

항목	질문
목적	왜 이 결과물이 필요한가
입력	무엇을 넣어야 하는가
절차	어떤 순서로 처리하는가
기준	좋은 결과의 조건은 무엇인가
예외	언제 멈추거나 물어봐야 하는가
완료	언제 끝났다고 볼 수 있는가

처음부터 완벽한 문서를 만들 필요는 없습니다. 반복되는 업무 하나를 고르고, 그 업무에서 자주 설명하는 말부터 적습니다. 그다음 AI에게 초안을 맡기고, 전문가가 기준과 예외를 고쳐가며 위키를 업데이트합니다.

이 워크숍에서 만드는 개인 LLM 위키는 바로 이 작업을 위한 공간입니다. 내 머릿속 기준을 밖으로 꺼내고, AI와 팀원이 다시 읽을 수 있는 형태로 남깁니다.

이 워크숍에서는 AI와 함께 일한 결과가 대화창에 흩어지지 않도록 두 가지 결과물을 직접 만듭니다.

하나는 개인용 결과물인 Obsidian LLM 위키입니다. 다른 하나는 팀용 결과물인 GitHub public repo 기반 팀 프로젝트입니다.

결과물 1 — 개인 LLM 위키

AI와 나눈 대화, 조사한 자료, 업무 판단 기준, 반복 프롬프트를 Obsidian vault에 정리합니다. 목표는 예쁜 노트앱을 꾸미는 것이 아니라, 사람도 읽고 AI도 다시 읽을 수 있는 작업 기억을 만드는 것입니다.

개인 위키는 두 층으로 나누어 관리합니다.

구분	담는 내용	예시
공통 원칙	어떤 프로젝트에서도 반복해서 쓰는 나의 작업 기준	출처 기록 방식, 검토 기준, 프롬프트 작성 원칙, AI에게 맡기기 전 체크리스트
프로젝트별 관리	특정 결과물을 만들기 위해 쌓이는 맥락과 결정	프로젝트 목표, 자료 링크, 의사결정 기록, 작업 로그, 결과물 후보, 회고

공통 원칙은 여러 프로젝트에서 다시 쓰는 운영체제에 가깝고, 프로젝트별 관리는 특정 일을 완성하기 위한 작업 기억에 가깝습니다. 이 둘이 분리되어야 새로운 프로젝트를 시작해도 매번 처음부터 설명하지 않고, 필요한 기준과 맥락을 빠르게 꺼낼 수 있습니다.

결과물 2 — 팀 프로젝트 저장소

팀별 public GitHub 저장소에서 공동 결과물을 만듭니다. 각 팀원은 최소 한 번 이상 브랜치, 커밋, PR 흐름을 경험합니다. 목표는 Git 명령을 외우는 것이 아니라, AI와 사람이 함께 일한 맥락을 저장소 안에 남기는 방식에 익숙해지는 것입니다.

개인 위키에는 반복 작업을 구조화한 개인 AI 작업 스택을 남기고, 팀 저장소에는 여러 사람이 검토하고 이어받을 수 있는 협업 기록을 남깁니다.

구분	남기는 것	의미
협업 기록	브랜치, 커밋, PR 설명, 검토 기록	누가 어떤 맥락에서 무엇을 바꿨는지 추적
팀 결과물	README, 지식 카드, 팀 규칙 문서	팀이 함께 만든 공개 가능한 산출물
개인 AI 작업 스택	Skill, Hook, Plugin, Worktree 기준	넓은 오너십을 가진 개인의 작업 기준
선택 확장	worktree 기반 병렬 작업 결과	여러 에이전트가 같은 파일을 덮어쓰지 않게 분리

워크숍을 마치면 아래 산출물이 개인 위키와 팀 저장소에 나뉘어 남습니다.

결과물	워크숍에서 만드는 모양	실무에서 쓰이는 장면
개인 LLM 위키	Obsidian vault + Markdown 노트	AI 대화와 업무 지식을 다시 꺼내 쓰기
결과물 후보 카드	만들 것, 사용자, 현재 방식, 검토 기준	AI에게 일을 맡기기 전 방향 잡기
업무 기준 카드	목적, 입력, 절차, 기준, 예외, 완료	암묵지를 명시지로 바꾸기
지식 카드	핵심 요약, 내 해석, 출처, 다음 행동	자료 조사 결과를 팀 지식으로 전환
Skill 초안	반복 절차와 출력 형식	매번 같은 지시를 다시 쓰지 않기
Hook 체크리스트	실행 전 차단, 실행 후 검증	민감정보, 출처 누락, 위험 작업 방지
Plugin Map	Skill, Hook, 도구 연결 묶음	에이전트 능력을 확장 가능한 단위로 묶기
개인 AI 작업 스택	LLM-Wiki, Skill, Hook, Plugin, Worktree를 묶은 운영 구조	넓은 오너십을 가진 개인의 작업 기준 정의하기
팀 repo PR	변경 이유와 검토 포인트	AI 산출물을 팀원이 이어받게 하기

이 워크숍에서 다루는 개념은 특정 제품에 묶이지 않습니다. Codex, Claude Code, Kiro, Hermes, OpenClaw 같은 도구는 각자의 환경과 선호에 따라 선택할 수 있습니다. 중요한 것은 어떤 도구를 쓰느냐보다, 그 도구 안에서 같은 구조를 알아보고 적용하는 능력입니다.

개념	본질	구현 예시
LLM 위키	AI와 사람이 함께 읽는 외부 기억	Obsidian, Markdown, Notion
에이전트 문서	AI에게 지속적으로 제공하는 작업 맥락	AGENTS.md, CLAUDE.md, Kiro steering
Skill	반복 절차와 출력 형식의 패키지	Codex Skills, Claude Skills, Kiro workflow
Hook	실행 전후 자동화와 가드레일	Claude Hooks, Git hooks, CI, 스크립트
Plugin	Skill, Hook, 도구, 설정을 묶은 확장 단위	Codex plugin, Claude plugin, MCP tool bundle
gstack	개인 AI 작업 스택을 제품 개발 프로세스로 묶은 사례	garrytan/gstack, 개인 mini gstack
GitHub	변경 이력과 협업 맥락	branch, commit, PR, review
Worktree	병렬 작업 공간 분리	git worktree

도구 이름은 바뀔 수 있습니다. 하지만 결과물, 맥락, 검증, 협업 구조를 이해하면 다른 도구로 옮겨도 같은 방식으로 일할 수 있습니다.