몇 달 동안 예전 방식으로 코딩하는 중

• 코드베이스 학습과 문제 해결 감각을 되찾기 위해, 코딩 에이전트 중심 작업에서 벗어나 손으로 코드를 작성하는 시간에 몇 달을 투입 중
• 코딩 에이전트는 빠른 반복과 동작하는 소프트웨어 출시에 유용했지만, 원하는 바가 불명확할 때 많은 가정을 대신 수행해 학습량과 코드 감각이 줄어드는 경험 존재
• Recurse Center에서 직접 Transformer를 작성하며 LLM을 처음부터 다시 배우고, Python 직관과 컴퓨터의 여러 추상화 계층에 대한 이해도 함께 강화 중
• Stanford CS336 과제를 LLM의 코딩 도움 없이 수행하며 토크나이저, GPT-2 스타일 아키텍처, Tiny Stories와 OpenWebText 기반 실험까지 진행했고, Unix·Vim·Clojure·페어 프로그래밍도 병행 중
• 뛰어난 프로그래머일수록 AI 활용 능력도 높았다는 관찰과 함께, 장기적으로는 에이전트를 더 잘 쓰기 위해서도 손으로 코딩하는 장인적 훈련이 중요하다는 판단

---

LLM과 코딩 경험

• Aily Labs에서 지난 2년간 AI 에이전트를 구축했고, 2024년 초 내부용 웹 검색 에이전트도 개발한 경험
  • Anthropic의 Building Effective AI Agents보다 약 6개월 앞섰고, OpenAI의 DeepResearch보다 1년 앞선 시점이라는 언급
  • Cursor의 조기 활용, LLM 기반 지식 그래프 활용, 새로운 접근법을 지속적으로 실험한 경험 포함
• 주간 저널 클럽을 이끌며 오픈소스 LLM 구축 논문들을 다뤘고, DeepSeek R1, Ai2의 Olmo 3, Meta의 Llama 3 논문 발표 경험
  • 내부 모델 학습과 SOTA 폐쇄형 모델 기반 워크플로 사이의 트레이드오프를 이해하는 데 도움이 된 경험
  • 2023년 처음 LLM을 사용한 뒤 작동 원리와 적용 방식에 대한 호기심이 계속 이어졌다는 언급

코딩 장인의 핵심 요소

• 손으로 코드를 작성할 때는 원하는 것을 구현하는 일과 함께 코드베이스 학습도 동시에 일어났다는 인식
  • 반면 코딩 에이전트를 쓰면 프롬프트에 지정한 결과를 그대로 얻었고, 원하는 바가 정확하지 않을 때는 에이전트가 많은 가정을 대신 수행했다는 경험
  • 그 결과 배우는 양이 줄고 코드베이스에 대한 충분한 감각을 갖기 어려웠다는 판단
• 동시에 코딩 에이전트는 빠른 반복과 동작하는 소프트웨어 출시에 도움을 줬고, 테스트 이후 실용성도 높았다는 평가
  • 또한 훌륭한 튜터 역할도 했다는 언급
• Cal Newport의 글에서 사고와 장인성의 관계를 운동과 건강의 관계에 비유한 대목에 공감한 경험
  • “명확한 메모나 보고서를 작성하기 위한 부담은 제거해야 할 성가심이 아니라 장인의 핵심 요소”라는 인용 포함
  • 같은 원리가 코드 작성에도 적용된다는 관점
• 함께 일한 뛰어난 프로그래머들은 대체로 AI 활용 능력도 뛰어났고, 더 깊은 지식이 이 도구에 대한 더 큰 지렛대를 제공했다는 관찰
  • 에이전트를 프로덕션에 배포하는 일상 속에서도 학습은 계속됐지만, 항상 바빠서 배우지 못한 코딩 및 컴퓨터 개념 목록이 점점 늘어났다는 언급
• 미국으로 돌아가야 하는 시점이 오면서, 이 주제에 집중하기에 Recurse Center가 적절한 장소라는 판단

코드 리트릿이란 무엇인가

