이제는 코드를 직접 작성하는 편이 더 유리하다

URL: https://www.youtube.com/watch?v=bzYziksDslU
날짜: 2026-08-17
채널: dreamsofcode
원문 제목: Writing code by hand is now an advantage
영상 길이: 약 17분 39초

---

📌 핵심 질문 / 손으로 코드를 작성하는 일이 에이전트 시대에 왜 장점이 되는가

==손으로 코드를 작성하는 일은 시간이 오래 걸리더라도 낭비가 아니라, 에이전트를 더 효과적으로 사용하게 만드는 기술적·인지적 장점이다.==

• 에이전트(Agent)가 작동하는 코드를 빠르게 만들어도 그 코드가 올바른지, 미래의 요구를 견딜 수 있는지 판단할 지식까지 제공하지는 않는다.
• 직접 구현하는 과정에서 문제와 씨름하고 해결책을 발견하면 언어·의존성·아키텍처·코드베이스에 대한 정신 모델(mental model)이 생긴다.
• 손으로 구현하는 경험이 희소해질수록 특정 언어와 핵심 시스템을 실제로 이해하는 개발자는 채용과 유지보수에서 눈에 띄는 사람이 된다.
• 모든 코드를 수동으로 작성하라는 뜻이 아니라, 학습 효과와 정확성의 투자수익률(ROI)이 높은 부분을 직접 만들고 나머지는 AI로 확장하는 선택적 결합이 핵심이다.

에이전트 기반 엔지니어링(Agentic Engineering)은 소프트웨어 개발의 기본 작업 방식을 바꾸고 있다. 그렇지만 속도만을 기준으로 손 코딩을 폐기하면, 작동하는 결과물은 얻어도 왜 작동하는지와 언제 깨지는지를 모르게 된다. 직접 코드를 쓰는 시간은 지식을 쌓고 에이전트의 결과를 검증하는 능력을 만드는 시간이며, 즐거움 자체도 정당한 개발 목적이다.

1. 에이전트 시대에 뒤집힌 손 코딩의 가치

1.1. “손으로 코딩하는 것은 낭비”라는 서사

소프트웨어 개발의 근본적 변화인 에이전트 기반 엔지니어링이 온라인의 새로운 서사를 만들었다. 코드를 손으로 쓰면 시간이 걸린다는 사실은 맞지만, 그 시간을 낭비라고 부르는 것은 부정확하다.

1. 빠른 생성과 가치 있는 시간은 같은 기준이 아니다

   1. 온라인의 통념: 손으로 코드를 작성하는 일은 이제 시간 낭비라는 말이 점점 더 자주 들린다.
   2. 핵심 반론: 에이전트를 효과적으로 사용할 수 있는 개발자의 능력은 코드 생성 속도만으로 생기지 않으며, 직접 구현하며 얻은 이해와 판단력에 기대는 경우가 많다.
   3. 주장: 손 코딩은 낭비가 아니라 오히려 장점으로 볼 수 있다.

2. “현실을 외면하는 자기합리화”라는 반응

   1. 변화의 속도: 지난 12개월 동안 개발 도구와 작업 방식이 크게 바뀌었기 때문에 손 코딩의 가치를 말하면 현실을 부정하거나 스스로를 위로하는 말처럼 들릴 수 있다.
   2. 가벼운 자기풍자: 이런 주장이 “cope”처럼 들릴 수 있다는 점을 인정한 뒤, 코웃음 섞인 반응을 넣으며 다음 사고실험으로 넘어간다.
   3. 사고실험의 목적: 에이전트 기반 엔지니어링의 부상이 오히려 손 코딩의 희소성과 가치를 키우는 과정을 보여준다.

1.2. 세 후보자 채용 사고실험

Rust와 FFmpeg로 만든 동영상 편집 애플리케이션의 개발을 넘겨받을 소프트웨어 엔지니어를 채용한다고 가정한다. 최종 후보 세 명은 모두 Rust로 자신의 동영상 플레이어를 최근 구현했다.

