describug
← 기록

API? MCP? — AI로 업무 도구를 만들 때 마주치는 말들

모델, 연결, 에이전트, 자료, 앱. 다섯 갈래로 나눠 풀고, 제가 만든 것들에서 실제로 어디에 쓰였는지 붙였습니다.

AI용어

Summary

과제
친구에게 모임 앱을 어떻게 만들었는지 설명하다가, 쓰는 말마다 다시 풀어야 했다
수단
AI로 무언가 만들 때 만나는 용어를 다섯 갈래로 나눠 정리하고, 내 앱과 작업에서 실제로 쓰인 자리를 예로 붙였다

DETAILED DESCRIPTION

오늘 친구가 모임 앱을 어떻게 만들었는지 물었습니다.

설명하다 보니 말마다 멈췄습니다. 「Supabase에 넣고 Vercel에 올렸어」라고 하면 그게 뭔지부터 풀어야 했고, 푸는 말에 또 모르는 말이 섞였습니다.

AI로 앱이든 업무 도구든 만들다 보면 이런 말들을 계속 만납니다. 한 번은 정리해둬야겠다 싶어서 씁니다.

특허 용어는 풀지 않고, 개발 용어만 풉니다. 프롬프트·컨텍스트·하네스·루프는 프롬프트에서 루프까지에 길게 적었으니 여기서는 짧게 넘어갑니다.

다섯 갈래로 나눴습니다

갈래 무엇에 관한 말인가 여기 속하는 말
1. 모델 AI 그 자체 LLM, 토큰, 컨텍스트 윈도우, 환각, 로컬 LLM
2. 연결 프로그램끼리, AI와 바깥을 잇는 길 API, API 키, JSON, 호출 제한, 도구 호출, MCP
3. 에이전트 AI가 스스로 일하게 하는 틀 에이전트, 서브에이전트, 스킬, 하네스·루프
4. 자료 AI에게 내 자료를 쥐여주는 법 RAG, 임베딩, LLM 위키, 파인튜닝
5. 앱 사람이 실제로 누르는 것 스택, 프론트엔드·백엔드, CLI, DB, 스토리지, 인증, 배포, 크론

1. 모델

LLM (Large Language Model, 대규모 언어모델) 엄청나게 많은 글을 읽고 「이 뒤에 올 말」을 맞히도록 학습된 프로그램입니다. 클로드, GPT, 제미나이가 모두 여기에 속합니다. 「모델」이라고만 해도 대개 이것을 가리킵니다.

토큰 모델이 글을 세는 단위입니다. 글자도 아니고 단어도 아닌, 그 중간쯤 되는 조각입니다. 값과 한도가 둘 다 토큰으로 매겨집니다. OA 대응안을 찾던 글에서 85만 토큰을 썼다고 적은 것이 이 단위입니다.

컨텍스트 윈도우 모델이 한 번에 볼 수 있는 분량입니다. 토큰 수로 적힙니다. 명세서와 인용발명 여러 건을 한꺼번에 넣으면 여기서 막힙니다. 넘치면 오류가 나거나, 앞의 대화를 요약·정리해 자리를 만듭니다. 그래서 넣기 전에 추리는 게 중요합니다.

환각 (hallucination) 모델이 그럴듯하지만 사실이 아닌 것을 자신 있게 내놓는 일입니다. 없는 판례 번호, 없는 청구항 문구가 대표적입니다.

체감상 요즘은 확실히 줄었습니다. 큰 이유 하나는 「모른다」고 말하도록 가르친 것입니다. OpenAI가 2025년 9월에 낸 논문의 요지는 이렇습니다. 그동안 모델을 채점할 때 틀린 답과 「모르겠다」가 똑같이 0점이었으니, 모델 입장에서는 찍는 쪽이 이득이었다는 것입니다. 시험에서 빈칸보다 아무거나 쓰는 게 나은 것처럼요. 틀린 답에는 감점을 주자는 게 그 논문의 제안입니다.

OpenAI가 논문과 함께 낸 글에 그 차이가 숫자로 나옵니다. 검색 없이 사실 질문에 답하게 한 결과입니다.

모델 답을 포기 맞힘 틀림
o4-mini (이전) 1% 24% 75%
gpt-5-thinking-mini 52% 22% 26%

맞힌 비율은 거의 같은데, 틀린 비율이 3분의 1로 줄었습니다. 더 똑똑해졌다기보다 모를 때 멈추게 된 것입니다. 여기에 답하기 전에 한참 생각하는 방식(추론 모델)과, 모르면 검색부터 하는 습관이 더해졌습니다.