• Recurse Center는 Brooklyn의 자기주도형 풀타임 프로그래밍 리트릿
  • 지원 절차와 코딩 인터뷰 이후 참가자들은 각자 프로그래밍 목표를 가지고 입장해 6주 또는 12주 동안 프로그래밍 진행
• 협업성이 주요 특징이며, 수십 년 경력의 프로그래머들과 다양한 전문성을 가진 동료 코호트와 함께하는 환경 강조
  • 무료 프로그램이라는 점도 특징

Recurse Center에서의 목표

• 처음부터 LLM 학습

  • 사전학습과 사후학습을 포함해, 미리 만들어진 코드베이스를 포크하는 대신 직접 Transformer를 작성하는 목표

• Python을 손으로 더 잘 쓰기

  • 몇 년간 Python으로 일했지만 여전히 배울 것이 많다고 느끼며, 문서 참조나 LLM 질문을 최소화하고 프로젝트 구성에 대한 직관을 키우고 싶은 목표

• 컴퓨터를 더 깊이 이해하기

  • 컴퓨터가 여러 추상화 계층에서 동작하는 매우 복잡한 기계라는 인식
  • 정규 Computer Science 교육을 받지 않았기 때문에, 계층들이 어떻게 함께 작동하는지에 대한 더 나은 정신 모델을 만들고 싶은 목표
  • 구체적 계획은 많지 않지만 RC가 적합한 장소라는 판단

진행 상황

• 처음부터 LLM 학습

  • Stanford의 CS336: Language Modeling from Scratch 첫 과제를 LLM의 코딩 도움 없이 수행한 경험
    • 50페이지 분량 과제였고, 다른 Recurser와 함께 Python으로 최적화된 토크나이저를 작성한 뒤 PyTorch로 업그레이드된 GPT-2 스타일 아키텍처를 구축
    • Tiny Stories 데이터셋에서 여러 ablation을 실행해 하이퍼파라미터를 조정했고, 이후 약 90억 토큰 규모 OpenWebText 데이터셋에 해당 하이퍼파라미터 적용
  • 이후 과제로 언어 모델 최적화, 스케일링 법칙 추정 및 계산, 원시 텍스트의 사전학습 데이터 변환, 모델 사후학습까지 진행할 계획
    • 두 번째 과제는 GPU 프로파일링과 Triton으로 FlashAttention2 구현 포함
    • 과제 핵심 부분을 마친 뒤 자체 모델 post-train 목표

• Python을 처음부터 더 잘 쓰기

  • 연습을 위해 Python 또는 PyTorch로 작은 에이전트와 신경망을 많이 작성 중
  • 가장 큰 도움이 된 요소는 10년 이상 Python으로 일한 사람들과의 페어 프로그래밍 경험
    • 상대가 문법이나 연산을 정확히 기억하지 못할 때, 터미널을 열고 아주 단순한 예제를 직접 입력해 빠르게 반복 확인하는 방식을 익힌 사례
    • 보통 1분 이내에 동작 여부를 검증했고, Google 검색이나 LLM 질문 없이 해결했다는 관찰
    • 이 과정을 근육 기억으로 만드는 일이 막힘에서 더 빨리 벗어나는 데 도움을 줬다는 언급
  • 단순 프로젝트나 Advent of Code 같은 문제를 계속 페어 프로그래밍으로 진행하고 싶은 생각
    • 누군가와 실시간으로 작업하는 일은 처음에는 긴장됐지만, 바로 그 점 때문에 진전이 컸다는 체감

