K2 Lee

AI 에이전트끼리 자연어로 대화시키면 망한다: Typed Agent Contract 설계법 AI 코딩 에이전트를 처음 만들 때는 보통 역할부터 나눈다. 구조만 보면 그럴듯하다. 하지만 실제로 운영해보면 이상한 문제가 생긴다. Planner는 분명 수정 파일을 세 개로 제한했다고 말한다.\ Implementer는 “관련 파일도 함께 수정했다”고 보고한다.\

Xcode MCP와 RenderPreview: AI가 SwiftUI 화면을 직접 렌더링하고 검증하는 방법 AI 코딩 도구를 iOS 개발에 쓰다 보면 한계가 분명하게 드러나는 순간이 있다. 코드는 빠르게 작성해주지만, 실제 화면이 어떻게 보이는지는 결국 개발자가 Xcode에서 직접 확인해야 한다. Figma를 기준으로 SwiftUI 화면을 구현한다고 해보자.

요즘 AI 코딩 에이전트로 UI 코드를 만들 때 가장 많이 하는 실수가 있다. 디자인 이미지를 하나 던지고 이렇게 말하는 것이다. 또는 이렇게 시킨다. 처음 결과는 꽤 그럴듯하다. 카드도 있고, 버튼도 있고, 텍스트도 얼추 맞는다. 그런데 실제 디자이너 리뷰에 들어가면 바로 문제가 나온다. AI가 UI를 못 짜서가 아니다. 입력이 부족했기 때문이다. UI

AI 에이전트가 어제 한 일을 잊지 않게 만드는 법: Durable Memory와 Run Ledger 설계 AI 코딩 에이전트를 며칠 이상 써보면 이상한 순간이 온다. 어제 분명히 같은 문제를 고쳤다.\ 같은 파일을 읽었다.\ 같은 테스트가 실패했다.\ 왜 그 접근을 버렸는지도 정리했다. 그런데 새 세션을 열면 다시 처음부터 시작한다. 개발자 입장에서는 답

AI가 실패하면 다른 AI가 이어받는다: Consensus·Self-Healing·Eval Gate 운영법 1편에서는 AI 코딩 에이전트의 역할을 나눴다. 2편에서는 Claude, Codex, Cursor를 중앙 Orchestrator로 연결했다. 이제 마지막 문제가 남는다. 정상적으로 흘러갈 때는 어렵지 않다. Planner가 계획을 만들고, Implem

AI가 AI를 리뷰하게 만드는 법: Codex·Claude·Cursor 오케스트라 연결하기 1편에서는 AI 코딩 에이전트를 하나의 만능 작업자로 쓰지 않고 역할별로 나눴다. Claude Code에는 계획과 독립 리뷰를 맡기고, Codex에는 구현과 제한된 수정을 맡겼다. Cursor는 개발자가 최종 diff와 보고서를 확인하는 Control Room으로 두

혼자 일하는 AI는 끝났다: Codex·Claude·Cursor로 AI 개발팀 설계하기 최근 AI 코딩 도구를 쓰는 방식이 꽤 달라졌다. 예전에는 개발자가 코드를 작성하다가 막히는 부분을 AI에게 물었다. AI는 옆자리 조수에 가까웠다. 하지만 지금의 코딩 에이전트는 파일을 직접 찾고, 코드를 수정하고, 터미널에서 테스트를 실행한다. 작업 범위가 명확하면

최근 AI 모델 새 버전들이 계속 나오고 있다. 이제는 발표 문구도 거의 비슷하다. 처음에는 모델 이름만 보게 된다. 이번엔 누가 더 똑똑한가.\ 코딩 벤치마크가 몇 점인가.\ 컨텍스트 창이 몇 토큰인가.\ 이전 모델보다 얼마나 빠른가. 그런데 실제 개발자가 봐야 할 핵심은 조금 다르다. 요즘 AI 새 버전들이 공통으로 향하는 방향은 단순히 “채팅 답변을

최근 iOS 개발 흐름에서 가장 중요한 변화 중 하나는 AI 기능이 더 이상 서버 API 호출만의 문제가 아니라는 점이다. 예전에는 앱에 AI 기능을 넣는다고 하면 보통 이런 구조를 먼저 떠올렸다. 고객센터 답변 추천, 회의록 요약, 쇼핑 추천, 여행 플래너, 메뉴판 설명, 사내 문서 검색 같은 기능은 대부분 서버에서 모델을 호출하고, 앱은 결과만 받아서

OpenAI가 GPT-5.6 시리즈를 공개했다. 이번 발표에서 눈에 띄는 이름은 세 가지다. Sol은 플래그십 모델, Terra는 일상적인 개발·업무에 맞춘 균형형 모델, Luna는 빠르고 비용 효율적인 모델로 소개됐다. 하지만 개발자 입장에서 이번 발표를 단순히 “새 모델이 더 좋아졌다” 정도로만 보면 조금 아쉽다. 이번 발표에서 더 중요하게 봐야 할 부