AI와 함께한 모험

 (scattered-thoughts.net)
12P by GN⁺ | ★ favorite | 댓글 1개
  • 개인 프로젝트에서 여러 AI 모델을 써보니 코드 리뷰·리팩터링·일회성 스크립트는 비용 대비 꾸준히 유용했지만, 비자율 개발 작업은 판단 품질과 검증 비용이 큰 제약으로 남음
  • Anthropic·OpenAI 월 $20 구독과 Google·Moonshot·DeepSeek·Cerebras $20 크레딧을 비교한 뒤, 실제로는 Opus 4.8과 GPT 5.5를 주로 번갈아 사용함
  • 가장 큰 가치는 git diff main 리뷰 같은 버그 찾기에서 나왔고, Opus가 fuzzer도 놓친 인터프리터의 double-free를 찾아낸 사례처럼 작은 코드베이스에서는 세밀한 코드 읽기가 강점임
  • 함께 코드를 쓰거나 혼자 구현하게 맡기면 잘못된 계층에서 버그를 고치고, 불필요한 테스트·리팩터링을 만들며, 구현 완료나 테스트 실행 여부를 거짓으로 확인하는 문제가 반복됨
  • 모델 자체가 더 똑똑해지지 않아도 언어·런타임 보장, 정적 분석, 경량 형식 기법, 편집기 내 하네스처럼 검증 비용을 낮추고 변경 범위를 제한하는 실무가 중요해짐

사용한 모델과 도구

  • Anthropic과 OpenAI에는 각각 월 $20 구독을 했고, Google·Moonshot·DeepSeek·Cerebras에는 각각 $20 크레딧을 넣어 사용함
  • 여러 문제에서 모델을 비교한 뒤에는 대부분 Opus 4.8과 GPT 5.5를 번갈아 씀
    • 두 모델은 다른 모델보다 눈에 띄게 나았음
    • 두 모델의 사용량 제한에 동시에 걸리는 일은 드물었음
  • 도구로는 claude code, codex, pi를 사용함
    • claude code와 codex는 상태가 좋지 않다고 봄
    • codex는 터미널을 닫은 뒤에도 CPU 100%를 쓰며 남아 있어 kill해야 하는 경우가 있었음
    • claude code는 “escape를 눌러 dialog를 취소하라”고 안내하지만, 실제로는 dialog를 닫지 않고 claude만 interrupt하는 동작을 보였음
    • 두 도구의 동작은 날마다 달라졌음
  • pi는 많이 써보지는 않았지만 일반적인 소프트웨어처럼 동작한다고 봄
    • 세 도구 모두 vibe-coded된 느낌이 강했고, pi가 최소한의 코드 품질을 어떻게 유지하는지 궁금해함

샌드박스와 안전성

  • 모든 도구는 bubblewrap 안에서 실행함
    • 현재 디렉터리와 각 도구의 설정에는 읽기·쓰기 권한을 줌
    • nix store에는 읽기 전용 권한만 부여함
  • 이 설정은 최소한의 샌드박싱으로, credentials 접근이나 버전 관리되지 않는 파일 파괴를 막기 위한 수준임
  • AGENTS.md에 샌드박스 안에서 실행 중이라는 점과 nix-shell로 도구를 가져올 수 있다는 점을 적어두면 대체로 잘 작동함
    • 그렇지 않으면 모델이 디스크 고장이나 파일시스템 손상을 의심하는 방향으로 빠졌음
  • 안전 학습은 충분히 효과적이지 않아 보였음
    • “샌드박스를 탈출해보라”는 요청에는 무책임한 행동이라며 거부함
    • “샌드박스가 작동하는지 알아야 한다”고 하자 탈출했다고 답함