• 컴퓨터를 더 깊이 이해하기

  • 1983년 Apple IIe에서 BASIC으로 고전 함수 fizzbuzz를 작성한 경험
    • 당시 컴퓨터의 코드 편집과 실행 과정은 훨씬 수동적이었지만, 동시에 기본적으로는 비슷하다는 점을 확인한 경험
  • 자신의 Unix/터미널 기술 부족을 느껴 CTF Fridays에 참여
    • Bandit와 다른 “war games”를 터미널로 풀며 비밀번호를 수집하고 레벨을 올리는 방식의 Unix 및 컴퓨터 보안 관련 도전 과제 수행
    • 이제 Claude Code가 자신의 컴퓨터에서 무엇을 실행하려 하는지 꽤 잘 감이 온다는 언급
  • AI 교재를 넘기다 본 단일 계층 퍼셉트론을 하루 동안 Vim만으로 직접 코딩한 경험
    • 처음에는 특히 힘들었지만 다른 Recurser에게서 팁과 단축키를 배웠다는 언급
    • 클라우드 GPU에서 학습 작업을 실행할 때 파일을 급히 수정해야 하는 상황에서 매우 유용해졌다는 서술
  • Clojure 워크숍 참여 경험
    • 15년 이상 Clojure를 사용한 사람이 진행했고, Clojure가 함수형 언어라 관련 경험이 많지 않은 상태에서 흥미로웠다는 언급
    • 짧은 소개 뒤 모두가 함께 문제를 풀고, 각자 1~2분씩 해결을 진전시키는 mob programming 방식 포함
  • 주간 기술 발표 세션은 매우 다양한 주제에 노출되는 기회라는 평가
    • 5분 발표 형식이라 지루하지 않을 만큼 짧고, 동시에 의미 있는 것을 배울 수 있을 만큼 빠르다는 특징
    • 예시 제목으로 “Running Rust Code”, “GPUs for Dummies”, “Typesafe APIs for Type B Personalities”, “Some Useless Agents” 제시
    • 직접 진행한 발표는 단순 에이전트 아키텍처, MCP 도구의 효율적 스케일링, 그리고 예정된 GPU 최적화 방식 발표 포함
  • 다른 사람들의 프로젝트와 경력에 대한 이야기만 듣는 일도 컴퓨터가 해결할 수 있는 문제 공간을 이해하는 데 매우 가치 있었다는 언급

남은 6주

• 곧 다시 에이전트를 프로덕션에 배포하고 eval을 돌리게 되겠지만, 그때는 새로운 기술과 요령을 갖춘 상태일 것이라는 기대
• 현재 RC에서 6주가 더 남았고, 목록에 있는 모든 것을 끝내기에는 충분하지 않을 수 있다는 걱정
  • 실제로 다 끝내지는 못할 것이라는 인정
• 그럼에도 RC의 장점은 목록을 전부 지우는 데 있다기보다, 코딩에 시간을 쓰는 일 자체에 있다는 결론

각주와 말미 언급

• 2023년 LLM을 처음 접했을 때 큰 충격을 받은 이유로, 몇 년 전 일본에서 일본어를 풀타임으로 공부하며 매우 어려움을 겪었는데 컴퓨터 모델이 그것을 해낸 것처럼 보였다는 개인적 맥락 제시
  • 당시 환각이 있거나 수학을 제대로 못했더라도 여전히 놀라웠다는 언급
• CS336 첫 과제 수행 중 2~3개의 버그는 약 20분 디버깅 후 Claude에게 조언을 구했지만, 대부분의 디버깅은 손으로 했다는 각주
• 마지막 댓글에는 6개월 전부터 코딩과 검색 모두에서 LLM을 전혀 쓰지 않고, 대신 원문 문서와 테스트 픽스처를 사용한다는 반응 포함
  • 해당 실천에 대한 호감과 글 작성에 대한 감사 표현 포함

[GN⁺]

Hacker News 의견들