그래도 없어지지는 않았습니다. 쓰는 쪽에서 줄이는 방법도 있습니다. Anthropic의 공식 안내에서 추렸습니다.

  • 「모르면 모른다고 해도 된다」고 적어준다
  • 원문을 먼저 그대로 인용하게 하고, 그 인용만 근거로 판단하게 한다
  • 주장마다 근거 문장을 달게 하고, 근거를 못 찾은 주장은 지우게 한다
  • 내가 준 문서 밖의 지식은 쓰지 말라고 한다
  • 같은 질문을 여러 번 돌려 답이 갈리는지 본다

특허 일에서는 둘째와 셋째가 제일 잘 듣습니다. 인용 대목이 원문에 정말 있는지는 사람이 대조합니다.

로컬 LLM 남의 서버가 아니라 내 컴퓨터에서 돌리는 모델입니다. 글이 밖으로 나가지 않는 대신, 컴퓨터 사양을 많이 타고 대체로 최신 유료 모델보다 덜 똑똑합니다. 출원 전 명세서처럼 밖으로 못 내보내는 문서가 있으면 제일 먼저 떠올리게 되는 선택지입니다.

2026년 9월 기준으로 자주 거론되는 공개 모델은 이렇습니다.

모델 만든 곳 메모
Qwen3.8 (27B) 알리바바 2026년 8월. 이미지도 읽음
Gemma 4 (E2B~31B) 구글 2026년 4월. 작은 것은 노트북에서도
gpt-oss (20b·120b) OpenAI 20b는 메모리 16GB에서 돈다
Mistral Small 4 미스트랄 2026년 3월
EXAONE 4.5 (33B) LG AI연구원 2026년 4월. 한국어
HyperCLOVA X SEED Think (32B) 네이버 2025년 12월. 한국어
Kanana-2 카카오 1.3B·3B 경량판은 2026년 7월

돌리는 도구로는 Ollama, LM Studio가 쉽습니다. 맥이라면 애플의 MLX가 빠릅니다. DeepSeek V4처럼 공개는 됐지만 개인 컴퓨터에는 너무 큰 모델도 있습니다.

2. 연결

API (Application Programming Interface) 프로그램이 다른 프로그램에 일을 시키는 정해진 창구입니다. 식당으로 치면 메뉴판과 주문서입니다. 주방에 들어가지 않고 양식대로 주문하면 음식이 나옵니다.

예를 들면 이런 것들입니다.

  • 일기예보 — 날씨 카드는 기상청 API에 「이 좌표의 날씨」를 물어 받아옵니다
  • 증권 계좌 — 자산 앱에 포트폴리오를 넣어두면 변동 추이가 쌓이는데, 지금은 시세만 받아오고 보유 수량은 손으로 적습니다. 증권사가 API를 열어두었으면 잔고까지 자동으로 가져올 수 있습니다. 한국투자증권(KIS Developers), 키움증권(2025년 REST API 출시), LS증권, 토스증권(2026년 공개) 등이 API를 제공합니다. 여러 증권사를 한 번에 모아주는 마이데이터는 허가받은 사업자만 쓸 수 있어서, 개인은 증권사마다 따로 붙여야 합니다
  • Claude API — 클로드를 채팅창이 아니라 내 프로그램에서 부르는 창구입니다(아래 따로)

특허 일에 쓸 만한 API도 꽤 있습니다.

무엇 어디 메모
출원·등록 서지, 공보 KIPRIS Plus (지식재산처) 월 1,000회 무료. 넘으면 유료, 개인·중소기업 할인
심판 정보·심결문 KIPRIS Plus 심판사항 API (공공데이터포털) 심결문 내려받기 경로까지. 무료
법령·판례·헌재결정·법령해석례 국가법령정보 공동활용 (법제처) 판례 목록과 본문. 특허심판원 심결은 없음
법원 판례·사건 정보 사법정보공유포털 (법원행정처) 2026년 9월 현재 「오픈API 추후 제공 예정」
미국 출원 서류 USPTO Open Data Portal 무료, API 키 필요
유럽 서지·패밀리·법적 상태 EPO OPS (유럽특허청) 무료 한도 있음
전 세계 서지 Google Patents (BigQuery) SQL로 조회

특허청은 2025년 10월에 지식재산처로 바뀌어서, 공공데이터포털의 API 이름도 「지식재산처_KIPRISPlus_…」로 되어 있습니다.

Claude API와 요금 채팅 앱의 월 구독(Pro·Max)은 정액제지만, API는 쓴 만큼 냅니다. 단위는 앞의 토큰이고, 넣은 글(입력)과 받은 글(출력)의 값이 따로 매겨집니다. 2026년 9월 기준 100만 토큰당 가격입니다(공식 요금표).

모델 입력 출력
Opus 5 $5 $25
Sonnet 5 $2 $10
Haiku 4.5 $1 $5

출력이 입력보다 다섯 배 비쌉니다. 긴 문서를 넣고 짧게 답받는 일은 싸고, 긴 초안을 뽑는 일은 비쌉니다. 급하지 않은 일을 모아서 보내는 배치 처리는 절반 값입니다.