1. 후보자 A — 에이전트만으로 만든 플레이어

   1. 경력과 전환: 숙련된 소프트웨어 개발자이며, “Vibe Coding”이라고 불리기 시작한 때부터 Agentic Engineering에 완전히 뛰어들었다.
   2. 수동 구현 경험: 2025년 초부터 코드 한 줄도 직접 작성하지 않았고, Rust 코드나 FFmpeg 통합 코드를 손으로 작성한 적도 없다.
   3. 구현 방식: 자신의 동영상 플레이어 전체를 Claude Code와 Codex 같은 도구로 만들고, 반복 루프(loops)와 공격자적 검토(adversarial review) 같은 기법을 사용했다.

2. 후보자 B — 언어 경험은 깊지만 핵심 플레이어는 의존성에 위임한 개발자

   1. 경력과 전환: 숙련된 개발자로서 최근 몇 달 동안 에이전트 기반 엔지니어링을 익혔다.
   2. 수동 구현 경험: 에이전트 시대가 오기 전 3년 동안 매일 Rust를 직접 작성했기 때문에 Rust 손 코딩 경험은 풍부하다.
   3. 구현 방식: Rust와 훌륭한 데스크톱 프레임워크인 iced로 플레이어의 많은 부분을 손으로 만들었지만, 실제 동영상 재생 기능은 직접 구현하지 않고 기능을 제공하는 기존 crate에 맡겼다.

3. 후보자 C — 에이전트를 쓰되 핵심 시스템을 직접 만든 개발자

   1. 현재 작업 방식: 다른 두 사람처럼 일상적으로 Agentic Engineering을 사용한다.
   2. 학습 습관: 개인적인 학습과 성장에 도움이 될 이유를 찾아 여전히 손으로 코드를 작성한다.
   3. 플레이어 구현: 미디어 엔진(media engine)의 대부분을 직접 구현했다. Rust에서 FFmpeg 바인딩 계열 crate를 사용했고, 막힐 때만 AI의 도움을 받았다.

4. 채용 선택과 차별점

   1. 첫 제안 대상: 세 후보 중 첫 제안을 받을 사람은 후보자 C다.
   2. 핵심 근거: 후보자 C만 동영상 플레이어의 핵심 구성 요소인 미디어 엔진을 직접 만들었다.
   3. 실무적 의미: 직접 구현하며 얻은 hands-on 경험은 동영상 편집기를 개발할 때 마주칠 핵심 개념을 이해하고 있음을 시사하므로, 나머지 두 후보보다 유리하다.
   4. 농담 섞인 인정: 후보자 C에게 유리하도록 판을 짠 사고실험이며, 후보자 C는 “도대체”라는 말이 나올 만큼 실제 마법사 같은 사람이라는 농담도 덧붙여진다.

1.3. 손 코딩의 희소성과 가치 검증

에이전트가 코드를 전부 생성하는 흐름이 계속되면 직접 코드를 작성해 본 경험은 점점 드물어지고, 그 단순한 행위만으로도 개발자가 군중 속에서 돋보일 수 있다. 다만 희소성만으로 장점이 되려면 손 코딩이 실제 가치를 제공하는지 확인해야 한다.

1. 희소성이 만드는 차별화

   1. 점점 더 많은 개발자가 코드 한 줄을 직접 쓰지 않고 완전한 애플리케이션을 만들고 있다.
   2. 이 추세가 이어지면 손 코딩 경험은 흔하지 않은 이력이 된다.
   3. 핵심 시스템을 직접 구현해 본 사람은 에이전트가 만든 결과를 단순히 실행하는 사람과 구별된다.

2. 가치는 ‘작성량’이 아니라 ‘판단력’에서 나온다

   1. 직접 구현의 가치는 모든 기능을 느리게 만드는 데 있지 않다.
   2. 직접 쓰면서 얻은 지식은 에이전트가 만든 결과가 정확한지, 유지 가능한지, 미래 목표에 맞는지 평가하는 기준이 된다.
   3. 따라서 손 코딩과 에이전트 사용은 경쟁 관계가 아니라, 이해를 먼저 만들고 자동화를 확장하는 보완 관계가 된다.

2. 미디어 엔진의 실패가 보여 준 지식 격차

2.1. 작동하지만 올바르지 않은 구현

최근 동영상 편집기 프로젝트의 미디어 엔진을 전부 Agentic Engineering으로 만들었을 때, 결과물은 작동했지만 올바른 구현이라고 부르기 어려웠다.

