TL;DR

  • 18년간 매일 손으로 코드를 작성한 뒤, Opus 4.5와 Claude Code를 계기로 원하는 바를 설명하는 편이 직접 작성하는 것보다 빨라져 손코딩으로 돌아갈 생각이 없어짐.
  • Filestage는 개발자당 월 20달러의 AI 구독 비용으로 월간 병합 풀 리퀘스트(PR)를 약 200건에서 300건으로 늘렸으며, 버그 신고는 증가하지 않음.
  • 지속적 통합(CI)의 린팅, 타입 검사, 중복 검사, 100% 테스트 커버리지, 엔드투엔드 테스트가 에이전트 변경 사항을 점검하며, AI 코드 리뷰 없이 병합하는 일이 무책임할 수 있다는 판단이 생김.
  • 에이전트가 더 많은 코드를 생성하더라도 의도와 제약을 드러내는 고수준 추상화는 유용하며, 대형 언어 모델(LLM) → 고수준 표현 → 결정론적 컴파일러 → 기계어 흐름이 여전히 적절하다는 관점임.
  • 코드 파일 대신 로직, 인터페이스, 데이터 모델을 직접 다루고 실제 운영 데이터 흐름까지 살펴보는 개발 환경이 수년 만에 처음으로 현실에 가까워졌다는 기대임.

더 많이 배포하고, 같은 수준의 안전장치 유지

  • 지난해부터 웹 채팅에 코드를 붙여 의견을 구하거나, 영어로 쿼리를 설명하거나, 정규식 문법을 묻는 등 AI를 일상 업무에 조금씩 활용함.
  • Claude Code의 Opus 4.5가 전환점이 됨. 원하는 바를 설명하는 편이 직접 코드를 작성하는 것보다 빨라졌으며, 거의 20년간 이어진 매일의 습관이 사라짐. 몇 달이 지난 지금도 코드를 손으로 만지고 싶은 마음은 점점 줄어들며, 이전 방식으로 돌아가는 모습을 상상하기 어려움.
  • 오랫동안 익힌 일을 기계가 대신하는 모습이 불편하게 느껴질 수 있다는 점을 이해하지만, 반복해서 드는 감정은 해방감임. 미뤄뒀을 개선 작업을 프롬프트로 시작할 수 있으며, 상상한 것의 상당 부분을 직접 만들 수 있다는 점이 놀라움.
  • Filestage는 월간 병합 PR이 약 200건에서 300건으로 증가했으며, 버그 신고는 늘지 않음. 개발자당 월 20달러의 AI 구독 비용이 들며, 각자 Codex, Claude Code, Cursor 중 원하는 도구를 선택함.
  • PR 수는 성과의 일부만 보여줌. 제품 전반에 걸친 더 큰 변경도 더 짧은 시간에 더 큰 확신을 갖고 진행함.
  • AI 에이전트의 성능 향상과 함께 지속적 통합(CI) 안전장치에 대한 투자가 효과를 냄.
  • 린팅, 타입 검사, 중복 검사, 100% 테스트 커버리지, 엔드투엔드 테스트가 포함됨.
  • 에이전트가 변경을 만들 때마다 해당 검사에서 피드백을 받음.
  • 모델 성능이 충분히 좋아져 AI 코드 리뷰 없이 병합하는 것은 무책임할 수 있다고 판단함. 검사 통과와 AI 리뷰 승인을 얻는 것만으로 PR 병합이 가능해질지 검토 중이나, 아직 결론을 내리지는 않음. 다만 더는 터무니없는 생각으로 들리지 않음.
  • 처리량 증가로 CI 병목이 드러남. 엔드투엔드 테스트 인스턴스가 외부 서비스의 웹훅을 받아야 했고, 그 결과 Cloudflare 무료 터널 한도에 걸려 엔지니어들의 CI가 중단되기 시작함. 공유 개발 데이터베이스도 연결을 처리할 수 있도록 리소스를 늘려야 했음.
  • 인프라스트럭처 코드(IaC) 구성과 오픈 소스 FRP 터널을 사용해 빠르게 바이브 코딩으로 해결책을 구축함. 추가 부하를 만든 도구가 병목 제거에도 도움을 줌.

