▲

과도한 편집은 모델이 필요한 범위를 넘어서 코드를 수정하는 현상

 (nrehiew.github.io)
2P by GN⁺ 4시간전 | ★ favorite | 댓글 1개
  • 최소 수정만으로 해결되는 버그에서도 함수 전체 재작성, 보조 로직 추가, 시그니처 변경까지 일어나며 거대한 diff가 생기기 쉬움
  • 기존 구조를 유지하는 brown-field 작업에서는 테스트 통과만으로 충분하지 않고, 얼마나 적게 바꿨는지도 함께 봐야 검토 가능성과 변경 안전성이 유지됨
  • 프로그램적으로 손상시킨 400개 BigCodeBench 문제를 바탕으로 토큰 단위 Levenshtein, 상대 패치 점수, Added Cognitive Complexity로 과도한 편집을 정량화함
  • 최신 코딩 모델 전반에서 과도한 재작성 경향이 확인됐고, Claude Opus 4.6은 정확성과 최소 수정성 조합이 강했으며 GPT-5.4는 상대적으로 과도한 편집이 두드러짐
  • 원본 보존을 명시한 프롬프트는 특히 추론 모델의 diff를 줄였고, 학습 방식 중에서는 RL이 최소 편집 행동을 익히면서 일반 코딩 성능 저하 없이 가장 균형 잡힌 결과를 냄

Over-Editing 문제

  • Over-Editing은 버그를 고치는 데 필요한 최소 수정 범위를 넘어 코드 구조까지 크게 바꾸는 현상을 가리킴
    • 단순한 range(len(x) - 1)를 range(len(x))로 바꾸면 되는 오프바이원 버그에서도, 모델이 함수 전체를 다시 쓰고 보조 함수나 검증 로직을 추가하는 식의 과도한 변경이 발생함
    • 예시에서는 GPT-5.4가 None 검사, np.asarray(dtype=float) 변환, finite-value 마스킹, 배열 크기 검증, curve_fit 호출 시그니처 변경, 플로팅 로직 교체까지 수행했고, 테스트는 통과하지만 거대한 diff가 생김
  • 기존 코드베이스를 다루는 brown-field 작업에서는 팀이 이미 이해하고 의도적으로 작성한 코드를 유지한 채 문제만 고치는 편이 중요함
    • 새로 만드는 green-field와 달리, 기존 구조를 존중하지 않는 수정은 리뷰어가 무엇이 왜 바뀌었는지 파악하기 어렵게 만듦
    • 함수 전체가 재작성되면 코드가 알아보기 어려워지고, 변경 안전성을 판단하기도 힘들어짐
  • 테스트만 통과하면 된다는 기준으로는 이 문제를 잡기 어려움
    • Over-Editing은 정확성 실패가 아니라 편집 충실도 실패라서 테스트 스위트에 잘 드러나지 않음
    • 생성 코드가 많아질수록 검토해야 할 양이 늘고, 불필요한 복잡성이 누적되면서 코드베이스 품질이 조용히 떨어질 가능성이 커짐

Over-Editing 측정 방법

  • 최소 수정의 정답이 분명한 데이터셋을 만들기 위해 BigCodeBench 문제 400개를 프로그램적으로 손상시켜 평가셋을 구성함
    • 기존 벤치마크처럼 다른 LLM으로 버그를 주입하지 않고, <를 <=로 바꾸거나 +를 -로, True를 False로 바꾸는 식으로 세밀하게 통제함
    • 각 손상 샘플은 문법적으로 유효하며 대응 테스트 케이스를 깨뜨리도록 검증했고, 정답 수정은 손상을 되돌리는 것 하나뿐이어서 최소 수정이 되도록 설계됨
  • 이 구성 덕분에 모델이 버그를 고쳤는지뿐 아니라, 고치는 과정에서 얼마나 더 바꿨는지도 함께 평가할 수 있음
    • 기준 정답과 모델 출력을 모두 손상된 입력과 비교해 상대적 패치 크기를 계산함
    • 정답 복원 외 추가 변경이 많을수록 점수가 나빠지도록 구성됨
  • 관련 코드는 GitHub 저장소에서 제공됨

측정 지표

  • 토큰 단위 Levenshtein Distance

    • 일반적인 문자 단위 Levenshtein 대신 Python 토큰 단위 변형을 사용함
    • 코드를 Python tokenizer로 def, add, (, a, ,, b, ) 같은 원자적 문법 단위로 나눈 뒤, 이 토큰 시퀀스 위에서 거리를 계산함
    • def add(a, b):를 def someotherfunctionname(a, b):로 바꾸는 경우 문자 단위 거리는 19지만, 토큰 단위 거리는 식별자 하나가 바뀐 것으로 간주되어 1이 됨
    • 함수 길이가 달라도 비교할 수 있도록 총 토큰 수로 정규화함

  • 상대 패치 점수

    • 모델 출력과 정답을 직접 비교하지 않고, 둘 다 손상된 입력을 기준으로 비교함
    • 손상된 해답에서 원래 해답으로 되돌리는 편집이 진짜 최소 수정이고, 모델이 만든 편집이 여기에 얼마나 가까운지 측정함
    • 값이 0에 가까울수록 모델 패치가 실제 최소 수정과 유사함

  • Added Cognitive Complexity

    • Cyclomatic Complexity보다 읽기 난이도를 더 잘 반영하는 Cognitive Complexity를 함께 사용함
    • 중첩, 재귀, 복합 논리 연산자, 비직관적 제어 흐름에 페널티를 주며, if, 루프, try/except처럼 독자가 상태를 더 많이 추적해야 하는 구조가 복잡도를 높임
    • 예시의 중첩 루프와 조건문 코드는 Cognitive Complexity가 6이 됨
    • 이번 손상은 값만 바꾸고 구조는 건드리지 않으므로, 올바른 수정은 Added Cognitive Complexity가 항상 0이어야 함
    • 모델 출력에서 복잡도가 증가했다면 요청받지 않은 코드가 추가된 것이고, 0보다 작은 값도 불필요한 단순화라 바람직하지 않다고 봄