1. 에이전트 결과의 한계

   1. 에이전트는 일단 실행되는 미디어 엔진을 만들어 냈다.
   2. 하지만 미디어 파일의 종류가 매우 다양하기 때문에 구현은 사용자의 파일에서 계속 깨졌다.
   3. “머피의 법칙(Murphy’s law)”이 여전히 유효해서, 문제가 생길 수 있는 파일이 실제 사용자에게 반드시 나타났다.

2. 지식 격차가 검증을 막았다

   1. 에이전트에게 계속 개선을 맡기면 언젠가 올바른 해결책에 도달할 가능성은 있었다.
   2. 그러나 미디어 엔진의 원리와 요구사항을 충분히 몰랐기 때문에, 도달한 결과가 정말 올바른지 판단할 수 없었다.
   3. 장래에 추가하려는 기능과 목표를 지지할 설계인지도 확인할 수 없었다.
   4. 이미 한 번 실망을 안긴 에이전트를 계속 신뢰하는 것보다 자신의 지식 격차를 먼저 메우는 선택이 필요했다.

2.2. FFmpeg을 직접 배우며 후보자 A에서 C로 이동

지식 격차를 메우기 위해 FFmpeg을 배우고, AI를 효율을 높이는 보조 수단으로 사용하면서 단순한 미디어 엔진 파이프라인을 손으로 구현했다.

1. 학습의 방식

   1. FFmpeg의 개념과 동작을 직접 파악하기 위해 작은 미디어 엔진 파이프라인을 만들었다.
   2. AI를 완전히 배제하지 않고, 막히는 부분을 질문하고 학습 과정의 효율을 높이는 데 활용했다.
   3. 손으로 구현하는 과정 자체가 재생과 미디어 처리에 관련된 개념을 깊게 이해하도록 만들었다.

2. 학습의 결과

   1. 자신의 미디어 엔진을 다시 설계하고 구현할 준비가 더 잘 갖춰졌다.
   2. FFmpeg과 미디어 재생을 이해하게 되면서 Agentic Engineering을 사용할 때도 더 좋은 지시와 검토를 할 수 있게 됐다.
   3. 에이전트에게 모든 것을 맡긴 후보자 A가 핵심 시스템을 직접 구현하는 후보자 C로 변한 셈이다.
   4. 손 코딩은 개발자를 과거의 방식에 묶어 두는 일이 아니라, 에이전트를 더 강하게 다루는 능력을 만들어 준다.

2.3. 학습에서 문제와 씨름하는 과정의 역할

Agentic Engineering으로도 학습할 수 있고, 기술 이해도를 높이는 방법도 여러 가지다. 그러나 도구를 사용하면 학습이 시작되는 계기 자체를 건너뛰기 쉽다.

1. 학습을 일으키는 사건

   1. 문제와 마주친다.
   2. 해결책을 찾기 위해 여러 가설을 세우고 시도한다.
   3. 시도 과정에서 예상과 실제의 차이를 발견하고, 그 발견을 통해 개념을 이해한다.

2. 에이전트가 제거할 수 있는 마찰

   1. 에이전트는 문제를 즉시 해결해 주므로 사용자가 직접 실패하고 원인을 추적할 기회를 줄인다.
   2. 결과적으로 코드는 얻지만, 왜 그 해결책이 맞는지와 어떤 조건에서 틀리는지에 대한 이해는 약해질 수 있다.
   3. 그래서 모든 코드를 손으로 쓰기보다, 개인 성장과 AI 활용에 가장 큰 투자수익률을 주는 부분을 의식적으로 직접 작성하는 전략이 필요하다.

3. 프로그래밍 언어를 배울 때 직접 구현하기

3.1. 2026년에도 언어 학습이 필요한가

새 언어의 코드를 에이전트가 매우 잘 생성하는 2026년에도 언어를 직접 배우는 일은 유효하다.

1. 언어 학습의 필요성에 대한 논쟁

   1. 에이전트는 여러 언어로 코드를 생성할 수 있으므로 개발자가 문법과 관용구를 직접 익힐 필요가 없다는 주장이 있다.
   2. 그러나 과거에 프로그래밍 언어를 배운 데 들인 시간을 후회하지 않는다면, AI 기반 개발이 늘어난 2026년에도 같은 논리를 적용할 수 있다.
   3. 언어 자체를 이해하면 에이전트가 내놓은 코드의 냄새와 위험한 설계 선택을 더 빨리 발견할 수 있다.

