왜 다들 앤스로픽의 모범 사례를 무시하는 걸까?

난 완전한 바이브 코더는 아니지만, 그렇다고 숙련된 개발자도 아니야. 네 접근 방식이나, 릴리스마다 어떤 프롬프트를 쓰는지, 어떻게 구조적인 변경을 하는지 구체적으로 더 배우고 싶어.

H\Q는 거의 모든 모델에 대한 프롬프트 가이드를 발행하고, 전반적인 사용법에 대해서는 이런 기사들을 내놓지.

그냥 클로드한테 그 기사들을 가리키면서 네 설정과 기사들을 비교하는 보고서를 작성해달라고 해.

그다음 보고서를 훑어보고 네 작업 방식에 맞는 것들을 구현하면 돼.

솔직히 그건 별로 좋은 접근 방식이 아니야. 리팩토링은 문서를 업데이트하는 게 아니라, 네 명세가 미래의 추가 사항을 고려하지 못해서 기존 코드와 충돌할 때 근본적인 아키텍처를 바꾸는 거거든. 문장을 추가하고 나서 보니 원래 의도했던 뜻이 아니었다는 걸 깨닫고 문서를 수정하는 거랑 비슷하지. 그리고 LLM 입장에선 꽤 비용이 많이 드는 일이야. LLM은 잘 정의된 명세를 따라 실행하면 되는데, 어디를 고쳐야 할지 찾으려고 코드베이스를 다시 읽어야 하니까. 문서도 결국 변질되기 마련이고. 이건 LLM에게 있어 기술 부채가 어떤 건지 잘 보여주는 사례야.

잘 작동한다고 해서 잘 설계된 건 아니야. 결국 설계 자체에서 피할 수 있었던 기술 부채와 버그를 만나게 될 거야. LLM이 무엇을 할 수 없는지, 즉 선택의 결과를 이해하지 못한다는 점을 고려해서 네가 직접 설계 결정을 내려야 해. LLM은 지식을 학습하고 있어서 도움을 받기엔 아주 좋지만, 네가 직접 고민하고 명세하는 데 시간을 더 써야 해.

왜 그걸 자랑스럽게 말하는지 모르겠지만, 견고한 소프트웨어를 개발하는 데는 확실히 좋은 방식이 아니야. 나도 첫 번째 바이브 코딩 프로젝트에서 그 실수를 했었거든. 이제는 안 그래.

난 그냥 클로드가 모범 사례를 알고 알아서 업데이트하는 줄 알았어. 하지만 좀 더 명시적으로 지시해야겠네.

모델들은 이전의 학습 데이터 세트로 훈련돼. 그다음 운영자들이 모델을 사용하면서 훈련이 끝난 후에야 모범 사례를 찾아내지. 모델을 계속 사용할수록 더 잘 사용하는 방법을 배우게 되고, 이 문서를 계속 업데이트하는 거야.

회사의 하네스에 의존하는 대신, 세션을 시작할 때 클로드에게 이 링크를 읽으라고 그냥 말하면 돼.

어제 나도 똑같은 비교를 하고 있었음! LLM으로 실제 목표를 달성하려고 하는 건 마치 예전에 젠투 리눅스로 특정 하드웨어에 맞춰 커널 컴파일하던 때랑 비슷함. 맞춤형이고 시간도 엄청 걸리고, 어떤 사람들은 놀라운 결과를 얻기도 하지만, 대부분 사람들에겐 여전히 이해하기 어려운 영역이지. 반면에 오늘날엔 55달러짜리 안드로이드 TV 기기를 사면 리눅스 커널이 돌아가는데, 대부분의 사용자는 그게 뭔지도 모르는 거랑 대조적이지.

응! 제발 부탁인데, 네가 직접 읽을 필요도 없어. 모든 프로젝트 시작할 때 클로드한테 모범 사례를 읽게 하고, 그걸 중심으로 프로젝트를 구축해. 클로드가 원래 작동하지 말아야 할 방식으로 억지로 일하게 하지 마.

이 글의 조언은 좀 구식인 것 같아. 그냥 모델한테 '빌드가 실패했어'라고 말하는 거랑, 빌드 에러를 복사해서 프롬프트에 넣는 거랑 품질 차이가 크게 안 나거든. 에이전트는 필요한 컨텍스트를 얻기 위해 체크를 실행할 만큼 똑똑해. 그러니 왜 굳이 추가 작업을 해야 하지?