예전 UX 기획 업무는 대체로 다음 순서로 진행됐다.기획자는 문서를 만들고, 디자이너는 화면을 다듬고, 개발자는 이를 실제 제품으로 구현했다.단계가 명확한 대신 문제가 하나 있었다.기획 단계에서 본 화면과 실제 동작하는 제품 사이에 큰 간격이 존재했다.예를 들어 기획서

GPT-5.6이 Codex에 들어오면서 모델을 선택하는 방식이 이전보다 복잡해졌다.이제 단순히로 끝나지 않는다.Codex에서는 다음을 함께 결정해야 한다.2026년 8월 기준 Codex에서 사용할 수 있는 GPT-5.6 제품군은 다음과 같다.Codex는 Main Age

최근 Claude Code 커뮤니티에서 비슷한 시기에 세 가지 글이 주목받았다.첫 번째는 웹페이지를 ChatGPT나 Perplexity 같은 AI 답변 서비스가 인용하기 좋은 형태로 점검하는 Claude Code Skill이다.두 번째는 상당히 과감하다.프로젝트의 CL

AI 코딩 에이전트를 개인이 사용할 때는 설정이 단순하다.사용할 모델을 고르고, 필요한 MCP Server나 Plugin을 연결한 뒤 작업하면 된다.하지만 팀 전체가 에이전트를 사용하기 시작하면 문제가 달라진다.각 개발자가 설정을 따로 관리하면 조직의 AI 개발 환경은

AI 코딩 Agent를 사용할 때 대부분의 작업은 짧다.또는정도로 끝난다.이런 작업은 Agent가 한 번 실행되는 동안 필요한 Context를 읽고 바로 끝내면 된다.하지만 최근 Agent 모델은 그보다 훨씬 긴 작업을 겨냥하고 있다.이런 작업은 단순히 Prompt를

Codex로 규격에 맞는 EPUB 만들기: 설치부터 EPUBCheck·공모전까지 EPUB 제작은 “문서를 변환해 .epub 확장자를 붙이는 일”이 아니다. 원고, 이미지, 목차, 메타데이터, 읽기 순서, 압축 구조가 서로 맞아야 하는 작은 웹사이트 패키징 작업에 가깝

AI 코딩 Agent를 처음 사용하면 보통 하나의 Agent에게 모든 작업을 맡긴다.작은 기능이나 버그 수정이라면 이 구조로 충분하다.하지만 작업이 커지면 문제가 생긴다.예를 들어 다음 작업을 생각해보자.Agent 하나가 이것을 순서대로 처리하면 꽤 오래 걸린다.그런데

AI Agent를 몇 턴 사용하다 보면 한 가지 문제가 생긴다.처음에는 Agent가 작업을 잘 이해하고 있다.Agent가 Repository를 조사한다.몇 차례 대화하면서 원인을 좁힌다.그런데 대화가 길어지면 이런 현상이 생긴다.그래서 많은 Agent 시스템이 모든 것

AI Agent를 만들다 보면 생각보다 많은 비용이 Tool 호출 사이에서 발생한다.예를 들어 Repository에서 여러 파일을 조사하고 테스트 결과를 모아야 하는 Agent가 있다고 하자.기존 방식은 대략 이렇다.Tool을 한 번 사용할 때마다 결과가 다시 모델 C

GPT-5.6과 Claude 5 세대가 나오면서 모델 선택이 오히려 더 복잡해졌다.예전에는 대략 이런 식이었다.지금은 그렇지 않다.OpenAI에는 GPT-5.6 Sol, Terra, Luna가 있고 Claude에는 Fable 5, Opus 5, Sonnet 5, Hai

Claude Code를 처음 쓰면 대부분 이런 식으로 시작한다.조금 사용하다 보면 같은 설명을 계속 반복하게 된다.그래서 자연스럽게 CLAUDE.md를 만들게 된다.그다음에는 더 많은 규칙을 넣는다.처음에는 잘 관리하는 것처럼 보인다.하지만 파일이 점점 길어진다.202

AI 코딩 에이전트를 한두 번 사용하는 것과 여러 에이전트를 팀처럼 운영하는 것은 전혀 다른 문제다.Codex나 Claude Code를 직접 실행할 때는 보통 이런 식이다.에이전트가 하나뿐이라면 이것으로 충분하다.하지만 여러 에이전트에게 일을 나누기 시작하면 관리해야

AI 에이전트를 하나만 사용할 때는 구조가 비교적 단순하다.Agent가 GitHub를 읽어야 하면 GitHub Tool을 연결한다.DB를 조회해야 하면 DB Tool을 연결한다.외부 API를 호출해야 하면 해당 Tool을 연결한다.이런 구조에서는 MCP가 잘 맞는다.그

AI 코딩 에이전트를 팀에서 오래 사용하다 보면 비슷한 지시를 계속 반복하게 된다.처음에는 이런 내용을 작업 요청마다 붙인다.조금 지나면 AGENTS.md, CLAUDE.md, 프로젝트 지침 파일에 공통 규칙을 넣는다.그런데 프로젝트가 커지면 전역 규칙만으로는 부족해진

AI 코딩 에이전트를 처음 만들 때는 보통 역할부터 나눈다.구조만 보면 그럴듯하다.하지만 실제로 운영해보면 이상한 문제가 생긴다.Planner는 분명 수정 파일을 세 개로 제한했다고 말한다.Implementer는 “관련 파일도 함께 수정했다”고 보고한다.Reviewer

AI 코딩 도구를 iOS 개발에 쓰다 보면 한계가 분명하게 드러나는 순간이 있다.코드는 빠르게 작성해주지만, 실제 화면이 어떻게 보이는지는 결국 개발자가 Xcode에서 직접 확인해야 한다.Figma를 기준으로 SwiftUI 화면을 구현한다고 해보자.기존 작업 흐름은 보

요즘 AI 개발 흐름을 보면 확실히 방향이 바뀌고 있다.예전에는 AI에게 물어봤다.이때 AI는 대답하는 도구에 가까웠다.하지만 지금은 다르다.AI가 직접 파일을 읽고, 코드를 고치고, 터미널 명령을 실행하고, 외부 도구와 연결된다.이제 AI는 단순히 “말하는 모델”이

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

2025년이 “AI 에이전트를 만드는 시대”였다면, 2026년은 본격적으로 AI 에이전트를 운영하는 시대에 가깝다.최근 해외 AI 개발 흐름을 보면 모델 자체의 성능만큼이나 반복해서 등장하는 주제가 있다.결국 핵심은 모델이 아니다.Agent Runtime이다.에이전트가

AI 코딩 에이전트를 며칠 이상 써보면 이상한 순간이 온다.어제 분명히 같은 문제를 고쳤다.같은 파일을 읽었다.같은 테스트가 실패했다.왜 그 접근을 버렸는지도 정리했다.그런데 새 세션을 열면 다시 처음부터 시작한다.개발자 입장에서는 답답하다.이미 확인한 내용인데 또 읽