추상화는 여전히 중요함

  • DHH의 Rails World 기조연설에서 손코딩의 종말을 다룬 내용에 상당 부분 동의함. 다만 에이전트가 Rust와 C++에서 어셈블리어로, 궁극적으로 마이크로코드로 옮겨갈 것이라는 예측은 지나치다고 봄.
  • 에이전트가 직접 선택하지 않을 언어로 더 빠른 구현을 작성하게 하는 매력은 이해함. 그러나 현재 LLM이 코드를 생성하는 방식을 고려하면 고수준 표현은 에이전트에도 유용함.
  • 생성하는 코드가 많아질수록 정확히 맞춰야 하는 세부 사항도 늘어남. 어셈블리어를 생성하려면 컴파일러가 처리할 수 있는 레지스터, 오프셋, 호출 규약 세부 사항까지 예측해야 함.
  • 간결한 코드는 문맥을 보존함. users.filter(u => u.active)는 몇 개의 토큰으로 표현되는 작업이지만, 어셈블리어로는 여러 명령어가 필요할 수 있음. 이미 20만 토큰에 달하는 저장소를 이해하는 일도 충분히 어려운데, 이를 저수준 명령어로 확장하면 부담이 커짐.
  • 타입, 함수, 모듈, 소유권, 데이터 구조는 의도와 제약을 드러내며 추론을 돕는 추상화임. 모든 것을 어셈블리어로 낮추면 이런 정보를 다시 파악하기 어려워짐.
  • Clang 같은 도구가 이미 소스 코드를 네이티브 기계어로 변환함. 결정론적 컴파일러가 효율적으로 처리하는 일반적인 변환을 확률적 추론으로 재현할 이유는 크지 않음. 특정 부분의 어셈블리어 최적화는 가치가 있을 수 있지만, 전체 시스템의 기본 표현으로 삼지는 않을 것임.
  • 선호하는 흐름은 LLM → 고수준 표현 → 결정론적 컴파일러 → 기계어임. 표현 방식은 바뀔 수 있지만, 에이전트가 더 큰 시스템을 맡을수록 유용한 추상화의 가치가 더 커질 것으로 봄.

텍스트 파일 다음에는 무엇이 올까?

  • 소프트웨어를 만드는 방식에 늘 불만이 있었음. Bret Victor의 「The Future of Programming」은 수십 년 전에 탐구된 가능성과 우리가 결국 선택한 방식을 비교하며 그 감정을 잘 담아냄.
  • 괄호와 따옴표의 짝을 맞추고, 탭과 공백을 두고 논쟁하며, 작동 방식을 파악하려 수백 개 파일을 검색하는 일에 오랜 시간을 씀. 포매터와 린터가 도움이 됐지만, 작은 코드 조각을 보는 동안 시스템 전체를 머릿속에 담아야 했음.
  • 에이전트가 코드를 처리할 수 있다면 원하는 로직, 인터페이스, 데이터 모델을 직접 다룰 수 있을지 질문함. UML과 엔터티 관계 다이어그램이 시스템 변경에 맞춰 동기화되는 실용적인 일상 인터페이스가 될 수 있는지도 궁금함.
  • 사용 사례를 보고 그 로직 안으로 들어가며, 필요할 때는 코드까지 내려가고 싶음. 데이터가 어떻게 이동하는지 살펴보고, 실제 운영 맥락도 같은 화면에 담고 싶음. 사람들이 실제로 사용하는 경로, 요청이 막히는 지점, 한 번도 실행되지 않는 분기를 확인하고자 함.
  • 그런 개발 환경이 어떤 모습일지는 아직 모르지만, 수년 만에 처음으로 현실에 가까워진 느낌임.
  • 18년 동안 코드를 입력한 뒤 프로그래밍의 감각을 안다고 생각했지만, 이제 다음에는 어떤 감각일지 알아갈 생각에 기대가 큼.