AI보조개발
-
프런트엔드 AX 설계기 3편 — `done` 경계를 측정으로 설계한 이야기AI 엔지니어링 2026. 7. 1. 19:51
1. 도입부 (Why This Matters)done은 안전해 보이는 단어다. 그런데 AI 보조 개발에서 done은 두 번 위험하다 — 작업이 들어갈 때, 그리고 나온 뒤.나온 뒤부터 보자. 대부분의 PM 도구는 작업 상태를 단방향으로 본다. specification → planned → in-progress → done. 한번 done이면 끝. "완료된 작업은 완료된 채로 남는다"는 가정 위에 서 있다. 사람만 일하던 시절엔 버텼다. 그러나 AI 에이전트는 task 7을 구현하다 이미 done인 task 2의 설계 결함을 드러내고, 당신은 의도를 실시간으로 바꾼다. 단방향 모델에는 무효화된 done을 표현할 자리가 없다.들어갈 때도 함정이 있다. AI가 짠 코드를 사람이 다 읽을 수 없으니, AI가 A..
-
프런트엔드 AX 설계기 2편 — 에이전트를 '자율 실행'에서 '명시적 동의'로AI 엔지니어링 2026. 6. 26. 19:16
1. 도입부 (Why This Matters)에이전트 도구를 처음 세팅하면 거의 모두 "자동"에 끌린다. 리뷰 에이전트, 문서 에이전트, 비평 에이전트를 만들어 두면 알아서 끼어들어 일을 거든다 — 적어도 그럴 거라 기대한다. 나도 그렇게 시작했다. 역할별 커스텀 에이전트 6개를 만들고, 요청이 들어오면 시스템이 알아서 적절한 에이전트를 골라 활성화하도록 했다.그리고 몇 주 뒤, 그 자동 활성화를 전부 껐다. 모든 에이전트를 명시적으로 호출할 때만 실행되는 '기본 OFF' 정책으로 되돌렸다.이 글은 그 회귀의 기록이다. 왜 자율성을 포기했는지, 그 대가로 무엇을 잃었는지, 그리고 "수백 개 에이전트를 상시 돌린다"는 마케팅을 최신 논문·토큰 데이터로 걸러낸 뒤 내린 절충안까지 다룬다. 도입을 고민하는 리..
-
프런트엔드 AX 설계기 0편 — 레거시 3개와 차세대 FE를 위한 워크플로우 설계기AI 엔지니어링 2026. 6. 19. 19:26
1. 도입부 (Why This Matters)React 15에 묶인 레거시 프로젝트 3개와, Next.js 기반 차세대 프로젝트들을 한 사람이 동시에 굴리는 상황을 떠올려 보자. 프로젝트마다 컨벤션이 다르고, 빌드 함정이 다르고, "여기서는 이렇게 하면 안 된다"는 암묵지가 다르다. 컨텍스트 스위칭 비용만으로도 하루가 샌다.여기에 AI를 얹으면 처음엔 빨라진 것 같다. 그런데 곧 다른 종류의 비용이 보인다. 채팅창에 그때그때 프롬프트를 복붙 하니 결과가 매번 다르고, AI가 건드리면 안 되는 곳을 건드려도 막을 경계가 없고, 잘 된 흐름을 재현할 수도 팀에 넘길 수도 없다. 산발적 사용의 한계는 속도가 아니라 운영 가능성에서 드러난다.이 글은 그 한계를 마주한 FE 한 명이 4개월에 걸쳐 AI 워크플로를..