로직을 한 번 승인하면, 그 이후로는 영원히 동일한 방식으로 실행되게 하세요.

요약(TL;DR): 반복 가능한 기술적 단계들을 프롬프트 대신 테스트 가능한 스크립트로 전환하여, 동작이 결정론적(deterministic)이고 저렴하게 유지되도록 하세요.

흔한 실수 ❌

당신은 매번 자유 형식의 프롬프팅(free-form prompting)을 통해 AI에게 동일한 다단계 작업을 반복하도록 요청합니다: API 호출, 설정 파일(config file) 파싱, 열 제한에 맞춘 텍스트 줄 바꿈 등.

매 실행마다 모델은 당신의 지침을 처음부터 다시 해석합니다. 따라서 월요일에 올바르게 실행되었던 단계가 화요일에는 어긋날 수 있고, 금요일쯤 되면 기본적으로 재즈 즉흥 연주를 하고 있을 것입니다.

더 나쁜 것은, .env 파일에 네 글자를 더 입력하는 것이 당신의 시간을 공격하는 것처럼 느껴져서 대화창에 직접 자격 증명(credential)을 붙여넣는 경우입니다. 이는 당신의 프롬프트를 의도치 않은 유출로 만듭니다.

해결되는 문제들 😔

• 모델이 고정된 로직을 실행하는 대신 자유 형식의 프롬프트를 재해석하기 때문에, 동일한 지침이 실행할 때마다 다른 출력을 생성합니다.

• 반복되는 모든 단계는 AI가 이미 알고 있는 규칙을 다시 설명하는 데 토큰을 소모하며, 이는 실제 컨텍스트를 위한 여유 공간을 줄입니다.

• 프롬프트에 입력된 비밀 정보는 대화 기록과 로그에 남게 되어, 결코 .env 파일을 벗어나서는 안 될 코드 내 비밀 정보로 변합니다.

• 수동 API 호출은 재시도(retries)와 백오프(backoff)를 건너뛰므로, 첫 번째 429 응답이 잠시 기다려 달라고 요청하는 대신 작업의 수명을 끝내버립니다.

• 자유 형식의 프롬프팅 내부에서 실패가 발생하면, 단 한 줄을 가리키는 스택 트레이스(stack trace)를 읽는 대신 긴 대화 내용을 다시 읽어야 합니다.

실행 방법 🛠️

1. 항상 동일한 입력을 받고 항상 동일한 출력을 생성하는 기술 단계(skill steps)를 나열하세요.

2. 해당 단계에 대해 또 다른 지침 문단을 작성하는 대신, 테스트 프레임워크(test framework)가 있는 언어를 사용하여 실제 스크립트(script)를 작성하세요.

3. 스크립트에 필요한 모든 자격 증명(credential)을 코드 곳곳에 설정값들을 흩뿌리는 대신 .env 파일로 옮기고, 런타임(runtime)에 이를 로드하세요.

4. 스크립트가 수행하는 모든 외부 API 호출에 대해 재시도(retries), 타임아웃(timeouts), 그리고 속도 제한 백오프(rate limit backoff)를 추가하세요.

5. 스크립트를 단위 테스트(unit tests)로 커버하여, 회귀(regression) 발생 시 사용자에게 배포되는 대신 테스트가 실패하도록 만드세요.

6. 다른 풀 리퀘스트(pull request)와 마찬가지로 스크립트를 검토하고, 이후 모든 실행에서 기술(skill)이 동일한 방식으로 이를 호출할 수 있도록 하세요.

7. 모델은 어떤 스크립트를 실행할지 결정하는 것과 같이, 스크립트가 수행할 수 없는 판단(judgment calls)에 대해서만 책임을 지도록 유지하세요.

8. 이미 프로덕션(production)에서 실행 중인 기술을 모델에게 감사(audit)하도록 요청하세요. 이때 동일한 사이트에 대한 여러 번의 WebFetch 호출처럼 여전히 자유 형식의 동작(free-form actions)을 통해 수행되는 단계가 있는지 확인하고, 직접적인 API 호출을 통해 스크립트로 대체할 수 있는 부분이 어디인지 지적하도록 하세요.

