https://team-edo.github.io/categories/ai-native/Recent content in AIFlow on 얼쑤 · Team EdoHugoko-krFri, 06 Nov 2026 16:22:01 +0900https://team-edo.github.io/posts/2026/11/coco-152-155-plan-build-handoff/Fri, 06 Nov 2026 16:22:01 +0900https://team-edo.github.io/posts/2026/11/coco-152-155-plan-build-handoff/<p>새 API를 계획하면서 라우트와 서비스의 위치를 확인해도, 구현 세션은 그 근거를 받지 못하면 같은 코드를 다시 찾게 됩니다. 반대로 검색 결과를 전부 넘기면 구현자가 다시 선별해야 합니다. 어느 범위에 메모가 도움이 되는지 알아보기 위해 새 기능과 기존 동작 변경, 고정 패치 검토를 나눠 비교했습니다. 1.5.2는 적용 범위를 좁혔고, 1.5.5는 넘겨받은 위치를 현재 코드와 대조했고, 1.5.6은 이전 검사가 이번 리뷰의 근거로 섞이지 않도록 했습니다.</p>https://team-edo.github.io/posts/2026/11/coco-154-blog-thumbnail-collaboration/Fri, 06 Nov 2026 15:38:35 +0900https://team-edo.github.io/posts/2026/11/coco-154-blog-thumbnail-collaboration/<p>얼쑤 블로그 첫 글의 썸네일에는 반려견 코코가 등장합니다. 코코나 팀의 백호 캐릭터 절쑤를 다른 글에서도 쓰려면 프로젝트가 정한 외형과 작성자가 이번 글에 맞춰 고를 장면을 구분해야 했습니다. 예를 들어 코코의 곱슬털과 목걸이는 유지하되, 표정과 소품은 글에 따라 달라질 수 있습니다. 1.5.4에서는 캐릭터 기준은 블로그에서 읽고, 구도 선택과 실제 화면 확인은 작성자와 함께 진행하도록 했습니다. <a href="https://team-edo.github.io/posts/2026/10/hello/">얼쑤 기술 블로그 첫 글</a></p> <h2 id="캐릭터는-블로그가-정하고-절차는-coco에-둔다">캐릭터 기준과 제작 절차 분리</h2> <p>얼쑤 블로그의 가이드에는 캐릭터 이름, 승인된 참고 이미지, 유지할 외형이 들어갑니다. COCO 1.5.4의 <code>coco-blog</code>는 작업하는 프로젝트에서 그 가이드를 찾고, 원고 방향이 정해지면 작성자에게 캐릭터 사용 여부부터 묻습니다. 한 캐릭터를 골라도 되고, 둘이 어울리는 장면을 구상할 수도 있습니다. 글의 개념 자체를 보여주는 그림이 적합하면 캐릭터 없이도 진행합니다. <a href="https://github.com/thisis-joe/skills/blob/v1.5.4/docs/coco-1.5.4.md">COCO 1.5.4 변경 기록</a></p>https://team-edo.github.io/posts/2026/11/coco-151-153-til-to-blog/Fri, 06 Nov 2026 15:15:45 +0900https://team-edo.github.io/posts/2026/11/coco-151-153-til-to-blog/<p>글감 추천을 검토하며 여러 사람의 메모와 제목이 같은 메모를 섞어 보았습니다. 후보를 고르기 전 원문을 전부 읽지 않도록 한 규칙이, 후보를 구별할 요약까지 막는 경우가 있었습니다. 문제 해결 사례에서는 또 다른 빈틈이 드러났습니다. 검토용 사례에서 조치 뒤 관찰을 빼면 해결을 확인할 근거가 사라졌습니다. 1.5.1에서는 글감을 고를 만큼 읽게 했고, 1.5.3에서는 사례로 저장할 때 해결을 확인한 증거를 요구했습니다.</p> <h2 id="151에서는-목록과-추천을-분리했다">1.5.1 목록과 추천 분리</h2> <p><code>coco-blog</code>는 로컬 TIL에서 대상이 되는 노트를 모두 찾아 번호, 제목, 짧은 요약을 보여 줍니다. 제목이 같아도 파일이 다르면 별도 항목으로 두고, 읽을 수 없거나 기여 관계가 확인되지 않은 항목은 그 상태를 표시합니다. 작성자가 고르기 전에는 메타데이터와 필요한 일부만 읽고, 선택이 끝난 뒤 해당 노트의 전문을 읽습니다. 이미 고른 노트가 있다면 그 선택에서 이어갑니다. <a href="https://github.com/thisis-joe/skills/blob/v1.5.1/docs/coco-1.5.1.md">COCO 1.5.1 변경 기록</a></p>https://team-edo.github.io/posts/2026/11/coco-150-skill-contents/Tue, 03 Nov 2026 22:28:09 +0900https://team-edo.github.io/posts/2026/11/coco-150-skill-contents/<p>1.4.2의 스킬 문서를 보면 <code>coco-research</code>는 한 문단으로 끝나고, <code>coco-build</code>에는 구현과 검증에 필요한 여러 절이 이어졌습니다. 파일을 처음 여는 사람과 에이전트가 읽을 부분을 찾기 쉽도록 1.5.0에서 스킬 30개에 공통 목차를 넣었습니다. 다음으로 풀어야 할 문제는 절 제목이 바뀌어도 목차가 실제 본문을 가리키게 하는 일이었습니다. <a href="https://github.com/thisis-joe/skills/blob/v1.5.0/docs/coco-1.5.0.md">COCO 1.5.0 변경 기록</a></p> <h2 id="목차와-본문이-함께-바뀌게-했다">목차와 본문 맞추기</h2> <p>목차는 본문의 모든 <code>##</code> 제목을 등장 순서대로 연결합니다. 문서에 아래와 같은 두 절이 있다면 목차에도 링크가 두 개 들어갑니다.</p>https://team-edo.github.io/posts/2026/11/coco-1-4-2-pr-metadata-readback/Tue, 03 Nov 2026 14:46:20 +0900https://team-edo.github.io/posts/2026/11/coco-1-4-2-pr-metadata-readback/<p>새 PR에 리뷰어를 붙이는 규칙을 확인하던 중, <code>gh pr edit --add-reviewer</code>로 PR 작성자 자신에게 리뷰를 요청했을 때 종료 코드가 <code>0</code>으로 나왔습니다. 같은 요청을 GitHub API로 보내자 작성자에게 리뷰를 요청할 수 없다는 <code>422</code> 응답이 돌아왔고, PR을 다시 조회하니 리뷰어는 비어 있었습니다. 이 차이 때문에 1.4.2에서는 설정 명령이 끝난 뒤 담당자·리뷰어·라벨을 다시 읽어 반영 결과를 판단하게 했습니다. <a href="https://github.com/thisis-joe/skills/commit/7feeb2bafff91985702a574792ff10be082b2287">수정 커밋</a></p> <h2 id="pr-생성과-메타데이터-쓰기를-분리한다">PR 생성과 메타데이터 설정 분리</h2> <p><code>coco-push</code>, <code>coco-merge</code>, <code>coco-ship</code>이 새 PR이나 MR을 생성하면 담당자와 리뷰어의 기본 후보는 해당 요청을 연 계정입니다. 로컬 Git 커밋 작성자 대신 GitHub나 GitLab에 로그인한 계정을 조회합니다. 사용자나 저장소 지침이 다른 사람을 지정했다면 그 지시를 따릅니다. 라벨은 저장소에 이미 있는 이름과 설명을 읽어 변경에 맞는 것만 추가합니다. 이미 열려 있던 요청은 생성 시점의 자동 설정 대상에서 제외합니다.</p>https://team-edo.github.io/posts/2026/11/coco-1-4-1-blog-cover-preview/Tue, 03 Nov 2026 12:08:31 +0900https://team-edo.github.io/posts/2026/11/coco-1-4-1-blog-cover-preview/<p>Team Edo 블로그의 같은 썸네일은 추천 영역에서는 가로로 넓게, 모바일 목록에서는 세로로 좁게 보입니다. 핵심 소품이 이미지 가장자리에 있으면 원본에서는 잘 보여도 모바일 카드에서 잘릴 수 있습니다. 1.4.1에서는 그림을 내보내기 전에 실제 블로그 레이아웃에서 후보를 비교하는 절차를 <code>coco-blog</code>에 넣었습니다.</p> <h2 id="시안은-글의-방향이-정해진-뒤-제안한다">글 방향을 정한 뒤 시안 제안</h2> <p><code>coco-blog</code>는 먼저 블로그가 썸네일을 어떤 필드에서 읽는지, 어떤 크기와 형식을 받는지, 이미지가 어디에 올라가는지 확인합니다. 글의 방향이 정해지면 본문에서 독자에게 남길 장면이나 개념을 골라 벡터 시안 두세 개를 대화에 보여 줍니다. 작성자는 후보를 고르거나 구도 수정을 요청할 수 있고, 직접 만든 이미지를 제시할 수도 있습니다. Team Edo 블로그에서 쓸 이미지라면 글 목록과 추천 영역에서 같은 그림을 어떻게 보여 주는지도 살핍니다.</p>https://team-edo.github.io/posts/2026/10/coco-1-4-0-askme-research/Fri, 30 Oct 2026 09:59:20 +0900https://team-edo.github.io/posts/2026/10/coco-1-4-0-askme-research/<p>기술 조사는 <code>coco-research</code>가, 복습 퀴즈는 <code>coco-askme</code>가 맡고 있었습니다. 예를 들어 방금 바꾼 재시도 코드의 이유를 묻고 퀴즈로 이해를 확인하려면, 같은 맥락을 두 스킬에서 이어가야 했습니다. 1.4.0에서는 한 질문에서 답변·추가 조사·퀴즈로 이어지도록 진입점을 모았습니다. 요약으로 대화를 이어받을 때는 확인할 수 있는 근거의 범위도 밝히게 했습니다.</p> <h2 id="무엇을-묻는지에-따라-시작을-바꾼다">질문에 맞춰 시작하기</h2> <p>질문을 적어 호출하면 관련 근거로 바로 답합니다. 예를 들어 “재시도 횟수를 다 썼을 때 원래 오류는 어디로 전달돼?”라고 물으면 코드 흐름을 따라 답할 수 있습니다. 인자 없이 부르면 현재 대화에서 더 알아볼 만한 주제를 최대 세 개 제시하고, 목록에 없는 질문도 받을 수 있습니다. 퀴즈를 요청하면 근거가 있는 문제를 하나만 내고 답을 기다립니다. 같은 코드가 출발점이어도 질문, 주제 탐색, 복습은 서로 다른 시작을 갖습니다. <a href="https://github.com/thisis-joe/skills/blob/aaeb1dc/docs/coco-1.4.0.md">COCO 1.4.0 릴리스 노트</a></p>https://team-edo.github.io/posts/2026/10/coco-1-3-0-til-primary-checkout/Fri, 30 Oct 2026 09:12:48 +0900https://team-edo.github.io/posts/2026/10/coco-1-3-0-til-primary-checkout/<p>기존 <code>coco-learn</code>은 실행한 worktree 아래에 노트를 저장했습니다. 작업이 끝난 worktree를 정리하면 Git이 추적하지 않는 개인 TIL도 함께 사라질 수 있는 구조였습니다. 1.3.0에서는 작업 폴더의 수명과 학습 기록의 수명을 분리했습니다. 어느 worktree에서 <code>coco-til</code>을 실행하든 기본 체크아웃에서 기록을 다시 찾을 수 있게 했습니다.</p> <h2 id="작업-트리의-상태와-폴더에-남은-파일을-각각-본다">워크트리에 있던 가상 환경이 사라졌습니다</h2> <p>병합을 끝낸 워크트리를 <code>git worktree remove</code>로 제거한 뒤, 그 아래에 만든 Python 가상 환경 <code>.venv</code>가 함께 사라진 것을 확인했습니다. 브랜치 참조는 별도로 남았지만, Git이 무시하던 파일의 내용은 커밋에 없었습니다. 기본 <code>git status</code>가 깨끗해도 삭제할 폴더에 이런 파일은 남아 있을 수 있습니다. 제거 전에는 <code>git status --short --ignored</code>로 확인합니다. 가상 환경처럼 잠금 파일로 다시 만들 수 있는 산출물과 사본이 없는 작업 기록을 여기서 구분할 수 있습니다.</p>https://team-edo.github.io/posts/2026/10/coco-1-2-0-blog-drafts/Thu, 29 Oct 2026 18:37:04 +0900https://team-edo.github.io/posts/2026/10/coco-1-2-0-blog-drafts/<p>개발 중 남긴 개인 TIL에는 실패한 테스트와 선택의 이유가 흩어져 있습니다. 여기서 공개할 근거를 골라 원고를 쓰더라도, 글을 언제 공개할지는 블로그마다 다른 규칙을 따릅니다. 초기 <code>coco-blog</code>는 공개 전환을 Hugo의 <code>draft: false</code>로 고정했습니다. 1.2.0을 준비하면서 원본 노트를 글로 편집하는 과정과 프로젝트마다 달라지는 게시 절차를 분리했습니다. <a href="https://github.com/thisis-joe/skills/blob/v1.2.0/docs/evaluation/coco-blog-1.2.0/report.md">1.2.0 검증 기록</a></p> <h2 id="한-편의-글이-될-근거를-고른다">글감의 근거 고르기</h2> <p>글감은 작성자가 직접 했거나 확인한 작업에서 고릅니다. 예를 들어 한 노트에 재시도 중복을 확인한 테스트가 있고 다른 노트에 수정 후 재현 결과가 있다면, 둘을 엮어 문제를 어떻게 발견하고 검증했는지 설명할 수 있습니다. 초안에는 독자가 재현과 판단을 이해하는 데 필요한 부분을 옮기고, 원본 노트는 그대로 둡니다. 이미 작성자가 고쳐 둔 원고는 그 내용을 읽고 이어 씁니다. 원본을 다시 가져온다는 이유로 기존 문장을 덮어쓰지 않습니다.</p>https://team-edo.github.io/posts/2026/10/coco-1-1-0/Mon, 26 Oct 2026 22:50:31 +0900https://team-edo.github.io/posts/2026/10/coco-1-1-0/<p>CSV 가져오기를 만든다고 해 봅시다. 열 하나가 빈 행을 만나면 그 행만 건너뛸까요, 파일 전체를 거절할까요? 구현 세션이 답을 가정하면 코드는 완성돼도 다음 작업자는 그 동작이 합의된 규칙인지 알아내기 어렵습니다. 1.1.0에서는 코드에서 확인할 수 있는 기존 동작과 사람이 정해야 할 새 동작을 구분했습니다. 이어서 작업하는 사람이 같은 판단을 재현할 수 있도록, 빠진 선택을 확인하는 시점과 합의를 기록할 위치도 정했습니다. <a href="https://github.com/thisis-joe/skills/blob/v1.1.0/docs/coco-1.0.0-to-1.1.0.md">1.1.0 변경 근거</a></p>https://team-edo.github.io/posts/2026/10/coco-1-0-0/Fri, 23 Oct 2026 12:35:00 +0900https://team-edo.github.io/posts/2026/10/coco-1-0-0/<p>다음 작업을 고르려고 <code>coco-start</code>를 호출했을 때 테스트와 병합 미리보기까지 이어졌습니다. 답변까지 147초가 걸렸지만, 사용자가 원한 결과는 다음 작업 경로였습니다. 1.0.0을 준비하며 한 사용자의 Claude Code 호출 11건을 살펴봤습니다. 요청에 필요한 확인과 스킬이 덧붙인 절차를 구분해야, 오래 걸리는 이유를 찾고 필요한 검사도 지킬 수 있었습니다. <a href="https://github.com/thisis-joe/skills/blob/v1.0.0/docs/evaluation/latency/README.md">대기 시간 진단</a></p> <h2 id="지금-받은-요청만-처리하게-만들다">시작 안내에 필요한 작업만</h2> <p><code>coco-start</code>에 구체적인 작업 없이 도움을 요청한 경우에는 경로를 안내하는 데 필요한 사실만 확인하도록 바꿨습니다. 검증이나 배포 점검이 필요한 경우에도 변경이 미치는 영향에 맞춰 절차를 골랐습니다. 예를 들어 마이그레이션은 수정 줄 수가 적어도 실제 실행 검사가 필요한 변경으로 다뤘습니다.</p>https://team-edo.github.io/posts/2026/10/coco-0-2-0/Tue, 20 Oct 2026 10:32:34 +0900https://team-edo.github.io/posts/2026/10/coco-0-2-0/<p>얼쑤에서 AI에 푸시를 맡기려면 먼저 무엇을 확인해야 할지 정해야 했습니다. 개발 브랜치가 바뀌었는지, 기존 테스트 결과를 재사용해도 되는지, Jira에는 언제 무엇을 남겨야 하는지가 모두 판단 대상이었습니다. HTTPS 전환 작업에서는 최신 개발 브랜치가 이미 작업 브랜치에 포함돼 검사 19개의 결과를 재사용했습니다. 서버 점검 작업에서는 새 변경을 통합한 뒤 테스트 13개를 다시 실행했습니다. 두 사례를 놓고 보면 팀별 기록 규칙과 검증을 다시 할 조건을 각각 어디에 둘지가 문제였습니다.</p>https://team-edo.github.io/posts/2026/10/coco-0-1-x/Tue, 20 Oct 2026 09:28:41 +0900https://team-edo.github.io/posts/2026/10/coco-0-1-x/<p>기능을 구현하다 막혔을 때, 먼저 풀어야 할 문제가 하나 더 있었습니다. 지금 필요한 게 요구사항을 좁히는 질문인지, 테스트를 설계하는 절차인지에 따라 여러 스킬 모음에서 비슷한 지침을 찾아 비교해야 했습니다. COCO는 이 탐색을 줄이기 위해 개발자가 하려는 일을 기준으로 스킬을 다시 묶는 작업에서 출발했습니다. 이름은 얼쑤 기술 블로그 첫 글에 등장한 팀원의 반려견 코코에서 따왔습니다. <a href="https://team-edo.github.io/posts/2026/10/hello/">얼쑤 기술 블로그 첫 글</a></p> <h2 id="작성자별-목록을-작업별-목록으로-바꾸다">스킬을 작업별로 묶다</h2> <p>Matt Pocock, Addy Osmani, Lauren Tan의 스킬 모음에서 출발했습니다. 각각을 통째로 설치하는 대신, 개발자가 하려는 일에서 출발하도록 묶었습니다. 요구사항을 좁힐 때는 <code>coco-clarify</code>, 구현할 때는 <code>coco-build</code>, 검증할 때는 <code>coco-verify</code>를 찾는 식입니다. 같은 작업에 도움이 되는 기법을 한곳에서 찾을 수 있게 했습니다.</p>