2. 현대적인 옛 방식

   1. 배우려는 언어의 책을 고른다.
   2. 책의 예제를 직접 타이핑하고 손으로 구현한다.
   3. 참고 자료만으로 막히거나 다른 설명이 필요할 때 LLM에게 질문해 이해의 빈틈을 메운다.
   4. 이 방식은 AI를 거부하는 방식이 아니라, 기초 이해는 직접 만들고 설명·질문·막힘 해소는 LLM으로 보완하는 방식이다.

3.2. Rust 재학습과 AI 코드 리뷰 감각

Rust를 다시 익히는 과정은 에이전트가 생성한 코드를 검토할 때 필요한 직관을 강화했다.

1. 코드 냄새를 알아보는 감각

   1. 언어를 직접 배우면 단순히 컴파일되는 코드와 언어의 설계 의도에 맞는 코드를 구별할 수 있다.
   2. 에이전트가 만든 코드는 흔히 “작동하는 가장 짧은 길”을 택하기 때문에, 숙련된 언어 감각이 없으면 문제가 누적된다.

2. Boolean creep 사례

   1. boolean creep은 에이전트가 잘 정의된 enum에 새 variant를 추가하는 대신, 상태를 표현하는 새 Boolean 값을 계속 만드는 현상이다.
   2. 실제 코드에는 메인 랜딩 페이지 사이드바의 활성 탭을 추적하는 구조체가 있었고, 사이드바의 활성 항목 상태별로 여러 Boolean 필드를 두고 있었다.
   3. 직접 소프트웨어를 만들어 본 개발자라면 이 구조가 나쁜 코드라는 점을 즉시 알아볼 수 있다.
   4. Rust에서는 각 상태를 상호 배타적인 enum variant로 모델링하는 편이 훨씬 낫다.
   5. 이 사례는 단순하지만 현실의 코드에서 실제로 발생한 문제이며, 언어의 모델링 철학을 알면 에이전트의 유사한 실수를 쉽게 포착할 수 있다.

3. 학습 전에 프로젝트를 시작하는 현실

   1. 2026년에는 많은 개발자가 언어를 충분히 배우기 전에 에이전트와 함께 프로젝트부터 시작할 가능성이 높다.
   2. 이때 언어를 직접 배운 경험이 없으면 Boolean creep 같은 설계 문제가 코드베이스 전체에 쌓일 수 있다.
   3. 코드 리뷰와 자동화 도구는 개발자가 언어를 익히는 동안 안전망 역할을 할 수 있다.

3.3. CodeRabbit을 이용한 에이전트 코드 검토

CodeRabbit은 손으로 쓴 코드와 에이전트가 만든 코드가 운영 환경에 도달하기 전에 품질을 점검하는 도구로 소개된다. 개인 프로젝트인 차세대 동영상 편집기 Kiru를 개발하면서 몇 달 동안 사용했고, 잠재적인 버그가 production 코드로 들어가는 것을 여러 번 막았다.

1. Pull Request 자동 검토

   1. CodeRabbit을 GitHub 프로젝트에 연결하면 main 브랜치로 보내는 Pull Request를 자동으로 검토한다.
   2. 잠재적 오류, 스타일 개선, 바로 적용할 수 있는 수정안을 자동으로 제시한다.
   3. 손 코딩과 에이전트 코딩 모두에 같은 검토 흐름을 적용할 수 있다.

2. 보안 버그 사례

   1. 새 API endpoint를 추가하는 단순한 PR에 심각한 보안 버그가 들어 있었다.
   2. CodeRabbit은 문제를 찾아 댓글로 표시하고, 상세한 요약과 수정 방향을 함께 제공했다.
   3. 에이전트에 보내 바로 해결하도록 사용할 수 있는 프롬프트도 제공했다.
   4. 이런 흐름은 보안 문제뿐 아니라 에이전트 코드에서 흔한 edge case와 일반적인 결함에도 적용된다.