API 키 API를 쓸 자격을 증명하는 긴 비밀 문자열입니다. 도장이자 법인카드입니다. 이 키로 부른 만큼 요금이 나가므로 코드 안에 그대로 적거나 저장소에 올리면 안 됩니다. 보통 「환경 변수」나 「시크릿」이라는 별도 금고에 둡니다.

JSON 프로그램끼리 주고받을 때 가장 흔히 쓰는 글 형식입니다. 칸 이름과 값을 짝지어 적습니다.

{
  "출원번호": "10-2026-0000000",
  "통지일": "2026-09-01",
  "거절이유": ["신규성", "진보성"],
  "대비표": [
    { "구성": "A 하우징", "인용1": "O", "인용2": "X" },
    { "구성": "B 필터",   "인용1": "X", "인용2": "O" }
  ]
}

사람이 읽어도 대충 보이고, 프로그램은 정확히 읽습니다. 정해진 양식을 채우는 일에 특히 좋습니다. AI에게 「이 칸들을 JSON으로 채워줘」라고 하면 프로그램이 그 값을 받아 워드 양식이나 표에 그대로 꽂을 수 있습니다. 글로 받으면 사람이 옮겨 적어야 하고, 옮기다 빠뜨립니다. 요즘 API에는 칸 목록(스키마)을 미리 주면 반드시 그 모양으로 답하게 하는 기능도 있습니다.

기한 관리 앱도 화면과 구글 시트가 JSON으로 사건 목록을 주고받습니다.

호출 제한 (rate limit) 정해진 시간에 부를 수 있는 횟수의 상한입니다. 넘으면 한동안 거절당합니다. KIPRIS Plus의 「월 1,000회 무료」도 일종의 호출 제한입니다. API를 붙일 때는 안 될 때 화면이 어떻게 보일지까지 같이 정해야 합니다. 날씨 카드가 사라졌던 게 그 대목입니다.

데이터 보존 · 학습 사용 여부 보낸 글을 그 회사가 얼마나 보관하는지, 모델 학습에 쓰는지를 말합니다. 서비스와 요금제마다 약관이 다릅니다. 비밀유지의무가 걸린 문서를 보내기 전에 확인할 첫 항목입니다. 저는 신규 사건은 아예 보내지 않기로 했습니다.

도구 호출 (tool use) 모델이 할 수 있는 일은 사실 하나뿐입니다. 글자를 내놓는 것입니다. 파일을 열 손도, 검색창을 누를 손가락도 없습니다.

그런데 클로드가 폴더의 파일을 읽고 웹을 검색합니다. 방법은 이렇습니다.

  1. 모델 옆에 심부름꾼 프로그램이 붙어 있습니다
  2. 모델에게 미리 알려줍니다. 「파일이 보고 싶으면 파일열기: 파일이름 이라고 써라」
  3. 모델이 답을 쓰다가 파일열기: 통지서.pdf 라고 씁니다
  4. 심부름꾼이 그 줄을 보고 실제로 파일을 열어, 내용을 모델에게 다시 넣어줍니다
  5. 모델은 그 내용을 읽고 이어서 답을 씁니다

모델은 「이걸 해달라」는 쪽지만 쓰고, 실제 일은 옆의 프로그램이 합니다. 검색하기, 메일 보내기, 시트에 쓰기가 전부 이 방식입니다. 쪽지의 양식이 앞의 JSON입니다.

MCP (Model Context Protocol) 위의 「심부름 목록」을 누구나 같은 규격으로 만들어 끼울 수 있게 한 약속입니다. Anthropic이 2024년 말에 공개했고, 흔히 **「AI용 USB-C」**라고 부릅니다. 서비스 쪽이 MCP로 한 번 만들어두면, 이 규격을 아는 AI는 어느 것이든 꽂아서 씁니다.

  • 구글 드라이브 — 「지난주 의견서 초안 찾아서 요약해줘」
  • 슬랙·노션·지메일 — 메시지 찾기, 페이지 쓰기, 메일 초안
  • GitHub — 코드 저장소 읽고 고치기
  • 카카오톡 — 카카오가 PlayMCP를 열어서, 클로드에 연결하면 「방금 정리한 거 카톡 나와의 채팅방에 보내줘」가 됩니다. 톡캘린더, 카카오맵도 있습니다
  • 특허 데이터 — 위 표의 KIPRIS Plus와 EPO OPS를 묶어 patent-api를 만들었습니다. 「이 한국 출원 서지랑 해외 패밀리 알려줘」라고 하면 클로드가 KIPRIS와 EPO에 직접 물어봅니다

API는 서비스마다 다른 창구이고, MCP는 AI가 그 창구들을 같은 방식으로 쓰게 하는 어댑터입니다. MCP 속을 열어보면 대개 그 서비스의 API를 부르고 있습니다. patent-api도 속은 KIPRIS·EPO API 호출입니다. Claude 앱에서는 이 연결을 커넥터라고 부릅니다.

