2025.09.22 AI에게 성질내지않기(1)

서론: AI에게 성질 내지 않기의 어려움

AI에게 성질내지 않기란 여간 힘든일이 아니다.

사람이 바라는게 많으면 화도 많이낸다고, 바라는게 없으면 성질도 안낼텐데 매달 Claude Code에 $200쓰고있는데 (거의 크로스핏 한달가격이다) 이 친구가 만든 결과물이 샛길로 샐때마다 “나무아미타불” 소리가 속에서 절로나온다.

높은 기대치의 근본 원인

사색중에 왜 그렇게 나는 얘한테 바라는게 많을까 고민을 해보았다. 높은기대치가 그 첫번째 원인이고, 그것은 내가 고객에게 보여주고 싶은 수준이 있기 때문인것이 두번째 원인이고, 여태껏 쌓아온 고객과의 높은 신뢰를 깨지않고 싶은 나의 욕심이 근본 원인이다.

내가 이 업계에 있는한은 이 것을 욕심으로 해석하기보다는 일종의 근본적으로 꼭 지키고 더 높게 쌓아가야하는 것이 맞는듯하다.

90%에서 99%로: 품질의 도전

AI로 90%정도의 퀄리티를 보여주는 프로덕트를 만드는것은 정말정말 쉬울수 있다. 하지만 여기서 1퍼센트씩 채워서 95%를 만들고 여기서 0.1씩채워서 96,97.. 99% 의 완성도까지 가는것은 진짜 각고의 노력이 필요하다.

해결책: 확률 기반 접근법 (Bayesian Harnessing)

어쨌건 높은 퀄리티의 성과를 보여주기위해서 요즘 내가 AI에게 하는 것은 “성질내지 않기” 다.

성질내지 않기 위해서는 어떻게해야하냐고 ? 좋은 결과물이 나올 “확률”이 높게 주변환경을 만들어줘야한다.(Harnessing). 일종의 베이시안 정리를 활용하여 최대한 특정 사건이 일어날 확률이 높아지도록 계속해서 주변환경 및 지시법을 유도시키는 방법이다.

도구 설정: Claude Code + Super Claude

참고:

CC(Cluade Code) + SC(Super Claude) 조합을 기본적으로 백엔드로 사용한다.

SC는 기본적으로 CC를 백엔드로 사용하면서 다양한 subagents의 사용이나, 프로젝트를 진행하는 사람이 기본적으로 자주사용하는 로딩, 디자인, 트러블슈팅, 설명, 문서화, 인덱싱 등등을 사전정의된 prompt들을 옵션형태로 녹여놨다. 게다가 여러 remote machine(ssh, container) 등을 날라다니면서 일해야하는 내 업무환경에서는 설치도쉽고 유지보수도 아주 잘되고있고 문서화도 착실한 거같아서 잘쓰고있다.

문서 기반 10단계 워크플로우

아래는 내가 지키는 기본 스탭이다.

  1. 요구사항, 인프라, 테스트, 배포 등에 대한 문서쓰기.
  2. 문서기반으로 워크플로우만들기(이것도 문서)
  3. 문서들을 기반으로 마일스톤/세세한 Action items 만들기 (이것도 문서ㅋㅋ)
  4. 문서기반으로 Action item수행
  5. 문서기반으로 Test 수행
  6. 문서기반으로 빌드 수행
  7. 문서기반으로 E2E 테스트 수행
  8. 문서기반으로 릴리즈 문서만들고 배포
  9. Clean up and migrate docs based on the newest ones
  10. Tag 후 remote sync up

image.png

핵심: 근본 원인 분석

대부분은 7~9에서 문제가 많이 발견된다. 내 요구사항을 제대로 반영못했거나 잘못짰거나 등등 삽질을 많이한다.

여기서가 핵심!! 인데 보통 내가 너무 이걸 해결하는 방법을 빨리 찾고 싶은 경우가 아니라면, 4~9 과정에서 문제가 생겼을때는 항상 문서가 부족했는지, 코드의 구현이 문제였는지를 차분하게 분석시켜야한다.

예를들어 내가 AI가 다됐다고해서 RC(Release Candidate)를 빌드하여 직접 E2E테스트로 유저시나리오대로 테스트해보다가 문제가 생겼다.

생각같아서는 “이새끼야 이거 됐다며? 고쳐!!” 하고싶지만 차분해야한다.

그냥 고쳐!!! 라고하는것은 보통 “fix it!!” 이거나 SC를 이용한다면 “/sc:troubleshoot —ultra-think based on current context. Figure out the root cause” 뭐 이렇게 고결하게 얘기할수있겠지만, 내 경험상 이 방법 두개다 궁극적으로 Long-term view로 도움이 크게 되진않는다.