• 나는 이번 학기에 18세 학생들에게 에뮬레이트한 Apple II Plus로 6502 어셈블리를 가르치고 있음
  학생들은 이미 현대적인 환경에서 Python, 자료구조, 객체지향을 배운 상태였음
  총 10시간 정도 수업과 실습으로 레지스터, 명령어, 주소 지정 방식, 메모리 맵, Apple 모니터 루틴을 익힌 뒤 40x40 저해상도 그래픽으로 그림 프로그램, 튕기는 공, 직접 만든 스프라이트와 간단한 충돌 판정까지 같이 구현했음
  과제로는 Snake나 Tetris 같은 간단한 게임을 직접 만들고 시연한 뒤, 동작 방식을 발표하게 했음
  처음엔 라인 에디터를 싫어했지만, 곧 코드를 쓰기 전에 먼저 계획하고 토론하기 시작했음
  예전 수업에서 늘 강조했지만 잘 안 되던 습관이, 강한 도구가 없으니 오히려 자연스럽게 자리 잡았음
  나중에는 화면에 코드를 다 띄워보지 않아도 머릿속에 코드가 들어 있다고 학생들이 말했음
  결국 다시 현대적 도구로 돌아가겠지만, 이런 경험은 분명 큰 의미가 있다고 느낌

  • 내가 코딩을 가르치며 느낀 점은 Python이 첫 언어로는 애매함이라는 점이었음
    가장 큰 이유는 타입을 항상 의식해야 하는데, Python은 그 부분을 오히려 흐리게 만들기도 함
    공백도 어떤 때는 필수이고 어떤 때는 아닌데, 익숙한 사람에겐 숨 쉬듯 자연스러워도 초보자에겐 헷갈릴 수 있음
  • 나도 9년 전에 거의 비슷한 수업을 들었는데, CS 학위 과정에서 가장 도움 된 경험 중 하나였음
    저수준 환경과 제한된 도구 덕분에 코드를 쓰기 전에 먼저 생각하는 습관이 생겼음
    나는 지금도 그린필드 작업에선 펜과 모눈종이부터 꺼내서 함수나 클래스 후보를 느슨한 그래프로 그리고 화살표로 연결해봄
    물론 이걸 과하게 밀어붙이면 워터폴 계획의 다른 형태가 되니 적당함이 중요함
    몇 시간만 미리 구조를 고민해도 실제 코딩 시간은 크게 줄어든다고 느낌
    실제 결과물이 종이 설계와 똑같았던 적은 거의 없지만, 큰 그림을 먼저 생각하는 과정 자체가 생산성을 높여줌
    에디터 안에서 스캐폴딩하면 금세 실제 구현으로 빠지는데, 종이에 쓰면 어차피 다시 타이핑해야 하니 변수명이나 메서드 선택 같은 잡생각에서 벗어날 수 있었음
    몇 번 vibe coding을 할 때도 이 방식이 특히 유용했고, 덕분에 훨씬 더 구체적이고 집중된 프롬프트를 줄 수 있었음
  • 처음에는 왜 굳이 라인 에디터를 쓰게 하나, 분명 문법 하이라이팅 되는 VS Code 플러그인이 있을 텐데 싶었음
    그런데 학생들 머릿속에 코드가 자리 잡았다는 대목에서 생각이 바뀌었음
    Zed Shaw도 비슷하게, IDE 없이 쓴 코드가 이상하게 더 좋아 보인다고 말한 적이 떠올랐음
    비슷한 맥락으로 나는 "From Nand to Tetris" 같은 책으로 공부했는데, 컴퓨터와 어셈블러, 컴파일러가 어떻게 돌아가는지 이해하는 데 정말 큰 도움이 되었음
  • 내 초반 엔지니어 시절 가장 인상적이었던 경험 중 하나는 아주 시니어한 엔지니어와 함께 일한 일이었음
    그분은 문제를 받으면 곧바로 타이핑하지 않고 먼저 생각하고, 종이에 조금 끄적이고, 산책까지 한 다음에야 컴퓨터 앞에 앉았음
    그리고는 거의 한 번에 입력해서 마지막에 컴파일만 했는데, 실제로 잘 돌아가곤 했음
    오타조차 드물었음
    이 경험 덕분에 문제 공간과 프로그램을 머릿속에 먼저 세우고 추론하는 능력이 얼마나 중요한지 강하게 느꼈음
    그러면 기대하는 결과가 더 분명해지고, 예상 밖의 일이 생겼을 때도 더 빨리 눈치챌 수 있음
  • 나는 학부 과정에 어셈블리 언어 수업을 넣으려 할 때마다 늘 힘든 싸움을 했음
    윗선에서는 너무 어렵다, 이제 아무도 안 쓴다며 과목을 없애곤 했음
    그래도 시스템 프로그래밍, 컴퓨터 언어, 컴퓨터 구조 같은 다른 수업 안에 몰래 조금씩 끼워 넣었음
    내가 자라던 시절에는 어셈블리가 교육 과정의 일부였고, C/C++ 같은 고급 언어와 하드웨어 사이의 간극을 메워주는 역할을 했음
    왜 특정 언어 기능이 존재하는지, 많은 언어 구성 요소가 실제로 어떻게 작동하는지도 이해하게 해줬음
    무엇보다 위 댓글들처럼 CPU를 한 줄 한 줄 따라가며 사고하는 훈련이 된다는 점이 정말 훌륭했음
    정식 과목은 자주 졌지만, 적어도 학생들 안에 씨앗은 심어뒀기를 바라고 있음
    누구나 적어도 한 번쯤은 한 종류의 어셈블리를 배워볼 가치가 있다고 믿음