3. 새 Review UI가 주는 이해도 향상

   1. 일반적인 코드 리뷰 도구는 변경 사항 전체를 평평한 diff로 보여주는 경우가 많다.
   2. CodeRabbit의 새 Review UI는 변경 사항을 여러 레이어로 나눠, 애플리케이션에서 실제로 호출되는 방식에 가깝게 코드를 검토하게 한다.
   3. 각 레이어가 수행하는 일을 요약하고, 특정 변경에 리뷰 댓글을 남길 수 있다.
   4. UML을 좋아하는 사람을 위해 함수와 통합 지점의 상호작용, 실제 API path를 포함한 endpoint 흐름을 시퀀스 다이어그램으로 생성한다.
   5. 자동 수정만 제공하는 것이 아니라 코드베이스를 더 쉽게 추론하게 만들어, AI가 생성한 코드의 이해도를 높인다.
   6. 소개된 CodeRabbit의 무료 체험은 영상 설명란의 링크를 통해 시작할 수 있으며, 해당 도구가 영상의 스폰서라는 감사 인사가 전해진다.

4. 의존성을 직접 배워야 하는 이유

4.1. CPAL과 실시간 오디오의 숨은 제약

대부분의 의존성(dependency)은 이름과 기본 사용법만 보면 이해하기 쉽지만, 일부는 큰 함정을 갖고 있다. CPAL은 그 대표 사례다.

1. CPAL의 오디오 처리 구조

   1. CPAL은 Windows, macOS, Linux에서 오디오를 재생하는 데 사용된다.
   2. 하드웨어 장치에 대한 context를 만들면 오디오 샘플을 기록할 수 있는 thread가 제공된다.
   3. 해당 샘플은 장치의 스피커를 통해 재생된다.

2. Real-time audio thread의 제약

   1. 이 thread는 이름 그대로 real-time audio thread이며 가능한 한 빠르게 실행돼야 한다.
   2. 처리가 늦어지면 소리가 튀는 pops, 끊기는 skips, 기타 원치 않는 artifact가 발생한다.
   3. 사람의 귀는 이런 오디오 결함에 매우 민감하다.

3. Mutex가 틀린 이유와 ring buffer의 대안

   1. 에이전트는 thread safety를 보장하려고 mutex를 사용했다.
   2. 실시간 오디오에서 mutex는 큰 금기다. 잠금 대기로 thread가 block될 수 있고, 그 결과 오디오 샘플이 drop된다.
   3. 먼저 작은 dummy project에서 직접 구현해 봤기 때문에 이 제약을 코드 리뷰에서 알아볼 수 있었다.
   4. 올바른 thread synchronization 방식은 실시간 ring buffer를 사용하는 것이었다.
   5. 의존성을 직접 다룬 경험은 API 호출법을 외우는 수준이 아니라, 해당 라이브러리가 절대 허용하지 않는 설계까지 알려 준다.

4.2. 문서가 나쁜 의존성과 AI의 보완 역할

애플리케이션에서 손으로 학습한 다른 의존성으로 FFmpeg과 GPUI가 언급된다. 둘 다 문서가 매우 좋지 않지만, 이 지점에서 에이전트의 질문 응답 능력이 유용하게 작동한다.

1. 손 학습과 질문의 결합

   1. 핵심 제약과 동작은 직접 구현하며 파악한다.
   2. 문서가 빠뜨린 세부 사항은 에이전트에게 질문해 이해한다.
   3. 질문으로 문서 격차를 메우면 의존성의 작동 방식을 파악하는 데 걸리는 시간이 줄어든다.

2. 긍정적 피드백 루프

   1. FFmpeg 같은 의존성을 직접 학습하면 미디어 엔진의 설계를 더 잘 판단할 수 있다.
   2. 판단력이 좋아지면 에이전트에 더 정확한 지시를 내리고 결과도 더 효과적으로 검토할 수 있다.
   3. 에이전트는 손 학습을 대체하는 도구가 아니라, 이해가 필요한 의존성의 문서와 설명을 보완하는 도구가 된다.

5. 아키텍처와 코드베이스 이해를 손으로 되찾기

5.1. 에이전트의 최단 경로와 설계의 엉킴

AI 코딩 도구의 주요 성향은 작동하는 코드까지 가는 가장 짧은 경로를 택하는 것이다. 빠른 프로토타입에는 유용하지만, 통제하지 않으면 코드베이스가 엉킨 덩어리가 된다.