이점 🎯

1. 결정론 (Determinism): 스크립트는 동일한 입력에 대해 매번 동일한 출력을 반환하므로, 눈에 보이는 이유 없이 변하는 동작을 쫓아다닐 필요가 없습니다.

2. 속도 (Speed): 실제로는 판단이 전혀 필요하지 않은 로직을 위해 모델의 왕복 (round trip)을 기다릴 필요 없이, 스크립트는 밀리초 단위로 실행됩니다.

3. 낮은 토큰 비용 (Lower token cost): 코드 내에 존재하는 로직은 실행될 때마다 컨텍스트 윈도우 (context window) 내에서 다시 설명될 필요가 없습니다.

4. 테스트 가능성 (Testability): 배포 전 다른 모든 변경 사항을 검토하는 것과 동일한 방식으로 스크립트에 유닛 테스트 (unit tests)를 적용할 수 있습니다.

5. 오류 감소 (Fewer errors): 검토된 스크립트는 모델이 압박 속에서 안전하지 않은 단계를 즉흥적으로 수행할 가능성을 제거합니다.

6. 일회성 승인 (One-time approval): 스크립트가 검토를 통과하면, 이후의 모든 실행은 프롬프트로부터 다시 결정하는 대신 정확히 동일한 로직을 재사용합니다.

7. 대화 내용에서 비밀 정보 분리 (Secrets stay out of the conversation): 런타임 시 .env에서 읽어온 자격 증명은 대화 기록 내의 코드 내 비밀 정보 (secrets in code)로 변하지 않습니다.

컨텍스트 (Context) 🧠

기술 (skill)이란 프롬프트를 입력하기 전에 설치하는 하네스 (harness)입니다.

스크립트는 호출할 때마다 모델이 새로 만들어내기를 원치 않는 그 하네스의 일부입니다.

이를 동일한 작업을 위해 MCP 서버를 연결하는 것과 비교해 보세요.

MCP 서버는 라이브 프로세스입니다. 자체적인 인증, 자체적인 프로토콜 변환, 자체적인 연결 관리가 필요하며, 작업 필요 여부와 상관없이 계속 실행됩니다.

축하합니다, API 호출 한 번 정도의 인사를 하기 위해 마이크로서비스 (microservice)를 구축하셨군요.

스크립트에는 그런 것이 전혀 없습니다.

기술이 스크립트를 직접 호출하고, 실행된 후 종료되며, 세션 사이에 패치하거나 모니터링하거나 계속 유지해야 할 서버가 남지 않습니다.

데이터베이스 세션이나 장시간 실행되는 구독(subscription)과 같이 실제로 실시간 연결이 필요한 상태를 위해서만 MCP를 예약해 두세요.

단일 API 호출이나 포맷팅 규칙의 경우, 모듈형 기술 (modular skill)로 감싸진 스크립트가 보안을 유지해야 할 공격 표면(surface area)을 줄이면서 동일한 작업을 수행하고, 주의 깊게 다루기 (treat carefully)에도 용이합니다.

이는 또한 훅(hooks)을 통해 표준을 강제하는 방법 (forcing your standards through hooks)과도 직접적으로 연결됩니다. 스크립트는 이미 연결된 훅이므로, 모델이 기분이 안 좋다고 해서 이를 건너뛸 (skip it on a bad day) 수 없습니다.

프롬프트 참조 (Prompt Reference) 📝

나쁜 프롬프트 (Bad Prompt) 🚫

/buy-lunar-moon 기술을 생성하세요.

이 기술은 결제 API를 호출하고 인보이스를 표시해야 합니다
...

좋은 프롬프트 (Good prompt) 👉

/buy-lunar-moon 기술을 생성하세요.

스크립트를 사용하여 API와 상호작용하세요.
...

고려 사항 (Considerations) ⚠️

스크립트는 판단이 전혀 필요 없는 단계만을 대체합니다.

