본문 바로가기

전체 글

 (78)
진짜 병목은 "이해" Understanding is the new bottleneck — Geoffrey Litt, Notion - YouTube 2026년 7월 AI Engineer 콘퍼런스에서 Geoffrey Litt가 발표한 Understanding is the new bottleneck 의 내용과 관련 조사를 바탕으로 정리한 글입니다.발표는 AI가 코드를 빠르게 작성하는 시대에도 인간이 왜 코드를 이해해야 하는지, 그리고 그 이해를 어떻게 따라갈 수 있는지를 다룹니다. -------------------------------------------------------------------------------------- 검증이 아니라, 참여하기 위해 이해한다인간이 코드를 이해해야 하는 이유로 가장 먼저 떠올리는 것..
Spring AI로 Pi 스타일 에이전트 하네스 만들기 (15) - MCP server endpoint 추가하기 이번 글의 목적M14에서는 외부 MCP server의 tool을 에이전트 안으로 가져왔습니다.Spring AI가 발견한 callback은 모델에 바로 넘기지 않았습니다.McpAgentTool로 감싼 뒤 기존 ToolRegistry, ToolExecutionService, ToolPolicy 경계 안에 넣었습니다. M14: 외부 MCP tool을 가져온다.M15: built-in tool을 MCP server로 내보낸다. M15에서는 방향이 반대입니다.프로젝트가 이미 제공하는 ls, read, find, grep, write, edit, bash를 외부 MCP client에 공개합니다.그렇다고 tool을 새로 구현하거나 기존 runtime을 MCP 중심으로 다시 짜지는 않습니다.이번 글에서는 네 가지를 확..
Spring AI로 Pi 스타일 에이전트 하네스 만들기 (14) - MCP tool 호출하기 이번 글의 목적M13에서는 SSE와 JSONL session history를 한 흐름으로 정리했습니다.SSE는 지금 실행 중인 agent를 관찰, JSONL은 나중에 같은 실행을 다시 확인하는 기록입니다.글의 마지막에는 다음 단계의 방향도 남겼습니다.MCP를 붙이더라도 기존 ToolRegistry, ToolPolicy, SSE, JSONL session history를 우회하지 않는다. M14는 위 방향을 구현하는 단계입니다.MCP server가 제공하는 tool을 Spring AI MCP client로 발견하되, 발견한 callback을 ChatClient에 곧바로 넘기지 않습니다. 먼저 프로젝트의 AgentTool로 감싼 뒤 기존 실행 경계 안으로 넣습니다.이번 글에서 답할 질문은 네 가지입니다.Sp..
Spring AI로 Pi 스타일 에이전트 하네스 만들기 (13) - SSE는 실시간 관찰, JSONL은 기록 이번 글의 목적M12에서는 tool safety를 다시 점검했습니다.write, edit, bash가 위험한 요청을 막는지 확인했고, 거부된 tool call이 SSE와 JSONL history에 남는지도 테스트로 고정했습니다.이번 M13에서는 그 기록 자체를 더 잘 다룹니다.코딩 에이전트는 단순히 답변만 만들지 않습니다.사용자의 메시지를 받고, 모델을 호출하고, 필요하면 tool을 실행하고, 그 결과를 다시 모델에게 넘깁니다.이 과정이 보이지 않으면 디버깅하기 어렵습니다.방금 agent가 무슨 일을 했는가?실시간으로는 무엇이 흘렀는가?나중에 다시 열어볼 수 있는 기록은 어디에 있는가?README만 보고 이 흐름을 따라갈 수 있는가? M13은 이 질문에 답하기 위해 session history 조회 흐름..
Spring AI로 Pi 스타일 에이전트 하네스 만들기 (12) - Tool 사용을 더 안전하게 이번 글의 목적이제부터는 무작정 기능을 늘리지 않습니다.M12의 목표는 이미 만든 tool safety를 다시 점검하고, 놓치기 쉬운 실패 사례를 테스트로 고정하는 일입니다. write/edit은 nested secret path도 막는가?bash는 PowerShell alias까지 위험 명령으로 보는가?policy deny reason은 SSE와 JSONL history에 남는가?기존 output limit과 timeout 테스트는 계속 살아 있는가? 기능은 나중에 다시 만들 수 있지만, safety policy가 흔들리면 프로젝트 전체를 믿기 어렵습니다.왜 hardening이 필요한가M10에서 bash를 붙였고, M11에서 README에 safety model을 정리했습니다.그 시점에도 주요 정책..
개발 관련 스킬을 쓰면 좋은 코드가 나올까? (karpathy-guidelines, yagni, solid, yagni+solid, caveman, ponytail, lazycodex, oh-my-codex) 모두 codex - gpt 5.5 xhigh 로 테스트 했고,실제 사용한 프롬프트와 완성된 코드는 너무 길어져서 추가하진 않았습니다. ---------------------------------------- 실험 목적이번 실험은 같은 구현 과제를 여러 AI 코딩 에이전트 세팅에 맡겼을 때 결과가 어떻게 달라지는지 보기 위한 비교 실험이다. 핵심 질문은 세 가지였다. 질문확인하려는 것토큰을 많이 쓰면 코드가 좋아지는가token 사용량과 실제 품질의 관계skill 또는 원칙 프롬프트가 결과를 바꾸는가Codex 기본값, skill, SOLID/YAGNI 조합의 차이workflow wrapper는 일반 Codex와 다른 흐름을 만드는가wrapper-light와 workflow-full의 비용, 구조, 산출물 차..
Spring AI로 Pi 스타일 에이전트 하네스 만들기 (11) - README.md 로 흐름 정리 이번 글의 목적M11에서는 새 기능을 만들지 않습니다.대신 지금까지 만든 것을 README와 데모 흐름으로 정리합니다.M0부터 M10까지의 작업은 작은 코딩 에이전트 하네스를 만드는 과정이었습니다.프로젝트 골격을 만들고, Spring AI ChatClient를 붙이고, 메시지와 이벤트를 모델링했습니다.그 뒤에는 JSONL session store, workspace guard, read-only tools, tool policy, Spring AI adapter, AgentRuntime, SSE, write/edit, bash까지 차례대로 올렸습니다.여기까지 오면 기능은 어느 정도 보입니다.사용자가 README만 보고 다음 질문에 답할 수 있어야 합니다.무엇을 만들었는가?왜 Spring AI로 만들었는가..
Spring AI로 Pi 스타일 에이전트 하네스 만들기 (10) - 위험한 bash 다루기 이번 글의 목적이번 단계에서는 가장 위험한 tool인 bash를 다룹니다.AI가 명령을 실행하더라도 사람이 이해할 수 있는 정책 안에서만 실행되게 한다. M10에서 추가한 것은 bash라는 새 기능 하나가 아닙니다.allowBash, BashCommandPolicy, timeout, output limit, workspace 고정 실행을 한 묶음으로 붙인 작은 수직 슬라이스입니다.bash가 왜 위험한가read는 파일을 읽습니다.write와 edit은 파일을 바꿉니다.하지만 bash는 거의 모든 것을 할 수 있습니다.파일 삭제네트워크 요청프로세스 실행환경 변수 출력패키지 설치권한 변경 그래서 처음부터 기본 활성화하면 안 됩니다.M10에서는 read-only, write/edit을 먼저 붙인 뒤 마지막에 ..

티스토리툴바