1. 단기 성공과 장기 비용

   1. 에이전트는 현재 요구사항을 만족하는 구현을 빠르게 내놓는다.
   2. 잘못된 경계와 임시 연결이 쌓이면 기능 추가가 잘 설계된 시스템보다 훨씬 어려워진다.
   3. 에이전트로 좋은 아키텍처를 만들 수 없다는 뜻은 아니지만, 초기 설계를 통째로 위임하면 개발자가 설계의 저항과 균형을 직접 느낄 기회를 잃는다.

2. Interstellar의 “공기 느끼기” 비유

   1. 영화 Interstellar에서 Cooper가 Miller 행성에 착륙할 때 컴퓨터 보조를 거부하고 물리적 피드백을 느끼며 조종하려는 장면이 비유로 사용된다.
   2. 핵심 대사는 “Now I need to feel the air.”이다.
   3. 고수준 아키텍처를 손으로 잡아 보면 전체 설계에서 느껴지는 저항을 직접 파악할 수 있다.
   4. 기계가 이어서 구현하게 하면 그 직접적인 피드백을 잃을 수 있다.
   5. “feel the air”라는 표현 뒤에는 짧은 코웃음이 붙어, 영화 장면을 개발 설계에 연결한 농담을 완성한다.

5.2. 미디어 엔진을 설계부터 손으로 만들기

동영상 편집기의 미디어 엔진을 다시 만들 때, 구현을 에이전트에게 바로 맡기지 않고 구조의 뼈대를 직접 세웠다.

1. 설계 순서

   1. 먼저 trait와 고수준 타입을 정의했다.
   2. 그다음 method signature와 function signature를 정했다.
   3. Rust의 unimplemented! 매크로를 사용해 구현이 없어도 코드를 컴파일했다.
   4. 이 미완성 표시는 설계를 직접 점검할 수 있게 하고, 에이전트에게 구현해야 할 경계를 알려 주는 marker가 됐다.

2. 설계 결과

   1. 에이전트 중심으로 설계한 이전 미디어 엔진보다 훨씬 능력 있는 엔진을 만들었다.
   2. 어느 플랫폼에서 실행해도 일관된 결과를 얻었다.
   3. 이미지, 효과, 전환 같은 미래 기능을 추가하기가 훨씬 쉬워졌다.
   4. 설계를 손으로 먼저 만들고 반복 구현을 에이전트에 위임하는 방식은 속도를 조금 늦추지만, 시스템의 확장 경계를 보존한다.

5.3. 앞으로 가장 큰 문제: Codebase comprehension

에이전트 시대 개발자에게 가장 큰 문제는 codebase comprehension, 즉 코드베이스 이해도가 될 가능성이 높다.

1. 과거의 정신 모델

   1. 과거에는 하나의 코드베이스에서 충분히 시간을 보내면 꽤 괜찮은 정신 모델이 만들어졌다.
   2. 버그나 이슈가 제기되면 코드베이스의 어느 부분에서 문제가 시작됐을지 직관적으로 짚을 수 있었다.

2. 에이전트 생성 프로젝트에서의 불안

   1. 에이전트로 만든 프로젝트는 처음부터 직접 만들었더라도, 모든 변경을 검토했더라도 이해도가 예전만큼 깊지 않다.
   2. 소프트웨어 업계에는 작성자 자신도 코드를 완전히 이해하지 못한 채 전체 프로젝트를 운영하는 상황이 생기고 있다.
   3. 이런 상태로 다른 사용자의 장치에서 실행될 코드를 배포하는 일은 개인적으로 불편하고 위험하다.

3. 정신 모델을 만드는 실천

   1. 더 깊이 이해하고 싶은 코드는 직접 구현한다.
   2. 그 패턴을 다른 곳에 적용하거나 개선하는 작업은 에이전트에게 위임한다.
   3. 한 번에 전부 생성하는 것(one-shot)보다 분명히 느리지만, 먼저 코드의 정신 모델을 만들고 그 위에서 자동화를 확장할 수 있다.
   4. 에이전트에게 구현을 질문하는 것도 유용하며, 가끔 환각(hallucination)이 발생한다는 한계까지 포함해 답변을 검증해야 한다.