어떤 스크립트를 호출할지 선택하고 모호한 입력을 해석하는 권한은 모델에게 맡기고, 스크립트는 기계적인 부분만 처리하도록 하세요.

스크립트도 여전히 유지보수가 필요합니다.

API가 변경될 때 누군가는 이를 업데이트해야 하므로, 소유자와 변경 이력(changelog)을 가진 다른 프로덕션 코드와 마찬가지로 취급하세요.

속도 제한(Rate limit) 처리는 모델이 기꺼이 건너뛰려 할 복잡성을 추가합니다.

지수 백오프(backoff)와 재시도(retries)를 올바르게 구축할 시간을 충분히 할애하세요. 429 오류(Too Many Requests) 발생 시 조용히 실패하는 스크립트는 소프트웨어 버전의 '읽씹(ghosting)'과 같으며, 다만 그 대상이 당신의 인보이스라는 점이 다를 뿐입니다.

모든 기술 단계가 스크립트가 될 필요는 없습니다.

일회성 작업이나 비정형 입력에 대한 추론이 진정으로 필요한 단계는 모델 자체가 처리하는 것이 더 낫습니다.

이 규칙을 하네스(harness) 자체에 밀어 넣으세요.

당장 일회성 명령이 얼마나 편리하게 느껴지든 간에, 임의의 즉석 스크립트를 실행하는 PowerShell 또는 Bash 호출은 기본적으로 거부하세요.

대신 기술 (skills)이 스크립트를 작성하게 하고, 이를 인간 참여형 (human-in-the-loop) 감사에 제출한 뒤, 승인되면 상시 권한 (standing authorization)을 부여하세요. 이렇게 하면 매번 다시 허가를 요청하는 대신, 향후 모든 실행에서 검토된 동일한 스크립트를 재사용하게 됩니다.

무해해 보이는 명령이라도 여전히 임의 실행 (arbitrary execution)을 몰래 수행할 수 있습니다.

find . -name "*.py" -exec python {} \;는 파일 검색처럼 보이지만, 찾은 모든 일치 항목을 실행합니다. 따라서 하네스 (harness)는 이 명령이 find로 시작한다고 해서 그냥 통과시켜서는 안 되며, 가공되지 않은 스크립트와 동일한 기준으로 거부해야 합니다.

유형 📝

[X] 반자동 (Semi-Automatic)

제한 사항 ⚠️

스크립트를 작성하고 테스트하는 데는 빠른 프롬프트 (prompt)가 필요로 하지 않는 초기 엔지니어링 시간이 소요됩니다.

스크립트는 그것이 구축된 정확한 사례만 다루므로, 예상치 못한 입력이 들어오면 여전히 인간이나 모델의 개입이 필요합니다.

태그 🏷️

• 안전 (Safety)

레벨 🔋

[X] 중급 (Intermediate)

관련 팁 🔗

AI 코딩 팁 004 - 모듈형 기술 사용하기 (Use Modular Skills)

Maxi Contieri

Maxi Contieri

팔로우

1월 27일

AI 코딩 팁 004 - 모듈형 기술 사용하기 (Use Modular Skills)

#ai #webdev #programming #beginners

3개 반응

읽기 시간 4분

AI 코딩 팁 006 - 커밋 전 모든 라인 검토하기 (Review Every Line Before Commit)

Maxi Contieri

Maxi Contieri

팔로우

2월 13일

AI 코딩 팁 006 - 커밋 전 모든 라인 검토하기 (Review Every Line Before Commit)

#ai #programming #development #softwaredevelopment

1 댓글

7분 분량

AI 코딩 팁 007 - 악의적인 기술 피하기

Maxi Contieri

Maxi Contieri

팔로우

2월 17일

AI 코딩 팁 007 - 악의적인 기술 피하기

#ai #programming #webdev #beginners

3 반응

4분 분량

AI 코딩 팁 009 - 컨텍스트 압축하기

Maxi Contieri

Maxi Contieri

팔로우

3월 3일