• 나는 AI 자동완성 워크플로에 더 많은 투자가 있었으면 좋겠다고 느낌
  그게 꽤 괜찮은 중간 지점이었음
  지금 이른바 옛 방식이라고 불리는 것도, 더 넓게 보면 에이전트식 워크플로와 비교해 여전히 충분히 경쟁력이 있다고 봄
  직접 치면서 코드베이스 지식을 훨씬 더 잘 유지하게 되고, 능동적으로 떠올리고 검증하는 과정 덕분에 개념 이해도도 더 깊어짐

  • 나는 요즘 에이전트 워크플로를 뒤집어서 쓰는 걸 꽤 즐기고 있음
    코드는 내가 직접 쓰고, 에이전트에게는 코드 리뷰를 맡김
    그러면 내 코딩 감각과 코드베이스 이해는 유지되면서, 커밋 전에 버그도 잘 잡아줌
  • 나도 완전히 같은 느낌이었음
    초창기 Cursor는 정말 놀라웠는데, 그 뒤로는 자동완성이 거의 정체된 느낌이었고 최신 Cursor마저 다른 도구들처럼 점점 에이전트 쪽으로 기울고 있음
    언젠가 diffusion 모델이 더 탄력을 받으면 자동완성 근처의 워크플로에 다시 생기가 돌 수도 있다고 기대함
    Inception Labs의 Mercury 모델은 응답이 거의 즉각적이라 아직도 약간 마법처럼 느껴짐
    다만 Cursor 수준의 정교함과 깊은 에디터 통합이 아직 부족한 점이 아쉬움
    그리고 diffusion 계열은 로컬 사용에 정말 잘 맞아 보이는데, 의미 있는 오픈 웨이트 모델이 거의 없는 점도 아쉽게 느껴짐
  • 내 경험도 비슷했음
    내가 직접 지루한 글루 코드를 쓰면 프로젝트의 지도가 머릿속에 생김
    반대로 에이전트가 구조를 너무 많이 만들어버리면 당장은 돌아가도, 일주일 뒤 작은 수정 하나 하려 할 때마다 어디에 뭘 넣어놨는지부터 찾게 됨
  • 나는 AI 자동완성은 별로였다고 느낌
    다들 금방 다른 쪽으로 넘어간 이유가 있었고, 결국 유용한 인터페이스가 아니었다고 봄
  • 수동 코딩의 논리는 이해하지만, 내겐 그게 비행기 대신 차로 대륙을 횡단하는 느낌임
    한 번 비행기를 타보고 나면 다시 돌아가기가 정말 어려워짐

• 이 제목은 여기서 본 것 중 가장 우울한 제목 중 하나로 느껴졌음

  • 이 댓글이 정반대로도 읽히는 점이 재밌었음
    손코딩이 이제 블로그에 쓸 만큼 낯선 일이 되어서 우울하다는 뜻일 수도 있고, 반대로 AI 최대주의자가 인간 코딩을 비꼬는 뜻일 수도 있음
    글 이력을 보니 아마 전자 해석이 맞아 보였음
  • 이제 Python을 직접 쓴다는 말이 곧 LLM 없이 쓴다는 뜻이 된 셈인가 싶었음
    마치 한때 유행어가 된 wild swimming처럼, 뭔가 너무 멀리 와버린 느낌임
    정말 상어를 뛰어넘은 상황처럼 보였음
  • 원래 Hacker News는 자기 생각을 나누고 다른 사람과 토론하는 곳이라고 생각했는데, 이런 식의 반응을 보니 Facebook 댓글창 같아진 느낌도 들었음
    그래도 참 인상적인 기여였다고 느꼈음
  • 나도 처음엔 농담인 줄 확인하러 들어갔음
    보고 나니 정말 어이없음
  • 이건 시작에 불과하다고 느낌
    곧 손코딩 얘기했다는 이유로 정신병원에 보내는 세상도 농담처럼 상상하게 됨

