전체 글
-
프런트엔드 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..
-
git 머지 드라이버는 '파일명 순서'로 협력하지 않는다 — pnpm-lock 충돌 자동화 심화기Git 2026. 6. 29. 19:23
1. 도입부 (Why This Matters)pnpm-lock.yaml은 package.json의 파생물이다. 그런데 git의 기본 머지는 이 파일을 '줄 단위 텍스트'로 본다. 두 PR이 각자 의존성을 건드리면 lockfile은 거의 항상 충돌하고, 텍스트 3-way 병합은 lockfile의 해시·트리 구조를 깨뜨린다. 결국 사람이 lockfile을 통째로 다시 만들어 커밋한다.2. 핵심 개념 (What & Why)git 커스텀 머지 드라이버란,. gitattributes로 특정 파일에 지정해 두면 그 파일이 충돌할 때 git이 기본 텍스트 병합 대신 우리가 만든 스크립트를 호출하게 하는 장치다(첫 등장이니 한 줄 정의).비유하자면, 기본 머지는 '줄 단위로만 비교하는 직원'이다. JSON이나 lock..
-
프런트엔드 AX 설계기 2편 — 에이전트를 '자율 실행'에서 '명시적 동의'로AI 엔지니어링 2026. 6. 26. 19:16
1. 도입부 (Why This Matters)에이전트 도구를 처음 세팅하면 거의 모두 "자동"에 끌린다. 리뷰 에이전트, 문서 에이전트, 비평 에이전트를 만들어 두면 알아서 끼어들어 일을 거든다 — 적어도 그럴 거라 기대한다. 나도 그렇게 시작했다. 역할별 커스텀 에이전트 6개를 만들고, 요청이 들어오면 시스템이 알아서 적절한 에이전트를 골라 활성화하도록 했다.그리고 몇 주 뒤, 그 자동 활성화를 전부 껐다. 모든 에이전트를 명시적으로 호출할 때만 실행되는 '기본 OFF' 정책으로 되돌렸다.이 글은 그 회귀의 기록이다. 왜 자율성을 포기했는지, 그 대가로 무엇을 잃었는지, 그리고 "수백 개 에이전트를 상시 돌린다"는 마케팅을 최신 논문·토큰 데이터로 걸러낸 뒤 내린 절충안까지 다룬다. 도입을 고민하는 리..
-
프런트엔드 AX 설계기 1편 — AI 에이전트 설정을 4개 레이어로 쪼갠 이유AI 엔지니어링 2026. 6. 24. 19:13
1. 도입부 (Why This Matters)에이전트 설정을 처음 만들 때는 보통 한 파일에 다 적는다. "이런 상황에선 이렇게 해라"(instruction)와 "그러면 커밋하고 푸시해라"(권한이 필요한 행동)를 같은 스킬 문서에 함께 둔다. 혼자 쓸 때는 문제가 없다.문제는 에이전트 도구가 스킬을 모델이 알아서 불러오는 기능(auto-invoke)을 갖추면서 시작된다. 모델이 "지금 이 스킬이 필요해 보인다"라고 판단하면 사용자가 부르지 않아도 그 문서가 로드된다. 그런데 그 문서 안에 "로드되면 git add → commit → push 한다"가 적혀 있다면? 스킬이 로드되는 것만으로 부수효과가 실행될 수 있는 구조가 된다. instruction을 담는 모듈과 권한을 부여하는 경계가 같은 곳에 있었기..
-
squash merge가 release마다 cherry-pick이 충돌하는 이유Git 2026. 6. 22. 18:40
1. 도입부 (Why This Matters)릴리즈 브랜치를 만들 때마다 같은 일이 반복된다. 분명 일상 통합 브랜치에서는 깨끗하게 머지됐던 변경인데, 릴리즈 브랜치에 모으려고 cherry-pick을 돌리면 매번 1~3건씩 충돌이 난다. -x, -m, -X theirs 같은 옵션을 바꿔봐도, 전략(recursive/ort)을 바꿔봐도 결과는 비슷하다. 손으로 풀고, 다음 릴리즈에서 또 푼다.이 글의 결론을 먼저 말하면 이렇다. cherry-pick을 튜닝하는 건 헛수고다. 충돌의 범인은 cherry-pick이 아니라, 그 한참 앞에서 일어난 squash 머지다. squash가 git이 3-way 머지의 기준점으로 쓰는 공통 조상(merge base)을 지워버리기 때문에, cherry-pick은 "이미 적..
-
프런트엔드 AX 설계기 0편 — 레거시 3개와 차세대 FE를 위한 워크플로우 설계기AI 엔지니어링 2026. 6. 19. 19:26
1. 도입부 (Why This Matters)React 15에 묶인 레거시 프로젝트 3개와, Next.js 기반 차세대 프로젝트들을 한 사람이 동시에 굴리는 상황을 떠올려 보자. 프로젝트마다 컨벤션이 다르고, 빌드 함정이 다르고, "여기서는 이렇게 하면 안 된다"는 암묵지가 다르다. 컨텍스트 스위칭 비용만으로도 하루가 샌다.여기에 AI를 얹으면 처음엔 빨라진 것 같다. 그런데 곧 다른 종류의 비용이 보인다. 채팅창에 그때그때 프롬프트를 복붙 하니 결과가 매번 다르고, AI가 건드리면 안 되는 곳을 건드려도 막을 경계가 없고, 잘 된 흐름을 재현할 수도 팀에 넘길 수도 없다. 산발적 사용의 한계는 속도가 아니라 운영 가능성에서 드러난다.이 글은 그 한계를 마주한 FE 한 명이 4개월에 걸쳐 AI 워크플로를..
-
안 만든 것이 규율이다 — 절제로 끌고 간 토이 프로젝트 회고 (Scrooge 5편)AI 엔지니어링 2026. 6. 16. 17:53
🔗 scrooge1. 도입부 — 토이 프로젝트가 망하는 진짜 이유개인 프로젝트는 보통 기능 부족으로 망하지 않는다. 하고 싶은 게 너무 많아서 망한다. "이왕 만드는 김에 이것도", "나중에 필요할 테니 미리", "더 일반적으로 추상화해두면" — 이런 충동이 쌓이면, 정작 핵심은 미완인 채로 곁가지에 짓눌려 프로젝트가 무거워진다. 혼자 쓰는 도구일수록 이 제동장치가 없다. 리뷰어도, 데드라인도, 말려줄 동료도 없으니까.scrooge는 약 2주, 57개 커밋으로 v0.6.1까지 굴러간 작은 도구다(2026-05-25 첫 커밋 ~ 06-02). 이 회고에서 말하고 싶은 건 그동안 만든 기능 목록이 아니다 — 그건 0~4화에서 충분히 다뤘다. 대신 "안 만든 것"이 어떻게 이 도구를 가볍게 유지했는가를 말하..
-
켰는데 왜 안 먹지 — 하나의 모드를 Claude Code와 Codex 두 호스트에 (Scrooge 4편)AI 엔지니어링 2026. 6. 15. 17:50
🔗 scrooge1. 도입부 — "같은 기능"이 호스트마다 다른 표면을 갖는다압축 모드 하나를 Claude Code에서 잘 돌렸다고 하자. 이걸 Codex에도 태우려 한다. 기능은 "똑같다" — 사용자 입력에 압축 지시를 끼워 LLM이 짧게 답하게 만든다. 그런데 막상 옮기려 보면, 두 호스트가 개입하는 메커니즘 자체가 다르다. 같은 기능인데 표면이 갈린다.여기에 더 음험한 문제가 겹친다. "scrooge가 켜졌다"는 말이 실은 세 가지 다른 의미로 쓰이고 있었다는 점이다. 설치됐다는 뜻인지, 지금 활성이라는 뜻인지, 이 세션에만 거는 지시라는 뜻인지. 이 셋을 섞으면 "분명 켰는데 왜 안 먹지" 같은 혼란이 반드시 생긴다.이 글에서 당신이 얻어갈 것은 두 가지다. 하나는 같은 기능을 다른 hook 메..