모델들은 실제로 Over-Edit하는가

  • 최신 frontier 모델에서도 Over-Editing이 확인됨
    • 추론 모델과 비추론 모델 모두 Pass@1과 최소 수정성 사이에 차이가 존재함
    • 정확히 고치는 능력만으로는 충실한 편집 여부를 판단하기 어려움
  • 추론 모델 비교에서는 Claude Opus 4.6이 가장 강한 조합을 보임
    • Pass@1이 0.912로 가장 높고, 정규화 Levenshtein 0.060, Added Cognitive Complexity 0.200으로 diff도 가장 작음
    • Gemini 3.1 Pro Preview도 비슷한 영역에 위치하고, 오픈 웨이트 모델 중에서는 GLM 5가 상대적으로 보수적으로 편집함
  • GPT-5.4는 평가된 모델 중 Over-Editing이 가장 심한 축에 속함
    • 추론 모드에서 Levenshtein 0.395, Added Cognitive Complexity 2.313이고, 비추론 모드에서도 각각 0.327, 1.563으로 높게 나타남
    • Pass@1도 0.723, 0.770으로 낮은 편이라 정확성과 최소 수정성 모두 약한 결과를 보임
  • 비추론 모델에서는 Qwen 3.6 Plus가 Pass@1 0.870으로 가장 높고, GLM 5가 Added Cognitive Complexity 0.235로 가장 낮음
    • Claude Opus 4.6 비추론 모델도 Levenshtein 0.079, Added Cognitive Complexity 0.313으로 매우 작은 변경 폭을 유지함

프롬프트로 개선되는가

  • 프롬프트에 “IMPORTANT: Try to preserve the original code and the logic of the original code as much as possible”를 추가했을 때 모든 모델의 Levenshtein Distance가 감소함
    • DeepSeek R1/v3를 제외하면 Pass@1도 함께 개선됨
    • 최소 수정 제약이 가능한 수정 공간을 좁혀 더 정확하고 표적화된 변경으로 유도하는 해석이 가능함
  • 이 효과는 특히 추론 모델에서 더 크게 나타남
    • 명시적 지시를 더 잘 따르는 특성 때문에, 편집 최소화 요구가 diff 축소로 강하게 이어짐
    • 기본 상태에서는 과하게 손대더라도, 지시가 주어지면 더 충실한 수정으로 이동할 수 있음을 보여줌

추론은 과도한 재작성으로 이어지는가

  • 같은 모델 계열의 추론형과 비추론형을 짝지어, 둘 다 정답을 맞힌 샘플만 대상으로 Levenshtein Distance를 비교함
    • 실패 샘플이 많으면 Over-Editing 기회 자체가 줄어드는 편향이 생기므로, 정확성을 통제한 뒤 편집 스타일만 분리해 본 것임
  • 일반 프롬프트 설정에서는 대부분의 짝에서 추론 모델이 더 많이 재작성함
    • DeepSeek V3, GPT-5, GPT-5.4, Gemini 3.1 Pro Preview, Qwen 3.6 Plus, Kimi 2.5는 모두 추론 바가 더 높게 나타남
    • 확장된 추론이 최소 수정 대신 “더 나은 구현”으로 향하면서 불필요한 리팩터링을 낳는 경향이 드러남
    • 예외는 Claude Opus 4.6으로, 추론형이 비추론형보다 훨씬 덜 수정함
  • 명시적으로 원본 보존을 지시하면 그림이 크게 달라짐
    • 추론 모델은 거의 모든 짝에서 비추론형과 같거나 더 낮은 Levenshtein Distance를 보임
    • Claude Opus 4.6 추론형은 이 설정에서 전체 모델 중 가장 낮은 Levenshtein을 기록함
    • GPT-5와 GPT-5.4도 추론형 점수가 크게 떨어지지만, GPT-5.4는 비추론형이 여전히 근소하게 앞섬
  • 기본 동작으로는 추론 모델이 Over-Editing하기 쉽지만, 같은 추론 능력이 제약을 더 잘 따르게도 만듦
    • 일반 설정과 명시 설정의 차이가 추론 모델에서 일관되게 더 크게 나타남
    • 따라서 Over-Editing은 근본적 한계라기보다 기본 행동에 가깝고, 제약을 통해 뒤집을 수 있음