이럴때는 “자 지금 우리의 Design Docs in @docs 에 General 디자인이 잘못된인지, @docs/tests/ 에 있는 테스트 디자인이 잘못된것인지, 디자인은 잘했는데 코드구현이 잘못된것인지 analyze(or explain)해주세요.” 라고 시켜야한다.

그러면 코드구현상 문제인지, 프로세스문제이지, 테스트 케이스가 문제였는지, 디자인자체의 문제였는지, 이런 유저의 시나리오를 예측하지 못했다던지하는 근원의 문제를 파악하고 이것을 문서로 남긴다.

그러면 다시 이 문서를 기반으로 3번부터 다시 시작하는거다.

이 과정을 계속 반복하는 방망이 깍는 노인이 되면, 이제 AI 어느정도 잘 다듬어진 Milestone N에 해당하는 기능을 담은 Product release를 뱉는다.

거기서 10번 이 너무너무 중요하다.

예를들어 내가 약 90% 정도 만족하는 상태라고 가정하자. 10번이후에 다음 Action item을 위해서 3번스탭 부터 다시 수행하다보면 90%에서 80%미만으로 내려오가는 일이 진짜 비일비재하게 벌어진다. 두더지 잡기처럼 하나를 잡았더니 다른 두더지가 튀어 나오기를 반복하는 일종의 Regression이 계속해서 발생하는 것이다.

그래서 우리는 돌아갈 포인트를 꼭 하나 찍어두고 발전시키다가 뭔가 너무나 돌이킬수 없을만큼 망가진게 느껴진다면 돌아가기로 거기로 결정해야한다.

돌아갈때도 그냥 돌아가면안된다. 꼭 회고록을 작성시켜야한다. 왜 이렇게 망가졌는지, 동작했던 시기의 Design과 지금의 Design의 차이는 뭔지. 어떤 방향성을 잘못잡았는지 등의 Lesson Learnt에 대한 문서를 작성해야한다.

그리고 이걸 돌아와서 두번다시 반복하지 않도록 꼭 반영시켜야한다. (반영해도 비슷한 실수를 계속해서 반복하는게 진짜 사람같다 … ㅋㅋㅋ하아)

Claude Code + SC 조합의 디테일한 이용법은 적다가 너무너무 길어져서 위처럼 간단하게 적어봤다.

AI를 쓰면서 가장 많이하는 하기도하고 가장 많이 하려고 노력하는게 바로 이런 글쓰기인듯하다.

내생각엔 이젠 하기싫은 일일수록, 하지 않아도 되는것 같아보이는 것일수록 더 많이 해야 AI시대에 조금 더 본질에 가까워질수 있는것 같다.

끝

디테일하게 들어가보자.

먼저 프로젝트의 내용을 담은 문서들을 아주 디테일하게 만든다. 여기에는 SC의 디자인(sc:design)을 이용하여 같이 문서를 만든다. 보통 가장 먼저 만드는 문서인 Architecture.md 에는 전체적인 프로젝트의 directory구조를 어떻게 담을것인지 부터 디테일하게 정하기 시작해서, 동작환경, 테스트환경, 실제 유저의 동작환경들을 디테일하게 정의하기 시작한다. 그리고 유저시나리오(UX) 대해 논의하면서 이 문서를 몇시간이고 몇일이고 계속해서 상상하면서 업데이트한다.

어느정도 그림이 나왔으면 이제 문서들의 좋은 탬플릿구조를 만들기시작한다. design, architecture, user-guide, test(or infra), release 등의 매번 문서를 만들때마다 기준삼아야할 문서들의 탬플릿을 만든다. 사실상 이문서들은 꽤나 재사용이 가능하지만, 매번 다시 만들고 리뷰하는것을 좋아한다. 내 머리에 남기기위해서.

그리고나서 SC의 workflow옵션으로 Workflow를 마일스톤, 세부 Checkpoint기준으로 나누기를 시키고 그 문서를 디테일하게 검토하여 중요도 및 디테일한 내용들을 검토하며 계속 업데이트한다.

그게 어느정도 되면 SC의 task기능으로 workflow 옵션으로 만든 workflow.md(예를들어) 를 참조시켜 드디어 코드작업 시킨다.

코드 작업을 하기까지 계속해서 AI에게 강조시켜야하는것이 있다.

“Don’t ever CODE until I command you to do it”, 즉 즐대즐대 절대절대(중요 X10000) 내가 시키기 전까지는 코딩하지 말라고 시켜야한다.