라운드 2 · 축 4·5 손익분기판정 · 채택
부호가 뒤집히는 지점
라운드 1은 “바뀐 데만 쓰기”가 더 길다며 기각했습니다. 이번엔 고칠 곳 개수도 흩어진 정도도 그대로 두고 파일 길이만 바꿨습니다. 부호가 뒤집혔습니다.
시킨 일 — 120줄짜리 설정 파일에서 6곳 고치기. 고칠 내용은 라운드 1의 30줄 파일과 의미상 완전히 동일하고, 덩어리 수도 3개로 같습니다. 다른 것은 파일 길이뿐입니다.
입력 — 모든 조건에 똑같이 준 것
120줄 파일 전문과 고칠 곳 6군데를 세 조건에 똑같이 줬습니다. 조건 간 공통부가 글자 단위로 같다는 것은 생성기가 해시로 확인했습니다.
## 변경 요청 (6곳) 1. `replicas` 를 3에서 6으로 변경 2. `env` 를 `staging` 에서 `production` 으로 변경 3. `logging.level` 을 `debug` 에서 `info` 로 변경 4. `logging.format` 을 `text` 에서 `json` 으로 변경 5. `autoscale.enabled` 를 `false` 에서 `true` 로 변경 6. `database.ssl` 을 `false` 에서 `true` 로 변경 그 외의 줄은 변경하지 않는다.
갈라지는 문장, 그리고 나온 답
전체를 저장한다. 120줄 전부 쓴다. 생략·축약을 쓰지 않는다.”service: payments-api namespace: payments owner: platform-team contact: platform@example.com description: Handles card and wallet payment authorization. metadata: tier: critical cost_center: CC-4417
unified diff로 저장한다. git apply -p1로 적용 가능해야 한다.”@@ -10,11 +10,11 @@ deployment: strategy: RollingUpdate max_surge: 1 - replicas: 3 + replicas: 6 max_unavailable: 0 min_ready_seconds: 15 progress_deadline_seconds: 600 -env: staging +env: production
1줄씩으로 한다.”@@ -12,3 +12,3 @@ max_surge: 1 - replicas: 3 + replicas: 6 max_unavailable: 0 @@ -16,3 +16,3 @@ progress_deadline_seconds: 600 -env: staging +env: production image:
그래서 얼마나 아꼈나
산출물 문자 수 · 120줄 파일 · 조건당 2회 시행
세 조건 모두 고친 결과 파일이 정답과 한 글자도 다르지 않았습니다. 12시행 전부 품질 게이트 통과, 무효 0건, 표준 git apply -p1 적용 12/12 성공.
⚠ 같은 수정을 30줄 파일에 하면 정반대가 됩니다
고친 곳 개수도, 흩어진 정도도, 지시문도 전부 같습니다. 파일 길이만 30줄로 줄였더니 결과가 뒤집혔습니다.
위치 표지가 원본 대부분을 다시 실어 나르는데, 원본이 애초에 짧으니 아낄 게 없기 때문입니다.
산출물 문자 수 · 30줄 파일 · 조건당 2회 시행
이 30줄 결과는 라운드 1과 산출물 해시가 같습니다 — 8개월 전 기각이 그대로 재현됐습니다.
그래서 라운드 1의 기각은 뒤집힌 게 아니라 좁혀졌습니다
라운드 1이 얻은 것은 “diff가 나쁘다”가 아니라 “30줄에서는 졌다”였습니다. 파일이 길어지면 같은 diff가 −66.7%로 이깁니다.
그래서 기법은 “diff를 써라”가 아니라 “파일이 경계선보다 길 때 diff를 써라”로 확정됐습니다. 적용 조건이 없는 기법은 라운드 1 결과와 정면으로 모순됩니다.
경계선은 표지 3줄 기준 약 38~40줄, 표지 1줄 기준 약 26~28줄입니다. 즉 출력 형식을 바꾸면 경계선 자체가 움직입니다.
표지를 줄이면 왜 무한정 줄지 않나
표지를 3줄에서 1줄로 줄이면 붙어 있던 덩어리가 갈라집니다. 120줄 파일에서 덩어리가 3개에서 5개로 늘었고, 덩어리마다 @@ 머리글이 하나씩 더 붙습니다.
이게 수확 체감의 정체입니다. 라운드 1에서 표지를 0줄까지 밀었을 때는 표준 git apply가 아예 거부했습니다 — 더 짧지만 쓸 수 없는 결과였습니다.
다만 이번에 표지 1줄에서는 적용 실패가 0건이었습니다. 그래서 “짧게 만들수록 적용이 위험해진다”는 라운드 1의 일반화는 표지 0줄에만 해당하는 문턱으로 정정했습니다.
판정 못 한 게 하나 있습니다 — 제 사전등록 기준이 틀렸습니다
“오버헤드를 줄이면 적용 실패가 오른다”는 가설의 채택 조건을 “적용 실패 또는 덩어리 분열이 더 많다”로, 기각 조건을 “적용 실패가 더 적거나 같다”로 써 뒀습니다.
이번 데이터에서 표지 1줄은 덩어리가 3→5로 갈렸고(채택 조건 충족), 적용 실패는 양쪽 다 0건이었습니다(기각 조건도 충족). 두 조건이 동시에 참이 됐습니다.
결과를 보고 둘 중 하나를 골라 읽으면 사전등록이 무의미해집니다. 그래서 판정 불가로 두고, 기준을 다시 써서 다음 라운드에 재검증합니다.
⚠ 표지 1줄 지시를 요청마다 붙이면 손해입니다
“표지는 1줄씩” 지시는 프롬프트를 147자 늘립니다. 30줄 파일에서 아낀 건 34자뿐이라, 요청마다 이 지시를 실으면 글자 기준으로 순손실입니다.
쓰려면 시스템 프롬프트나 프로젝트 규약에 한 번만 넣으세요. 그러면 지시 비용은 한 번이고 절감은 요청마다 쌓입니다.
그래서 언제 이렇게 시키나
| 파일 길이 | 이렇게 시킨다 | 아끼는 양 |
|---|---|---|
| 40줄 초과 | “unified diff로, 표지 줄은 위아래 1줄씩” | −78.4% (120줄 기준) |
| 28~40줄 | “unified diff로” — 표지 1줄 지시가 있으면 이득 | −6.8% ~ −67%, 파일 길이에 따라 |
| 28줄 미만 | 그냥 파일 전체를 다시 쓰게 둔다 | diff를 쓰면 역효과 |
| 변경이 파일 전체에 흩어져 있음 | 덩어리 수가 늘면 경계선이 올라갑니다. 다시 계산하세요 | 판단 필요 |
댓글 0
불러오는 중…