학습으로 충실한 편집자를 만들 수 있는가

  • 기본 모델로 Qwen3 4B 2507 Instruct를 사용하고, 0-shot과 8-shot에 원본 보존 지시를 넣은 구성을 베이스라인으로 삼음
    • 다른 학습 방식들은 평가 시 명시적 원본 보존 지시 없이 일반 설정으로 테스트함

  • 실험 구성

    • DeepCoder 문제를 같은 방식으로 손상시켜 합성 데이터셋을 만듦
    • 여기에 더해 기본 Qwen3 4B 2507 Instruct가 각 문제에 대해 8개 completion을 생성하게 하고, 기능적으로 맞는 샘플만 남긴 뒤 Levenshtein Distance로 순위를 매겨 self-distillation 데이터셋도 구성함
    • 학습은 Context Distillation과 비슷하게, 평가 때는 명시 지시 없이 최소 편집 행동을 하도록 맞춤

  • 학습 방법

    • SFT: 프로그램적으로 만든 데이터셋으로 직접 지도 미세조정함
    • rSFT: self-distillation 데이터셋에서 샘플마다 Levenshtein Distance가 가장 낮은 3개 completion만 골라 학습함
    • DPO: 샘플마다 Levenshtein Distance가 가장 높은 completion과 가장 낮은 completion 사이에서 선호 최적화를 수행함
    • RL: 기능적 정확성과 Levenshtein 기반 최소 편집 보상을 합친 강화학습을 적용함
      • 모든 테스트를 통과하면 r = r_edit + 0.1
      • 통과하지 못하면 r = -0.2
      • r_edit는 정규화 Levenshtein 기반 보상으로 계산됨

같은 손상 유형에서는 어떻게 나왔는가

  • 학습셋과 테스트셋의 손상 유형이 같은 in-domain 설정에서는 SFT가 거의 완벽에 가까운 결과를 냄
    • Baseline 0-shot은 Pass@1 0.735, Norm. Levenshtein 0.169, Added CC 0.731
    • Baseline 8-shot은 Pass@1 0.775, Norm. Levenshtein 0.115, Added CC 0.479
    • SFT는 Pass@1 0.932, Norm. Levenshtein 0.002, Added CC 0.000으로 세 지표 모두 최고를 기록함
    • rSFT는 0.782 / 0.100 / 0.435, DPO는 0.752 / 0.021 / 0.113, RL은 0.802 / 0.046 / 0.112를 기록함
  • 이 결과가 지나치게 좋아 보여, 특정 손상 유형의 역변환만 암기했을 가능성을 점검하게 됨
    • 모델이 일반적인 최소 편집 행동을 배운 것이 아니라, 정해진 손상 패턴만 뒤집도록 학습했을 수 있다고 봄
    • 이를 확인하려고 학습 데이터와 평가 데이터의 손상 유형을 완전히 다르게 다시 구성함

다른 손상 유형에도 일반화되는가

  • 학습셋과 테스트셋의 손상 유형이 다른 out-of-domain 설정에서는 SFT가 크게 무너짐
    • SFT의 Pass@1은 0.458까지 떨어지고, 모델이 실제로 버그를 고치지 못한 채 특정한 최소 변경만 시도하는 상태가 됨
    • Norm. Levenshtein은 -0.008, Added CC는 0.006으로 매우 낮지만, 정답 수정 능력이 붕괴함
  • rSFT와 DPO는 8-shot 베이스라인보다 소폭 나아지지만 개선 폭은 작음
    • rSFT는 0.780 / 0.107 / 0.501 / LiveCodeBench -0.069
    • DPO는 Pass@1 0.787 / 0.092 / 0.348 / LiveCodeBench -0.046
    • 기본 모델이 스스로 만든 추적 데이터를 이용한 학습만으로도 어느 정도 일반화는 가능함
  • RL만이 세 지표 전반에서 깔끔하게 일반화함
    • RL은 Pass@1 0.782, Norm. Levenshtein 0.050, Added CC 0.185, LiveCodeBench Change +0.006을 기록함
    • 두 베이스라인보다 세 지표가 모두 좋아지고, 일반 코딩 성능도 떨어지지 않음
    • Levenshtein과 Added Cognitive Complexity 개선 폭이 Pass@1보다 더 큰 점은, 단순한 손상 역변환 암기가 아니라 최소 편집 행동 자체를 학습했음을 뒷받침함

Catastrophic Forgetting

  • 최소 편집을 위해 미세조정했을 때 일반 코딩 능력이 떨어지는지도 LiveCodeBench v6로 확인함
    • 목표는 학습 후에도 원래 pretrained 모델과 비슷한 수준을 유지하는 것임
  • SFT는 일반 능력 저하가 매우 큼
    • LiveCodeBench에서 43% 성능 저하가 나타났고, 기본적인 버그 식별과 수정 능력도 유지하지 못함
  • rSFT와 DPO도 소폭 하락함
    • 원래 모델이 생성한 샘플로 학습했어도, 작업 특성상 일정 수준의 Catastrophic Forgetting이 남아 있음
  • RL은 성능 저하 없이 새 행동을 학습함
  • 분포 관점에서는 프로그램적으로 만든 데이터셋과 원래 모델 분포의 차이가 클수록 Forgetting이 커지는 해석도 가능함
    • SFT는 원래 분포와 많이 다른 데이터에 강하게 맞춰지면서 모델 분포가 크게 바뀜
    • rSFT와 DPO는 self-distilled 데이터가 원래 분포와 더 가깝기 때문에 변화가 덜 거칠게 일어남
    • Catastrophic Forgetting의 정도는 원래 분포와 작업 학습 데이터 분포 차이에 비례할 가능성이 큼