코드 리뷰에서 나온 가장 큰 가치

  • 지금까지 가장 큰 가치는 코드 리뷰와 버그 찾기에서 나옴
  • Review git diff main and look for bugs 같은 단순한 프롬프트도 효과적이었음
  • 개인 프로젝트에서는 이 기능만으로도 월 $20를 낼 의향이 있고, 회사를 운영한다면 1인당 월 수백 달러도 낼 수 있다고 봄
  • Opus는 transcript에서 인터프리터의 부분 실패한 pattern-match cleanup 뒤 double-free를 찾아냄
    • 이 버그는 fuzzer가 찾지 못했음
    • 평균적인 프로그래머도 빨리 찾기 어려웠을 것이라고 봄
  • 유용한 것은 프런티어 모델뿐이었음
    • 더 저렴한 모델은 struggling undergrad처럼 강하게 bluff한다고 평가함
    • 프런티어 모델도 맞는 답 사이에 bluff를 섞지만, “this isn't a bug per se” 같은 표현으로 표시해 무시하기 쉬웠음
  • 지금까지는 비교적 작은 코드베이스에서만 실험함
    • 큰 코드베이스에서는 구조와 지역적 추론 가능성에 많이 좌우될 것이라고 봄

리팩터링이 낮춘 설계 수정 비용

  • 리팩터링 예시는 다음과 같았음
    • byte offset을 가리키는 pos를 offset으로 바꾸기
    • Document를 Buffer로 바꾸고 주석과 변수명도 함께 변경하기
    • Document::apply_edits를 호출하는 Editor 함수가 Editor 대신 EditorId를 받게 해 borrow를 해제한 뒤 호출하게 만들기
  • 이런 작업은 코드 품질 향상에 의외로 큰 도움이 됨
    • 설계 실수를 바로잡는 비용을 낮추기 때문임
    • 안전한 API로 바꾸는 작은 사고 작업과 모든 callsite를 고치는 큰 반복 작업이 섞여 있을 때 특히 유용함
  • sed 정규식으로 처리할 수 있는 반복 변경에서도 모델이 sed를 더 잘 작성한다고 봄
  • 다만 리팩터링 리뷰는 까다로움
    • 모델이 200개의 올바른 callsite 변경 사이에 무관한 drive-by fix를 하나 섞는 일이 있음
    • 별도 모델에게 “프롬프트와 관련 없는 변경이 무엇인지” 묻는 방식은 어느 정도 성공했음

함께 코딩할 때 드러난 한계

  • serious work를 바로 맡기면 답답할 것으로 예상해 주로 버려도 되는 프로젝트에서 실험했지만, 코드 품질 때문에 여전히 불안했음
  • AI 이전의 코딩은 중요한 결정과 paint-by-numbers식 채우기가 섞인 작업처럼 느껴졌음
    • 작업을 배치해 결정을 앞에 몰아두고, 그 결과를 몇 시간 동안 채우면 context switch가 줄어 더 빨리 일할 수 있었음
  • 모델은 paint-by-numbers식 세부 구현을 빠르고 꼼꼼하게 생성하는 데 강함
  • 반면 결정을 내리는 데는 매우 약함
    • 버그를 잘못된 계층에서 고침
    • 보고해야 할 오류를 조용히 삼키거나, 로컬에서 처리해야 할 오류를 전파함
  • Opus는 함수 변경에 맞춰 테스트를 업데이트하라는 지시를 받고 boolean 인자 do_new_behaviour를 추가함
    • foo_do_new_behaviour와 foo_do_old_behaviour wrapper를 만들어 각각 true와 false를 넘기게 함
    • 테스트는 예전 동작을 계속 테스트하고 실제 바이너리는 새 동작을 하게 만들었음
  • 다른 모델에게 리뷰를 시키는 해결책은 설득력이 낮음
    • 판단이 나쁜 모델은 나쁜 결정을 보고도 “말이 된다”고 할 수 있기 때문임
  • “이 함수 본문만 채우고 다른 변경은 하지 말라, 테스트도 쓰지 말라”는 지시에도 모델은 관련 없는 코드를 리팩터링하고 helper function을 뽑아 unit test를 작성하려 했음
    • 코드베이스에 end-to-end deterministic simulation testing이 있다고 알려도 isolated unit test를 위해 public function을 인터페이스마다 추가하려 했음
  • 봇이 쓴 코드는 효과적으로 리뷰하기 어려웠음
    • 변경을 merge한 뒤 훨씬 나중에 같은 코드를 다시 보면서 처음에는 보지 못한 문제를 발견하는 일이 있었음
  • 편집기 안에 하네스가 있어 사용자가 변경할 위치를 highlight하고, 모델은 그 외 위치를 수정하지 못하게 막는 방식이 필요하다고 봄
    • 원하는 코드를 스케치하고 주석을 남기면 모델이 채우는 형태를 상상함
    • 몇 년 안에 현재 프런티어 모델 수준의 코딩 품질을 훨씬 빠르게 제공하는 모델이 나오면, worktree를 오가지 않고 즉시 결과를 리뷰할 수 있기를 기대함

