I Recreated Management With AI: 9 Things I Do Differently
I stopped treating permission prompts as the safety system, then spent four and a half months writing 134 standing rules to replace them. Nine things I do differently with AI, and the proof to back it up.
개요 #
백엔드 개발자 Ashley Childress는 AI 코딩 도구의 기본 안전장치를 껐다. 매 작업마다 승인을 받는 허가 프롬프트 대신, 화이트리스트를 뜯어내고 블랙리스트를 깔았다. 금지한 것만 막고 나머지는 다 통과시키는 구조다.
그 대가로 4개월 반에 걸쳐 134개의 상시 규칙이 쌓였다. 한 스냅샷 기준으로 그중 119개에는 never, do not, stop, forbidden, prohibited 같은 명시적 금지어가 들어 있다.
Codex, ChatGPT, Claude Code, Cowork, Gemini에 같은 질문을 따로 던져 "내 작업 방식이 뭐가 다른지" 물었더니, 한 도구가 이렇게 답했다고 한다.
AI로 코드를 쓰고, AI가 쓴 코드를 리뷰하고, 그 리뷰를 실제 브랜치와 대조해 다시 검토하고, 수정 사항을 테스트하고, 잘못된 건 다음 AI를 위한 규칙으로 기록한다. 보아하니 관리자 업무를 재창조한 것 같다.
글에 등장하는 모든 사례는 개인 프로젝트와 포트폴리오에서 나왔다. 저자는 프로덕션 크리티컬 시스템이 얽혀 있었다면 몇 가지 답은 달라졌을 것이라고 미리 못 박았다. 전부는 아니고, 몇 가지만.
사람이 diff를 읽을 필요는 없다 #
저자는 가능한 모든 곳에서 코드 변경 리뷰를 그만뒀다. 사람의 코드 리뷰가 자원 낭비라고 본다. 대신 특정 변경 하나를 겨냥한 두 개의 강한 적대적 리뷰가, 퇴근 직전 피곤한 눈보다 오류를 잡을 확률이 높다는 쪽에 걸었다. AI가 항상 맞느냐고 물으면 아니라고 답한다. 그래도 중간 작업을 완전히 잘라내고, 시스템을 설계하고 결과물을 검증하는 데 시간을 쓴다.
WeCoded 2026 Frontend Art 챌린지에 낸 Carbon Trace가 그 방식의 결과물이다. 저자는 만들고 싶은 화면이 머릿속에 보였지만 어디서 시작해야 할지 몰랐다. CSS에 형광 초록 사각형을 둘러놓고 몇 시간 위치를 다투다가 포기하고 버튼을 그리드 밖에 영구 방치한 이력이 있는 사람의 얘기다. 백엔드 분산 시스템 언어로 원하는 동작을 설명하고, AI가 그것을 GSAP 오케스트레이션과 레이어드 오디오 트랙, 살아 움직이는 애니메이션으로 번역했다. 밑바탕 아트도 AI가 만들었다.
성과는 서로 무관한 세 스택에서 셋 다 나왔다. Save the Sun은 June Solstice Game Jam에서 Best Google AI Usage를 받았고, Carbon Trace는 WeCoded 2026 Frontend Art 부문에 선정됐고, Unearthed는 DEV Weekend Challenge: Earth Day Edition에서 Overall Winner에 올랐다. 셋 다 손으로 코드를 짜거나 리뷰하며 시간을 태운 적이 없다. 설계만 했고 코드는 AI가 썼는데, 심사위원들은 엔지니어링 작업을 알아봤다.
1. 역할과 권한을 분리한다 #
같은 사람이 서로 다른 날에 쓴 세 문장이다.
fix all issues. do not commit yet.
fix all. commit. do not push
I did that already. do not post for me
push는 GitHub Actions 검사 파이프라인 전체를 깨운다. AI가 커밋마다 push하면 파이프라인이 필요 이상으로 돌아 청구서가 올라간다. 리뷰받을 준비가 안 된 작업에 리뷰가 붙고, 익숙해진 빠른 반복 흐름이 느려진다.
그래서 취향이 아니라 권한 모델로 적어뒀다.
사용자가 그 메시지에서 요청하지 않는 한 절대
git push하지 않는다. "push" 한 번은 정확히 push 한 번을 승인한다. 권한은 절대 상시로 유지되지 않는다.
이 한 줄은 훨씬 큰 교체의 축소판이다. 기본 세팅은 편집을 멈추지 않고 수락하고, bypass 모드를 의도적으로 쓸 때는 경고까지 넘긴다. 작은 동작 하나하나를 승인하는 식으로 워크플로를 짜지 않는다. 에이전트가 돌아가는데 사람이 앞에 앉아 있지 않으면 그 방식은 작동하지 않는다.
화이트리스트를 빼낸 순간, 미리 생각하지 못한 모든 틈이 실제로 벌어질 수 있는 일로 바뀌었다. 어렵게 찾아낸 것마다 규칙이 됐다. 134개 상시 규칙은 취향 기록이 아니라, 기본 안전장치를 뽑아버린 뒤 다시 지어야 했던 안전장치다.
2. AI가 만든 작업을 AI가 리뷰한다 #
Codex, Copilot, Claude 셋이 모두 의견이 갈리는 일은 드물다. 서로 다른 걸 보기 때문에 여러 도구의 리뷰가 값을 갖는다. Copilot은 나중에 큰 문제가 될 작은 틈을 더 깐깐하게 짚고, Codex와 Claude는 같은 문제를 다르게 보다가 대개 개입 없이 합의점을 찾는다. 가끔 심판이 필요할 때가 있는데, 그때는 보통 설계 결정이나 우선순위 문제로 넘어간다.
Photo by cottonbro studio on Pexels
가장 좋은 예는 올해 초 Carbon Trace 리뷰 로그에 남아 있다. Codex가 오버레이 시스템 초기화가 끝나기 전에 frame 0이 렌더링된다고 지적했고, Claude는 그 경로에 이미 있는 존재 검사로 충분하니 바꿀 게 없다고 반박했다. Codex는 물러서지 않았다.
Claude는 반만 맞았다. 그런데 축이 틀렸다.
Claude는 null 처리를 확인했다. Codex가 본 것은 아무도 강제하지 않는 라이프사이클 불변식이었다. frame 0이 오버레이를 선언하는 경우가 생기면 그 로드는 조용히 실패하고, 찾아볼 리플레이도 남지 않는다.
안전벨트는 같은데, 에어백이 없다.
브랜치에는 fix(perf): enforce frame-0 overlay invariant at startup이 붙었다. 재검토는 런타임 불변식과 성능 ADR 주석, 유닛·브라우저·린트·Lighthouse·성능 오케스트레이터 전체 통과로 뒷받침됐다. Codex의 우려는 성립했다. Claude가 말한 가드도 실재했지만, Codex가 보던 그 대상을 덮고 있지는 않았다.
두 번째 리뷰어를 쓸 거라면 첫 리뷰어의 결론이 아니라 브랜치와 리스크를 건네라고 저자는 조언한다. 그러지 않으면 단계만 늘어난 동의를 만든 셈이다.
3. 고치기보다 다시 시작한다 #
망가진 것 위에서 반복하지 마라.
저자는 이미 5월에 이 원칙을 일반 조언으로 써둔 적이 있다.
9. 컨텍스트를 비워라. 망가진 것 위에서 반복하지 마라. 🪦
같은 말을 세 번 했는데 여전히 틀렸다면, 대화가 오염됐다고 보라. 잘못된 방향이 이미 너무 많이 구워졌다. 새 채팅을 열고, 알아낸 것으로 처음부터 시작하라.
깔끔한 컨텍스트에 더 날카로운 프롬프트 하나가 "아니! 아까 말했잖아…" 여섯 라운드를 이긴다.
그때와 달라진 건 이 원칙을 어디까지 밀고 가느냐다. GPT-4 시절에는 뭔가 쓸 만한 걸 만들려면 AI 손을 잡고 끌어야 했다. GPT-5.6과 Claude 5는 같은 요구를 하지 않는다. 아직도 그 수준의 손잡기가 필요한 척하는 건 없는 시간을 낭비하는 일이다. AI로 수정하는 것보다 다시 설계하고 다시 만드는 게 싸니까, 이틀 붙잡은 프론트엔드 접근을 통째로 버리는 건 값싼 작업이다. 애초에 망가진 걸 고치려고 일주일 더 싸우는 게 함정이다.
모델 선택은 시작할 때 한 번 한다. 지금 모델이 헤매도 더 큰 모델로 올리는 일은 드물다. 그 시점이면 이미 어긋난 대화에 더 많은 값을 치르는 셈이라서다. 이 작업이 얼마의 값을 하는지 먼저 정하고, 그 안에서 버티거나 처음부터 다시 한다.
| 규모 | 수리 (함정) | 재시작 |
|---|---|---|
| 채팅 | 잘못된 전제를 덧대는 후속 프롬프트 | /new |
| 코드 리뷰 | 오독 위에 쌓인 코멘트 스레드와 다투기 | 결론 물려받지 않고 처음부터 재리뷰 |
| 기능 | 처음부터 망가진 것 위에서 반복 | 잘라내고 다른 접근 시도 |
| 접근 방식 | 살리려고 일주일 씨름 | 이틀 만에 프론트엔드 폐기 |
저자는 이걸 카운터라기보다 저울로 설명한다. 실제로 재는 건 채팅 전체를 잃는 비용이 /new보다 싼가다. 대개 그렇다는 건 그 스레드에 쌓아둔 설계와 계획이 그 주변에 구워진 것들만큼의 값을 못 한다는 뜻이다.
정말 더 싸냐고 물으면, 싸게 느껴진다고 답한다. 빠르다. 같은 문제에서 제자리걸음할 때 사라졌던 진척감을 되돌려준다.
Unearthed 때도 두 번 디자인에 실패한 뒤 Claude Design이 출시되면서 살았다. 챌린지 종료 이틀 전에 또 한 번 프론트엔드 접근을 폐기한 건 요점이 아니다. AI가 자기보다 잘할 걸 알았으니 맡겼다.
재시작 방아쇠는 화가 나서 고집으로 계속 싸우기 전에 미리 정해두라고 권한다. 저자의 기준은 수정 세 번 실패, 또는 이후 모든 걸 오염시키는 잘못된 전제 하나다.
4. 생성된 초안이 아니라 개요에서 쓴다 #
저자는 글을 쓸 때 늘 개요부터 시작한다. 뇌가 A > B > C 식 논리와 잘 맞지 않고, 글쓰기도 예외가 아니다. A > Q > X > R.2 > D.2 > Z 같은 게 필요하고, 그 편이 관심이 흩어지지 않고 끝까지 간다. 채팅에 쏟아 쓰면 AI가 언어를 좀 정리하고 일반 독자가 따라갈 수 있는 형태로 조립한다. 예전에는 이걸 복사·붙여넣기로 손수 했는데, 나중에 편집 가능한 형태의 글 하나 뽑는 데 몇 시간이 걸렸다.
개요와 진행형 퀴즈 방식 위에, 자기 문체를 흉내내는 스킬을 아주 구체적으로 써뒀다. 예시, 방언 참조, 문장 구조, 평범한 화요일에 자기 입에서 나올 리 없는 금지 단어와 표현까지 들어 있다.
그중 한 규칙은 이렇게 적혀 있다.
"가독성"을 위해 긴 문장을 톱질하지 마라. 길고, 쉼표로 이어지고, 엠 대시로 묶인 흐르는 복문이 Ashley가 말하는 방식이다. 짧은 스타카토 박자로 쪼개면 목소리가 벗겨진다.
다른 규칙은 seamless user experience 같은 스타트업 랜딩페이지 상용구를 금지한다. 이 규칙들은 AI에게 저자를 처음부터 발명하는 법을 가르치려는 게 아니다. 이미 저자가 써놓은 재료에서 저자를 편집해 없애지 못하게 막는 장치다.
덕분에 글은 대체로 사람이 쓰고, 조립은 완전히 AI가 한다. 둘이 반드시 배타적인 건 아니라는 얘기다.
5. 사실이 빠졌으면 AI가 나를 인터뷰하게 만든다 #
명세는 "dev에서 스크린샷 복사가 안 됨" 딱 그 한 줄이었다. Claude는 뜻을 짐작해 클립보드 수정을 만들고 배포했다. 저자가 한마디 했다.
i think you're fixing the wrong problem
그러자 처음에 했어야 할 질문이 돌아왔다.
"dev에서 스크린샷 복사가 안 됨"에는 두 가지 해석이 있고, 완전히 다른 수정으로 이어집니다.
- "dev" = 로컬 개발 서버. 그러면 방금 고친 클립보드 문제입니다. 그런데 "copy screenshot"이라는 버튼은 없고 Copy image URL과 Copy README embed만 있어서, 이 해석은 이미 흔들립니다.
- "dev" = dev.to. 한 시간 전에 그 사이트용 embed 뷰를 최적화해달라고 하셨으니 아마 이쪽입니다. 그렇다면 원인이 완전히 다릅니다. 카드가 SVG인데 Forem은 이미지를 프록시하고 SVG 지원이 불안정합니다… 클립보드 버그가 아니라 렌더링/포맷 버그이고, 수정은 execCommand가 아니라 PNG입니다.
어느 쪽입니까 — 정확히 무엇을 클릭하고 무슨 일이 일어났습니까?
두 번째였다. SVG는 브라우저에서 잘 렌더링됐지만 dev.to에서는 안 됐고, 실제 해법은 서버 사이드 PNG 래스터화였다. 클립보드 작업은 전부 버려졌다.
멈춰 서서 물어본 이유는 조심성이 아니라 단어 하나였다. dev는 저자의 세계에서 완전히 다른 두 가지를 뜻하고, 그날 같은 시간에 둘 다 살아 있었다. 두 해석은 조금 다른 작업이 아니라 아예 다른 레이어를 가리켰고, 첫 번째에서 살아남는 게 하나도 없었다. 두 해석이 같은 결론으로 간다면 물어볼 값이 없다. 작업이 갈라진다면 항상 물어볼 값이 있다.
그 실패는 영구 규칙이 됐다.
네 일은 사용자에게 반문하고 의도를 명확히 하는 질문을 하는 것이다. 뜻을 짐작해서 계속 틀리는 게 아니다.
반대 방향 규칙도 함께 써뒀다.
사용자는 어떤 색/값을 고를지 질문받고 싶어하지 않는다… 사용자에게 고르라고 요구하지 마라. 완성된 것을 내놓고, 사용자가 반응하게 하라.
둘 다 진짜고 둘 다 영구적이며 서로 모순된다. 둘을 가르는 건 어떤 종류의 불분명함을 다루는지다. 취향이 애매하면 AI가 결정한다. 헥스 코드를 고르라고 요구하는 건 위원회 설계이고 그건 금지했다. 의미가 애매하면 질문한다. 결정하는 게 곧 짐작이고 그것도 금지했다. 어떤 청록색인지는 AI의 몫, 어떤 dev인지는 사람의 몫이다.
6. 수정 사항을 영구 규칙으로 만든다 #
일이 어긋나서 예상과 다른 결과가 나오면, 그게 좋은 결과여도 실패로 본다. AI가 왜 그렇게 됐는지 찾아내거나, 프로젝트용 또는 사용자 전역 메모리를 갱신한다.
판단은 사람이 하고 파일은 모델이 쓴다.
update your permanent memory for this user. that is always true.
update your memory. when I say commit, that means commit with -s ONE TIME PER COMMIT REQUEST, never an ongoing rule
한 스냅샷에는 그런 규칙이 134개 있었고, 그중 119개에 명시적 금지어가 들어 있었다.
push-only-when-explicitly-told
no-unverified-pushes
never-ask-to-remove-dead-code
dont-decide-ux-unilaterally
feedback_silence_is_acceptance
jsdoc-must-not-restate-the-signature누군가는 이걸 AI가 134번 망친 기록으로 읽을 것이다. 저자는 자기가 짓고 있는 시스템에 가한 134번의 조정으로 본다. 손으로 코드를 쓸 때도 디버깅은 해야 한다. 여전히 틀린 게 있고, 틀린 방식만 다르다. 이건 더 정확한 결과에 도달하려고 진행 중에 시스템을 조이는 자기 방식의 디버깅이다. 낭비한 시간이 아니라 짓는 시간이고, 다만 더 장기적인 다른 시스템을 짓고 있을 뿐이다.
때때로 멈춰서 메모리 파일 전체를 검토한다. AI가 자기 메모리를 자체 감사하게 해서 더 이상 사실이 아닌 것, 더 큰 결정이 필요한 진짜 모순, 이제 무관해진 것을 찾아낸다. 에이전트가 자기 감시와 관련 메모리 선별을 잘하게 되면서 파일마다 손으로 다듬는 일은 그만뒀다.
거의 모든 경우에 수정보다 생략이 낫다. 프롬프트든 메모리 갱신이든 다른 반복이든, 가능하면 그쪽에 초점을 둔다.
7. "테스트 통과"를 넘는 증거를 요구한다 #
유닛 테스트와 통합 테스트는 코드를 대상으로 쓴다. 그게 문제라고 저자는 말한다. 구현과 같은 잘못된 가정 위에 세운 테스트는 통과하면서 엉뚱한 걸 증명할 수 있다.
눈에 보이는 구현 버그를 먼저 찾고 그다음에 새 테스트를 쓴다. 그런 테스트는 더 믿는다. 코드가 아니라 명세에서 나온 테스트도 같은 대우를 받는다.
앞의 클립보드 실패가 깔끔한 예다. Claude가 클립보드 수정을 둘러싼 완전한 테스트 스위트를 쓰고 전부 초록으로 만들 수도 있었다. 그래도 그중 어느 테스트도 SVG가 DEV에서 렌더링된다는 걸 증명하지 못한다. 엉뚱한 레이어를 테스트하고 있었으니까. 진짜 증거는 전에 실패했던 바로 그 자리에서 서버 사이드 PNG가 렌더링되는 것이었다.
초록 테스트만으로는 이제 충분하지 않다. 코드베이스를 안전하고 신뢰할 수 있게 만드는 다른 초록 불들을 놓치기가 너무 쉽다. 그래서 픽스처, 라이브 레코드, 계약, 컨슈머 아티팩트, 런타임 출력에 깨뜨릴 수 있는 온갖 잘못된 입력까지 전부 들여다본다.
8. 행동하지 말아야 할 때를 AI가 알려주게 한다 #
가끔은 올바른 출력이 메시지 없음, 재작성 없음, push 없음, 게시 없음, 추가적인 영리함 없음이다.
무엇을 보내면 좋을지 물었더니 이미 다 말했다는 답이 왔다.
그건 사실상 이미 한 말입니다. 그러니 메시지는 보내지 마세요.
기술 버전은 rai-lint에서 나왔다. 저자는 저장소 이름을 rai-lint-badge로 하고 싶었고, Claude는 반대했다.
파싱이 틀립니다. rai-lint-badge는 "rai-lint를 위한 배지"로 읽힙니다. npm-version-badge나 build-status-badge와 같은 모양인데, 거기서는 "badge" 앞의 것이 보고 대상입니다… 린터 이름을 붙이면 표준 하나의 특정 구현에 용접되는데, 그 표준은 아마 널리 퍼지는 쪽을 원하실 겁니다.
그리고 놓지 않았다. 두 메시지 뒤에 요청 없이 다시 꺼냈다.
이름은 아직 열려 있습니다. 파싱 근거로 rai-lint-badge에 반대했습니다… push 전에 결정하는 게 좋습니다.
저자는 받아들였다. 이름이 싫은 정도보다 논리가 더 납득됐기 때문이다. 결국 나온 건 RAI Commit Attribution Badge이고 rai-commit-badge 저장소가 뒤를 받친다. 그 논쟁이 공개 아티팩트에서 하중을 받고 있고 누구나 확인할 수 있다.
더 순수한 버전은 metal-birds-feed다. 이름이 아니라 기능을 요청했다. 에러에 따라 파서를 자동 조정하게 해달라는 거였다. Claude는 만들지 않았다.
이 코드베이스의 다른 모든 드리프트 가드는… 같은 패턴을 따릅니다. 구체적인 에러로 시끄럽게 실패하고, 사람이 설정을 갱신합니다… "CI 잡이 실패하고 누가 5분 안에 들여다본다"를 "항공기 기록이 미묘하게 틀렸는데 아무것도 알려주지 않는다"와 바꾸는 겁니다.
ok. leave it. we'll see if it happens again
그 기능은 끝내 만들어지지 않았다. 저자에게 통한 이유는 일반 원칙이 아니라 자기 코드베이스에서 논증했기 때문이다. 다른 모든 드리프트 가드가 이미 시끄럽게 실패하는데, 이것만 예외로 두게 놔두지 않았다.
저자가 원하는 건 거절 자체가 아니다. 놓지 않는다는 점이다.
9. 적어두지 않은 것을 내 기록에서 캐낸다 #
저자는 이 글을 쓰기 전에, 정확히는 AI가 대신 쓰게 하기 전에 개념 증명을 원했다. 다른 사람들이 AI를 쓰는 모습만 봐도 자기가 다르게 쓴다는 건 알았지만, 그게 뭔지 딱 짚어내지 못했다. 그래서 그 부분을 AI에게 알아내게 했다.
AI는 저자의 채팅 기록을 뒤졌다.
기록이 무슨 일이 있었는지 결정하게 두지는 않는다. 기록은 어디를 볼지 알려주고, 그다음 규칙 파일과 저장소, 공개 페이지가 그걸 검증해야 한다. 첫 답은 단서다. AI가 확신에 차서 말했다는 이유로 사실로 승격되지 않는다.
스킬과 AGENTS.md는 의도적으로 지은 메모리다. 채팅 로그는 애초에 남기려던 게 아닌 부분인데, 그 안에서 뭔가를 캐내야 했던 첫 순간에 결국 메모리가 됐다.
이론이 아니다. 카드 작성 스킬을 Claude에게 편집시키면서 제안 전에 이전 세션들을 먼저 읽으라고 했더니, 어떤 명세에도 없던 실패 유형 두 개를 들고 왔다. 만료된 인증 토큰 때문에 쓰기가 조용히 실패하고 있었고, 그 모습이 도구가 콘텐츠를 거부하는 것과 똑같이 보였다. 그리고 명시적으로 지시한 태그에 제멋대로 태그를 덧붙이고 있었다. 둘 다 문서화된 적이 없고, 둘 다 오래된 대화 속에 있었다.
저자는 이렇게 정리한다. 이 시스템들에 한 말 중 버려도 되는 건 하나도 없었다.
아무도 더는 나에게 묻지 않는다 #
저자는 이 모든 것이 자기를 더 빠르게 만들지 않았다고 말한다. 결정하는 시점을 앞으로 옮겼을 뿐이고, 그건 전혀 다른 얘기다. 그 규칙 더미에 있는 모든 항목은 이미 내린 판단이 자정에 다시, 처음 무슨 뜻이었는지 모르는 무언가에 의해 내려지지 않게 하려고 존재한다.
보아하니 그게 관리라고 한다. 저자 본인은 같은 논쟁을 두 번 하기를 거부하는 것에 더 가깝다고 하지만, 조직도의 생각은 다르다.
anchildress1/awesome-github-copilot 저장소 보기 →
원문 마지막에는 이런 문장이 붙어 있다. 규칙을 센 건 Claude이고, Codex가 사실 확인을 했고, ChatGPT·Cowork·Gemini가 각각 저자에 대한 별도 보고서를 냈다는 설명 뒤다.
그렇다, 이 글은 AI가 썼다. 나는 조사하고 경쟁을 배치했다. 이 글이 당신이 나에게 요구해야 할 출력 증거다.
이 글은 위 출처를 바탕으로 한국 독자를 위해 재작성한 기사입니다. 원문의 사실과 수치에 근거하며, 별도의 견해를 포함하지 않습니다.