3. 에이전트

에이전트 한 번 묻고 한 번 답하고 끝나는 것이 채팅이라면, 에이전트는 목표를 받아 끝날 때까지 스스로 여러 번 움직이는 AI입니다.

「이 폴더의 통지서를 읽고 기한표를 채워줘」를 받으면

  1. 폴더 목록을 봅니다 (도구 호출)
  2. 통지서를 하나씩 엽니다 (도구 호출)
  3. 기한을 계산합니다
  4. 시트에 씁니다 (도구 호출)
  5. 제대로 들어갔는지 다시 열어봅니다
  6. 틀렸으면 고치고, 맞으면 멈춥니다

생각 → 도구 → 결과 보기 → 다음 행동을 되풀이합니다. 사람이 단계마다 지시하지 않습니다.

「모델 + 하네스 = 에이전트」가 맞습니다. 요즘 이렇게 많이들 정리합니다. 모델은 두뇌이고, 하네스는 그 두뇌에 손(도구), 업무 지침, 되풀이하는 구조, 멈추는 조건을 붙인 틀입니다. Claude Code, Cowork가 이 하네스이고, 그 안에서 클로드가 돌면 에이전트가 됩니다.

서브에이전트 에이전트가 일의 일부를 따로 맡기는 보조 에이전트입니다. 담당 변리사가 인용발명 검토를 다른 사람에게 넘기고 결론만 받는 것과 같습니다.

쓰는 이유는 둘입니다.

  • 컨텍스트 윈도우를 아낍니다. 인용문헌 전문을 본 에이전트가 다 읽으면 창이 금방 찹니다. 서브에이전트가 따로 읽고 요점만 돌려주면 본 에이전트의 창은 가볍게 유지됩니다
  • 서로의 생각을 못 봅니다. 서브에이전트는 빈 상태로 시작합니다. 그래서 「출원인 입장」과 「심사관 입장」을 나눠 맡기면 서로 끌려가지 않습니다

대신 비쌉니다. 서브에이전트를 부를 때마다 지침과 자료를 처음부터 다시 읽히므로, 제 작업에서는 하나 부르는 데만 약 4만 토큰이 고정으로 들었습니다. 출원인·심사관·판정으로 나눠 돌린 것이 앞의 OA 대응안 글입니다.

스킬 잘 적어둔 프롬프트가 핵심입니다. 다만 몇 가지가 더 붙습니다.

스킬은 폴더 하나입니다. 안에 이런 것이 들어갑니다.

  • SKILL.md — 「이 일은 이런 순서로, 이런 기준으로 한다」는 지침. 이게 그 프롬프트입니다
  • 양식 파일 — 채워 넣을 워드 서식, 예시 문서
  • 스크립트 — 매번 똑같이 해야 하는 계산이나 검사는 AI에게 맡기지 않고 프로그램으로 돌립니다

그냥 프롬프트를 복사해 붙이는 것과 다른 점은 셋입니다.

  • 부르지 않아도 알아서 꺼냅니다. 지침 맨 위에 「언제 쓰는 스킬인지」를 한 줄 적어두면, 「이 PDF로 초안 써줘」라는 말에 에이전트가 맞는 스킬을 찾아 엽니다
  • 필요할 때만 읽습니다. 평소에는 그 한 줄만 보고 있다가 쓸 때 전체를 읽으니, 스킬이 수십 개여도 창을 거의 차지하지 않습니다
  • 파일과 스크립트가 같이 다닙니다. 프롬프트만으로는 못 하는 「양식에 채워서 저장」까지 이어집니다

사무소로 치면 업무 매뉴얼 + 서식 + 계산기를 한 서랍에 넣어둔 것입니다. 저는 엑셀 현황판을 기한 관리 앱에 등록하는 일, 보고서에서 일부를 발췌해 레터를 쓰고 그 레터를 붙인 아웃룩 메일 초안까지 만드는 일에 스킬을 씁니다.

하네스 · 루프 하네스는 모델을 감싼 틀 전체(지침 파일, 스킬, MCP, 검사 스크립트)이고, 루프는 그 틀이 사람 없이 여러 번 돌게 만드는 방식입니다. 루프 엔지니어링과 앞의 「프롬프트에서 루프까지」에 적었습니다.

4. 자료

모델은 내 사무소의 자료를 모릅니다. 과거 의견서, 자주 쓰는 논리, 심사관별 경향 같은 것들입니다. 이걸 쥐여주는 방법이 몇 가지 있습니다.

RAG (Retrieval-Augmented Generation, 검색 증강 생성) 이름은 어렵지만 뜻은 단순합니다. 찾아서(검색) 옆에 펴주고(증강) 쓰게 한다(생성).

