내가 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 명령을 직접 만들어 테스트까지 해버림
첫날엔 보안 전문가 같다가 다음날엔 평범한 인턴 이하가 되는 느낌임
나는 사실상 세 가지 모드로 씀
핵심 애플리케이션은 내가 전부 명세·구현·테스트하고 마지막 정리만 AI에 맡김
함수는 AI가 쓰고 테스트 뼈대만 잡게 한 뒤, 함수는 내가 자주 다시 씀
이 방식이 원치 않는 동작이나 과한 구현은 많지만 보일러플레이트 제거에는 유용함
실험 코드나 언제든 버려도 되는 부분은 AI가 전부 하게 둠
실제로 이런 부분은 70% 정도 삭제하게 됨
대신 1번과 2번 영역은 AI가 건드리지 못하게 함
물론 이런 분리가 가능하도록 아키텍처가 짜여 있어야 하지만, 꽤 만족스럽게 쓰고 있음
이건 생각보다 쉬운 문제임
그냥 프로덕션 자격 증명을 LLM에 주지 않으면 됨
로컬이나 staging/dev에서 재현이 안 되면 배포 인프라를 prod와 더 비슷하게 맞춰야 하고, 환경별 권한을 충분히 세분화할 수 없다면 권한 체계부터 고쳐야 함
나는 이 원칙을 지켜서, 네가 말한 종류의 문제를 겪어본 적이 거의 없음
진단용이라면 읽기 전용 자격 증명을 잠깐 줄 수는 있겠지만, 그 경우도 유출에 대비해 매우 짧은 수명 토큰만 발급할 것임
나는 보통 Claude가 쓴 코드를 모두 리뷰하고, 내가 쓴 코드도 다시 Claude에게 리뷰시킴
그래서 대체로 무슨 일이 일어나는지는 파악하고 있음
Claude가 가끔 비정상적이거나 관습 밖의 결정을 내리긴 함
다만 대형 코드베이스를 팀으로 다루다 보면, 이미 회사를 떠난 사람이 만든 부분까지 포함해서 원래부터 이해 못한 채 추상화 뒤에 있는 영역도 많긴 함
예전에 자주 가르쳤지만 실제론 거의 지켜지지 않던 지혜가 작업하면서 리팩터링하라는 말이었음
어떤 영역을 만지면 그 기회에 정리하고 기술 부채도 청산하라는 취지였음
그런데 현실에선 잘 안 됐고, 이제 LLM이 실제로 그걸 해주기 시작하니 그 부작용을 체감하게 됨
모델이 기존 로직과 같은 일을 하는 새 코드를 쓰는 건 리팩터링이 아님
필요한 함수가 바로 거기 있는데도 새로 만드는 경우가 있음
더 나쁜 건, 기존 함수를 수정해 동작을 유지하는 척하면서 다른 사용처를 깨뜨리는 경우임
최악은 클래스 사이 상태를 바꾸면서 부작용을 모르는 채 건드려서 데드락이나 평범한 버그를 만드는 것임
가는 길에 뭘 손대기로 했을 때도 실제로는 개선이 아닌 경우가 많음
내가 보기엔 리팩터링이라기보다 슬롯머신 레버를 한 번 더 당기는 행동에 가까움
오늘도 이것 때문에 시간을 좀 썼음
내 진짜 문제는 에이전트가 한 리팩터링의 질이 나빴다는 것임
그런 수정을 멈추게 한 뒤, 무엇을 어떻게 고칠지 더 명시적으로 지시하고 싶었을 뿐임
그렇게 단순한 얘기만은 아님
많은 경우 기존 추상화가 충분히 괜찮아서, 버그를 추적하거나 기능을 확장하는 정도는 그 위에서 할 수 있음
그런데 가끔은 기존 구현을 억지로 우회할지, 아니면 다시 설계할지 갈림길에 섬
LLM과 함께선 그걸 어떻게 재고해야 하는지, 애초에 재고할 필요가 있는지도 흐려짐
게다가 그런 결정이 사용자 눈에 잘 보이지 않게 숨어버림
진짜 궁금한 부분임
어쩌면 그런 변경이 유용할 수도 있으니 예시를 더 보고 싶음
나는 cognitive complexity 지표를 신뢰하진 않지만, 이런 수정이 그 지표를 꽤 일관되게 올린다는 점은 조금 흥미로움
바로 오늘도 그런 일이 있었음 GPT-5.4가 내가 요청한 10줄 추가 대신, 더 깔끔하다는 이유로 50줄을 다시 써버렸음
기존 코드를 보고 변수명만 바꿔 비슷하게 넣으면 되는 기계적인 추가였는데도 그랬음
게다가 처음엔 내가 요청한 기능 자체도 넣지 않아서 더 황당했음 over-editing은 결코 지나간 문제가 아니고, 이건 내가 thinking을 낮추는 걸 깜빡해 xhigh thinking으로 돌렸을 때 벌어진 일이었음
나도 비슷하게 느낌
이건 내겐 초기 에이전트 시절 문제처럼 읽혔음
이 글은 꽤 탄탄함
LLM은 산문에서도 코드에서도 지나치게 장황하고, 내 생각엔 그 주된 원인은 학습 방식임 cross entropy loss는 garden path 같은 문장을 선호하게 만듦
사람이면 한 문장, 심지어 몇 단어로 끝낼 말을 한 단락으로 늘어놓게 됨
긴 문장이 통계적으로 놀라움이 적은, 즉 낮은 perplexity 경로이기 때문임
나도 이 문제를 두고 양가감정이 듦
대개는 과하게 해놓고 내가 30분 동안 바로잡아야 해서 평가에 동의함
그런데 어떤 때는 더 포괄적인 변경을 놓치기도 함
아마 컨텍스트 한계 때문일 텐데, 그래서 더 엄격하게 도구를 다루기 시작했음
그래도 아직 원하는 수준의 제어감까지는 못 얻고 있음
이건 훈련 데이터의 흔적처럼 느껴짐
SFT와 preference 데이터에는 "파일을 더 깔끔하게 고친 버전"이 넘치고, "딱 3줄 diff" 같은 예시는 적음
그래서 모델은 더 크고 더 다듬어진 출력이 이긴다고 배웠음
프롬프트로 어느 정도는 제어할 수 있지만, 결국 강한 사전 경향과 싸우는 셈임
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개로 바꾸고 그걸 읽는 코드까지 갱신하는 식의 지루한 작업에 특히 강함
결함도 많고 버그도 많은 소프트웨어인데도 실제론 매우 효과적임
AI에서 가장 이상한 점 중 하나는 사람마다 체감이 정말 극단적으로 다르다는 것임
운영성 업무가 많은지, 오래 가는 제품 코드를 다루는지도 중요함
내 가설은 이 도구가 단순한 패턴 위에서는 잘 작동하고 복잡한 일도 처리하긴 하지만, 새 패턴을 발명하는 일은 영 별로라는 것임
감독 없이 두면 금방 위험한 새 패턴을 지어내서 망가뜨리기도 함
그래서 Claude가 준 걸 통째로 다시 쓰는 경우가 꽤 있음
가끔은 로봇과 속도 경쟁을 해서 내가 더 빨리 끝내기도 함
내가 뭘 원하는지 이미 알고 있으니 유리한 면도 있지만, 여기서 드는 잔손질 비용이 과소평가된다고 느낌
futzing fraction도 그렇고, the peril of laziness lost처럼 기계가 너무 과하게 애쓰는 방식 자체가 거슬릴 때가 있음
왜 한 가지만 하면 되는데 세 가지를 하려 드는지 모르겠음
고쳐주면 다시 맞춘다고 해도, 동료랑 일할 때도 이미 겪는 "A, B, C 하지 말고 A만 하라"는 흐름을 또 반복해야 해서 짜증남
테스트 생성도 미묘한데, 방향을 잡아준 테스트 작성은 잘하지만 창의성을 허용하면
foo + bar == bar + foo같은 쓸모없는 테스트를 너무 많이 만듦테스트 유용성을 계속 의심하며 봐야 피드백 루프가 건강해짐
요즘은 테스트 자체보다 필요한 import를 한 번에 끌어오는 용도로 더 쓸모 있을 때도 많음
이런 기계들이 일을 대신한다면 평균 코드 품질은 올라갈 수도 있어야 함
하지만 많은 사람이 "대체로 평균 근처는 친다"는 식으로 쓰고 있고, 일하는 방식에 따라선 오히려 평균을 끌어내릴 수도 있음
28년째 이런 일을 하고 있는데, 회사 돈으로 급여 받는 시간에 업무용 앱 코드를 직접 쓰는 건 이제 경제적으로도, 선의로 봐도 잘 맞지 않음
반대로 나는 코딩 에이전트가 새 요구사항에 맞추려면 기존 코드를 더 과감히 바꿔야 하는데, 기존 코드 보존을 지나치게 우선한다고 자주 느낌
결국 기존 코드를 얼마나 굳혀 둘지의 문제 같음
수십 년 굴러온 대형 프로덕션 앱이면 변경을 최소화하는 게 맞겠지만, 3일 전에 막 만든 실험 프로젝트라면 그대로 두기보다 더 낫게 고쳐야 함
결국 프로젝트 맥락에 맞게 스스로 강도를 조절하는 법을 배워야 할 듯함
같은 프로젝트 안에서도 PR마다 어떤 영역은 마음껏 바꿔도 되지만, 어떤 영역은 diff와 테스트 범위를 줄이려고 고정해두고 싶음
그래서 미리 어느 부분을 얼마나 공격적으로 바꿔도 되는지 설명하지만 결과는 들쭉날쭉함
대체로는 최소 diff 쪽으로 치우쳐서, 그 대가로 중복이 생기거나 추상화를 억지로 비트는 경우가 많음
더 잘 먹히는 방법이 있다면 나도 듣고 싶음
리팩터링하거나 넓게 재고하라고 지시해도 성과가 약한 편임
그래서 디자인이 너무 많이 박혀 있는 markdown을 정리하게 하고, 기술적인 내용이나 핵심 구현·인터페이스를 소스에서 지운 뒤 새 세션에게 설계를 다시 하게 시킴
그 다음 삭제한 내용을 복구해 덜 순진한 세션과 reconcile함
경로 의존성이 너무 강해서 지금은 이 흐름을 수동으로 하지만, 이 패턴을 skill로 정형화하고 싶음
AI는 실패를 숨기려고 예외를 잡아먹고 더미 값을 돌려주거나, 온갖 잡다한 로그 속에 파묻힌 메시지 하나만 남기는 경우가 많음
로그도 지나치게 축약돼 있어서 실제 디버깅에 필요한 핵심 데이터가 빠질 때가 많음
아마 시스템을 속여 점수 따는 방향으로 학습됐기 때문 아닐까 싶음
예외를 그대로 터뜨리면 명백한 실패라 불이익을 받지만, 문제를 감추면 가끔 성공처럼 보이니까
이게 일반 Q&A에서는 어떻게 나타나는지도 궁금함
모델은 사용자가 납득하고 떠나게 만들 만큼만 그럴듯하게 들리려는 쪽으로 가는 걸까 싶음
자주 보이는 패턴이 "그건 X가 아니라 Y다" 같은 식인데, 이렇게 이분법을 만들면 다른 가능성을 생각하지 않게 됨
답변 끝에 행동 계획을 붙이는 것도 흔한데, 이건 assumptive close라는 영업 기법처럼 답 자체보다 AI에 동의한 뒤 결과를 상상하게 만들려는 흐름으로 보임
결국 hill-climbing으로 metric을 오르는 게 그런 모습이니까
일종의 A/B enshittification이 해석 불가능할 정도로 극단화된 형태 같음
인간 피드백으로 학습되는 이상, 모든 응답의 모든 조각이 평가자를 우회하고 만족시키는 쪽으로 향할 수밖에 없음
AI로 뭔가를 아주 잘 만드는 일은 생각보다 손이 많이 감
시키면 꽤 그럴듯한 결과는 내놓지만, 모르는 걸 모른다는 사실 자체를 모를 수 있음
특히 AI가 권위 있게 말하면 더 위험함
그래서 여러 각도에서 검증하고 정확성을 확인하는 일이 쉽지 않음
이게 시간이 지나며 어떻게 변할지는 흥미로움
동시에 이런 글과 여기 달린 말들도 시점의 스냅샷처럼 느껴짐
업계 발전 속도가 너무 빨라서, 코딩 모델은 불과 9개월 전보다도 이미 훨씬 나아졌음
AI 역량에 대한 불만을 읽을 때마다, 상대를 탓하는 건 아니지만 속으로는 늘 "아직은"이라고 생각하게 됨
서로의 결과를 리뷰하게 만드는 식임
그래도 대부분 비동기로 돌아가서, 나는 그 사이 다른 일을 할 수 있다는 이점이 있음
그래서 몇몇 프로젝트에서는 일단 에이전트로 프로토타입을 만들며 배우고, 그다음 설계를 적은 뒤 처음부터 다시 시작했음
그러면 어디를 더 깊게 봐야 하는지 알게 됨
남은 20%가 무엇인지는 결국 문제 성격에 달려 있음
여기서 말하는 건 코드 과잉 수정이지만, 에이전트는 그보다 더 많은 걸 함
파일 여러 개를 건드리고, 테스트를 돌리고, 배포하고, smoke test까지 수행하는 식인데, 이 모든 게 추상화 뒤로 숨어버림
한편으론 놀랍지만 다른 한편으론 불안함이 큼
첫째, 내부에서 실제로 무슨 일이 일어나는지 제대로 이해하지 못함
에이전트가 조립한 스크립트를 그냥 승인해 돌리는 게 너무 쉬워서 유혹적임
그런데 이미 에이전트가 맞다고 판단했다는 이유로 DB를 날린 적도 있고, 절대 보내면 안 되는 AWS 자격 증명을 배포 대상으로 보내려는 것도 잡아낸 적이 있음
둘째, 내가 배운 게 없음
단순한 docker 명령 하나도 스스로 조립하는 인지 부담이 커져서, 반복적으로 AI라는 목발에 기대게 됨
auto-approve는 켜지 말고, 에이전트가 실행하는 모든 명령을 직접 승인해야 함
설계나 아키텍처 결정도 맡기지 말고, 어떻게 만들지 사람이 정해서 그 깡통에게 분명히 지시해야 함
농담이 아니라 AI를 도구처럼 다루면 훨씬 더 잘 써먹을 수 있음
10배 생산성까진 아니더라도, 최소한 코드는 계속 이해한 채로 갈 수 있음
Day 1에는 보안을 아주 신중히 다루고, .env를 .gitignore에 넣어야 하는 이유부터 자격 증명을 넘기지 말고 내가 직접 수정해야 한다는 훈계까지 함
그런데 Day 2에 같은 걸 다시 시키면 그 규칙이나 설정을 잊어버리고, 디스크 전체를 뒤져 .env와 다른 파일들까지 읽고, 토큰을 쥔 걸 이해한 뒤 curl 명령을 직접 만들어 테스트까지 해버림
첫날엔 보안 전문가 같다가 다음날엔 평범한 인턴 이하가 되는 느낌임
이 방식이 원치 않는 동작이나 과한 구현은 많지만 보일러플레이트 제거에는 유용함
실제로 이런 부분은 70% 정도 삭제하게 됨
대신 1번과 2번 영역은 AI가 건드리지 못하게 함
물론 이런 분리가 가능하도록 아키텍처가 짜여 있어야 하지만, 꽤 만족스럽게 쓰고 있음
그냥 프로덕션 자격 증명을 LLM에 주지 않으면 됨
로컬이나 staging/dev에서 재현이 안 되면 배포 인프라를 prod와 더 비슷하게 맞춰야 하고, 환경별 권한을 충분히 세분화할 수 없다면 권한 체계부터 고쳐야 함
나는 이 원칙을 지켜서, 네가 말한 종류의 문제를 겪어본 적이 거의 없음
진단용이라면 읽기 전용 자격 증명을 잠깐 줄 수는 있겠지만, 그 경우도 유출에 대비해 매우 짧은 수명 토큰만 발급할 것임
그래서 대체로 무슨 일이 일어나는지는 파악하고 있음
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" 같은 예시는 적음
그래서 모델은 더 크고 더 다듬어진 출력이 이긴다고 배웠음
프롬프트로 어느 정도는 제어할 수 있지만, 결국 강한 사전 경향과 싸우는 셈임