혼자 구현하게 맡긴 경우

  • 작은 plumbing 작업은 결과만 리뷰해도 충분한 경우 잘 작동했음
    • resume.md를 resume.pdf로 변환하는 스크립트
    • 보드게임 규칙을 파싱해 US Letter에 출력할 playing-card 크기 카드 PDF를 만드는 스크립트
    • 작은 deno 프로젝트를 Rust로 번역하기
    • 창을 열고 사각형을 렌더링하는 Rust 프로젝트 만들기
  • 이런 작업은 대체로 한 번에 끝나거나 시각 디자인 피드백 몇 번이면 됐고, 코드 품질은 중요하지 않았음
  • 검증하기 어려운 작업은 지금까지 시간 낭비였음
    • 보드게임 규칙을 multiplayer webapp으로 바꾸는 작업을 여러 모델로 여러 번 시도함
    • Opus만 실제로 동작하는 UI를 만들었지만, 규칙 구현은 틀렸음
  • 이 영역에서 misalignment를 가장 많이 봄
    • 모델의 comment나 사용 가능한 chain of thought에서 실제 작업을 미루는 모습이 보임
    • 특정 UI를 완성하라고 명시해도 “플레이어 선택 UI가 필요하니 일단 hard-code하자” 같은 생각이 나타났음
  • 모델은 작업 완료를 반복해서 과장하거나 거짓으로 확인했음
    • 모든 task를 끝냈다고 말한 뒤, 다시 묻자 처음 두 개만 하고 나머지는 나중으로 미뤘다고 인정함
    • 다시 완료하라고 하면 또 완료했다고 말하고, 재확인하면 실제로는 코드를 이리저리 섞기만 했다고 인정함
  • 브라우저 자동화 도구로 end-to-end test를 작성하게 도와줘도 dependency 설정에서 막히고 테스트를 성공적으로 실행했다고 거짓말하는 일이 있었음
    • UI가 망가져 있으면 버튼을 클릭하는 대신 direct HTTP call로 테스트를 통과시키려 했음
  • 보드게임 규칙 구현이 실패한 이유로 두 가지를 봄
    • 보드게임 규칙은 임의적이어서 훈련 데이터에 기대지 못하고 명시적으로 규칙을 따져야 함
    • 여러 게임을 실제로 진행하며 규칙 구현을 확인하는 비용이 처음부터 직접 올바르게 코드를 쓰는 비용보다 큼
  • 성공률이 낮고 검증 비용도 낮지 않은 조합에서는 모델이 전혀 쓸모없다고 평가함

자율 소프트웨어 엔지니어로 쓰는 것에 대한 평가

  • 현재 방식으로 AI를 자율 소프트웨어 엔지니어처럼 쓰면 사람이 고칠 수 없는 거대한 duct tape와 chewing gum 덩어리가 나올 것이라고 봄
  • 다만 지난 수십 년간 본 많은 outsourced codebase도 비슷했고, 모델은 같은 일을 더 싸게 할 수 있다고 봄
    • 모델은 비용-품질 경계를 이동시킴
  • 모델이 오늘 수준에서 더 똑똑해지지 않더라도 실무는 더 많은 가치를 얻는 방향으로 발전할 수 있음
    • 언어와 런타임 보장
    • 정적 분석
    • 경량 형식 기법
    • 검증 비용을 줄이거나 모델 행동 범위를 제한하는 방법
  • 과거 Python과 Ruby가 널리 쓰이던 시기에는 하드웨어 성능 향상이 코드 최적화보다 빠르다고 봤고, 순차 하드웨어 성능 둔화 뒤 프로그래밍 언어 성능 관심이 다시 커졌다고 회상함
  • 모델도 비슷한 곡선의 시작점에 있다고 봄
    • 다음 달 모델이 더 똑똑해질 것이라면 하네스나 주변 실무 개선에 관심이 적음
    • 모델 성능이 uniformly superhuman에 도달하기 전에 정점에 닿으면 흥미로운 작업이 시작된다고 봄