과거 의견서가 3,000건 있다고 합시다. 다 넣으면 컨텍스트 윈도우가 터집니다. 그래서 이렇게 합니다.

  1. 질문이 들어옵니다. 「필터 배치 구성에 진보성 거절, 과거에 어떻게 대응했나?」
  2. 3,000건 중 이 질문과 닮은 문단 다섯 개를 먼저 찾습니다
  3. 그 다섯 개만 질문과 함께 모델에게 넣습니다
  4. 모델은 그걸 근거로 답합니다

선행문헌 조사와 구조가 같습니다. 찾고, 추리고, 그걸 근거로 씁니다. RAG의 성패는 거의 2번, 얼마나 잘 찾느냐에서 갈립니다.

임베딩 · 벡터 검색 2번에서 「닮은 것」을 찾는 기술입니다.

키워드 검색은 글자가 같아야 걸립니다. 「하우징」으로 찾으면 「케이스」는 안 나옵니다. 임베딩은 글의 뜻을 숫자 좌표로 바꿉니다. 지도에 점을 찍듯이요. 뜻이 비슷한 문장은 가까운 자리에, 다른 문장은 먼 자리에 찍히도록 학습된 모델이 해줍니다.

  • 미리 과거 의견서의 문단마다 좌표를 매겨 저장해둡니다 (실제로는 수백~수천 개 숫자의 묶음입니다)
  • 질문이 오면 질문에도 좌표를 매깁니다
  • 질문 좌표와 가장 가까운 문단들을 꺼냅니다. 이게 벡터 검색입니다

그래서 단어가 달라도 뜻이 같으면 걸립니다. 좌표를 매겨주는 모델은 따로 있습니다. Anthropic은 자체 임베딩 모델이 없고 Voyage AI를 안내하는데, 여기에는 법률 문서용 모델(voyage-law-2)도 있습니다.

LLM 위키 RAG와 방향이 다른 방법입니다. 카파시(Andrej Karpathy)가 제안했습니다.

RAG는 원본 더미에서 매번 찾아옵니다. LLM 위키는 모델이 읽은 것을 스스로 정리해 노트로 쌓아둡니다. 「이 논리는 이런 거절이유에 먹혔다」, 「이 인용문헌은 이런 식으로 반박했다」를 주제별 파일로 남기고, 목차 파일 하나에 목록을 적어둡니다. 다음 사건에서는 원본을 다시 뒤지지 않고 목차부터 봅니다.

사람으로 치면 RAG는 매번 서고에 가서 찾는 것, LLM 위키는 정리해둔 내 업무 노트를 펴는 것입니다. 노트가 쌓일수록 좋아지는 대신, 노트가 틀리면 틀린 채로 쓰입니다. 그래서 깨진 연결이나 빠진 항목을 기계로 검사하는 린트 스크립트를 같이 둡니다.

카파시는 원본 자료가 백 건 남짓한 규모까지는 임베딩 없이 목차와 글자 검색만으로 충분하다고 했습니다. 제 OA 작업이 지금 그 상태입니다(자세히).

파인튜닝 이미 만들어진 모델을 내 자료로 추가 학습시키는 것입니다. RAG와 위키가 「참고자료를 옆에 펴주는 것」이라면, 파인튜닝은 「공부를 더 시키는 것」입니다. 비용과 품이 훨씬 들고, 모델이 바뀔 때마다 다시 해야 합니다. 개인이 업무 도구를 만들 때는 스킬, 위키, RAG 쪽을 먼저 해보는 편이 낫습니다.

5. 앱

스택 앱을 이루는 기술의 조합을 스택이라고 부릅니다. 층층이 쌓여 있어서 붙은 이름입니다. 「무슨 스택으로 만들었어?」는 「화면은 뭘로, 저장은 어디에, 어디에 올렸어?」라는 뜻입니다. 대개 아래 칸들로 나눠 말합니다.

프론트엔드 · 백엔드 프론트엔드는 화면(버튼, 표, 입력칸)이고, 백엔드는 그 뒤에서 계산하고 저장하는 부분입니다. API 키는 반드시 백엔드에 둡니다. 프론트엔드에 두면 누구나 볼 수 있습니다.

제 것 넷을 칸별로 놓으면 이렇습니다.

모임 앱 이유식 기록 앱 특허 도면 도구 docx2patent
어떤 앱 웹앱 웹앱 내 컴퓨터에서 여는 웹 화면 데스크톱 앱
프론트엔드 Next.js Next.js Flask 화면 + 자바스크립트 Flask 화면을 앱 창에 담음
백엔드 Next.js 안의 API AWS Amplify (Lambda) 내 컴퓨터의 Flask 내 컴퓨터의 Flask
DB Supabase DynamoDB 없음 (파일) 없음
파일 보관 Cloudflare R2 AWS S3 내 컴퓨터 내 컴퓨터
로그인 Supabase Auth AWS Cognito 없음 없음
올린 곳 Vercel Amplify Hosting 없음 설치 파일을 R2에
그 밖에 웹 푸시, 매일 크론 PWA 도면 부호 OCR GitHub Actions로 맥·윈도우 빌드

