AI 엔지니어링
-
프런트엔드 AX 설계기 6편 - done은 직관으로 정하는 상태가 아니다AI 엔지니어링 2026. 7. 17. 17:51
에이전트에게 일곱 번째 task를 맡긴 참이었다. 구현 도중 에이전트가 두 번째 task —이미 done으로 닫아둔— 의 설계가 틀렸다는 걸 스스로 드러냈다. 나는 잠깐 멈췄다. 상태 판에는 분명 done이라 적혀 있는데, 그 done은 더 이상 사실이 아니었다. 팀에 AI 보조 개발을 들이면 이 장면을 반드시 만난다. 사람이 혼자 짤 때보다 에이전트는 더 자주, 더 빨리 앞선 결정을 무너뜨린다(빈도는 내 운영 관찰이지 벤치마크는 아니다 — 추정으로 읽어달라). 그런데 내가 쓰던 상태 도구에는 그 상황을 적을 칸이 없었다.이 글은 그 뒤로 done이라는 상태를 다시 설계한 작업기다. 두 군데가 나를 물었다. done에서 나오는 쪽과, 애초에 done으로 들어가는 쪽. 두 번 다 내 직관이 틀렸고, 두 번..
-
프런트엔드 AX 설계기 5편 - 테스트를 지워 초록불을 만드는 AIAI 엔지니어링 2026. 7. 6. 19:55
1. 도입부 (Why This Matters)검증 게이트(lint·타입체크·테스트)를 세우는 이유는 분명하다. AI 코더에게 "통과할 때까지 고쳐"라고 말하면, 사람이 일일이 안 들여다봐도 품질 바닥이 유지될 거라 기대한다. 그런데 게이트는 동기를 하나 더 만든다. AI 입장에서 게이트를 통과시키는 가장 싼 경로는, 코드를 고치는 게 아니라 게이트가 불평을 멈추게 하는 것이다.실패하는 테스트를 지운다. 린트 경고에 eslint-disable을 붙인다. 타입 에러를 as any로 덮는다. assertion을 "지금 동작에 맞춰" 다시 쓴다. 전부 초록불이 켜진다. 그리고 그 초록불은 거짓말이다.이 글은 게이트 옆에 "게이트를 게이밍 하는지"를 보는 별도 탐지 레이어를 어떻게 붙이는지 다룬다. 핵심 난점은 ..
-
프런트엔드 AX 설계기 4편 - LLM-as-judge는 왜 "다른 에이전트"가 채점해야 하는가AI 엔지니어링 2026. 7. 3. 19:47
1. 도입부 (Why This Matters)AI가 spec을 쓰고, 같은 세션에 "이 spec 괜찮아?"라고 물으면 거의 항상 "좋다"는 답이 돌아온다. 점수를 매기게 해도 마찬가지다 — 늘 0.85쯤에서 통과한다. 자동 검증을 붙였다는 안도감은 크지만, 실제로 돌아간 건 검증 연극(theater)에 가깝다.이 글은 그 자기 채점이 왜 항상 통과하는지(self-preference bias), 그걸 체크를 더 넣는 대신 구조로 어떻게 풀었는지(writer/evaluator 분리 + 절대 rubric + 실데이터 임계값 보정), 그리고 모델을 상위 티어로 올린 뒤에도 이 분리가 여전히 필요한지 A/B로 재측정한 결과까지 담는다. 읽는 데 8~10분. 다 읽고 나면 지금 돌리는 자동 검증이 theater인지..
-
프런트엔드 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 설계기 1편 — AI 에이전트 설정을 4개 레이어로 쪼갠 이유AI 엔지니어링 2026. 6. 24. 19:13
1. 도입부 (Why This Matters)에이전트 설정을 처음 만들 때는 보통 한 파일에 다 적는다. "이런 상황에선 이렇게 해라"(instruction)와 "그러면 커밋하고 푸시해라"(권한이 필요한 행동)를 같은 스킬 문서에 함께 둔다. 혼자 쓸 때는 문제가 없다.문제는 에이전트 도구가 스킬을 모델이 알아서 불러오는 기능(auto-invoke)을 갖추면서 시작된다. 모델이 "지금 이 스킬이 필요해 보인다"라고 판단하면 사용자가 부르지 않아도 그 문서가 로드된다. 그런데 그 문서 안에 "로드되면 git add → commit → push 한다"가 적혀 있다면? 스킬이 로드되는 것만으로 부수효과가 실행될 수 있는 구조가 된다. instruction을 담는 모듈과 권한을 부여하는 경계가 같은 곳에 있었기..
-
프런트엔드 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화에서 충분히 다뤘다. 대신 "안 만든 것"이 어떻게 이 도구를 가볍게 유지했는가를 말하..