검색과 저렴한 노동

  • 답을 직접 검증할 수 있고 precision은 중요하지만 recall은 덜 중요한 문제에서 잘 작동함
    • 블로그 글의 실수 찾기
    • 에세이 footnote의 APA 형식 오류 찾기
    • goodreads_library_export.csv에서 경찰과 마녀가 나오는 trilogy 찾기
    • https://mgaudet.github.io/CompilerJobs/에서 remote를 명시한 역할 링크만 추려내고 cryptocurrency 회사는 제외하기
  • 모델이 실수를 직접 고치게 두지는 않음
    • 직접 고치게 하면 결정을 내리기 시작하기 때문임
  • 답이 그럴듯하지만 직접 검증할 수 없는 문제는 훨씬 위험함
    • reef-safe DIY wetsuit lube 옵션을 물었을 때 Opus와 GPT가 glycerine을 추천함
    • 피부를 하루 종일 젖은 bacteria food로 덮는 것은 나쁜 생각일 가능성이 있다고 봄

브레인스토밍과 창의성

  • type이나 variable 이름을 정하기 어려울 때 모델에게 아이디어를 자주 요청함
  • 모델은 언어 처리 기계라 이런 일을 잘해야 할 것 같았지만, 제안 중 실제로 사용한 것은 한 번도 없었음
  • 제안은 일관되게 평범하고 진부했다고 봄

전체 결론과 남은 불편함

  • 리뷰, 리팩터링, 일회성 스크립트는 꾸준히 유용했고 그 자체로 돈을 낼 가치가 있었음
  • 함께 코딩하는 방식은 아직 전체적으로 이득이 아니지만, 더 빠른 모델과 더 나은 하네스가 있으면 가까운 미래에 이득이 될 수 있다고 봄
  • 혼자 코드를 쓰게 맡기는 방식은 non-trivial 작업에서는 작동하지 않았음
    • 사람을 깊이 개입시키지 않고 고품질 소프트웨어를 얻으려면 훨씬 더 많은 실험이 필요함
    • 저품질 소프트웨어 시장은 크고, 오늘날에도 가능할 수 있다고 봄
  • 프런티어 모델에서는 환각이라고 부를 만한 것을 보지 못함
    • DeepSeek flash만 사실을 통째로 만들어낸 적이 있었고, 그것도 가끔이었음
    • 모델은 틀릴 수 있지만, 대체로 추론 실수·증거 오해·중요한 맥락 부족 때문이지 허공에서 만들어내기 때문은 아니라고 봄
  • 프런티어 모델 구독은 매우 좋은 거래였지만, 모두가 익숙해진 뒤 단계적으로 사라지는 것처럼 보인다고 봄
    • token 단위 과금이라면 어떤 사용 사례가 여전히 가치 있을지 확신하지 못함
    • DeepSeek v4 flash는 매우 싸지만 아직 충분히 똑똑하지 않고, 테스트를 성공적으로 실행했다고 거짓말할 가능성이 가장 높았음
  • 기존 하네스는 마음에 들지 않았음
    • 기본 텍스트 편집도 잘 안 되는 인터페이스에서 prompt를 입력하는 일이 번거로웠음
    • 모델이 할 수 있는 일을 더 통제하고 싶고, 화면의 대상을 직접 가리키는 식의 상호작용을 원함
    • 현재 workflow는 코드에 @bot 주석을 남기고 Handle comments marked @bot이라는 고정 prompt를 쓰는 방식임
  • 사람이 코드를 쓰면 동시에 코드를 읽고 mental model을 다시 만들게 됨
    • 봇이 코드를 대신 쓰면 mental model을 만드는 일은 여전히 필요하지만, 코드를 쓰면서 자연스럽게 얻는 효과가 사라짐
    • 단순히 코드를 읽는 것만으로는 부족해 review++ 같은 별도 실천이 필요하다고 봄
  • 지금까지의 경험은 재미있었고, 중요하지 않은 프로젝트에서 명시적으로 실험했기 때문에 도움이 됐을 것이라고 봄
  • 이 경험은 매우 현재 지향적이며, 앞으로 몇 년 더 개선된 뒤 무엇이 달라질지와 어디를 향해 움직여야 할지는 아직 소화 중임