5.4. 정확성이 치명적인 코드는 직접 작성하고 공격적으로 검토하기

에이전트의 설명과 생성 결과에 환각 위험이 있으므로, 완전한 이해와 정확성이 특히 중요한 일부 코드는 앞으로도 손으로 작성한다.

1. 손으로만 구현할 영역

   1. 결제(payment) 처리
   2. 사용자 인증(user authentication)
   3. 버그가 들어가면 잠재적으로 치명적인 기타 코드

2. 아이러니한 보완책

   1. 중요한 코드는 직접 작성해 원리를 이해하고 정확성을 확보한다.
   2. 동시에 에이전트나 CodeRabbit을 이용한 공격자적 검토를 선호한다.
   3. 서로 다른 관점의 검토로 버그가 production까지 도달하는 것을 막는다.
   4. 이 마지막 검토 항목은 목록의 덜 중요한 항목이 아니라, 오히려 개인적으로 가장 중요한 항목에 가깝다.

6. 손으로 코드를 쓰는 즐거움을 다시 받아들이기

6.1. 개발의 보상은 생산성만이 아니다

업계의 모든 사람이 같은 감정을 느끼는 것은 아니지만, 소프트웨어 개발에서 중요한 즐거움 중 하나는 실제 코드를 직접 작성하는 일이었다.

1. 제품 개발과 코드 작성의 차이

   1. 제품 개발 측면, 즉 무엇을 만들고 사용자에게 어떤 가치를 줄지 정하는 일도 즐겁다.
   2. 그러나 에이전트가 그 과정을 대신하게 하면 손으로 제품을 만들 때만큼 정신적으로 자극적이지 않다.
   3. 직접 코드를 작성할 때는 작은 결정과 피드백이 계속 이어지며, 그 과정 자체가 개발의 재미를 만든다.

2. “수동 코딩의 종말”에 대한 태도

   1. 손 코딩의 종말을 애도하기보다, 직접 작성하는 방식을 다시 받아들이기로 한다.
   2. 많은 사람이 손으로 코드를 쓰는 일을 시간 낭비라고 생각해도, 자신이 즐기는 일에 시간을 쓰는 것은 진정한 의미의 낭비가 아니다.
   3. 손 코딩은 생산성 계산에서 빠진 오락이 아니라, 지속적으로 배우고 개발자로 남게 하는 동기이자 실력의 원천이다.

주요 발언 모음

“Coding by hand is not a waste of time and instead can actually be considered an advantage.”

“손으로 코드를 작성하는 것은 시간 낭비가 아니며, 오히려 장점으로 볼 수 있다.”

“Now I need to feel the air.”

“고수준 아키텍처를 손으로 작성하면 기계가 넘겨받기 전에 전체 설계의 저항을 직접 느낄 수 있다.”

“If it's not yet clear, I myself had transformed from candidate A all the way into candidate C through the simple act of writing code by hand.”

“즐기는 일에 시간을 낭비하는 것은 결코 시간 낭비가 아니다.”

핵심 데이터 & 수치

• 지난 12개월: 에이전트 기반 개발을 포함한 소프트웨어 개발 방식이 크게 변한 기간으로 제시된다.
• 2025년 초: 후보자 A가 손으로 코드를 작성하지 않기 시작한 시점이다.
• 3년: 후보자 B가 에이전트 시대 이전에 Rust를 매일 손으로 작성한 기간이다.
• 세 명: Rust로 동영상 플레이어를 만든 최종 채용 후보자 수다.
• 약 두 달 전: 미디어 엔진의 지식 격차를 체감하고 FFmpeg을 직접 학습하기 시작한 시점이다.
• 몇 달: Kiru를 개발하며 CodeRabbit을 사용한 기간이다.
• Windows·macOS·Linux: CPAL이 오디오 재생을 지원해야 하는 세 운영체제다.
• 한 줄의 코드도 없음: 후보자 A가 2025년 초부터 손으로 작성한 코드의 양이다.
• 대표적인 실패 모드: mutex로 인해 실시간 오디오 thread가 block되고 오디오 sample이 drop되는 현상이다.

결론 및 시사점

