이 글은 내가 만들고 있는 TaoIDE를 소개하는 글이다. 그 전에 요즘 개발자들이 어떤 IDE를 많이 쓰는지 확인하고, AI와 일하는 방식에 맞춰 주목받는 IDE와 도구들을 살펴본 뒤 TaoIDE를 소개하려 한다. IDE는 만들려는 제품과 사용하는 언어에 맞춰 선택한다. Android 앱인지, iOS 앱인지, 웹 서비스인지에 따라 필요한 개발 환경이 다르
은행 사이트에 들어갔다가 프로그램 설치 화면부터 본 적이 있다. 내 정보를 보려면 내 정보를 보호한다는 프로그램을 먼저 설치해야 한다. 휴대전화에서는 금융 앱이 내가 설치한 다른 앱 목록을 확인한다. 서비스 하나를 이용하려는데 요구가 하나씩 늘어난다. 보안 프로그램을 설치하고 여러 인증 절차를 거치는 동안에도 개인정보 유출 사고는 반복됐다. 이용자는 대개
왜 공통화에 집중하는지는 0부에, Tao Agent OS를 처음 소개한 내용은 Tao Agent OS: AI 에이전트의 작업 습관을 프로젝트 밖에 저장하기에 적었다. AI 코딩 에이전트는 세션을 열 때마다 빈 컨텍스트에서 시작한다. 요즘 에이전트는 메모리나 지난 세션 요약을 들고 오기도 한다. Claude Code에는 auto memory가, Codex에는
Tao Agent OS 이야기는 여러 번 썼다. 처음 소개한 글부터 스킬 문서, 문서 라우팅, 게이트, 워크트리, 회고까지 한 편씩 따로 다뤘다. 이 글은 그 뒤를 잇는 시리즈의 입구다. 기능을 하나 더 소개하기 전에, 왜 계속 공통화 쪽으로 만들고 있는지부터 적어 둔다. 원한 것 AI 코딩 에이전트는 이제 하나가 아니다. Claude Code, Codex
이전에 소개한 Router는 Activity 간 이동과 Compose Navigation 안의 이동을 함께 처리했다. 화면에서는 Navigator로 이동을 요청하고, 요청을 받은 쪽에서 Activity를 열거나 Navigation의 화면을 바꾼다. Navigation을 쓴다고 앱의 Activity가 하나일 필요는 없다. Activity가 있는 feature
지난 글에서는 Activity가 필요할 때 impl을 추가하고, Activity와 Compose host가 같은 화면을 쓸 때 ui를 분리한다고 정리했다. 여기서 ui를 stateless composable만 모아 둔 모듈로 생각하면 문제가 생긴다. ViewModel과 navigation 연결을 impl에 남기면 Compose host가 화면을 열 때 결국
지난 글에서는 AI와 함께 개발할수록 코드의 위치와 의존 방향을 분명히 정해야 한다고 썼다. 이번에는 그 기준을 Activity가 필요한 feature에 적용한다. 결론부터 말하면 Activity가 필요할 때 impl을 추가한다. impl은 feature 화면 전체를 넣는 기본 모듈이 아니다. Android가 feature에 들어오는 방법을 구현하는 모듈이
지난 글에서는 한 작업에서 발견한 빈틈을 다음 에이전트가 재사용할 수 있는 스킬과 검증 규칙으로 바꾸는 과정을 정리했다. 다음 개발 작업에서 같은 실수를 반복하지 않게 만드는 방법이었다. 다만 거기서 다룬 것은 코드 밖의 규칙이었다. 문서와 스킬, 검증 장치를 통해 판단 기준을 코드 외부에 심어두는 방식이었다. 이번에는 그보다 앞선 질문을 생각해 보려 한다
지난 글에서는 여러 에이전트가 동시에 작업할 때 격리가 깨지는 문제를 방지하고, 원본 체크아웃을 더럽히지 않은 채 작업을 안전하게 중단하는 방법을 정리했다. 워크트리를 생성하지 못했거나 작업 위치가 올바르지 않으면 그 상태로 실패 처리하고, 미완성 결과물은 지우지 않은 채 보존하는 방식이다. 하지만 작업을 멈췄다고 해서 같은 실수가 저절로 사라지는 것은 아
에이전트를 한 번에 여러 개 돌리는 방식이 점점 늘어난다. Orca는 Codex, Claude Code 같은 CLI 에이전트를 각자의 worktree에서 나란히 실행하고 작업을 조율한다. 한 작업을 여러 조각으로 쪼개 동시에 맡기면 전체 시간이 줄어든다. 그런데 병렬 실행에서도 격리한 워크트리가 아니라 공유 체크아웃에 결과가 새어 들어갈 수 있다. 워커마다
문서 연결을 다룬 글에서는 AI가 바뀌어도 같은 문서와 기준에 따라 일하게 만드는 방법을 정리했다. 요청에 맞는 문서를 찾고, 반드시 읽어야 할 문서와 필요할 때만 참고할 문서를 구분하며, 코드와 문서의 연관 관계를 추적하는 구조였다. 당시에도 Tao Agent OS를 '에이전트 OS'라 불렀지만, 솔직히 '에이전트 실행 환경'에 가깝다고 썼다. 문서를 연
요즘은 새로운 에이전트가 쉴 새 없이 나온다. Hermes Agent는 기억과 스킬을 쌓으며 오래 사용하는 에이전트를 지향한다. Orca는 Codex, Claude Code, OpenCode, Pi 같은 여러 CLI 에이전트를 나란히 실행하고 작업을 조율한다. Codex나 Claude Code는 저장소를 직접 읽고 파일을 수정하는 실행 도구로 자리 잡았다.
며칠 전에 AI는 스킬 문서를 알아서 읽지 않는다는 글을 썼다. 이전 글에서는 스킬 문서를 만들어두는 것만으로는 부족하다고 정리했다. 에이전트가 문서의 존재를 알고, 현재 작업에서 읽어야 할 문서를 찾을 수 있어야 한다는 내용이었다. 프로젝트 안의 .agents/skills, 루트 AGENTS.md, 공유 플레이북, 검색 스크립트를 연결하는 방법도 함께 적
AI는 이미 꽤 그럴듯한 코드를 만든다. 특히 웹 코드는 프롬프트만 넣어도 화면과 상태, 간단한 데이터 흐름까지 빠르게 만든다. 지난 1년 동안 AI에게 결과물을 요구하면 웹 코드가 가장 자주 나왔고, 그 구조도 계속 바뀌어왔다. 웹이 학습하기 쉬운 영역이라서일 수도 있고, 공개된 예제와 시행착오가 오래 쌓인 영역이라서일 수도 있다. 그러면 모바일 앱 개발
AI 코딩 에이전트를 계속 쓰다 보면 프롬프트보다 더 자주 문제가 되는 지점이 있다. 작업 습관이다. 처음에는 모델이 더 똑똑해지면 해결될 문제처럼 보인다. 그런데 실제 프로젝트에 붙여서 여러 번 돌려보면 비슷한 문제가 계속 나온다. 프로젝트 지침을 읽었다고 하지만 실제로는 열어보지 않는다. 요구사항이 모호한데 구현부터 시작한다. 코드 위치를 정하지 않고
KeyFlow를 처음 만들 때 나는 안티그래비티와 제미나이를 중심으로 작업했다. 그때의 질문은 단순했다. 정말 AI와 함께 서비스를 어디까지 만들 수 있을까. 기획서가 완벽하지 않아도, 디자인 시스템이 처음부터 정리되어 있지 않아도, 일단 대화를 이어가며 제품을 만들 수 있을까. 그래서 Antigravity의 제미나이를 붙잡고 밀어붙였다. KeyFlow 탄
[!AI] 이 글은 제미나이가 작성한 글 마우스 움직임이나 스크롤에 맞춰 UI가 살아있는 액체처럼 반응하는 인터랙션을 자주 볼 수 있다. 단순한 글래스모피즘(Glassmorphism)을 넘어, 실제 유리가 빛을 굴절시키는 듯한 쫀득한 감성에 독특한 스크롤 모핑 기능을 더한 바텀 네비게이션 바를 구현해 보았다. 흔한 디자인이 아니라 오픈소스 레벨에서 색다른
AI가 등장한 뒤로, 누구나 마음만 먹으면 무언가를 만들 수 있는 시대가 됐다.\ 그것이 단 한 장짜리 페이지이든, 간단한 앱이든, 이제는 프롬프트 몇 줄만으로도 시작할 수 있다. 나 역시 KeyFlow를 만들면서 그 변화를 여러 번 체감했다.\ AI는 살을 붙이는 데 굉장히 능하다.\ 요구하면 요구한 방향대로 결과물을 빠르게 만들어낸다.\ 디자인이 마음에
키플로우를 만들면서 “왜 굳이 제미나이였어?”라는 질문을 참 많이 들었다. 사실 이 질문은 나도 여러 번 스스로에게 던졌던 것 같다. 제미나이는 쓰다 보면 정말 인상적일 때가 있다. 폭발적인 힘으로 생각의 폭을 먼저 열어주기도하고, 반대로 의도와 전혀 어긋난 답을 내놓아 답답하게 만들 때도 있다. 그럴 때면 화가 나기도 하지만, 돌이켜보면 나는 계속 제미나
서비스를 운영하다 보면 누구나 한 번쯤 고민에 빠지는 지점이 있죠. "그래서 이번 배포, 버전 번호 뭐로 올리지?"라는 질문입니다. 단순한 숫자 같지만, 그 안에는 개발팀의 의도, 작업의 규모, 그리고 사용자와의 커뮤니케이션 방식이 모두 담겨 있거든요. 키플로우(Keyflow)는 실용성과 명확한 커뮤니케이션을 위해 '날짜 기반'의 버저닝을 채택하고 있습니다