diff --git a/posts/ai-workflow-after-100m-tokens/index.mdx b/posts/ai-workflow-after-100m-tokens/index.mdx index e4fa8d4..7154f0d 100644 --- a/posts/ai-workflow-after-100m-tokens/index.mdx +++ b/posts/ai-workflow-after-100m-tokens/index.mdx @@ -1,79 +1,75 @@ ## 들어가기 -AI를 이미 쓰고 있는데도 결과 품질이 들쭉날쭉하다면 문제는 모델 선택만이 -아닐 가능성이 크다. 같은 모델을 써도 어떤 사람은 초안을 빨리 만들고, -어떤 사람은 실제 배포 가능한 결과물까지 가져간다. 차이는 대부분 질문 -문장이 아니라 작업 환경에서 난다. +AI를 쓰면 생산성이 올라간다는 말은 이제 낯설지 않다. 너무 많이 들어서 오히려 +조금 납작하게 느껴질 때도 있다. 생산성이 얼마나 올라가는지보다 더 궁금한 것은 +따로 있었다. -최근 3개월 동안 ChatGPT Pro를 월평균 1억 토큰 이상 사용했다. 그 기간에 -일주일에 하나씩 제품을 만들며 3개의 결과물을 끝까지 구현했다. 이 경험으로 -확인한 결론은 단순하다. AI는 검색창처럼 쓸 때보다 **컨텍스트를 읽고, 도구를 -실행하고, 검증 결과로 다음 행동을 바꾸는 작업 시스템**으로 쓸 때 훨씬 큰 -가치를 낸다. +정말로 결과물을 끝까지 만들 수 있을까? -![문서, 코드, 로그, 검증 루프를 거쳐 AI 결과물이 만들어지는 작업 흐름 삽화](/images/posts/ai-workflow-after-100m-tokens/ai-workflow-illustration.png) +카카오톡 선물하기 이벤트로 ChatGPT Pro 월 구독권 5장을 저렴하게 구매했다. +덕분에 최근 3개월 동안 월평균 1억 토큰 이상을 써볼 수 있었다. 그 기간에 +일주일에 하나씩 제품을 만들며 총 3개의 결과물을 끝까지 구현했다. + +사용량을 보고 나도 조금 놀랐다. 그런데 토큰을 많이 썼다는 사실보다 더 +흥미로웠던 것은, AI를 대하는 내 태도가 꽤 많이 바뀌었다는 점이다. -이 글은 AI 내부 수학을 설명하는 글이 아니다. 이미 AI를 업무에 쓰고 있지만 -"어디까지 맡겨도 되는지", "왜 결과가 자주 빗나가는지", "비용과 검증을 -어떻게 관리해야 하는지"가 애매한 개발자를 위한 글이다. +처음에는 AI를 잘 쓰는 일이 좋은 질문을 던지는 일에 가깝다고 생각했다. 지금은 +조금 다르게 본다. AI는 검색창보다 작업 시스템에 가깝다. 컨텍스트를 읽고, +도구를 실행하고, 실패한 결과를 다시 보고, 다음 행동을 바꿀 때 비로소 제대로 +힘을 낸다. -핵심은 여섯 가지다. +![문서, 코드, 로그, 검증 루프를 거쳐 AI 결과물이 만들어지는 작업 흐름 삽화](/images/posts/ai-workflow-after-100m-tokens/ai-workflow-illustration.png) -- 토큰은 비용과 한도를 결정하는 작업량이다. -- 프롬프트는 예쁜 질문이 아니라 작업 계약이다. -- 컨텍스트는 많이 넣는 것이 아니라 필요한 근거만 고르는 일이다. -- RAG는 모델 기억 확장이 아니라 런타임 근거 주입이다. -- 에이전트는 자율성이 아니라 도구 사용과 피드백 루프다. -- 하네스는 AI가 일할 작업장을 검증 가능하게 제한하는 장치다. +이 글은 AI 내부 수학을 설명하는 글이 아니다. 월 1억 토큰 이상을 쓰며 내가 +실제로 체감한 변화에 가깝다. 토큰, 프롬프트, 컨텍스트, RAG, 에이전트, +하네스라는 말이 실제 작업 품질과 어떻게 이어지는지 정리한다. -작성 시점은 2026년 5월 12일이다. 모델 이름, 가격, 사용 한도는 자주 -바뀐다. 그래서 이 글은 특정 수치보다 계산 구조와 판단 기준을 중심으로 -정리한다. +작성 시점은 2026년 5월 12일이다. 모델 이름, 가격, 사용 한도는 자주 바뀐다. +그래서 이 글은 특정 수치보다 계산 구조와 판단 기준을 중심으로 읽는 편이 +안전하다. --- -## 검색창으로 쓰는 AI와 작업 시스템으로 쓰는 AI는 다르다 +## 처음에는 그냥 많이 시켜보면 된다고 생각했다 -검색 엔진은 문서를 찾아준다. LLM은 주어진 입력과 모델 상태를 바탕으로 다음 -토큰을 생성한다. 외부 검색, 파일 읽기, 코드 실행, 브라우저 조작은 모델이 -혼자 수행하는 능력이 아니라 주변 시스템이 붙여준 도구다. +처음 AI를 업무에 붙일 때는 다들 비슷하게 시작하지 않을까 싶다. -그래서 AI 활용의 첫 번째 기준은 "질문을 어떻게 멋지게 쓸까"가 아니다. -먼저 정해야 할 것은 아래 세 가지다. +모르는 것을 묻는다. 답이 나오면 복사한다. 뭔가 어긋나면 질문을 조금 바꾼다. +그래도 안 되면 다시 검색하듯 다른 말로 물어본다. -1. 어떤 정보를 컨텍스트로 넣을 것인가. -2. 어떤 도구 사용을 허용할 것인가. -3. 결과를 어떤 테스트나 근거로 검증할 것인가. +이 방식도 충분히 도움이 된다. 나도 처음에는 이렇게 썼다. 작은 코드 조각을 +물어보고, 에러 메시지를 붙여 넣고, 글 초안을 만들어 달라고 했다. 그 자체로도 +예전보다 빠르다. -이 관점에서 AI 활용은 단일 질의응답이 아니라 작은 실행 시스템에 가깝다. +그런데 제품 하나를 끝까지 만들려고 하면 이 방식은 금방 한계가 온다. AI가 +방금 한 말을 잊지는 않더라도, 내가 진짜 중요하게 생각하는 기준을 항상 붙잡고 +있지는 못한다. 테스트가 실패했는데도 그럴듯하게 설명을 이어가고, 이미 결정한 +구조를 슬쩍 바꾸고, 모르는 내용을 아는 것처럼 말하기도 한다. -```mermaid -flowchart LR - A["사용자 목표"] --> B["프롬프트와 컨텍스트 구성"] - B --> C["모델 추론과 토큰 생성"] - C --> D{"도구가 필요한가"} - D -->|아니오| E["응답 생성"] - D -->|예| F["검색, 파일 읽기, 코드 실행"] - F --> G["도구 결과를 다시 컨텍스트에 추가"] - G --> C - E --> H["검증, 테스트, 리뷰"] -``` +그때부터 질문이 바뀌었다. + +> 어떻게 더 좋은 답을 받을까? + +에서 -한 번의 프롬프트보다 중요한 것은 입력, 도구, 피드백 루프, 검증 기준이다. -이 네 가지가 없으면 더 좋은 모델을 써도 결과는 운에 가까워진다. +> 어떻게 하면 AI가 내 작업 환경 안에서 덜 위험하게 일하게 만들까? + +로 바뀌었다. + +이 차이를 느끼고 나서야 토큰, 프롬프트, 컨텍스트 같은 단어가 단순한 사용법이 +아니라 작업 설계의 언어로 보이기 시작했다. --- -## 토큰은 AI가 소비하는 작업량이다 +## 토큰을 많이 쓰면 비용보다 먼저 습관이 보인다 -토큰은 모델이 텍스트를 처리하는 기본 단위다. 단어와 정확히 같지 않다. -문자 하나일 수도 있고, 단어 일부일 수도 있고, 공백이나 문장부호도 토큰 수에 -영향을 준다. 영어 기준으로는 대략 1토큰이 4자 또는 0.75단어 정도로 -설명되지만, 한국어를 포함한 비영어권 텍스트에서는 비율이 달라질 수 있다. +토큰은 모델이 텍스트를 처리하는 기본 단위다. 단어와 정확히 같지 않다. 문자 +하나일 수도 있고, 단어 일부일 수도 있고, 공백이나 문장부호도 토큰 수에 영향을 +준다. -개발자가 토큰을 알아야 하는 이유는 세 가지다. +개발자가 토큰을 알아야 하는 이유는 명확하다. -1. 토큰 수가 비용에 직접 영향을 준다. +1. 토큰 수가 비용에 영향을 준다. 2. 토큰 수가 응답 속도에 영향을 준다. 3. 토큰 수가 컨텍스트 한도 초과 여부를 결정한다. @@ -86,28 +82,36 @@ API 응답의 사용량 필드에는 보통 입력 토큰, 출력 토큰, 전체 실제 비용 = 토큰 종류별 사용량 * 모델별 단가 + 도구 사용 비용 ``` -여기서 중요한 점은 입력과 출력의 단가가 같지 않을 수 있다는 것이다. 긴 -문서를 넣는 비용과 긴 답변을 생성하는 비용은 모델과 제공자에 따라 다르게 -책정된다. reasoning 모델에서는 최종 응답에 보이지 않는 추론용 출력 토큰도 -사용량에 포함될 수 있다. +하지만 직접 많이 써보니, 토큰은 비용 계산표이기 전에 습관을 비추는 거울에 +가까웠다. + +내가 자주 낭비한 토큰은 긴 답변이 아니었다. 이미 말한 배경을 다시 설명하고, +필요 없는 파일을 통째로 붙이고, 실패한 시도를 정리하지 않은 채 같은 요청을 +반복하는 데 쓴 토큰이 더 아까웠다. ChatGPT, Claude 같은 구독형 제품에서 보이는 "크레딧"이나 "사용량 한도"는 -API 토큰 과금과 완전히 같지 않다. 제품 UI에서는 메시지 수, 모델, 대화 길이, -파일, 도구 사용량, 서버 부하 같은 요소가 함께 반영될 수 있다. 정확한 비용을 -보려면 해당 제품의 usage 화면이나 API usage 필드를 기준으로 확인해야 한다. +API 토큰 과금과 완전히 같지 않을 수 있다. 제품 UI에서는 메시지 수, 모델, 대화 +길이, 파일, 도구 사용량, 서버 부하 같은 요소가 함께 반영될 수 있다. 정확한 +비용을 보려면 해당 제품의 usage 화면이나 API usage 필드를 기준으로 확인해야 +한다. + +내가 얻은 기준은 단순하다. -**정리: 토큰은 글자 수가 아니라 모델 작업량이다. 비용을 줄이려면 답변만 짧게 -요구하는 것보다 불필요한 입력과 반복 컨텍스트를 줄이는 편이 효과적이다.** +> 비용을 줄이고 싶다면 답변을 짧게 만들기 전에, 반복해서 넣는 컨텍스트부터 +> 줄여야 한다. + +토큰은 글자 수가 아니라 작업량이다. 많이 쓸 수 있다는 것보다, 무엇에 쓰고 +있는지 아는 것이 더 중요했다. --- -## 프롬프트는 작업 계약이다 +## 프롬프트보다 먼저 작업 계약이 필요했다 -프롬프트 엔지니어링은 모델이 원하는 결과를 안정적으로 만들도록 지시, 예시, -제약, 출력 형식을 설계하는 일이다. "더 친절하게 설명해줘" 같은 표현을 잘 -고르는 일이 핵심이 아니다. +한동안은 프롬프트를 잘 쓰면 대부분 해결될 줄 알았다. "전문가처럼 답해줘", +"단계별로 생각해줘", "친절하게 설명해줘" 같은 문장을 바꿔가며 시도했다. -실무에서는 아래 네 가지가 먼저다. +효과가 없지는 않았다. 하지만 오래가지는 않았다. 작업이 조금만 길어지면 +프롬프트 문장보다 더 중요한 것들이 드러난다. | 항목 | 약한 요청 | 더 나은 요청 | |---|---|---| @@ -116,128 +120,97 @@ API 토큰 과금과 완전히 같지 않다. 제품 UI에서는 메시지 수, | 입력 | "우리 시스템 기준으로" | "아래 ADR과 테스트 규칙을 기준으로" | | 출력 | "설명해줘" | "위험도 순으로 5개 이하로 정리해줘" | -좋은 프롬프트는 모델에게 모든 판단을 넘기지 않는다. 오히려 판단 경계를 -좁힌다. - -- 모델이 맡을 역할과 책임 범위를 정한다. -- 모델이 근거로 삼을 자료를 함께 준다. -- 하지 말아야 할 작업과 사람에게 다시 확인해야 할 조건을 적는다. -- 결과 형식, 우선순위, 최대 개수를 정한다. -- 결과를 어떤 테스트나 문서로 검증할지 정한다. +좋은 프롬프트는 멋진 문장이 아니라 작업 계약에 가깝다. AI에게 모든 판단을 +맡기는 대신, 무엇을 보고 무엇을 하지 말아야 하는지 정해준다. -OpenAI와 Anthropic 문서 모두 프롬프트 개선 전에 성공 기준과 평가 방법을 -먼저 세우는 접근을 강조한다. 이유는 단순하다. 성공 기준이 없으면 모델이나 -프롬프트를 바꿨을 때 품질이 실제로 개선됐는지 확인할 수 없다. +- 이번 작업의 목표는 무엇인가. +- 성공과 실패를 무엇으로 판단할 것인가. +- 어떤 문서와 테스트를 근거로 삼을 것인가. +- 바꾸면 안 되는 경계는 어디인가. +- 모르면 추측하지 말고 어디서 멈춰야 하는가. -**정리: 프롬프트 엔지니어링은 문장 꾸미기가 아니라 작업 계약을 쓰는 일이다.** +OpenAI와 Anthropic 문서 모두 프롬프트 개선 전에 성공 기준과 평가 방법을 먼저 +세우는 접근을 강조한다. 나도 이 순서가 맞다고 느꼈다. 성공 기준이 없으면 +AI가 더 그럴듯해졌는지, 실제로 더 나아졌는지 구분하기 어렵다. --- -## 컨텍스트는 근거와 잡음을 가르는 설계다 +## 컨텍스트는 많이 넣을수록 좋은 것이 아니었다 -프롬프트 엔지니어링이 "어떻게 지시할지"에 가깝다면, 컨텍스트 엔지니어링은 -"무엇을 보여줄지"에 가깝다. +프롬프트가 지시라면 컨텍스트는 작업 기억이다. 현재 질문, 이전 대화, 시스템 +지시, 파일 내용, 검색 결과, 도구 설명, 테스트 출력이 모두 컨텍스트가 된다. -컨텍스트는 모델이 현재 응답을 만들 때 볼 수 있는 정보 묶음이다. 현재 질문, -이전 대화, 시스템 지시, 파일 내용, 검색 결과, 도구 설명, 테스트 출력이 모두 -컨텍스트가 될 수 있다. 컨텍스트 윈도우는 이 정보를 담을 수 있는 작업 기억 -공간이다. +처음에는 많이 보여줄수록 좋다고 생각했다. 저장소 전체를 읽히고, 긴 로그를 +붙이고, 관련 있어 보이는 문서를 다 넣으면 더 똑똑하게 판단할 것 같았다. -컨텍스트가 크다고 항상 좋은 것은 아니다. +그런데 꼭 그렇지는 않았다. -- 오래된 대화가 남아 있으면 현재 목표와 충돌할 수 있다. +- 오래된 대화가 남아 있으면 현재 목표와 충돌한다. - 관련 없는 파일이 많으면 중요한 신호가 묻힌다. -- 긴 로그를 통째로 넣으면 모델이 원인보다 표면 패턴에 끌릴 수 있다. -- 같은 지시를 매번 바꾸면 캐시 효율이 떨어질 수 있다. +- 긴 로그를 통째로 넣으면 원인보다 표면 패턴에 끌린다. +- 같은 지시를 매번 바꾸면 캐시 효율도 떨어진다. + +컨텍스트 엔지니어링은 결국 무엇을 보여줄지보다 무엇을 빼야 할지에 가까웠다. -그래서 컨텍스트 엔지니어링은 보통 아래 순서로 생각한다. +나는 지금 아래 순서로 생각하려고 한다. -1. 지금 작업의 성공 기준을 정한다. -2. 성공 기준에 직접 필요한 자료만 고른다. -3. 안정적인 지시와 변하는 입력을 분리한다. -4. 긴 자료는 구조화하거나 요약한 뒤 원문 위치를 남긴다. -5. 모델 답변을 테스트, 로그, 문서로 다시 검증한다. +1. 지금 작업의 성공 기준을 먼저 정한다. +2. 그 기준에 직접 필요한 자료만 고른다. +3. 안정적인 지시와 매번 바뀌는 입력을 분리한다. +4. 긴 자료는 요약하되 원문 위치를 남긴다. +5. 모델 답변을 테스트, 로그, 문서로 다시 확인한다. 프롬프트 캐싱도 같은 맥락에서 이해할 수 있다. 제공자별 구현은 다르지만, 공통 아이디어는 반복되는 긴 입력을 매번 새로 처리하지 않도록 재사용하는 -것이다. OpenAI는 일정 길이 이상의 동일한 프롬프트 prefix에 자동 캐싱을 -적용하고, Anthropic은 `cache_control`로 캐시할 구간을 지정하는 방식을 -제공한다. 둘 다 안정적인 지시, 도구 정의, 예시, 긴 배경 자료를 앞쪽에 두고 -변하는 사용자 입력을 뒤쪽에 두는 구성이 유리하다. +것이다. 안정적인 지시, 도구 정의, 예시, 긴 배경 자료를 앞쪽에 두고 변하는 +사용자 입력을 뒤쪽에 두는 구성이 유리하다. -**정리: 컨텍스트 엔지니어링은 더 많이 붙이는 기술이 아니라, 지금 판단에 -필요한 정보만 남기는 기술이다.** +정리하면, 컨텍스트는 많이 붙이는 기술이 아니다. 지금 판단에 필요한 근거만 +남기는 기술이다. --- -## RAG는 모델 기억을 늘리는 기술이 아니다 +## RAG와 에이전트는 이름보다 운영 방식이 중요했다 -RAG(Retrieval Augmented Generation)는 외부 문서나 데이터에서 관련 정보를 -찾아 현재 프롬프트에 주입하는 방식이다. 모델 자체의 학습 내용을 바꾸는 것이 -아니라, 응답 시점에 참고할 근거를 추가한다. +AI를 쓰다 보면 멋진 이름을 자주 만난다. RAG, agent, workflow, tool use 같은 +단어가 그렇다. 처음에는 이 단어들이 어떤 특별한 마법처럼 느껴졌다. -RAG를 쓰면 "모델이 우리 사내 문서를 학습했다"고 표현하기 쉽지만 정확한 -표현은 아니다. 더 정확히는 아래에 가깝다. +하지만 직접 써보면 조금 담백해진다. + +RAG(Retrieval Augmented Generation)는 모델이 우리 문서를 학습하는 기술이 +아니다. 외부 문서나 데이터에서 관련 정보를 찾아 현재 프롬프트에 넣는 방식에 +가깝다. ```text 질문 -> 관련 문서 검색 -> 검색 결과를 컨텍스트에 추가 -> 모델 응답 생성 ``` -이 차이는 운영에서 중요하다. RAG 품질은 모델 성능만으로 결정되지 않는다. -문서 분할 방식, 임베딩, 검색 쿼리, 랭킹, 중복 제거, 출처 표시, 오래된 문서 -정리까지 함께 영향을 준다. - -사내 지식 기반을 붙일 때는 아래 질문을 먼저 해야 한다. - -- 검색 결과가 실제로 질문에 답할 수 있는가? -- 오래된 문서와 최신 문서를 구분하는가? -- 모델이 근거 문장이나 원문 위치를 표시하는가? -- 검색 실패 시 모른다고 말할 수 있는가? -- 답변 품질을 평가할 테스트 질문 세트가 있는가? - -**정리: RAG는 모델 기억 확장이 아니라 런타임 근거 주입이다. 검색 품질이 낮으면 -좋은 모델도 그럴듯한 오답을 만들 수 있다.** - ---- - -## 에이전트는 피드백 루프다 +그래서 RAG의 품질은 모델만으로 결정되지 않는다. 문서 분할 방식, 검색 쿼리, +랭킹, 중복 제거, 오래된 문서 정리, 출처 표시가 모두 영향을 준다. 검색 결과가 +별로면 좋은 모델도 그럴듯한 오답을 만든다. -에이전트라는 말은 넓게 쓰인다. 어떤 팀은 도구를 쓰는 챗봇을 에이전트라고 -부르고, 어떤 팀은 여러 단계의 작업을 스스로 계획하고 실행하는 시스템을 -에이전트라고 부른다. - -Anthropic은 agentic system을 크게 두 부류로 나눈다. - -| 구분 | 설명 | 적합한 상황 | -|---|---|---| -| Workflow | 코드가 미리 정한 경로로 LLM과 도구를 조합한다 | 경로가 명확하고 예측 가능해야 할 때 | -| Agent | LLM이 다음 단계와 도구 사용을 동적으로 결정한다 | 필요한 단계 수를 미리 알기 어려울 때 | - -개발 업무에서는 이 구분이 중요하다. 모든 일을 에이전트로 만들 필요는 없다. -브랜치 생성, 린트 실행, 릴리즈 체크리스트처럼 절차가 정해진 일은 workflow가 -더 낫다. 반대로 원인 모를 테스트 실패를 조사하거나, 큰 코드베이스에서 수정 -범위를 탐색하는 일은 agent 방식이 유리할 수 있다. - -에이전트의 핵심은 "알아서 한다"가 아니다. 매 단계마다 환경에서 ground truth를 -얻고, 그 결과로 다음 행동을 바꾸는 피드백 루프다. +에이전트도 비슷했다. 핵심은 "알아서 다 한다"가 아니었다. 매 단계마다 환경에서 +ground truth를 얻고, 그 결과로 다음 행동을 바꾸는 피드백 루프가 핵심이었다. ```text 계획 -> 도구 실행 -> 결과 관찰 -> 계획 수정 -> 다시 실행 -> 검증 ``` -이 루프에는 비용도 있다. 단계가 늘어나면 토큰과 도구 호출이 늘어난다. 한 번의 -잘못된 판단이 다음 단계의 입력으로 들어가면 오류가 누적될 수 있다. 그래서 -에이전트에는 중단 조건, 권한 경계, 테스트, 로그, 사람 승인 지점이 필요하다. +Anthropic은 agentic system을 workflow와 agent로 나눈다. 절차가 명확하면 +workflow가 낫고, 필요한 단계 수를 미리 알기 어려우면 agent가 유리하다. 개발 +업무도 마찬가지다. 브랜치 생성, 린트 실행, 릴리즈 체크리스트처럼 경로가 정해진 +일은 workflow가 더 안정적이다. 반대로 원인 모를 테스트 실패를 조사하거나, 큰 +코드베이스에서 수정 범위를 탐색하는 일은 agent 방식이 잘 맞는다. -**정리: 에이전트는 마법 같은 자율 실행이 아니라 도구 사용과 검증을 반복하는 -제어 루프다.** +여기서 중요한 것은 이름이 아니다. AI가 어떤 근거를 보고, 어떤 도구를 쓰고, +실패했을 때 어디까지 다시 시도할지 정하는 운영 방식이다. --- -## 하네스는 AI가 일할 작업장이다 +## 하네스를 만들고 나서야 일이 끝나기 시작했다 -하네스 엔지니어링은 OpenAI의 Codex 활용 글에서 접한 표현이다. 이 글에서는 -AI가 안정적으로 일하도록 감싸는 실행 환경을 설계하는 일로 정리한다. +하네스 엔지니어링은 OpenAI의 Codex 활용 글에서 접한 표현이다. 나는 이 말을 +AI가 일할 작업장을 만드는 일로 이해했다. 코딩 에이전트를 예로 들면 하네스는 아래 요소를 포함한다. @@ -253,58 +226,63 @@ AI가 안정적으로 일하도록 감싸는 실행 환경을 설계하는 일 불안정하면 결과가 흔들린다. 테스트가 느리거나, 의존성이 깨져 있거나, 문서가 오래됐거나, 권한 경계가 불명확하면 모델은 그 틈에서 불필요한 추측을 한다. -실무에서 하네스 품질을 높이는 방법은 단순하다. - -1. 자주 쓰는 작업은 명령어 하나로 검증되게 만든다. -2. 실패 로그가 원인을 좁힐 수 있게 출력 형식을 정리한다. -3. AI에게 허용할 도구와 금지할 행동을 분리한다. -4. 반복되는 절차는 프롬프트가 아니라 Skill이나 script로 고정한다. -5. 결과는 사람이 검토할 수 있는 diff, 테스트 결과, 링크로 남긴다. - 이 관점에서 `AGENTS.md`, ADR, 테스트 스크립트, CI, 린트 규칙은 모두 AI 활용 품질에 영향을 준다. AI를 잘 쓰는 팀은 프롬프트만 잘 쓰는 팀이 아니라 AI가 읽고 실행하고 검증할 수 있는 환경을 잘 정리한 팀이다. -**정리: 하네스 엔지니어링은 AI에게 일을 더 많이 맡기는 기술이 아니라, 맡긴 일을 -검증 가능한 형태로 제한하는 기술이다.** +이걸 체감한 뒤로는 AI에게 일을 맡길 때 먼저 작업장을 확인하게 됐다. + +1. 이 저장소에서 따라야 할 규칙이 문서화되어 있는가. +2. 바꿔도 되는 파일과 바꾸면 안 되는 파일이 분명한가. +3. 검증 명령이 한 번에 실행되는가. +4. 실패했을 때 원인을 좁힐 로그가 남는가. +5. 사람이 마지막에 볼 수 있는 diff와 요약이 남는가. + +하네스는 AI에게 일을 더 많이 맡기는 기술이 아니다. 맡긴 일을 검증 가능한 +형태로 제한하는 기술이다. --- -## 실제 업무에서는 세 가지 기준으로 시작한다 +## 그래서 지금은 이렇게 맡긴다 -AI를 검색 봇 이상으로 쓰려면 매번 아래 세 가지를 먼저 확인해야 한다. +3개월 동안 AI를 많이 쓰면서 가장 크게 바뀐 것은 요청 방식이다. 예전에는 +"이거 해줘"에 가까웠다면, 지금은 작은 작업 주문서처럼 쓴다. -### 1. 성공 기준은 관찰 가능해야 한다 +요청 전에 먼저 적는 것은 대략 이렇다. -"좋은 답변"은 성공 기준이 아니다. 성공 기준은 실행 결과로 확인할 수 있어야 -한다. +```text +목표: 무엇을 끝내야 하는가 +맥락: 어떤 문서와 코드를 기준으로 삼아야 하는가 +경계: 무엇은 바꾸면 안 되는가 +검증: 어떤 명령이나 근거로 맞았다고 볼 것인가 +보고: 결과를 어떤 형태로 받을 것인가 +``` -- 테스트가 통과한다. -- 공식 문서 링크가 붙어 있다. -- 기존 API 동작을 바꾸지 않는다. -- 리뷰 코멘트가 파일과 라인 기준으로 정리된다. -- 비용이 이전 방식보다 낮다. +이 다섯 가지를 적으면 프롬프트가 길어지긴 한다. 하지만 전체 토큰은 오히려 +줄어드는 경우가 많았다. 중간에 방향을 잃고 되묻는 일이 줄고, 엉뚱한 파일을 +고치는 일이 줄고, 검증 결과를 기준으로 다음 행동을 정하기 쉬워졌기 때문이다. -성공 기준이 없으면 프롬프트도, 컨텍스트도, 에이전트도 개선하기 어렵다. +AI를 쓸 때마다 거창한 시스템을 만들 필요는 없다. 다만 최소한 아래 세 가지는 +먼저 정해두는 편이 좋았다. -### 2. 모델이 볼 정보와 보지 말아야 할 정보를 나눈다 +### 1. 성공 기준은 관찰 가능해야 한다 + +"좋은 답변"은 기준이 아니다. 테스트가 통과한다, 공식 문서 링크가 붙어 있다, +기존 API 동작을 바꾸지 않는다처럼 실행 결과로 확인할 수 있어야 한다. -모델에게 모든 것을 보여주는 방식은 초반에는 편하지만 규모가 커질수록 비싸고 -불안정하다. 현재 판단에 필요한 문서, 코드, 로그만 좁혀야 한다. +### 2. 모델이 볼 정보와 보지 말아야 할 정보를 나눈다 -반대로 필요한 정보를 숨기면 모델은 추측한다. AI 오답의 상당수는 모델이 -멍청해서라기보다 판단에 필요한 근거가 컨텍스트에 없어서 생긴다. +필요한 정보를 숨기면 모델은 추측한다. 반대로 모든 것을 보여주면 중요한 신호가 +묻힌다. 지금 판단에 필요한 문서, 코드, 로그만 고르는 일이 중요하다. ### 3. 결과를 검증 가능한 형태로 회수한다 -AI가 낸 결과는 최종 결과물이 아니라 검증 대상이다. - -- 코드는 테스트와 타입 검사로 검증한다. -- 문서는 공식 문서와 원문 링크로 검증한다. -- 설계는 대안 비교와 실패 조건으로 검증한다. -- 운영 작업은 로그와 롤백 기준으로 검증한다. +AI가 낸 결과는 최종 결과물이 아니라 검증 대상이다. 코드는 테스트와 타입 검사, +문서는 공식 문서와 원문 링크, 설계는 대안 비교와 실패 조건으로 다시 확인해야 +한다. -이 검증 루프가 있어야 AI 활용이 반복 가능한 엔지니어링이 된다. +이 세 가지를 지키면 AI는 더 이상 신기한 대화 상대에만 머물지 않는다. 꽤 +쓸만한 작업 파트너가 된다. --- @@ -336,31 +314,23 @@ AI는 보일러플레이트, 반복 구현, 초안 작성 같은 우발적 비 대한 불확실성 같은 본질적 복잡성은 그대로 남는다. 오히려 AI가 결과물을 더 빨리 만들수록 그 본질을 읽고 판단하는 개발자의 역량은 더 선명하게 드러난다. -**정리: AI 시대의 개발자는 덜 중요한 사람이 아니라, 더 많은 결과물에 책임 있는 -판단을 내려야 하는 사람이다.** - --- ## 마무리 -AI 활용의 허들은 모델 내부를 모르는 데서만 생기지 않는다. 더 큰 허들은 AI를 -검색창처럼만 바라보는 데서 생긴다. - -토큰은 비용과 한도를 결정한다. 프롬프트는 작업 계약을 만든다. 컨텍스트는 -모델의 작업 기억을 구성한다. RAG는 외부 근거를 런타임에 주입한다. 에이전트는 -도구와 피드백 루프를 반복한다. 하네스는 그 모든 과정이 안전하게 실행되도록 -작업장을 만든다. +월 1억 토큰을 썼다고 AI를 완전히 이해하게 된 것은 아니다. 오히려 반대에 +가깝다. 많이 써볼수록 AI를 더 조심해서 써야 한다는 생각이 강해졌다. -그래서 AI를 잘 쓰는 개발자의 기준은 "질문을 예쁘게 쓰는 사람"이 아니다. 목표를 -정의하고, 필요한 컨텍스트를 고르고, 도구 사용을 제한하고, 결과를 검증 가능한 -형태로 회수하는 사람이다. +다만 한 가지는 분명해졌다. AI는 검색 봇보다 작업 시스템에 가깝다. 좋은 +프롬프트 하나보다 좋은 작업 환경과 검증 기준이 더 오래간다. 결과물을 만드는 단계는 이미 가능해졌다. 이제 차이는 더 많이 생성하는 데서만 나지 않는다. 무엇을 만들지, 왜 그렇게 만들지, 어떤 근거로 맞다고 판단할지, 그리고 나중에 어떤 비용으로 돌아올지를 설명할 수 있는지에서 난다. -> AI는 검색 봇보다 작업 시스템에 가깝다. 생산성은 더 긴 프롬프트가 아니라 -> 더 좋은 실행 환경과 검증 기준에서 나온다. +처음에는 AI에게 일을 맡기는 법을 배우는 줄 알았다. 지금은 조금 다르게 +생각한다. AI를 잘 쓰는 일은 결국 내가 어떤 개발자인지 더 선명하게 드러내는 +일에 가깝다. --- @@ -368,15 +338,52 @@ AI 활용의 허들은 모델 내부를 모르는 데서만 생기지 않는다. ### 이 글의 팩트체크에 사용한 OpenAI 자료 -- 토큰과 비용 구조: [What are tokens and how to count them?](https://help.openai.com/en/articles/4936856-what-are-tokens-and-how-to-count-them) -- 프롬프트와 평가 기준: [Prompt engineering](https://developers.openai.com/api/docs/guides/prompt-engineering), [Working with evals](https://developers.openai.com/api/docs/guides/evals) -- 프롬프트 캐싱: [Prompt caching](https://developers.openai.com/api/docs/guides/prompt-caching) -- API 사용량 필드: [Responses API reference](https://platform.openai.com/docs/api-reference/responses) -- Retrieval/RAG 관점: [Retrieval](https://developers.openai.com/api/docs/guides/retrieval) -- Codex와 하네스 엔지니어링: [하네스 엔지니어링](https://openai.com/ko-KR/index/harness-engineering/) +
+
토큰과 비용 구조
+
+ What are tokens and how to count them? +
+
프롬프트와 평가 기준
+
+ Prompt engineering +
+
+ Working with evals +
+
프롬프트 캐싱
+
+ Prompt caching +
+
API 사용량 필드
+
+ Responses API reference +
+
Retrieval/RAG 관점
+
+ Retrieval +
+
Codex와 하네스 엔지니어링
+
+ 하네스 엔지니어링 +
+
### 같이 읽어볼 자료 -- 프롬프트 패턴을 넓게 훑을 때: [Prompt Engineering Guide 한국어판](https://www.promptingguide.ai/kr) -- agent와 context engineering 관점을 비교할 때: [Anthropic: Building effective agents](https://www.anthropic.com/engineering/building-effective-agents), [Anthropic: Effective context engineering for AI agents](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents) -- AI 시대 개발자 역할을 고민할 때: [Evan Moon: AI가 코드를 쓰는 시대, 개발자의 진짜 역량이 드러난다](https://evan-moon.github.io/2026/02/10/developer-in-ai-era/) +
+
프롬프트 패턴을 넓게 훑을 때
+
+ Prompt Engineering Guide 한국어판 +
+
agent와 context engineering 관점을 비교할 때
+
+ Anthropic: Building effective agents +
+
+ Anthropic: Effective context engineering for AI agents +
+
AI 시대 개발자 역할을 고민할 때
+
+ Evan Moon: AI가 코드를 쓰는 시대, 개발자의 진짜 역량이 드러난다 +
+
diff --git a/posts/ai-workflow-after-100m-tokens/meta.json b/posts/ai-workflow-after-100m-tokens/meta.json index 3d112ef..d0f27fc 100644 --- a/posts/ai-workflow-after-100m-tokens/meta.json +++ b/posts/ai-workflow-after-100m-tokens/meta.json @@ -1,7 +1,7 @@ { - "title": "월 1억 토큰을 쓰며 정리한 AI 활용 기준", + "title": "월 1억 토큰을 쓰고 나서야 보인 AI 활용법", "slug": "ai-workflow-after-100m-tokens", - "description": "AI를 검색창이 아니라 컨텍스트 실행 시스템으로 쓰기 위해 토큰, 프롬프트, 컨텍스트, RAG, 에이전트, 하네스 관점을 정리한다.", + "description": "3개월간 월평균 1억 토큰 이상을 쓰며 AI를 검색창이 아니라 작업 시스템으로 바라보게 된 과정을 정리한다.", "date": "2026-05-12", "category": "Tech", "image": "/images/posts/ai-workflow-after-100m-tokens/ai-workflow-illustration.png", diff --git a/styles/globals.css b/styles/globals.css index dca9abc..15a7e95 100644 --- a/styles/globals.css +++ b/styles/globals.css @@ -387,6 +387,41 @@ color: var(--color-grey-400); } +.prose .resource-links { + display: grid; + gap: 0.875rem; + margin: 1.125rem 0 1.75rem; +} + +.prose .resource-links dt { + margin: 0; + color: var(--color-grey-700); + font-weight: var(--font-medium); + line-height: var(--leading-normal); +} + +.prose .resource-links dd { + position: relative; + margin: -0.375rem 0 0 1rem; + color: var(--color-grey-700); + line-height: var(--leading-prose); +} + +.prose .resource-links dd + dd { + margin-top: -0.625rem; +} + +.prose .resource-links dd::before { + content: ''; + position: absolute; + top: 0.85em; + left: -0.875rem; + width: 0.25rem; + height: 0.25rem; + border-radius: var(--radius-full); + background: var(--color-grey-400); +} + .prose blockquote { border-left: 3px solid var(--color-toss-blue); padding: 1.125rem 1.25rem;