ekyu 님의 블로그

Jev가 뭐냐판단만 빠르게 하는 AI가 나온 이유최근 AI 모델은 점점 더 많은 일을 할 수 있게 됐습니다.코드를 작성하고, 웹을 검색하고, Tool을 호출하고, 여러 단계를 거쳐 문제를 해결합니다.그런데 실제 서비스를 만들다 보면 모든 문제에 이런 큰 모델이 필요한 것은 아닙니다.예를 들어 이런 판단이 있습니다.이 문의는 결제 문제인가?이 요청을 검색으로 보낼까,DB 조회로 보낼까?이 메시지는 위험한가?이 결과를 자동 승인해도 되는가?이 Agent의 응답을 다시 검토해야 하는가?각각은 AI가 필요한 문제일 수 있습니다.하지만 GPT나 Claude 같은 Frontier LLM에게 매번 긴 답변을 생성하게 하는 것은 꽤 비싼 방법이기도 합니다.TypeSafe AI가 2026년 9월 14일 공개한 Jev는 ..

멀티에이전트는 이렇게 시작하면 된다Codex와 Claude Code로 만드는 가장 단순한 구조멀티에이전트를 처음 적용하려고 하면 구조부터 크게 그리기 쉽습니다.Main Agent ├─ Coding Agent ├─ Test Agent ├─ Review Agent ├─ Security Agent └─ Research Agent여기에 MCP Server를 붙이고 Skill을 만들고 Agent마다 Model과 권한까지 따로 설정합니다.그런데 실제 Codex와 Claude Code에서는 처음부터 이렇게 만들 필요가 없습니다.두 도구 모두 기본 Agent 자체가 이미Repository 탐색파일 수정Shell 실행TestGitTool 호출을 처리할 수 있습니다.멀티에이전트의 시작점은 Agent를 여러 개 만드는 것이..

MCP 다음은 A2A다Agent끼리 통신하는 아키텍처는 언제 필요한가앞선 글에서는 Multi-Agent 구조를 만들 때 모든 전문 기능을 Agent로 분리할 필요는 없다는 이야기를 했습니다.정해진 절차+명확한 Tool ↓Skill + MCP반대로 이런 작업은 조금 다릅니다.탐색+가설+반복 판단+독립적인 Context ↓Agent그렇다면 실제로 Agent를 분리해야 할 때는 어떻게 연결해야 할까요?같은 애플리케이션 안의 객체라면 직접 호출하면 됩니다.하지만 Agent가다른 서버에서 실행되고다른 팀이 관리하고다른 언어와 Framework로 만들어졌으며서로 다른 모델과 Context를 사용하고몇 분 또는 몇 시간 동안 독립적으로 작업한다면단순한 Function Call로 보기 어려워집..

멀티에이전트가 항상 답은 아니다Agent를 Skill로 바꾸는 아키텍처AI Agent 시스템을 만들기 시작하면 구조가 빠르게 커집니다.처음에는 하나의 Agent가 여러 Tool을 사용합니다.User ↓Main Agent ↓Tools기능이 늘어나면 역할을 분리하기 시작합니다.Main Agent │ ├─ Release Agent ├─ Refactoring Agent ├─ Migration Agent └─ Research Agent겉으로 보면 깔끔합니다.각 Agent가 자기 역할만 담당하니 Microservice처럼 책임도 명확해 보입니다.그런데 여기서 한 번 생각해볼 필요가 있습니다.저 기능마다 정말 별도의 LLM Agent가 필요한가?Microsoft가 9월 16일 공개한 Agent Fr..

Swift 6.4, 빌드와 디버깅이 모듈 중심으로 바뀐다LLDB부터 dSYM, Bridging Header, Swift Build까지 한 번에 정리Swift 6.4에서 꽤 큰 변화가 하나 들어옵니다.새로운 문법이나 SwiftUI API가 아니라 Compiler, Build System, LLDB가 Swift Module을 다루는 방식입니다.Swift.org가 9월 11일 공개한 내용을 보면 Swift 6.3부터 진행되던 Explicit Module Tracking이 Swift 6.4에서 Debugging까지 본격적으로 연결됩니다.결과적으로 대부분의 Xcode와 SwiftPM 프로젝트에서는 별다른 코드 변경 없이LLDB의 Module Lookup 안정성 개선일부 Debugging 지연 감소Bridging ..

기술부채도 이제 AI에게 티켓처럼 던진다GitHub Agentic Autofix가 바꾸는 기술부채 처리 방식프로젝트를 오래 운영하다 보면 이상하게 없어지지 않는 목록이 하나 있습니다.Code Quality backlog입니다.당장 장애를 만드는 버그는 아니지만 언젠가는 고쳐야 하는 코드들입니다.중복 코드불필요한 조건문사용되지 않는 표현식복잡도가 높은 함수유지보수성이 떨어지는 코드신뢰성 문제CodeQL이나 각종 정적 분석 도구가 계속 문제를 찾아내지만 실제 프로젝트에서는 이런 finding이 빠르게 쌓입니다.이유는 간단합니다.급하지 않기 때문입니다.신규 기능 ↓버그 수정 ↓긴급 배포 ↓성능 문제 ↓기술부채항상 기술부채가 마지막으로 밀립니다.그런데 GitHub가 9월 9일 공개한 Agentic..

Kotlin이 Swift 쪽으로 한 발 더 들어왔다Kotlin 2.4.20의 Swift Export, 그리고 iPhone Duo 시대의 KMPKotlin 2.4.20이 9월 7일 정식 출시됐습니다.전체 변경사항을 보면 Standard Library, Kotlin/Wasm, Kotlin/JS, Gradle 등 여러 영역이 업데이트됐지만 iOS 개발자라면 Kotlin/Native 쪽 변화를 눈여겨볼 만합니다.이번 버전에서 특히 볼 부분은 세 가지입니다.Swift Export 기능 확대SwiftPM 연동을 위한 Package.swift 생성 지원Kotlin/Native Incremental Compilation 개선각각만 보면 작은 개선처럼 보일 수도 있습니다.하지만 방향은 꽤 명확합니다.기존 KMP의 iOS..

iOS 27.1 커스텀 탭바를 당장 버릴 필요는 없다iOS 27.1과 iPhone Duo 시대, 오래된 Navigation을 어떻게 가져갈 것인가iPhone Duo가 공개되면서 오래 운영한 iOS 프로젝트라면 한 번쯤 확인해야 할 코드가 생겼습니다.대표적인 것이 이런 UI입니다.Custom Tab BarCustom Navigation BarCustom ToolbarUIScreen.main 기반 레이아웃Orientation 기반 분기고정 Width / HeightSafe Area 직접 계산최근 SwiftUI 프로젝트라면 TabView, NavigationStack, NavigationSplitView를 사용하는 경우가 많아 상대적으로 대응이 쉽습니다.반면 몇 년 이상 운영한 UIKit 프로젝트나 디자인 요..