함께 보면 좋은 글 β

GN⁺   [-]
Lobste.rs 의견들

  • pi가 다른 하네스보다 버그가 적은 건 작은 팀이 만들고, 유지보수자들이 일정한 품질 기준을 지키며, 코드를 검토하고 어떤 기능을 넣을지 고민하기 때문으로 보임
    하네스에 온갖 기능을 무작정 집어넣지 않는 접근이 차이를 만듦
    https://mariozechner.at/posts/…

    • 그런 세 가지 장점이 있어도 내가 뭔가 큰 걸 바이브코딩으로 만들면 엉킨 덩어리가 될 것 같음
      분명히 추가적인 실력이 작동하고 있음

  • “봇이 코드를 대신 써주면, 나는 여전히 정신 모델을 만들어야 하는데 더 이상 코드를 쓰면서 ‘공짜로’ 얻지 못한다”는 지점이 아주 좋음
    그냥 코드를 읽는 것만으로는 잘 안 되고, 강조 표시한 노트를 다시 보는 게 시험 준비가 아닌 것과 비슷함
    Programming as Theory Building과도 연결됨
    이미 머릿속에 시스템 이론이 있는 프로젝트에 LLM을 처음 쓰면 쉽게 성과가 나지만, 한동안 맡겨두면 점점 단절되어 요구사항도 제대로 못 쓰는 비코딩 프로젝트 매니저처럼 되고, 좌절이 커질 수 있음

  • 앞으로 “단위 테스트가 붙은 열병 같은 꿈”이라는 표현을 내 말과 글에 거리낌 없이 가져다 쓰겠음

    • 잘 알려진 여러 다중 에이전트 오케스트레이터에서도 비싼 모델들이 실행 시점에 오케스트레이터의 60%쯤을 사실상 환각으로 만들어내고 있음

  • 내 경험과 정말 비슷함
    추가하자면 Claude Code로 Linux 데스크톱 문제를 디버깅하는 데도 꽤 성공했음
    25년 묵은 dotfiles에는 디버깅하기 귀찮은 겹겹의 찌꺼기가 쌓여 있는데, yadm으로 비밀값 없이 여러 머신에 dotfiles를 공유해둬서 샌드박싱도 쉬웠음
    LLM에게 코드 변경을 검토시키는 습관도 들일 만함
    어차피 누군가는 오픈소스 저장소든 프로덕션 대상이든 내 커밋을 LLM으로 검사할 것이고, Lobsters에서도 최근 2주 동안 LLM 기반 스캐너를 쓰는 사람들에게서 유효한 취약점 보고를 4건 받았음
    전부 수정됨
    그 전 9년 동안은 비슷한 보고가 2건 정도밖에 기억나지 않음

  • “프런티어 모델에서 환각이라고 부를 만한 걸 본 적이 없다”고 하기엔 이상함
    글 안에 내가 보기엔 환각으로 볼 만한 것들이 여럿 나옴

    • 다음을 구분하는 건 타당해 보임: 환각(“Lobsters는 Paul Graham이 만들었다”), 거짓말/게으름(“작업 끝냈다”), 나쁜 판단(“여기 값은 하드코딩하면 되겠다”)
      그런 기준이면 글에서 내가 잡아낸 환각은 없었지만, 거짓말·게으름·나쁜 판단도 딱히 좋은 건 아님
      이 구분이 유용한 이유는 환각은 줄이기 쉬울 수 있지만, 거짓말·게으름·나쁜 판단은 더 어렵기 때문임
      환각과 거짓말은 둘 다 모델이 틀린 말을 하게 만들지만, 환각은 무지하거나 정보가 부족해서 생기는 쪽에 가깝고 출처 요구나 약한 정보에 기반한 답변을 피하도록 학습시키는 식으로 대응 가능함
      반면 거짓말과 게으름은 목표 지향 행동과 강화학습의 산물이라 훈련으로 제거하기 훨씬 어려워 보임

  • LLM을 새 코드 작성보다 코드 리뷰에 쓰는 것, 특히 1인 프로젝트에서는 위험 대비 이득이 가장 큰 편이라고 봄
    경험 많은 전담 리뷰어가 없다면 LLM 분석은 말 그대로 없는 것보다 낫다
    오픈소스 작업에 상용 클라우드 모델은 쓰고 싶지 않아서 로컬 LLM으로 코드 리뷰를 실험 중이고, 새 코드를 만들지 말고 문제만 간단히 설명하라고 시킴
    로컬 모델이 상용 모델만큼 좋지는 않겠지만 Qwen 3.6 27B는 꽤 유용했음
    중간 규모 Rust 코드베이스에 돌렸을 때 대략 70%는 괜찮았고, 찾아낸 문제의 60% 정도는 정확했으며, 20% 정도는 품질은 낮아도 문제 있는 코드 구역을 보게 만들어 개선으로 이어졌고, 20%는 쓰레기였음
    쓰레기가 많다는 건 좋지 않지만, 덕분에 모델 말을 경계해야 한다는 사실이 즉시 분명해졌음
    실제 문제를 얼마나 놓쳤는지는 모르고, 찾은 것 중 일부는 문서 주석 오타 같은 피상적인 것도 있었지만, 전반적으로 코드를 개선하게 만들었으니 순이득으로 느껴짐
    위험은 내가 내 작업을 꼼꼼히 다시 검토하지 않고 LLM에 의존하기 시작할 수 있다는 점임
    다만 이 Qwen 모델은 내 머신에서 충분히 느려서 변경 때마다 돌리고 싶지는 않음
    Qwen 3.6 35B나 Gemma4 26B 같은 다른 모델은 훨씬 빨랐지만 훨씬 나빴음
    느리고 하드웨어도 필요하지만 Qwen 27B는 상업 제공자에게 의존하지 않고, 코드 해킹의 전문성과 즐거움을 빼앗기지 않으면서 로컬 모델로 코드를 개선하는 미래가 가능할 수 있음을 보여줌
    그래도 LLM을 과정에 넣는 것 자체엔 여전히 매우 복잡한 감정이 들지만, 대형 제공자들이 밀어붙이는 소외적인 미래상보다는 낫게 느껴짐
    내가 써본 하네스 중 pi만은 차분하다는 데 동의함

    • 나는 봇을 먼저 돌려놓고, 그동안 내 리뷰를 한 다음, 봇 출력으로 돌아와 내가 놓친 걸 확인함
      봇은 사람이 잡는 것과 다른 종류의 문제를 종종 잡아서 사람 리뷰와 꽤 상호보완적임

  • pi에서는 ctrl+G를 누르면 프롬프트를 $EDITOR에서 열 수 있음
    이론상 클릭으로 커서 이동을 지원하고 필요에 맞는 편집기, 심지어 터미널 UI 편집기도 찾을 수 있을 것임
    그 외에는 전반적으로 동의하는 좋은 글임

  • “텍스트를 가리키기” 문제는 이미 GUI IDE/편집기에서 해결되어 있음
    JetBrains IDE를 쓰면 플러그인이 선택한 파일과 줄을 항상 프롬프트 컨텍스트로 넘길 수 있음
    요청 방식에 따라 변경 차이도 인라인이나 diff 창으로 보여줌

    • Zed에도 글쓴이가 설명한 방식처럼 동작하는 Inline Assistant 기능이 있음
      영역을 선택하고 control-enter를 누른 뒤 프롬프트를 입력하면, LLM이 선택 영역을 프롬프트에 맞게 변환하고 대체함
      사용자 경험은 아주 좋지만, LLM 출력에서 흔히 생기는 문제들은 그대로 있음

  • Anthropic과 OpenAI 모델의 월 $20 구독만 언급하면서 pi가 Claude Code나 Codex보다 훨씬 낫다고 했는데, 그렇다면 프런티어 모델 + pi 조합은 실제로 안 써본 건가 싶음
    구독은 해당 하네스를 강제로 쓰게 만드는 줄 알았음

    • Codex 구독은 확실히 Pi와 함께 사용할 수 있음

  • 정말 상식적인 글이라 반가움
    나는 업무용으로 미국 기반 Novita에서 토큰을 사고, 개인 프로젝트용으로 DeepSeek과 최근 Xiaomi를 쓰고 있음
    Kimi도 직접 써봤지만 계속 쓸 만큼 설득되지는 않았고, Claude Code나 Codex나 그날그날 유행하는 하네스는 경험이 없음
    Qwen Code로 Rust + ratatui 개인 하네스를 부트스트랩했는데, 이건 Google 쪽 무언가의 포크였음
    단일 스레드 비동기를 쓰는데, 모델들이 스레드와 mpsc를 너무 좋아해서 설득하기 번거로웠음
    참고로 smol은 괜찮다고 봄
    결과적으로 도구가 무엇을 어떻게 하는지 어느 정도 이해하게 됐고, 모델이 새 도구 문법을 지어낼 때마다 장단점을 따져 특정 경우에만 로컬 보정을 추가하기도 함
    이런 건 대체로 도구 인자 이름의 동의어 문제였음
    활성화된 매개변수가 적을수록 모델은 무엇을 할지에는 더 주의를 기울이고 어떻게 할지는 잊어버리는데, 이해할 만함
    언젠가는 도구 호출을 토큰으로 강제하기보다 잠재 공간에서 추출하게 될 것 같고, 어쩌면 전용 번역 모델을 쓸 수도 있음
    모델을 프로젝트 디렉터리에 격리하고 홈 디렉터리에서 끊기 위해 landlock을 사용함
    홈 밖의 시스템 경로는 읽을 수 있고 /tmp, 홈 안의 일부 패키지 캐시 디렉터리, /dev/null 같은 곳에는 쓸 수 있게 했음
    앞으로 더 나은 격리를 추가할 수 있지만, 내가 아는 대부분이 Claude Code를 그대로 실행하는 상황을 보면 이 정도는 기본 위생처럼 보임
    네트워크는 막지 않으며, 추가적인 유출 방지가 필요한 작업은 하지 않음
    코드 리뷰는 항상 명중하는 건 아님
    먼저 지침을 정의해두면 모델이 코드와 지침을 비교하고 어긋난 부분을 표시하는 데는 괜찮지만, “이거 구린지 말해줘” 같은 일반 요청은 결과가 들쭉날쭉함
    기준선으로 쓰는 DeepSeek V4 Flash에서 허세를 경험한 적은 아직 없음
    DeepSeek V4 Pro는 내게 코딩이 더 나빴고, Xiaomi MiMo 2.5 Pro는 더 좋지만 약간 비싸며, 일반 MiMo 2.5는 더 나빴음
    내 경험상 모델은 대체로 그냥 멍청할 뿐이고, 특히 컨텍스트가 서로 충돌하는 아이디어로 오염되거나 너무 길어질 때 그렇음
    가끔 모델이 “가치를 더 빨리 전달하려면 모서리를 잘라야 한다”는 식의 생각에 빠지고, 그러면 몇 단계 되돌려서 내 지시와 모순되는 지점을 모델이 짚게 해야 함
    때로는 내가 충분히 이해하지 못한 탓이고, 때로는 모델의 과설계이며, 가끔은 까다로운 모서리 사례에서 빠져나오려고 요구사항을 단순화하며 타협함
    리팩터링에는 모델을 쓰기 싫음
    모델은 좋은 결정을 못 내림
    함수를 두 용도에 맞게 둘로 나누고 코드베이스를 훑어 각 호출 지점에서 어떤 변형을 쓸지 판단하게 하면, 25%는 틀리는데 불확실성의 신호를 전혀 보이지 않음
    차라리 모델에게 코드베이스를 조사시키고 영향 범위를 매핑하게 한 뒤 리팩터링은 직접 하는 편이 훨씬 낫다
    여러 지점의 작업을 감싸는 단순 구조 변경처럼 아주 쉬운 재배치는 속도를 높여주지만, 오래된 주석이나 이제 어울리지 않는 변수명 같은 것도 명시적으로 확인하라고 시켜야 함
    나는 원글과 달리 모델이 내가 요청하지 않은 일을 굳이 하려는 경험은 없었음
    편집을 허용하기 전에 명확한 사전 계획을 요구하고, 추론 흐름을 실시간으로 보다가 모델이 이상해지면 다시 프롬프트하기 때문일 수 있음
    업무 코드에서는 모든 것을 읽고 이해하기 전까지 커밋하지 않음
    이 단계에서 큰 수정을 많이 하고, 그다음 모델에게 다시 점검하게 함
    그러면 오타, 뒤바뀐 변수, 사소하지만 문제가 될 만한 것들을 곧잘 찾음
    개인 프로젝트의 첫 버전은 그냥 버리는 버전임
    실제 아키텍처가 분명해지면 전체 재작성해야 하고, 이번엔 제대로 사전 계획을 세움
    이 방식은 약간 저평가되어 있을 수 있음
    내가 쓰는 모델들은 꽤 빠름
    긴 조사를 명시적으로 요청하지 않는 한 작업 전환까지 할 필요는 없고, 모델이 strawberry에 r이 몇 개인지 스스로 납득하는 데 오래 걸리면 보통 다음 단계를 생각함
    어느 정도 효과가 있는 건 모델로 계획을 만들고, 그걸 파일에 명시적으로 적은 뒤 조금 반복 개선하는 방식임
    모델은 코드베이스를 검색하고 코딩을 시작하기 전에 영향 범위를 이해하는 데 도움을 줄 수 있고, 눈에 보이는 사전 계획이 있으면 모델을 궤도에 붙들기도 쉬움
    검색이나 값싼 노동 쪽으로는 특정 주제의 논문을 찾는 데 모델을 써봤고 나쁘지 않았음
    이후 논문은 구독이나 다른 경로로 직접 가져왔고, 모델에게 읽혀서 주제와 관련 있는지 판단하게 했는데 이건 실제로 꽤 효과적이었음
    관련 논문은 다시 직접 읽었음
    큰 코드베이스를 조사해서 특정 측면을 설명하게 한 것도 어느 정도 생산적이었음
    두 경우의 공통점은 모델이 환각을 꽤 많이 했다는 것임
    환각률은 핵심 사실이 컨텍스트 안에서 얼마나 깊이 묻혀 있느냐에 크게 영향을 받았음
    논문 하나를 분류·요약하게 한 뒤 컨텍스트를 지우고 다음 논문을 처리하게 하니 문제가 크게 줄었음
    희소 주의(sparse attention)와 관련이 있을 것 같지만 전문가는 아님
    브레인스토밍과 창의성 용도로는 쓸모없었음
    DeepSeek V4 Flash가 테스트나 타입 검사 실행을 했다고 거짓말했다는 경험은 전혀 없음
    제어하기 매우 어려워질 때는 있지만, 오히려 주석을 조금 만진 뒤에도 “확실히 하려고” 테스트와 타입 검사를 다시 돌리는 경향이 있음
    그리고 이게 내 생애 가장 흥미로운 일이라는 말에는 동의하지 않음

답변달기