1. 선택적으로 직접 구현한다: 모든 코드를 손으로 쓰지 말고, 새로운 언어·복잡한 의존성·고수준 아키텍처·치명적 정확성이 필요한 영역을 직접 만든다.
2. AI를 학습 보조로 쓴다: 책과 실습으로 기초를 만들고, 막힌 부분의 설명·문서 격차·반복 구현은 LLM과 에이전트로 보완한다.
3. 작동과 올바름을 구분한다: 에이전트가 만든 코드가 실행된다는 사실만으로 미래의 입력과 요구를 견딘다고 판단하지 않는다.
4. 제약을 먼저 이해한다: CPAL의 실시간 오디오 thread처럼 라이브러리의 금지사항을 알면 에이전트의 그럴듯하지만 위험한 선택을 즉시 걸러낼 수 있다.
5. 설계의 피드백을 보존한다: trait, 타입, 함수 시그니처처럼 시스템의 뼈대를 직접 잡고 unimplemented!로 경계를 확인한 뒤 구현을 자동화한다.
6. 정신 모델을 만든다: codebase comprehension을 미래의 핵심 역량으로 보고, 직접 구현한 작은 영역을 기준으로 에이전트의 확장을 통제한다.
7. 자동 리뷰를 겹친다: 결제·인증처럼 위험한 코드는 직접 이해하되, 에이전트와 CodeRabbit의 공격자적 검토로 운영 유입을 막는다.
8. 즐거움을 가치로 인정한다: 직접 코드 작성이 주는 정신적 자극과 재미는 생산성 지표에 잡히지 않아도 개발을 지속하게 하는 실제 가치다.

핵심 요약 (20줄)

1. 손으로 코드를 작성하는 일은 에이전트 시대에도 단순한 시간 낭비가 아니다.
2. Agentic Engineering의 부상은 작동하는 코드를 만드는 속도를 크게 높였다.
3. 빠른 생성은 코드가 올바른지 판단할 지식까지 자동으로 제공하지 않는다.
4. 손 코딩 경험이 희소해질수록 핵심 시스템을 직접 만든 개발자는 더 눈에 띈다.
5. Rust와 FFmpeg 동영상 플레이어를 만든 세 후보 중 미디어 엔진을 직접 구현한 후보자 C가 가장 유리하다.
6. 후보자 C의 hands-on 경험은 동영상 편집기의 핵심 개념을 이해하고 있음을 보여 준다.
7. 에이전트만으로 만든 미디어 엔진은 작동했지만 다양한 미디어 파일에서 계속 깨졌다.
8. FFmpeg을 배우며 단순한 미디어 엔진 파이프라인을 직접 만든 과정이 지식 격차를 메웠다.
9. 문제와 씨름하고 해결책을 발견하는 과정이 기술 학습을 일으키는 핵심 마찰이다.
10. 새로운 언어는 책의 예제를 손으로 구현하고 LLM으로 막힌 부분을 보완하는 방식으로 배울 수 있다.
11. Rust를 직접 익히면 에이전트 코드의 boolean creep 같은 설계 냄새를 알아보기 쉬워진다.
12. 상태를 여러 Boolean으로 표현하기보다 상호 배타적인 enum variant로 모델링하는 편이 낫다.
13. CodeRabbit은 GitHub PR에서 보안 문제와 edge case를 찾아 코드 품질을 높인다.
14. CodeRabbit의 레이어 기반 리뷰와 시퀀스 다이어그램은 에이전트 코드의 구조를 이해하게 돕는다.
15. CPAL의 real-time audio thread에서 mutex는 block과 오디오 sample drop을 유발할 수 있다.
16. CPAL의 올바른 thread synchronization 대안은 real-time ring buffer다.
17. FFmpeg과 GPUI처럼 문서가 나쁜 의존성도 직접 배우고 에이전트에게 질문하면 이해할 수 있다.
18. 고수준 아키텍처를 직접 설계하면 Interstellar의 “feel the air”처럼 설계의 저항을 감지할 수 있다.
19. 결제와 인증처럼 치명적인 코드는 직접 이해하고 에이전트와 자동 도구로 공격적으로 검토해야 한다.
20. 직접 코드 작성의 즐거움에 쓰는 시간은 즐기는 일을 위한 시간이므로 진정한 낭비가 아니다.