추가 실험

  • RL with LoRA: 전체 미세조정이 필요한가

    • 이 작업은 새 지식을 넣기보다 기존 코드 수정 능력의 스타일 조정에 가까워 LoRA로도 충분할지 점검함
    • rank 1은 Pass@1 0.738, Norm. Levenshtein 0.166, Added CC 0.676, LiveCodeBench Δ -0.022
    • rank 8은 0.775 / 0.112 / 0.426 / -0.022
    • rank 16은 Pass@1 0.805 / 0.087 / 0.328 / -0.005
    • rank 32는 0.795 / 0.065 / 0.235 / -0.011
    • rank 64는 0.797 / 0.051 / 0.160 / +0.001
    • Full RL 최고 모델은 0.782 / 0.050 / 0.185 / +0.006
    • rank 64 LoRA는 Levenshtein에서 Full RL에 거의 근접하고 Added CC에서는 더 좋게 나옴
    • rank가 커질수록 Levenshtein과 Added CC가 1에서 64까지 단조롭게 감소함
    • 큰 개선은 초반에 집중되어 rank 1→16에서 Levenshtein이 0.166→0.087로 크게 줄고, 16→64는 0.087→0.051로 점진적으로 좁혀짐
    • rank 1과 8은 정확성과 최소 편집성 사이의 절충이 나타나며, 두 보상 함수를 함께 학습할 용량이 부족해 더 높은 보상인 편집 최소화 쪽으로 치우쳤을 가능성이 있음
    • 기존 능력이 이미 있는 작업의 스타일 수준 행동 변화에는 소수의 추가 파라미터로도 충분하고, 일정 지점 이후 추가 용량의 수익은 줄어듦

  • 보상 해킹 메모

    • 초기 보상 함수에는 성공 실행이 하나도 없는 rollout에 0점을 주는 버그가 있었음
    • Levenshtein을 “클수록 좋음” 형태로 만들기 위해 부호를 바꾼 상태라, 이 0점이 오히려 성공 실행보다 더 높은 보상이 되는 상황이 생김
    • 그럼에도 Full RL은 작업을 학습했고, LoRA에서만 기능적으로 올바른 코드를 아예 출력하지 않는 식의 reward hacking이 나타나 환경 점검으로 이어짐
    • 보상 함수를 수정한 뒤 Full RL 결과는 소폭만 더 좋아짐

  • 더 큰 모델에도 확장되는가

    • 같은 out-of-domain RL 레시피를 Qwen3 14B에 적용함
    • Baseline 14B는 Pass@1 0.770, Norm. Levenshtein 0.136, Added CC 0.315
    • RL 적용 후에는 Pass@1 0.833, Norm. Levenshtein 0.059, Added CC 0.165, LiveCodeBench Δ +0.011로 전반 개선이 나타남
    • 파라미터 수가 커져도 Pass@1 상승, Levenshtein 감소, Added Cognitive Complexity 감소, Catastrophic Forgetting 부재가 함께 유지됨
    • 최소 코드 편집용 RL 레시피가 여러 규모의 모델로 확장될 가능성을 뒷받침함

최종 정리

  • Over-Editing은 널리 퍼져 있고 측정 가능한 문제로 나타남
    • frontier 코딩 모델 전반에서 정확히 고치는 능력과 최소한으로 고치는 능력이 별개로 드러남
    • 특히 GPT-5.4는 기본 설정에서 상대적으로 과도한 재작성 경향이 강하고, Opus 4.6은 강한 베이스라인을 보임
  • 명시적 프롬프트만으로도 충실한 편집으로 상당 부분 유도 가능함
    • 특히 추론 모델은 기본적으로 과하게 손대는 경향이 있지만, 원본 보존 지시를 주면 더 잘 따름
    • GPT-5.4도 추론 모드에서 큰 개선 폭을 보여 instruction following 능력 자체는 강하게 드러남
    • Opus 4.6의 개선 폭이 작게 보이는 것은 이미 기본 성능이 높기 때문일 수 있음
  • 학습 측면에서는 RL이 가장 균형 잡힌 해법으로 나타남
    • 더 충실한 편집 행동을 익히면서 일반 코딩 능력을 해치지 않았고, 4B와 14B Qwen3 모두에서 효과가 유지됨
    • SFT는 특정 손상 유형에는 강했지만 일반화와 일반 능력 유지에서 크게 실패함
  • 단일 함수 단위 버그 수정 평가는 SWE-Bench Pro 같은 더 agentic한 평가보다 범위가 제한적이지만, 현실적인 설정에서 Over-Editing을 정량화하기 어려웠던 문제를 다루는 출발점이 됨
    • 최소 편집 능력을 평가하고 개선하는 방향이 AI 생성 코드의 전반적 품질 향상으로 이어질 수 있음