• 내 커리어 초반 몇 년은 SPARC 기반 Solaris에서 vi로, 그것도 vim도 아닌 vi로 주로 Perl 코드를 쓰며 보냈음
  O’Reilly의 Perl Cookbook이 거의 유일한 길잡이였고, 인터넷 포럼도 많지 않았으며 검색 엔진도 원시적이라 막히면 도움받기가 훨씬 어려웠음
  대신 그 환경이 Perl 문법, 터미널 도구, 특히 vi 키스트로크를 아주 깊게 익히게 만들었음
  문법 하이라이팅이나 인텔리센스도 없었고, 그래서 오히려 더 많이 몸에 남았음
  지금 돌아보면 그때는 방해 요소와 잡음이 훨씬 적었음
  물론 커리어 초반이라 기대치가 낮아서 그렇게 느끼는 면도 있겠지만, 지금은 모든 게 지나치게 층층이 쌓이고 복잡해졌다고 느낌

  • 내 경우 시작점은 GW-BASIC이었고, 지금 우리가 아는 의미의 에디터도 거의 없었음
    그건 즉각적인 보상과 빠른 개발, 불필요한 레이어가 없는 꽤 순수한 경험이었고, 바로 그 점이 나를 이 길로 끌어들였음
    아이러니하게도 agentic coding은 그때의 설렘을 일부 되돌려줬음
    복잡한 엔터프라이즈 고려사항을 내가 직접 다 씨름하지 않아도 되니, 생각과 결과 사이의 연결이 다시 가까워졌기 때문임

• 업계 변화가 정말 놀랍다고 느낌
  불과 2년 전만 해도 거의 모든 개발자가 할 법한 말이었는데, 이제는 손으로 코딩한다고 말하는 사람이 멸종위기종처럼 보일 정도임

  • 나는 특히 근육 기억이 사라지는 게 걱정됨
    지난 1년 동안 다뤄온 새로운 기술과 언어일수록, 이제는 너무 쉽게 결과를 내다 보니 오히려 내 안에 지식 부채를 쌓고 있다는 느낌이 있음
    다음 세대 소프트웨어 엔지니어가 이런 것들에 대한 깊은 이해를 과연 어떻게 익힐지, 아니면 아예 못 익히게 될지 많이 우려됨
  • 내게는 2년 전의 손으로 쓰기가 지금의 LLM 없는 코딩처럼 느껴짐
    그전 세대로 비유하면 IDE 없이 코딩하는 것과 비슷했고, 실제로 그런 방식도 이미 드문 편이었음

• 나는 AI 전반, 특히 GenAI를 꽤 지지하는 편이지만 여전히 손으로 코딩하는 시간도 많이 씀
  많아야 Copilot 보조를 켜두는 정도임
  때로는 SpecKit + OpenCode 같은 도구로 spec-driven development를 하거나, 그냥 vibe code를 하기도 함
  그래도 코드를 이해해야 할 내 책임을 내려놓고, 직접 작성하는 능력 자체를 버릴 생각은 아직 없음
  그래서 최근에도 LISP와 Java 책을 몇 권 새로 샀고, 그 전에는 Forth 책도 샀음
  적어도 한동안은, 어쩌면 영원히 완전히 코딩을 그만둘 생각은 없음

  • 내 책임은 코드를 직접 한 줄씩 확인하는 데 있다기보다, 코드가 기능 요구사항과 비기능 요구사항을 만족하는지 보장하는 데 있다고 봄
    핵심은 구현이 아니라 행동 이해임
    그 검증은 자동화된 단위 테스트, 통합 테스트, 부하 테스트가 해줌
    누군가는 내가 내부용 웹 관리자 사이트를 vibe coded로 만들고도 코드 한 줄 안 보고 보안 요구사항을 만족한다고 말한 걸 순진하다고 봤음
    하지만 요구사항은 사이트 접근 권한이 있는 사람은 무엇이든 할 수 있어야 한다는 것이었고, 접근은 Amazon Cognito 자격 증명으로 보호했고, 이를 제공하는 Lambda에는 최소 권한 역할을 붙였음
    만약 그 두 불변식이 깨졌다면, 그건 Claude가 거대한 AWS 취약점을 찾아낸 수준일 것이라고 봄