왼쪽 둘은 서버에 올린 앱이고, 오른쪽 둘은 내 컴퓨터 안에서만 도는 앱입니다. 오른쪽은 출원 전 문서를 다루니 문서가 밖으로 나가는 길을 만들지 않았습니다.

로컬 · 클라우드 로컬은 내 컴퓨터, 클라우드는 남의 컴퓨터를 빌려 쓰는 것입니다. 위 표의 오른쪽 둘은 내 컴퓨터에 작은 서버를 띄워 자기 자신과만 대화합니다.

웹앱 · 데스크톱 앱 · 실행파일 웹앱은 주소로 여는 것, 데스크톱 앱은 내려받아 설치하는 것입니다. 웹앱은 고치면 모두에게 바로 반영되지만 서버가 필요하고, 데스크톱 앱은 서버가 없어도 되지만 새 버전을 다시 나눠줘야 합니다. 파이썬 코드를 더블클릭으로 열리는 파일로 묶을 때는 PyInstaller를 씁니다. 서명 없이 나눠주면 백신이 오탐하기도 합니다.

CLI · GUI · 터미널 CLI(Command Line Interface)는 글자로 명령을 쳐서 쓰는 프로그램입니다. 버튼과 창으로 쓰는 보통의 프로그램은 GUI(Graphical User Interface)라고 부릅니다. CLI를 쓰는 검은 창이 터미널입니다.

ls를 치면 폴더 안 파일 목록이 나오고, git push를 치면 코드가 올라갑니다. 처음엔 낯설지만 순서를 글로 적어두면 그대로 다시 돌릴 수 있어서 자동화에 잘 맞습니다. 그래서 많은 개발 도구가 CLI로 먼저 나옵니다.

Claude Code도 원래 CLI입니다. 터미널에서 claude를 치면 시작되고, 에이전트가 그 터미널에서 명령을 직접 치며 일합니다. 지금은 데스크톱 앱 화면으로도 씁니다.

DB (데이터베이스) 앱의 표입니다. 행과 열이 있고, 찾고 거르고 정렬합니다. 회원 목록, 회비 내역, 사건 목록처럼 칸이 정해진 기록이 들어갑니다.

  • Supabase — 무료로 시작할 수 있는 DB 서비스입니다. 표준 DB(PostgreSQL)에 로그인 기능과 권한 규칙까지 붙어 있어서, 혼자 만드는 웹앱에 많이 씁니다
  • DynamoDB — 아마존의 DB입니다
  • 구글 시트 — 작을 때는 시트도 훌륭한 DB입니다. 기한 관리 앱이 그렇습니다

오브젝트 스토리지 앱의 창고입니다. 사진, PDF, 설치 파일처럼 통째로 된 파일을 넣어둡니다. DB와 다른 점은 안을 뒤져 찾지 않는다는 것입니다. 이름표(주소)로 넣고 이름표로 꺼냅니다.

  • Cloudflare R2 — 파일을 내려받을 때 요금(전송료)이 없어서, 사진이나 설치 파일 배포에 씁니다
  • AWS S3 — 이 분야의 원조입니다

보통 둘을 같이 씁니다. 사진은 창고(R2)에 넣고, 표(DB)에는 「누가 언제 올린 사진, 창고의 어느 칸」만 적습니다.

인증 · 권한 인증은 누구인지 확인하는 것, 권한은 그 사람이 무엇을 볼 수 있는지 정하는 것입니다. 방식마다 편하고 위험한 지점이 다릅니다.

방식 어떻게 편한 점 조심할 점
개인 링크 주소 끝에 그 사람만의 키(?key=…)를 붙인다 로그인 없이 링크만 누르면 된다 링크가 곧 열쇠. 메신저로 전달되거나 브라우저 기록에 남으면 누구나 들어온다. 키를 바꿀 수 있게 만들어둬야 한다
공용 비밀번호 모두가 같은 암호 하나 만들기 쉽다 누가 들어왔는지 모른다. 한 명이 나가면 전원의 암호를 바꿔야 한다
계정 로그인 이메일 + 비밀번호 (Supabase Auth, Cognito 등) 사람마다 구분된다. 한 명만 막을 수 있다 비밀번호 저장을 직접 짜면 위험하다. 검증된 서비스에 맡긴다
초대코드 + 승인 초대 링크로 가입하고, 관리자가 승인해야 들어온다 모르는 사람이 가입하지 못한다 초대코드에 유효기간과 1회용 제한을 건다
소셜 로그인 구글·카카오 계정으로 비밀번호를 따로 안 만든다 그 계정이 털리면 같이 털린다
매직링크 이메일로 온 링크를 누르면 로그인 비밀번호가 없다 메일함이 곧 열쇠다

