최적의 LLM 보조 코딩 경험을 찾아가는 여정을 이어가고 있다. 특히, 한 가지 완벽한 방식에 집중하기보다는 여러 워크플로우를 섞어서 각 장단점을 “봉합(stitch up)”하며 점점 더 다양화해서 활용하는 것 같다.
개인적으로 LLM 보조의 핵심(약 75% 정도)은 여전히 (Cursor의) 탭 자동완성이다. 내가 직접 코드/주석을 구체적으로 작성하고 코드의 올바른 위치에 배치하는 것이 LLM에 “작업 명세(task specification)”를 전달하는 가장 효율적인 방법이라고 생각한다. 즉, 본질은 작업 명세 비트(bits)를 전달하는 것인데, 내가 원하는 바를 텍스트로만 설명하기에는 너무 많은 비트와 지연(latency)이 필요하다. 차라리 코드 안에서 직접 보여주는 것이 훨씬 빠르다. 가끔 탭 완성 모델이 짜증날 때가 있어서 켜고 끄기를 자주 반복한다.
그다음 단계는 구체적인 코드 블록을 하이라이트하고 어떤 수정 작업을 요청하는 것이다.
그 위 단계는 Cursor 옆에서 돌리는 Claude Code, Codex 같은 모델이다. 큰 기능 단위이고 프롬프트로 명세하기 쉬운 경우에 사용한다. 매우 유용하지만 여전히 결과가 섞여 있고, 가끔은 답답하다. 나는 YOLO 모드(그냥 무작정 실행)로 쓰지 않는데, 모델이 산으로 가서 쓸데없는 일을 하기 때문이다. 그래서 ESC를 자주 누른다.
여러 인스턴스를 병렬로 활용하는 생산적인 방법도 아직 못 찾았다—하나만 해도 벅차다. CLAUDE[.]md 같은 걸 제대로 유지·업데이트하는 방법도 아직 못 찾았다.
스타일이나 취향 문제 때문에 정리(cleanup) 작업을 자주 해줘야 한다. 예를 들어, 지나치게 방어적으로 try/catch를 남발하거나, 추상화를 과도하게 복잡하게 만들거나, 리스트 컴프리헨션이나 한 줄 if-then-else로 충분한 경우에도 중첩된 if-else 블록을 쓰거나, 헬퍼 함수로 뺄 수 있는 코드를 중복시키는 등… 기본적으로 “코드 취향”이 없다.
그래도 내가 익숙하지 않은 영역(예: 최근 Rust 작성, SQL 명령, 예전에 거의 안 써본 언어들)에 발을 담글 때는 필수적이다. CC로부터 코드와 동시에 학습하려고 시도했지만 완전히 실패했다—이 모델은 코드를 설명하는 것보다 그냥 코드를 쓰는 데 더 집중한다. 예전에 CC로 하이퍼파라미터 튜닝을 시켜본 적도 있는데 꽤 웃겼다.
또 CC는 단발성 저위험 시각화, 유틸리티, 디버깅 코드에 굉장히 유용하다. 내가 직접 짜기엔 너무 오래 걸릴 것 같은 것들이다. 예를 들어, 특정 버그를 잡기 위해 1,000줄짜리 맞춤형 시각화 코드를 CC가 뚝딱 만들어주고, 버그를 찾자마자 다 삭제하는 식이다. 이건 코드 포스트-스카시티(post-scarcity, 희소성 해소) 시대다—수천 줄의 맞춤형, 일회성 코드를 만들었다가 바로 버려도 괜찮다. 이제 코드는 더 이상 귀하고 비싼 자원이 아니다.
마지막 방어선은 GPT-5 Pro다. 가장 어려운 문제를 맡긴다. 예를 들어, 나/커서/CC가 10분 동안 같은 버그에 갇혀 헤매는데, 전체 코드를 5 Pro에 붙여넣으면 10분 정도 돌리다가 실제로 아주 미묘한 버그를 찾아내는 경우가 있었다. 정말 강력하다. 희귀한 문서나 논문 같은 것도 잘 찾아낸다. 좀 더 무거운 작업에도 활용했다. 예컨대 추상화를 정리하는 방법을 제안하게 했는데 결과는 반반이었다—괜찮은 아이디어도 있었지만 그렇지 않은 것도 있었다. 또는 사람들이 어떤 방법을 쓰는지 전체 문헌 리뷰를 요청하면 관련 자원이나 참고 자료를 잘 모아준다.
어쨌든, 지금은 코딩이 여러 “종류”의 코딩 방식과 각기 다른 장단점을 가진 도구들로 완전히 열린 상태다. 집단적으로 가능한 최전선(frontier)에 내가 못 따라가고 있다는 불안감을 피하기 어렵다. 그래서 이런 일요일 샤워 중 잡생각들이 나오고, 다른 사람들은 어떤 경험을 하고 있는지에 대한 호기심도 크다.
https://x.com/karpathy/status/1959703967694545296?s=46&t=h5Byg6Wosg8MJb4pbPSDow