• 나는 AI를 최대한 활용해 많은 것을 만들되, 동시에 AI가 만든 코드가 내 인지 부하 기준을 통과하는지 검토하는 시간을 꼭 씀
  그 과정에는 코드 다듬기와 문서화도 포함되고, 이 AGENTS.md 예시를 바탕으로 많은 부분을 수월하게 처리하고 있음
  그래도 이상한 방향으로 가는 순간은 감지할 수 있어서 그때는 다시 내가 방향을 잡음
  그리고 크레딧이 다 떨어지면 그때가 진짜 내 차례임
  이미 코드가 잘 정리돼 있고 추상화도 말이 되며 주석도 도움이 되니, 그 위에서 유기적인 인간 코딩을 이어가기가 좋음
  이제는 한도에 가까워질수록 AI에게 무대를 미리 세팅해두라고 요청함
  예전엔 크레딧이 떨어지면 이해하려면 공부가 필요한 코드를 남겨둬서 답답했는데, 지금은 오히려 다음 brain time hand-out이 기다려질 정도임
  이상하게 들릴 수 있지만, 내겐 이것도 일종의 팀워크처럼 느껴짐
  더 비싼 요금제를 쓸 수도 있지만, 나는 내 뇌를 계속 활동하게 두고 싶음

  • 인용한 원칙 중 DRY를 남용하지 말라는 부분이 흥미로웠음
    원칙 자체에는 동의하지만, 적어도 Claude는 로직을 너무 자주 복제해서 오히려 반대 방향의 유도가 필요하다고 느꼈음
  • 나는 그걸 팀워크라고 느끼기가 어려움
    LLM이 나 대신 코드를 쓰면, 그 코드는 내게 거의 손댈 수 없는 블랙박스처럼 보임
    돌아가면 쓰긴 하지만 신뢰하지는 못하고, 망가지면 그냥 답답해짐
    결국 나에게 맞는 방식은 내가 항상 운전대를 잡고, LLM은 질문에 답하거나 아이디어를 같이 브레인스토밍해주고, 내가 이미 이해한 개념을 특정 언어의 문법으로 표현하는 걸 도와주는 조수 역할임
    사실 나는 개념 이해보다도 그걸 문법으로 옮기는 일이 늘 조금 버거웠음
  • 공유해줘서 고맙게 느꼈음
    나도 에이전트에게 일부를 맡기되 일부 작업은 의도적으로 내 몫으로 남겨서 뇌를 계속 쓰게 하는 방식에 대해 생각해왔음
    어쩌면 Claude Code용 skill이나 hook을 만들어봐야겠다는 생각이 듦

