아프니까 개발자다 아프니까 개발자다

"AI가 앱 개발 진입 장벽을 낮춘다"는 말은 이제 슬로건이 됐다. 그런데 정작 무엇이 낮아진다는 건지 물으면 답이 흐릿하다. 코드가 줄어드는 걸까, 아니면 프레임워크가 똑똑해지는 걸까. 최근 몇 년 사이 서로 다른 진영 — 구글, 애플, 그리고 개방형 표준 — 이 내놓은 설계를 나란히 놓고 보면, 진입 장벽이 낮아지는 지점은 놀랍도록 한 곳으로 수렴한다. 바로 기능을 어떻게 노출하느냐다.핵심 전환은 이것이다. 예전에는 두 시스템을 잇는 일이 곧 명령형 통합이었다. A가 B의 API를 알아야 하고, 엔드포인트·파라미터·순서를 코드에 박아 넣어야 했다. 상대가 바뀌면 통합 코드도 다시 짰다. AI 시대의 설계는 이 방향을 뒤집는다. 개발자는 앱 기능을 타입 있는 계약으로 '선언'만 하고, 시스템이나 에이전..

새로운 기술 영역이 열리면 거의 항상 "표준 전쟁"이 벌어진다. 여러 진영이 각자 규격을 들고나와 서로 자기 것이 사실상의 표준이 되기를 노린다. 웹 브라우저가 그랬고, 메시지 규격이 그랬다. 대개는 한쪽이 이기고 다른 쪽이 사라지거나, 둘 다 살아남아 개발자가 양쪽을 다 지원하느라 고생한다.그런데 에이전트 협업 프로토콜에서는 조금 다른 일이 일어났다. IBM의 ACP(Agent Communication Protocol)와 Google의 A2A(Agent2Agent)가 거의 같은 시기에 같은 문제 — "독립적으로 만들어진 에이전트끼리 어떻게 대화하게 할까" — 를 들고나왔는데, 싸우는 대신 하나로 합쳤다. 이 글은 그 수렴(convergence) 과정 하나만 다룬다. 기술 스펙이 아니라 표준이 만들어지는..

번역 에이전트에게 일을 맡겼다고 하자. 짧은 문장이면 즉시 답이 온다. 그런데 300쪽짜리 문서라면 어떨까? 처리에 몇 분이 걸린다. 이때 평범한 API 호출처럼 "요청 보내고 응답 올 때까지 기다리기"로 짜면 문제가 생긴다. 연결이 몇 분간 묶여 있어야 하고, 그사이 진행 상황은 깜깜하며, 중간에 연결이 끊기면 처음부터 다시다.그래서 A2A(Agent2Agent)·ACP(Agent Communication Protocol) 같은 에이전트 협업 프로토콜은 호출을 단순한 요청/응답이 아니라 생명주기를 가진 실행(Run)으로 다룬다. "이게 왜 그냥 REST 호출이 아니라 별도 프로토콜이어야 하는가"라는 질문의 답이 바로 여기에 있다. 이 글은 그 실행의 세 가지 방식 — 동기·비동기·스트리밍 — 하나만 다..

사람 사이의 협업은 대개 명함 한 장에서 시작한다. 이름, 하는 일, 연락처가 적혀 있어서 "이 사람에게 무엇을 부탁할 수 있는지"를 만나자마자 안다. AI 에이전트에게도 이런 명함이 있다 — Agent Card다. A2A(Agent2Agent)와 ACP(Agent Communication Protocol) 계열 프로토콜이 협업을 시작하는 방식이 이 명함을 주고받는 것이다.그런데 명함 이야기부터 꺼내면 순서가 뒤집힌다. 명함을 받으려면 상대가 어디 있는지부터 알아야 하기 때문이다. 사람도 명함을 받기 전에 "그런 일을 하는 사람이 어디 있는지"를 먼저 수소문한다. 에이전트도 똑같다. 그래서 이 글은 명함이 아니라 발견(discovery)에서 출발한다. 상대를 찾고, 확인하고, 그제야 명함을 펼친다.발견 ..

AI 에이전트를 처음 만들 때 가장 먼저 하는 일은 "도구를 붙이는 것"이다. 날씨를 물어보면 날씨 API를, 문서를 찾으면 검색 엔진을 연결한다. 나도 그렇게 시작했고, 한동안은 그걸로 충분해 보였다. 그런데 어느 순간 멈칫하는 지점이 왔다. "번역은 번역 잘하는 에이전트한테 맡기고 싶은데, 이건 도구를 붙이는 거랑 뭐가 다르지?"이 멈칫이 사실 요즘 에이전트 생태계 전체가 두 갈래로 갈라진 이유다. 에이전트가 바깥세상과 연결되는 방식에는 서로 다른 두 개의 축이 있고, 각 축을 담당하는 프로토콜이 따로 있다. 이 글은 그 두 축을 구분하는 것 하나만 다룬다. 이것만 잡으면 MCP·A2A·ACP 같은 약어들이 왜 동시에 존재하는지가 한 번에 풀린다.먼저 익숙한 축 — 에이전트가 도구를 붙이는 일에이전트..