로그인만으로는 부족합니다. 로그인한 사람이 남의 데이터까지 볼 수 있으면 소용이 없습니다. 그래서 DB에 「이 행은 이 사람(또는 이 가족, 이 모임)만 읽을 수 있다」는 규칙을 겁니다. Supabase에서는 RLS(행 단위 보안), AWS에서는 그룹 권한이라고 부릅니다. 화면에서 숨기는 것은 보안이 아닙니다. 규칙은 DB에 걸어야 합니다.

배포 · 호스팅 · CI/CD 배포는 만든 것을 남이 쓸 수 있는 자리에 올리는 일, 호스팅은 그 자리를 빌려주는 서비스입니다. Vercel과 AWS Amplify Hosting이 여기에 속합니다.

CI는 Continuous Integration(지속적 통합), CD는 Continuous Delivery/Deployment(지속적 전달·배포)의 약자입니다. 코드를 올리면 빌드·검사·배포를 기계가 알아서 해주는 흐름입니다.

  • Vercel, Amplify Hosting — GitHub에 코드를 올리면 알아서 빌드해 새 버전으로 바꿔 답니다. 이것도 CD입니다. 이유식 앱이 Amplify로 이렇게 돌고, 이 사이트는 Vercel로 그렇습니다
  • GitHub Actions — 「이 일이 생기면 이걸 해라」를 직접 적는 도구입니다. docx2patent는 버전 번호를 붙여 올리면 맥·윈도우용 설치 파일을 각각 만들어 R2에 올리는 것까지 자동으로 합니다. 맥에서 작업해도 윈도우용이 나오는 이유입니다

예약 작업 · 크론 정해진 시각에 알아서 도는 일입니다. 크론(cron)은 그 시각을 적는 형식의 이름으로, 0 9 1 * *라고 적으면 「매월 1일 9시」입니다.

할 수 있는 일은 이런 것들입니다.

  • 매일 기록 — 자산 앱은 매일 아침 시세를 받아 그날의 합계를 남깁니다. 그래서 추이 그래프가 생깁니다
  • 매일 알림 — 모임 앱은 하루 한 번 돌면서 보낼 알림을 골라 보냅니다
  • 정기 점검 — OA 작업의 위키는 매월 1일에 깨진 연결을 검사합니다
  • 감시 — 관심 출원의 상태가 바뀌었는지, 경쟁사의 새 공개가 떴는지 KIPRIS API로 매일 확인
  • 브리핑 — 출근 전에 오늘 기한을 모아 메시지로 받기

에이전트에게도 예약을 걸 수 있습니다. 그러면 사람이 부르지 않아도 AI가 정해진 시각에 일합니다.

스크래핑 · 브라우저 자동화 API가 없는 곳에서 사람이 보는 화면을 대신 읽어오는 방식입니다. 에이전트가 브라우저를 직접 눌러 파일을 받아오게 하는 것도 여기에 속합니다. API보다 잘 깨집니다. 화면이 조금만 바뀌어도 못 읽습니다. API가 있으면 API를 씁니다.

웹 푸시 · PWA 웹앱으로도 푸시 알림을 보낼 수 있습니다. 앱스토어에 올리지 않아도 됩니다. PWA는 웹앱을 홈 화면에 앱처럼 올려두는 방식이고, 아이폰은 웹앱을 홈 화면에 추가해야 알림을 받습니다. 모임 앱의 알림이 이렇게 갑니다.

저장소 · 커밋 · 푸시 (git) 저장소는 코드와 그 변경 이력을 담은 폴더입니다. 커밋은 변경을 하나의 기록으로 남기는 것, 푸시는 그 기록을 GitHub 같은 원격 저장소에 올리는 것입니다. 언제 무엇을 왜 바꿨는지 되짚을 수 있고, 잘못 고쳤으면 되돌릴 수 있습니다. 비공개 저장소라도 API 키는 올리지 않습니다.

제 OA 작업에서는

앱이 아닌 쪽도 하나 적어둡니다. OA 대응 초안을 만드는 작업(Cowork 프로젝트)에는 위 말들이 거의 다 들어 있습니다.

말 이 작업에서
에이전트 · 스킬 보고서에서 발췌해 레터를 쓰고 아웃룩 메일 초안까지 만드는 절차가 스킬
서브에이전트 · 루프 출원인·심사관·판정으로 나눠 최대 3라운드
토큰 한 방식이 약 38만, 서브에이전트로 나눈 방식이 약 85만
커넥터 (MCP) 구글 드라이브 커넥터로 휴대폰에서도 초안과 기한표를 읽음
API · JSON 기한 관리 쪽 API를 불러 사건 목록을 받음
LLM 위키 · 린트 논리·인용·주제 노트 120개. 매월 1일 예약 작업으로 점검, 제출 전에는 문서 검사 24종
로컬 · 클라우드 원본 서류와 최종 문서는 내 컴퓨터에만, 중간 작업 파일은 드라이브에