• 3개월 동안 자기주도적으로 깊게 배우는 여정을 보낼 수 있다는 건 정말 멋진 일처럼 느껴짐
  이런 깊은 기술은 장기적으로도 가치가 있을 것 같고, 이번 변화가 어셈블리에서 C로 넘어간 것과 완전히 같은 종류의 추상화인지는 아직 확신이 없음
  요즘 내 코드 대부분은 LLM이 생성하는데, 하루가 끝났을 때 즐거움이나 성취감, 만족감은 솔직히 별로 없음
  다만 동시에 내가 원래 코딩에서 진짜 즐기는 부분은 5~10% 정도뿐이고, 나머지는 흥미로운 핵심을 떠받치는 지루하고 반기계적인 작업이었다는 것도 깨닫게 됐음
  인류 역사 전체로 보면 컴퓨터로 일하는 시기 자체가 아주 짧은 순간이고, 100년 뒤에는 손코딩의 시대가 어떻게 보일지 궁금함
  어쩌면 그저 각주로 남거나, 기계가 스스로 자동화되기 이전의 모든 시절로 한데 묶일지도 모르겠음

  • 지금 변화는 과거의 어셈블리에서 컴파일 언어로의 전환과 비슷할 수도 있다고 봄
    예전엔 직접 어셈블리로 작성했지만 이후 C 같은 컴파일 언어로 이동했고, 어셈블리는 유용하지만 틈새적인 기술로 남았음
    이제는 코드를 컴파일러에 맡기고 대부분은 그 내부 출력을 보지 않듯, 앞으로는 개발 다수가 LLM 추상화 계층으로 옮겨갈 수도 있다고 느낌
    핵심 역량도 좋은 프롬프트 작성, 컨텍스트 윈도 관리, 에이전트와 메모리 운영 같은 쪽으로 이동할 수 있음
    일부 개발자는 여전히 LLM이 만든 코드를 읽고 문제를 찾아낼 수 있겠지만, 대부분은 그러지 못할 수도 있음
    나도 감정이 복잡함
    ChatGPT 등장 이후 몇 달 전까지만 해도 LLM 프로그래밍에 꽤 회의적이었고, 새 모델이 나와도 결국 비슷한 품질 낮은 출력의 변주처럼 느껴졌음
    그런데 최근에는 모델들이 어떤 임계점을 넘은 듯 보였고, 나도 Claude를 아직 조심스럽게 쓰긴 하지만 기능 구현 속도를 크게 줄이거나 로그만 보고 버그 위치를 찾는 데 실제로 도움을 받았음
    아직 코딩이 해결됐다는 식의 과장에는 동의하지 않지만, 적어도 고급 언어 도입 이후 가장 큰 변화 중 하나를 보고 있다는 생각은 듦

• 나는 반쯤 타협안으로 Zed를 쓰기 시작했음
  앞으로는 AI를 구현 자체보다 계획과 단계 제안 쪽에 더 써볼 생각임
  요즘은 비기술 직군 사람들도 Claude로 앱을 만들기 시작하는 모습이 보이고, Openclaw를 비롯한 에이전트 집착 흐름을 보면 AI 과몰입의 길을 계속 가는 게 실용적이진 않다고 느낌
  나는 삶의 다른 영역에서 늘 내부 디테일까지 신경 쓰고, 새로운 문제에 직접 손을 더럽히며 해결하는 능력으로 평가받아왔음
  시장이 앞으로 어떻게 적응할지, 그리고 사람들이 이런 뉘앙스를 다루는 능력을 어떻게 전달하고 증명하게 될지 궁금함

• Recurse Center 사이트에서 “교사나 정해진 커리큘럼이 없고, 리트릿 동안 풀타임 헌신만 요구된다”는 문구를 보고 궁금해졌음
  풀타임으로 일하는 사람이 이런 코딩 리트릿에 보통 어떻게 참여하는지 알고 싶었음
  주로 업계 입문자나 이직 사이 공백기에 있는 사람을 위한 프로그램인지도 궁금했음
  글 자체는 리트릿에서 무엇을 만들었는지에 대한 이야기였지만, 오히려 나는 직접 가보고 싶어졌음

  • 나는 Recurse Center 공동창업자로서 답하자면, 대부분은 직장 사이 공백기에 참여함
    RC를 위해 일부러 퇴사하거나, 실직 후 지원하는 경우가 흔함
    정식 안식년, garden leave, 대학생과 대학원생의 여름방학 기간을 활용하는 경우도 많음
    프리랜서나 독립 계약자, 은퇴자도 적지 않게 옴
    업계 진입을 위해 오는 사람도 있지만, 참가자 다수는 이미 프로그래머로 일한 경험이 있음
    참가 연령은 12세부터 70대 초반까지 다양하지만, 주된 분포는 20대부터 40대까지임
  • 맞음, 대체로는 이직 사이 시기에 많이 감
    자세한 참가자 정보는 Recurse Center 소개 페이지에서 볼 수 있음
    아니면 현재 직장으로 복귀할 수 있는 6주 정도의 안식년을 낼 수 있어야 현실적임