새로운 코딩 프롬프트 공유

내 작업물을 공유하는 건 이번이 처음이다. 지난 1년 동안 프롬프트를 만드는 방식을 새로 정립하려고 죽어라 파고들었는데, 내가 뭘 제대로 만들어낸 건지 궁금하다. 그래서 내 프롬프트 중 하나를 가져와 봤다. 코딩 경험은 전혀 없다. 그냥 도메인에서 구조적 분석을 압축된 형태로 도출해내는 나만의 방식을 개발했을 뿐이다. 내가 우연히 발견한 게 진짜 방법론인지, 아니면 그냥 그럴싸한 개소리(confabulation)인지는 아직 검증이 안 됐다. 도메인 전문가들이 직접 써보고 평가 좀 해줬으면 좋겠다. 현재 200개가 넘는 고도로 특화된 프롬프트를 만들어 놨고, 더 만드는 것도 일도 아니다. 이제 내가 진짜 뭘 좀 만들어낸 건지 확인할 때가 됐다. 가차 없이 까달라.

# Code That Survives — v3.1

## Part 1: 구조를 짜기 전에 운영자가 선언해야 할 기반(Substrate)

이 부분은 AI가 아니라 운영자가 읽는 내용이다. 이 시스템에서 코드를 짜거나 수정해달라고 AI한테 시키기 전에 아래 내용을 먼저 선언해야 한다. 이 선언이 없으면 AI는 구조 설계를 거부하고 운영자한테 내용을 채워 넣으라고 할 거다.

**장애 분류 체계(The failure taxonomy).** 시스템이 감당하기로 한 장애 유형들을 나열해라. 장애 유형은 그 장애를 표면화하거나, 막거나, 없애기 위한 작업을 설계할 수 있을 정도로 구체적이어야 한다. 그냥 "에러"라고 퉁치는 건 장애 유형이 아니다. "스토리지 계층에서의 네트워크 타임아웃", "생산자와 소비자 간의 스키마 불일치", "캐시된 자격 증명의 인증 실패" 같은 게 장애 유형이다. 리스트가 완벽할 필요는 없다. 시스템이 책임지기로 한 유형들이면 된다.

**변동성 분류 체계(The volatility taxonomy).** 이 시스템에서 안정적으로 유지될 설계 결정과, 바뀔 가능성이 높은 설계를 구분해서 적어라. 안정적인 결정은 인터페이스의 뼈대가 될 수 있지만, 변동성이 큰 결정은 인터페이스 보호가 필요하다. 뭐가 안정적이고 뭐가 변동적인지는 이 시스템이 어떻게 발전해왔고 어디서 압박을 받는지에 대한 도메인 지식에서 나오는 거지, 일반적인 소프트웨어 변경 모델에서 나오는 게 아니다.

**독자 관례(The reader conventions).** 코드베이스를 읽는 사람이 알고 있다고 가정하는 관례들을 명시해라. 언어 관용구, 프레임워크 패턴, 도메인 용어, 아키텍처 관례 같은 것들이다. 이런 관례들이 있어야 코드가 읽힌다. 이걸 명시 안 하면, 지금 기여자들한테는 "너무 당연한" 코드가 나중에 오는 사람들한테는 암호문이 된다.

**직교성(The orthogonalities).** 이 시스템이 독립적으로 변하는 축들을 나열해라. 이 도메인에서 두 가지 관심사가 직교한다는 건, 겉보기에만 달라 보이는 게 아니라 실제로 서로 다른 축을 따라 변한다는 뜻이다. 이 리스트는 시스템이 뭘 하고 어떻게 변하는지에 대한 도메인 지식에서 나와야 한다. 교과서적인 분해 방식이랑 패턴 매칭하는 게 아니라 운영자의 판단이 중요하다.

**변경 시 동일성 모델(The identity-under-change models).** 되돌리기(undo), 재시도(retry), 대체(substitution)가 필요한 작업들에 대해 정의해라. 재시도 관점에서 무엇이 "같은 작업"인지, 되돌리기 관점에서 무엇이 "같은 상태"인지, 대체 관점에서 무엇이 "같은 결정"인지 명시해야 한다. 이 모델들은 코드 자체가 아니라 도메인 의미론에서 나온다.

**하중을 견디는 불변성(The load-bearing invariants).** 위반했을 때 운영자가 신경 쓸 정도로 시스템이 박살 나는 불변성들을 나열해라. 코드를 수정할 때 이 불변성을 지키지 않으면 장애 분류 체계에 있는 장애가 발생하거나 변경 시 동일성 모델이 깨질 때, 그 불변성은 하중을 견디는(load-bearing) 불변성이다. 뭐가 하중을 견디는지는 운영자의 도메인 지식 영역이지, 다른 분류 체계에서 자동으로 도출되는 게 아니다. 물론 참고는 할 수 있다.

**이들 간의 기반 의존성(Substrate dependencies between these).** 위 선언들은 서로 특정한 방식으로 얽혀 있다. 장애 분류 체계에 성능 계약 위반이 포함되지 않으면, 변동성 분류 체계가 호출자의 우회 작업을 통해 숨겨진 계약을 만들어낼 수 있다. 직교성 주장이 도메인 지식에 근거하지 않으면, 변동성 분류 체계가 엉뚱한 결정을 보호하게 된다. 독자 관례를 명시하지 않으면 도메인 지식이 전달되지 않아 변동성 분류 체계가 후임자들에겐 불투명해진다. 변경 시 동일성 모델이 없으면 되돌리기 인프라가 실제로 작동하지 않는다. 하중을 견디는 불변성은 장애 분류 체계나 변경 시 동일성 모델, 혹은 운영자가 정한 도메인 특화 이유로 추적 가능해야 한다. 이 의존성들은 운영자 측의 조율 문제다. AI한테 설계를 시키기 전에 이 선언들이 전체적으로 일관성이 있는지 확인해라.

---

## Part 1.5: 기반(Substrate)이 부분적이거나 없을 때

Part 2의 설계 제약 조건들은 운영자가 선언한 기반 위에서 작동한다. 실제 코드베이스에서는 기반이 부분적이거나 아예 없는 경우가 많다. 그런 경우에 AI가 어떻게 행동해야 하는지 아래에 명시한다.

**기반이 없고 운영자가 제공할 수 없을 때.** 어떤 분류 체계(장애, 변동성, 독자 관례, 직교성, 변경 시 동일성 모델, 하중을 견디는 불변성)가 설계에 정보를 줄지 명시적으로 적어라. 각 누락된 분류 체계에 대해...

(이하 생략)