만들어두고 접은 스킬도 하나 있습니다. 이 글을 쓰려고 뒤져보다 다시 찾았습니다.

OA 원본 서류를 읽어 md로 정리하고 초안까지 만들어 드라이브에 올려두는 스킬입니다. 사람이 붙어 있는 시간을 줄이려고 만든 것이었습니다.

그림은 이랬습니다. 출근길에 휴대폰으로 클로드 앱의 음성 대화를 켜고 말로 초안 브리핑을 받습니다. 출근길에 대응 방향을 정하고, 사무실에 도착하면 PA를 워드 파일로 받아 조금만 고치고 끝냅니다. 휴대폰에서 읽을 수 있게 문서를 미리 md로 만들어두는 게 그 스킬의 몫이었습니다.

음성에서 막혔습니다. 클로드 앱이 한국어를 소리 내 읽는 게 매끄럽지 않았고, 특히 영문과 숫자와 한글이 섞이면 버벅거렸습니다. OA 브리핑은 거의 모든 문장이 그렇습니다. 「D1의 단락 [0032]에 개시된 housing 10」 같은 식이니까요. 그래서 현재 출근 시간을 활용하고 있지 못합니다. 출근길 브리핑을 ChatGPT나 Gemini에서 시도해보려고 생각 중입니다.

안 쓰는 것도 있습니다. RAG·임베딩, 파인튜닝, 로컬 LLM은 아직 쓰지 않습니다.

한 장으로 줄이면

말 한 줄
토큰 값과 한도를 세는 단위. 출력이 입력보다 비싸다
컨텍스트 윈도우 한 번에 볼 수 있는 분량
환각 그럴듯한 거짓. 인용을 먼저 뽑게 하고 원문과 대조한다
로컬 LLM 내 컴퓨터에서 도는 모델. 안 나가는 대신 덜 똑똑하다
API 프로그램끼리 일을 시키는 창구. 기상청, 증권사, KIPRIS
API 키 도장이자 법인카드. 코드에 적지 않는다
JSON 칸 이름과 값의 짝. 양식 채우기에 좋다
MCP AI용 공통 어댑터. 속은 대개 API
에이전트 모델 + 하네스. 목표를 받아 끝까지 스스로 움직인다
서브에이전트 빈 상태로 일부를 맡는 보조. 창은 아끼고 토큰은 더 든다
스킬 지침 + 서식 + 스크립트를 담은 서랍. 알아서 꺼내 쓴다
RAG 닮은 자료를 찾아 옆에 펴주고 쓰게 하기
LLM 위키 AI가 정리해 쌓는 업무 노트
스택 화면·서버·DB·저장소·로그인·호스팅의 조합
CLI 글자로 명령을 치는 프로그램. Claude Code가 그렇다
DB · 스토리지 표와 창고. 보통 같이 쓴다
인증 · 권한 누구인지, 무엇을 볼 수 있는지. 규칙은 DB에 건다
CI/CD 코드를 올리면 빌드·배포를 기계가 한다
크론 정해진 시각에 알아서 도는 일

남는 생각

이 글을 쓰다 보니 OA 대응 검토 보고서를 쓰는 일에 JSON을 더 적극적으로 쓸 수 있겠다는 생각이 들었습니다.

지금은 기한 관리 앱의 원본 시트와 OA 서류들에서 서지사항을 뽑아 md로 정리하고, 그걸 LLM이 워드에 하나씩 넣고 있습니다. 이걸 처음부터 JSON으로 뽑으면 워드에 넣는 일은 프로그램이 할 수 있습니다. 칸이 정해져 있으니 빠진 칸은 넣기 전에 드러나고, 옮기다 틀릴 일도 없습니다.

표가 들어가는 자리도 마찬가지입니다. 신규성·진보성 검토의 구성대비표처럼 행과 열이 정해진 곳은 JSON으로 받아 표를 그리게 하면 됩니다. 대비 결과를 O와 X로만 받게 정해두면 엉뚱한 기호가 끼어들 틈도 없습니다.

검사(린트)에도 쓸 수 있습니다. 지금은 제출 전 검사 결과가 사람이 읽는 글로만 나오는데, JSON으로도 내게 하면 통과 여부를 기계가 판정하고, 어떤 규칙이 자주 걸리는지도 쌓아서 볼 수 있습니다.

다음에는 지식재산처 같은 곳에서 여는 API로 무엇을 할 수 있을지 고민해보려고 합니다. 좋은 아이디어가 있으면 contact@describug.dev로 알려주세요.