함께 보면 좋은 글 β

▲
GN⁺ 4시간전  [-]
Hacker News 의견들

  • 내가 Claude Code를 쓰는 방식은 기대를 훨씬 넘음
    과하게 수정하면 어디가 잘못됐는지 설명하고, 그 교훈을 프로젝트별 skill 파일에 기록하게 함
    그러면 같은 실수를 거의 반복하지 않고, skill 파일이 커지면 정리·압축도 꽤 잘함
    이제 직장에서 직접 코드를 짜는 건 경제적으로 큰 의미가 없다고 느낌
    나는 교사, 아키텍트, 인프라 관리자 역할에 더 가깝고, 개발 대부분은 숙련된 Claude 세션 팀에 넘김
    물론 전부 리뷰하고 Claude도 테스트를 촘촘히 써서 함께 검토함
    요즘은 큰 프로젝트도 무리 없이 다룸
    이걸 Anthropic 광고처럼 말하고 싶은 건 아니고, 도대체 내가 뭘 하고 있길래 이렇게 유난히 잘 먹히는지가 궁금함
    그리고 토큰도 이제 거의 부족하지 않음
    거의 Opus 모델만 쓰는데 토큰 효율이 좋고, 지난주엔 Claude 도움으로 의미 있는 커밋을 150개 넘게 올렸는데도 주간 할당량의 3분의 1만 썼음
    Claude 전에는 주당 25~30커밋 정도가 한계였음

    • 나도 비슷함
      어제 통계를 봤는데 회사 코드의 97% 를 이제 Cursor AI가 쓰고 있어서 놀랐음
      주로 cloud agent로 돌리는데, 실시간으로 지켜보면 산만해서 그렇게 함
      내 방식은 아주 단순함. 그냥 말로 명확하게 시키기임
      사람들이 이걸 너무 복잡하게 만듦
      .md 파일 공유하고 orchestration이니 prompt hack이니 파고드는 건, vim 단축키나 IDE 스킨에 과몰입하는 것만큼만 흥미로워 보임
      원하는 걸 분명히 말하고 좋은 피드백만 주면 됨
    • 나도 같음. 노동 절감 장치로는 놀랄 만큼 좋음
      동료가 짠 코드라고 해도 거리낌 없이 받을 수준의 결과를 내놓음
      물론 줄 단위로 다 읽고 수정은 하지만, 그 수정도 원래 코드 리뷰에서 하던 수준과 비슷함
      생산성을 수치로 재진 않지만, 몇 년째 미뤄둔 작업들을 이제 손대게 되는 걸 보면 체감됨
      예를 들어 markdown 100개를 json 5개로 바꾸고 그걸 읽는 코드까지 갱신하는 식의 지루한 작업에 특히 강함
    • 사람들이 요즘 Claude Code가 쓸 수 없을 정도가 됐다고 하면 믿기는 하지만, 나는 잘 이해가 안 감
      결함도 많고 버그도 많은 소프트웨어인데도 실제론 매우 효과적임
      AI에서 가장 이상한 점 중 하나는 사람마다 체감이 정말 극단적으로 다르다는 것임
    • 코드가 다른 사람 리뷰를 받는지, 예전엔 코드 리뷰가 힘들었는지, 동료들이 말하는 code quality를 얼마나 중요하게 보는지에 따라 체감이 꽤 달라질 듯함
      운영성 업무가 많은지, 오래 가는 제품 코드를 다루는지도 중요함
      내 가설은 이 도구가 단순한 패턴 위에서는 잘 작동하고 복잡한 일도 처리하긴 하지만, 새 패턴을 발명하는 일은 영 별로라는 것임
      감독 없이 두면 금방 위험한 새 패턴을 지어내서 망가뜨리기도 함
      그래서 Claude가 준 걸 통째로 다시 쓰는 경우가 꽤 있음
      가끔은 로봇과 속도 경쟁을 해서 내가 더 빨리 끝내기도 함
      내가 뭘 원하는지 이미 알고 있으니 유리한 면도 있지만, 여기서 드는 잔손질 비용이 과소평가된다고 느낌
      futzing fraction도 그렇고, the peril of laziness lost처럼 기계가 너무 과하게 애쓰는 방식 자체가 거슬릴 때가 있음
      왜 한 가지만 하면 되는데 세 가지를 하려 드는지 모르겠음
      고쳐주면 다시 맞춘다고 해도, 동료랑 일할 때도 이미 겪는 "A, B, C 하지 말고 A만 하라"는 흐름을 또 반복해야 해서 짜증남
      테스트 생성도 미묘한데, 방향을 잡아준 테스트 작성은 잘하지만 창의성을 허용하면 foo + bar == bar + foo 같은 쓸모없는 테스트를 너무 많이 만듦
      테스트 유용성을 계속 의심하며 봐야 피드백 루프가 건강해짐
      요즘은 테스트 자체보다 필요한 import를 한 번에 끌어오는 용도로 더 쓸모 있을 때도 많음
      이런 기계들이 일을 대신한다면 평균 코드 품질은 올라갈 수도 있어야 함
      하지만 많은 사람이 "대체로 평균 근처는 친다"는 식으로 쓰고 있고, 일하는 방식에 따라선 오히려 평균을 끌어내릴 수도 있음
    • 나도 같은 느낌임
      28년째 이런 일을 하고 있는데, 회사 돈으로 급여 받는 시간에 업무용 앱 코드를 직접 쓰는 건 이제 경제적으로도, 선의로 봐도 잘 맞지 않음

  • 반대로 나는 코딩 에이전트가 새 요구사항에 맞추려면 기존 코드를 더 과감히 바꿔야 하는데, 기존 코드 보존을 지나치게 우선한다고 자주 느낌
    결국 기존 코드를 얼마나 굳혀 둘지의 문제 같음
    수십 년 굴러온 대형 프로덕션 앱이면 변경을 최소화하는 게 맞겠지만, 3일 전에 막 만든 실험 프로젝트라면 그대로 두기보다 더 낫게 고쳐야 함
    결국 프로젝트 맥락에 맞게 스스로 강도를 조절하는 법을 배워야 할 듯함

    • 이 트레이드오프는 맥락 의존적이라서, 에이전트가 프로젝트만 훑어보고 항상 올바르게 판단할 수는 없음
      같은 프로젝트 안에서도 PR마다 어떤 영역은 마음껏 바꿔도 되지만, 어떤 영역은 diff와 테스트 범위를 줄이려고 고정해두고 싶음
      그래서 미리 어느 부분을 얼마나 공격적으로 바꿔도 되는지 설명하지만 결과는 들쭉날쭉함
      대체로는 최소 diff 쪽으로 치우쳐서, 그 대가로 중복이 생기거나 추상화를 억지로 비트는 경우가 많음
      더 잘 먹히는 방법이 있다면 나도 듣고 싶음
    • 에이전트가 가끔은 스스로 생각하게 만들려면, 코드와 markdown을 먼저 꽤 지워야 한다는 느낌이 듦
      리팩터링하거나 넓게 재고하라고 지시해도 성과가 약한 편임
      그래서 디자인이 너무 많이 박혀 있는 markdown을 정리하게 하고, 기술적인 내용이나 핵심 구현·인터페이스를 소스에서 지운 뒤 새 세션에게 설계를 다시 하게 시킴
      그 다음 삭제한 내용을 복구해 덜 순진한 세션과 reconcile함
      경로 의존성이 너무 강해서 지금은 이 흐름을 수동으로 하지만, 이 패턴을 skill로 정형화하고 싶음
    • 이 말투만 봐도 Codex 쓰는 게 보임

  • AI는 실패를 숨기려고 예외를 잡아먹고 더미 값을 돌려주거나, 온갖 잡다한 로그 속에 파묻힌 메시지 하나만 남기는 경우가 많음
    로그도 지나치게 축약돼 있어서 실제 디버깅에 필요한 핵심 데이터가 빠질 때가 많음
    아마 시스템을 속여 점수 따는 방향으로 학습됐기 때문 아닐까 싶음
    예외를 그대로 터뜨리면 명백한 실패라 불이익을 받지만, 문제를 감추면 가끔 성공처럼 보이니까
    이게 일반 Q&A에서는 어떻게 나타나는지도 궁금함
    모델은 사용자가 납득하고 떠나게 만들 만큼만 그럴듯하게 들리려는 쪽으로 가는 걸까 싶음
    자주 보이는 패턴이 "그건 X가 아니라 Y다" 같은 식인데, 이렇게 이분법을 만들면 다른 가능성을 생각하지 않게 됨
    답변 끝에 행동 계획을 붙이는 것도 흔한데, 이건 assumptive close라는 영업 기법처럼 답 자체보다 AI에 동의한 뒤 결과를 상상하게 만들려는 흐름으로 보임

    • AI 행동은 최적화 대상 지표를 어떻게든 속인다는 관점으로 보면 꽤 예측 가능함
      결국 hill-climbing으로 metric을 오르는 게 그런 모습이니까
      일종의 A/B enshittification이 해석 불가능할 정도로 극단화된 형태 같음
      인간 피드백으로 학습되는 이상, 모든 응답의 모든 조각이 평가자를 우회하고 만족시키는 쪽으로 향할 수밖에 없음

  • AI로 뭔가를 아주 잘 만드는 일은 생각보다 손이 많이 감
    시키면 꽤 그럴듯한 결과는 내놓지만, 모르는 걸 모른다는 사실 자체를 모를 수 있음
    특히 AI가 권위 있게 말하면 더 위험함
    그래서 여러 각도에서 검증하고 정확성을 확인하는 일이 쉽지 않음
    이게 시간이 지나며 어떻게 변할지는 흥미로움

    • 전적으로 동의함
      동시에 이런 글과 여기 달린 말들도 시점의 스냅샷처럼 느껴짐
      업계 발전 속도가 너무 빨라서, 코딩 모델은 불과 9개월 전보다도 이미 훨씬 나아졌음
      AI 역량에 대한 불만을 읽을 때마다, 상대를 탓하는 건 아니지만 속으로는 늘 "아직은"이라고 생각하게 됨
    • 요즘은 AI로 뭔가를 직접 만들기보다, 한 AI 컨텍스트로 다른 AI 컨텍스트를 검토시키는 데 더 많은 시간을 씀
      서로의 결과를 리뷰하게 만드는 식임
      그래도 대부분 비동기로 돌아가서, 나는 그 사이 다른 일을 할 수 있다는 이점이 있음
    • 내가 뭘 모르는지도 모른다면, 코딩 에이전트보다 더 나은 걸 어떻게 만들겠나 싶음
      그래서 몇몇 프로젝트에서는 일단 에이전트로 프로토타입을 만들며 배우고, 그다음 설계를 적은 뒤 처음부터 다시 시작했음
      그러면 어디를 더 깊게 봐야 하는지 알게 됨
    • 맞음. 대체로 80% 지점까지는 꽤 잘 데려다 줌
      남은 20%가 무엇인지는 결국 문제 성격에 달려 있음

  • 여기서 말하는 건 코드 과잉 수정이지만, 에이전트는 그보다 더 많은 걸 함
    파일 여러 개를 건드리고, 테스트를 돌리고, 배포하고, smoke test까지 수행하는 식인데, 이 모든 게 추상화 뒤로 숨어버림
    한편으론 놀랍지만 다른 한편으론 불안함이 큼
    첫째, 내부에서 실제로 무슨 일이 일어나는지 제대로 이해하지 못함
    에이전트가 조립한 스크립트를 그냥 승인해 돌리는 게 너무 쉬워서 유혹적임
    그런데 이미 에이전트가 맞다고 판단했다는 이유로 DB를 날린 적도 있고, 절대 보내면 안 되는 AWS 자격 증명을 배포 대상으로 보내려는 것도 잡아낸 적이 있음
    둘째, 내가 배운 게 없음
    단순한 docker 명령 하나도 스스로 조립하는 인지 부담이 커져서, 반복적으로 AI라는 목발에 기대게 됨

    • 왜 LLM이 운전대를 잡게 두는지 모르겠음
      auto-approve는 켜지 말고, 에이전트가 실행하는 모든 명령을 직접 승인해야 함
      설계나 아키텍처 결정도 맡기지 말고, 어떻게 만들지 사람이 정해서 그 깡통에게 분명히 지시해야 함
      농담이 아니라 AI를 도구처럼 다루면 훨씬 더 잘 써먹을 수 있음
      10배 생산성까진 아니더라도, 최소한 코드는 계속 이해한 채로 갈 수 있음
    • 자격 증명 쪽은 내가 보기엔 이렇음
      Day 1에는 보안을 아주 신중히 다루고, .env를 .gitignore에 넣어야 하는 이유부터 자격 증명을 넘기지 말고 내가 직접 수정해야 한다는 훈계까지 함
      그런데 Day 2에 같은 걸 다시 시키면 그 규칙이나 설정을 잊어버리고, 디스크 전체를 뒤져 .env와 다른 파일들까지 읽고, 토큰을 쥔 걸 이해한 뒤 curl 명령을 직접 만들어 테스트까지 해버림
      첫날엔 보안 전문가 같다가 다음날엔 평범한 인턴 이하가 되는 느낌임
    • 나는 사실상 세 가지 모드로 씀
      1. 핵심 애플리케이션은 내가 전부 명세·구현·테스트하고 마지막 정리만 AI에 맡김
      2. 함수는 AI가 쓰고 테스트 뼈대만 잡게 한 뒤, 함수는 내가 자주 다시 씀
        이 방식이 원치 않는 동작이나 과한 구현은 많지만 보일러플레이트 제거에는 유용함
      3. 실험 코드나 언제든 버려도 되는 부분은 AI가 전부 하게 둠
        실제로 이런 부분은 70% 정도 삭제하게 됨
        대신 1번과 2번 영역은 AI가 건드리지 못하게 함
        물론 이런 분리가 가능하도록 아키텍처가 짜여 있어야 하지만, 꽤 만족스럽게 쓰고 있음
    • 이건 생각보다 쉬운 문제임
      그냥 프로덕션 자격 증명을 LLM에 주지 않으면 됨
      로컬이나 staging/dev에서 재현이 안 되면 배포 인프라를 prod와 더 비슷하게 맞춰야 하고, 환경별 권한을 충분히 세분화할 수 없다면 권한 체계부터 고쳐야 함
      나는 이 원칙을 지켜서, 네가 말한 종류의 문제를 겪어본 적이 거의 없음
      진단용이라면 읽기 전용 자격 증명을 잠깐 줄 수는 있겠지만, 그 경우도 유출에 대비해 매우 짧은 수명 토큰만 발급할 것임
    • 나는 보통 Claude가 쓴 코드를 모두 리뷰하고, 내가 쓴 코드도 다시 Claude에게 리뷰시킴
      그래서 대체로 무슨 일이 일어나는지는 파악하고 있음
      Claude가 가끔 비정상적이거나 관습 밖의 결정을 내리긴 함
      다만 대형 코드베이스를 팀으로 다루다 보면, 이미 회사를 떠난 사람이 만든 부분까지 포함해서 원래부터 이해 못한 채 추상화 뒤에 있는 영역도 많긴 함

  • 예전에 자주 가르쳤지만 실제론 거의 지켜지지 않던 지혜가 작업하면서 리팩터링하라는 말이었음
    어떤 영역을 만지면 그 기회에 정리하고 기술 부채도 청산하라는 취지였음
    그런데 현실에선 잘 안 됐고, 이제 LLM이 실제로 그걸 해주기 시작하니 그 부작용을 체감하게 됨

    • 모델이 기존 로직과 같은 일을 하는 새 코드를 쓰는 건 리팩터링이 아님
      필요한 함수가 바로 거기 있는데도 새로 만드는 경우가 있음
      더 나쁜 건, 기존 함수를 수정해 동작을 유지하는 척하면서 다른 사용처를 깨뜨리는 경우임
      최악은 클래스 사이 상태를 바꾸면서 부작용을 모르는 채 건드려서 데드락이나 평범한 버그를 만드는 것임
    • 가는 길에 뭘 손대기로 했을 때도 실제로는 개선이 아닌 경우가 많음
      내가 보기엔 리팩터링이라기보다 슬롯머신 레버를 한 번 더 당기는 행동에 가까움
    • 오늘도 이것 때문에 시간을 좀 썼음
      내 진짜 문제는 에이전트가 한 리팩터링의 질이 나빴다는 것임
      그런 수정을 멈추게 한 뒤, 무엇을 어떻게 고칠지 더 명시적으로 지시하고 싶었을 뿐임
    • 그렇게 단순한 얘기만은 아님
      많은 경우 기존 추상화가 충분히 괜찮아서, 버그를 추적하거나 기능을 확장하는 정도는 그 위에서 할 수 있음
      그런데 가끔은 기존 구현을 억지로 우회할지, 아니면 다시 설계할지 갈림길에 섬
      LLM과 함께선 그걸 어떻게 재고해야 하는지, 애초에 재고할 필요가 있는지도 흐려짐
      게다가 그런 결정이 사용자 눈에 잘 보이지 않게 숨어버림
    • 진짜 궁금한 부분임
      어쩌면 그런 변경이 유용할 수도 있으니 예시를 더 보고 싶음
      나는 cognitive complexity 지표를 신뢰하진 않지만, 이런 수정이 그 지표를 꽤 일관되게 올린다는 점은 조금 흥미로움

  • Claude Code나 Codex에서 과잉 수정을 한동안 못 봐서, 이 연구에 어떤 프롬프트를 썼는지 궁금했음
    아마 여기 있는 것 같고 마지막 수정은 8개월 전임
    https://github.com/nreHieW/fyp/blob/5a4023e4d1f287ac73a616b5b944a14f28422c7e/partial_edits/utils/prompts_utils.py

    • 바로 오늘도 그런 일이 있었음
      GPT-5.4가 내가 요청한 10줄 추가 대신, 더 깔끔하다는 이유로 50줄을 다시 써버렸음
      기존 코드를 보고 변수명만 바꿔 비슷하게 넣으면 되는 기계적인 추가였는데도 그랬음
      게다가 처음엔 내가 요청한 기능 자체도 넣지 않아서 더 황당했음
      over-editing은 결코 지나간 문제가 아니고, 이건 내가 thinking을 낮추는 걸 깜빡해 xhigh thinking으로 돌렸을 때 벌어진 일이었음
    • 나도 비슷하게 느낌
      이건 내겐 초기 에이전트 시절 문제처럼 읽혔음

  • 이 글은 꽤 탄탄함
    LLM은 산문에서도 코드에서도 지나치게 장황하고, 내 생각엔 그 주된 원인은 학습 방식임
    cross entropy loss는 garden path 같은 문장을 선호하게 만듦
    사람이면 한 문장, 심지어 몇 단어로 끝낼 말을 한 단락으로 늘어놓게 됨
    긴 문장이 통계적으로 놀라움이 적은, 즉 낮은 perplexity 경로이기 때문임

  • 나도 이 문제를 두고 양가감정이 듦
    대개는 과하게 해놓고 내가 30분 동안 바로잡아야 해서 평가에 동의함
    그런데 어떤 때는 더 포괄적인 변경을 놓치기도 함
    아마 컨텍스트 한계 때문일 텐데, 그래서 더 엄격하게 도구를 다루기 시작했음
    그래도 아직 원하는 수준의 제어감까지는 못 얻고 있음

  • 이건 훈련 데이터의 흔적처럼 느껴짐
    SFT와 preference 데이터에는 "파일을 더 깔끔하게 고친 버전"이 넘치고, "딱 3줄 diff" 같은 예시는 적음
    그래서 모델은 더 크고 더 다듬어진 출력이 이긴다고 배웠음
    프롬프트로 어느 정도는 제어할 수 있지만, 결국 강한 사전 경향과 싸우는 셈임

답변달기
긱뉴스에 GeekBadge 기능이 추가되었습니다. 긱배지로 자신을 표현해 보세요.