이 채널의 미래: AI 과열이 아닌 기본기로 돌아가기

URL: https://www.youtube.com/watch?v=kAsvDoM9WJw 날짜: 2026-09-13 채널: ArjanCodes

---

메타데이터

• 원문 제목(요청 기준): The Future of this Channel (It’s not AI Hype)
• 현재 YouTube 메타데이터 제목(yt-dlp 확인): Back to the Fundamentals
• 영상 ID: kAsvDoM9WJw
• 원본 업로드일(drop_date): 2026-09-11 (yt-dlp upload_date 기준)
• 원본 업로드 시각: 2026-09-11 15:00:15 UTC, 2026-09-12 00:00:15 KST (yt-dlp timestamp 기준)
• 다이제스트 처리일: 2026-09-13
• 콘텐츠 유형: YouTube 자막 기반 개인 업데이트·채널 방향성 심층 다이제스트
• 영상 길이: 18분 49초
• 발표자: Arjan, ArjanCodes 운영자
• 관련 프로그램: Software Design Mastery
• 프로그램 안내: https://arjan.codes/mastery
• 챕터: Intro(0:00), The Move(0:29), Second Move(2:22), Channel Focus(3:58), AI(7:34), Channel Direction(10:16), Practical Channel Things(13:41), Final Thoughts(18:04)

---

📌 핵심 질문 / 이 채널이 앞으로 다룰 핵심 논점

==AI 코딩 도구의 유행을 좇지 않고도, 소프트웨어 설계와 Python이라는 채널의 본질을 유지하면서 AI 시대의 개발자에게 계속 도움이 될 수 있는가?==

• AI 코딩 도구와 에이전트(agent)는 빠르게 변하지만, 좋은 소프트웨어를 설계하는 원칙과 시스템 사고(systems thinking)는 오래 남는다.
• Python과 소프트웨어 설계는 비전공자와 다양한 배경의 개발자도 복잡한 애플리케이션을 만들도록 돕는 채널의 검증된 조합이다.
• 생성형 AI는 코드를 더 많이 만들어 내는 방향으로 작동하기 쉬운 반면, 설계는 불필요한 것을 제거하고 문제를 단순하게 만드는 일에 가치를 둔다.
• ArjanCodes는 특정 AI 도구 리뷰나 ‘이번 주의 AI 과열’을 중심에 두지 않고, 사람이 직접 코딩하든 AI 에이전트 팀을 활용하든 적용할 수 있는 설계 기본기를 다룬다.
• 이 선택은 조회수와 성장률을 낮출 수 있지만, 깊이 있는 콘텐츠를 지속하려면 시청자의 좋아요·댓글·공유·구독이 필요하다.

집과 사무실을 연달아 옮기는 개인적 변화, 채널이 무엇을 가르쳐야 하는지에 대한 고민, AI가 소프트웨어 개발을 바꾸는 방식, 후원과 강의 사업의 재편이 하나의 전환점으로 이어진다. 핵심 방향은 “AI를 무시한다”가 아니라 “AI가 무엇을 하든 더 나은 소프트웨어를 설계하는 사고를 중심에 둔다”는 것이다.

1. 집과 사무실을 동시에 옮기는 생활의 전환

개인 생활과 업무 공간이 함께 바뀌면서 Arjan의 시간과 정신적 여유가 크게 줄었지만, 두 이동이 끝나면 새로운 단계에 진입할 수 있다.

1.1. 오래된 집을 다시 주거 공간으로 되돌리는 공사

1. 한 건물에 여러 시대의 용도가 겹쳐 있다

   1. 오래된 주택의 역사: 가족과 함께 산 집은 원래 1900년대 초에 한 가족이 살던 곳이었다.
   2. 연속된 용도 변경: 이후 오랫동안 호텔로 쓰였고, 정신의학 병동(psychiatric ward)을 거쳐 사무실 건물이 됐다.
   3. 구매 당시의 상태: 집을 샀을 때에도 여전히 사무실로 등록된 상태라, 다시 주거용으로 정확히 등록하는 일이 필요했다.

2. 주거 등록과 금융 절차가 예상 밖의 난관이 됐다

   1. 등록 문제: 가족이 실제로 살 수 있는 집으로 만들려면 건물의 법적·행정적 용도를 바로잡아야 했다.
   2. 모기지 문제: 주택담보대출(mortgage)을 받는 일까지 등록 상태와 연결되어 있어, 단순히 집을 사서 이사하는 과정이 아니었다.
   3. 체감 난이도: 이 행정·금융 절차는 “엄청난 골칫거리(huge pain)”로 표현될 만큼 복잡했다.

3. 철거 공사만 약 4개월이 걸렸다

   1. 천장 철거: 서로 겹쳐 있던 천장 세 겹을 제거했다.
   2. 오래된 배선 제거: 100년 된 전기 케이블을 뜯어냈다.
   3. 낡은 통신 인프라 정리: 전화 케이블과 30년 전의 인터넷 인프라까지 제거했다.

4. 전문 공사가 필요한 규모였다

   1. 셀프 작업의 한계: 직접 할 수 없는 일이 많아 결국 시공업체(contractor)가 필요했다.
   2. 예산의 오차: 이미 비관적인 예산을 세웠다고 생각했지만 실제 비용은 그 예상에조차 훨씬 못 미칠 정도로 더 컸다.
   3. 공사 우선순위: 무엇이 얼마인지 파악하고, 직접 절약할 수 있는 부분과 미룰 부분, 아예 생략할 부분을 나눠야 했다.

5. 현재의 편의보다 미래의 공사 문제를 예방해야 했다

   1. 당장 해야 할 일: 미래에 각종 건축 문제를 만들지 않으려면 지금 반드시 처리해야 하는 공사를 골라야 했다.
   2. 미루기의 위험: 비용을 아끼려고 모든 것을 미루면 나중에 더 큰 시공 문제로 돌아올 수 있으므로, 지연 가능한 항목과 불가능한 항목을 구분해야 했다.
   3. 가족의 생활 조건: 공사 중에도 가족이 지낼 수 있도록 새 집의 일부를 먼저 거주 가능한 상태로 만들어야 했다.

6. 기존 집을 파는 일까지 동시에 진행됐다

   1. 매각 병행: 새 집 공사만 하는 것이 아니라 현재 살던 집도 팔아야 했다.
   2. 정신적 부담: 행정·예산·철거·시공·매각을 동시에 처리하면서 집 공사가 머릿속 공간을 크게 차지했다.
   3. 전환의 안도감: 이 콘텐츠를 볼 때쯤에는 최소한 이사를 마쳤을 것이므로, 가장 큰 부담 하나는 어깨에서 내려놓게 된다.

1.2. 중앙 교도소 건물에서 새 사무실로

1. 현재 사무실은 임시 공간이었다

   1. 장소: 약 반년 동안 네덜란드 위트레흐트(Utrecht) 중심부의 오래된 교도소 건물에서 일했다.
   2. 장점: 도심의 위치를 매우 좋아했고, 밖으로 나가 Dom Tower(돔 타워) 같은 장소까지 걸을 수 있었다.
   3. 업무 효과: 주변을 산책할 수 있는 차분한 환경이 마음을 정리하고 생각을 곧게 유지하는 데 도움이 됐다.

2. 교도소 건물 특유의 불편함이 있었다

   1. 냉방 부재: 에어컨(air conditioning)이 없어 네덜란드의 여름에도 사무실이 꽤 불편해질 수 있었다.
   2. 창문을 열 수 없음: 감옥 건물이라 사람들이 빠져나가면 안 되므로 창문을 열 수 없었다.
   3. 예정된 대규모 공사: 처음부터 건물 전체의 대규모 리노베이션이 예정돼 있었고, 결국 모든 입주자가 떠나야 했다.

3. 새 사무실은 위치와 기능을 개선한다

   1. 도심 유지: 새 사무실도 위트레흐트 중심부에 있어 기존 장소의 산책과 접근성 장점을 유지한다.
   2. 교통 편의: 기차역과도 가까워 이동이 더 편리하다.
   3. 냉방 확보: 에어컨이 있어 계절에 따른 작업 환경 문제가 줄어든다.

4. 새 배경은 직접 꾸며야 한다

   1. 표준형 사무실: 새 공간은 기존의 개성 있는 교도소 건물과 달리 천장과 구조가 전형적인, 다소 지루한 사무실 방에 가깝다.
   2. 장식 작업: 영상 배경으로 쓰려면 어느 정도 직접 꾸며야 한다.
   3. 채널 화면의 변화: 한두 달 안에 영상 배경이 다시 바뀌게 되며, 시청자는 새 사무실의 분위기를 보게 된다.

1.3. 두 번의 이사가 만든 전환점

1. 집과 회사의 이동이 겹쳤다

   1. 첫 번째 이동: 가족의 주거지를 옮기는 대형 리노베이션과 이사가 진행됐다.
   2. 두 번째 이동: 약 한 달 뒤 ArjanCodes의 업무 공간도 새 사무실로 옮긴다.
   3. 농담 섞인 표현: “한 번만 이사하면 너무 쉬울 테니까” 두 번 이사하게 된 셈이라는 식으로 상황을 가볍게 풀어낸다.

2. 변화가 끝나야 채널에 집중할 수 있다

   1. 현재의 정신적 점유: 공사와 이사 문제는 일상뿐 아니라 생각할 수 있는 정신적 공간까지 차지했다.
   2. 예상되는 해방감: 적어도 집 이사가 끝나면 가장 큰 부담이 사라져 업무에 다시 집중할 여지가 생긴다.

2. ArjanCodes의 정체성은 소프트웨어 설계와 Python이다

다양한 주제를 다뤄 왔지만, 채널의 지속 가능한 중심은 소프트웨어 설계(software design)와 Python이며, 이 조합은 비전공자까지 포괄하는 경험에서 나왔다.

2.1. 5년 전 채널이 자리 잡은 이유

1. Python 사용 범위가 단순 스크립트를 넘어섰다

   1. 시기의 변화: 채널을 만들던 약 5년 전, Python을 간단한 스크립트에만 쓰지 않고 더 복잡한 시스템에 쓰는 사람이 늘고 있었다.
   2. 새로운 활용처: Python으로 머신러닝 파이프라인(machine learning pipeline), 데이터 분석 시스템, API, 웹 애플리케이션을 만들기 시작했다.
   3. 복잡성의 문제: 언어를 시작하는 것보다 그렇게 커진 시스템의 복잡성을 관리하는 방법을 배우는 일이 어려워졌다.

2. Python 커뮤니티는 전통적인 컴퓨터과학 배경에 한정되지 않는다

   1. 다양한 진입 배경: 여러 분야에서 온 사람들이 Python을 접하고 개발을 시작한다.
   2. 학습의 다음 단계: 언어 자체를 좋아하게 된 뒤에는 더 복잡한 소프트웨어를 만들고 더 많은 원리를 배우고 싶어 한다.
   3. 콘텐츠 적합성: 복잡성을 다루는 설계 콘텐츠가 이처럼 다양한 배경을 가진 학습자에게 잘 맞았다.

3. 소프트웨어 설계와 Python이 서로를 강화한다

   1. 언어의 실용성: Python은 빠르게 시작할 수 있으면서도 데이터·웹·AI 등 다양한 시스템을 구성하는 데 쓰인다.
   2. 설계의 필요성: 시스템이 커질수록 문법보다 구조, 경계, 책임, 변화에 대응하는 설계가 중요해진다.
   3. 채널의 조합: Python을 실제 재료로 삼고 소프트웨어 설계를 사고의 틀로 삼는 구성이 핵심 강점이 된다.

2.2. Arjan의 교육·개발 경험이 뒷받침하는 주제

1. 대학에서 여러 해 프로그래밍과 설계를 가르쳤다

   1. Python만 가르친 것은 아니다: 대학 교육 여정에서 Python은 오히려 작은 부분이었다.
   2. 주요 언어: C++, Java 같은 언어를 주로 가르쳤다.
   3. 언어보다 중요한 것: 실제로 사용하는 프로그래밍 언어가 무엇인지는 설계와 사고의 원리보다 덜 중요하다.

2. 연구와 사업에서 완성형 애플리케이션을 만들어 왔다

   1. 연구 경험: 그래픽스 엔진(graphics engine)과 스크립팅 시스템(scripting system)을 결합하는 등 여러 요소를 조합한 애플리케이션을 만들었다.
   2. 창업 경험: 몇 개의 회사를 시작해 웹 기반 애플리케이션, 백엔드 등 서로 다른 형태의 시스템을 개발했다.
   3. 주제의 자연스러움: 이런 경험 덕분에 소프트웨어 설계를 이야기하는 일이 억지로 전문성을 연출하는 일이 아니라 자연스럽게 즐기는 일이 됐다.

3. 과거의 확장 주제가 중심을 바꾸지는 않았다

   1. 다뤄 본 기술 주제: 소프트웨어 테스트(software testing), 클라우드 시스템(cloud systems)도 다뤘다.
   2. 제품 리뷰: MacBook이 개발에 적합한지, 기계식 키보드(mechanical keyboard)가 어떤지 같은 제품 리뷰도 했다.
   3. 우선순위: 여러 주제를 다뤄도 채널의 핵심 순서는 언제나 소프트웨어 설계, 그다음 Python이다.

2.3. 실제 업무에서 코딩보다 설계를 더 많이 한다

1. 최근 직접 코딩하는 시간은 줄었다

   1. 솔직한 변화: 요즘 실제 소프트웨어 개발을 많이 직접 하지는 않는다.
   2. 코드를 완전히 떠난 것은 아님: 코드 한 줄도 보지 않는다는 뜻은 아니며, 영상 예제와 자료를 준비할 때 코드를 작성한다.
   3. 핵심 역할의 이동: 구현자에서 문제·도메인·아키텍처·우선순위를 정하는 설계자 쪽으로 역할이 이동했다.

2. ArjanCodes 내부 도구를 개발한다

   1. 업무 자동화: 송장과 회계를 처리하는 자동화(automation) 등 사업 운영을 지원하는 도구를 만든다.
   2. 기업용 포털: 기업이 강의 좌석(course seats)을 대량 구매하고 직원에게 배정할 수 있는 웹 기반 포털을 구축했다.
   3. 기술 구성: 포털에는 깊은 Stripe 연동(Stripe integration), REST API, 그 밖의 기능이 들어 있다.

3. 설계자는 도메인과 방향을 결정한다

   1. Arjan의 기여: 포털에서 도메인을 정의하고, 아키텍처를 설계하며, 기능과 다음 작업을 계획하는 데 많은 시간을 쓴다.
   2. 구현의 분업: 실제 코드는 개발자가 작성한다.
   3. AI 활용: 해당 개발자는 요즘 Claude Code를 많이 사용한다.
   4. 결론: AI가 구현을 도와도 어떤 문제를 풀고 시스템을 어떻게 구성할지 결정하는 설계 업무는 계속 남는다.

3. 생성형 AI와 좋은 소프트웨어 설계의 긴장

AI는 소프트웨어 개발에서 가장 큰 영향을 받는 분야를 만들고 있지만, 빠른 생성 능력과 설계의 단순화 원칙 사이에는 근본적인 불일치가 있다.

3.1. AI가 개발자의 역할을 빠르게 바꾼다

1. 소프트웨어 개발은 AI의 충격이 가장 큰 분야다

   1. 수동 작업의 대체: 과거 사람이 직접 하던 많은 작업을 AI가 대신하기 시작했다.
   2. 역할의 재정의: 개발자는 코드를 입력하는 사람에 머물 수 없고, AI가 만든 결과를 어떤 목적과 구조로 사용할지 판단해야 한다.
   3. 적응의 필요: 개발자의 역할이 무엇을 의미하는지 다시 생각하고 변화에 적응해야 한다.

2. AI는 점점 더 독립적인 개발 작업을 수행한다

   1. 버그 처리: AI 시스템이 스스로 버그를 찾고 수정한다.
   2. 테스트 작성: 요구된 기능에 대한 테스트를 자동으로 만든다.
   3. 기능 구현: 완전히 새로운 기능을 처음부터 개발하기도 한다.

3. 변화 속도가 따라가기 어렵다

   1. 짧은 수명: 어떤 도구 사용법을 익히면 몇 달 뒤, 때로는 몇 주 뒤에 완전히 달라진다.
   2. 지속적인 학습 부담: 현재의 최선의 워크플로를 익히는 순간 다음 버전이 등장해 다시 배워야 한다.
   3. 심리적 압박: 늘 이 분야에서 한참 뒤처져 있다는, 끊임없이 신경 쓰이는 감각이 생긴다.

3.2. 생성은 늘리지만 설계는 줄이는 일이다

1. 좋은 설계의 기본 방향은 단순화다

   1. 제거의 가치: 설계에서는 불필요한 것을 단순히 추가하기보다 없애는 데 큰 가치가 있다.
   2. 개념적 단순성: 코드를 덜어 내고 개념을 단순하게 만들어 특정 요구에 더 잘 맞게 한다.
   3. 목적 적합성: 좋은 설계는 가능한 것을 모두 넣는 것이 아니라 문제에 필요한 구조만 남기는 일이다.

2. 생성형 AI의 기본 경향은 반대 방향이다

   1. 대량 생성: 생성형 AI는 무엇인가를 추가하고, 더 많은 코드와 산출물을 만들어 내는 데 최적화돼 있다.
   2. 거대한 변경: AI 에이전트(agent)를 쓰면 거대한 풀 리퀘스트(pull request)가 생기기 쉽다.
   3. 양의 착시: 코드와 기능이 늘어났다는 사실이 문제가 더 잘 해결됐다는 뜻은 아니다.

3. ‘왜 만드는가’라는 질문이 빠지기 쉽다

   1. 에이전트 과잉: 사람들이 잠든 동안 여러 에이전트를 돌려 소프트웨어를 만들었다는 사례가 등장한다.
   2. 목적 점검: 몇 개의 에이전트를 돌릴 수 있는지가 아니라 왜 이 작업이 필요한지 먼저 물어야 한다.
   3. 성과 점검: 만들어진 결과로 실제로 무엇을 달성했는지 확인해야 한다.

4. AI가 슬롭 엔진(slop engine)이 될 위험이 있다

   1. 토큰 비용: 의미 있는 결과보다 토큰(token)에 많은 돈을 쓰는 상황이 생길 수 있다.
   2. 사용되지 않는 소프트웨어: 아무도 쓰지 않는 소프트웨어를 점점 더 많이 만들 수 있다.
   3. 도구의 목적 전도: AI가 더 나은 일을 돕는 도구가 아니라, 생성량 자체를 늘리는 엔진으로 전락한다.

4. AI 과열을 좇지 않는 채널 방향

채널은 AI를 배제하는 대신, 빠르게 사라지는 도구보다 오래 남는 설계 원칙과 개발자의 판단력을 중심에 둔다.

4.1. 댓글에서 드러난 두 가지 기대

1. AI 에이전트 중심으로 확장하라는 요구가 있다

   1. 설계와 AI의 결합: AI 에이전트를 활용한 소프트웨어 설계를 더 많이 다뤄 달라는 의견이 있다.
   2. 하네스 엔지니어링(harness engineering): 여러 AI 코딩 에이전트를 효과적으로 관리하는 방법을 다뤄 달라는 요구가 있다.
   3. 제품 소개: 여러 AI 에이전트 제품과 시스템을 소개해 달라는 기대도 있다.

2. AI에서 거리를 둔 현재 방향을 지지하는 시청자도 있다

   1. 상대적 비(非)AI 채널: 이 채널이 지금까지 비교적 AI에 치우치지 않은 상태를 유지한 점을 좋아하는 사람이 있다.
   2. 도구 리뷰 피로감: 최신 AI 에이전트 시스템을 계속 리뷰하는 채널로 변하지 않기를 바란다.
   3. 공포 마케팅 거부: 새 AI 모델이 나올 때마다 “이제 모든 것이 끝났다”고 말하는 클릭베이트식 공포 조장을 원하지 않는다.

3. 채널은 갈림길에 서 있다

   1. 상충하는 요구: 한쪽은 AI 에이전트의 실전 활용을 원하고, 다른 쪽은 기본기 중심의 안정적인 콘텐츠를 원한다.
   2. 선택의 기준: 어떤 주제가 유행하는지보다 Arjan이 실제로 중요하다고 느끼고 시청자에게 기여할 수 있는지를 기준으로 삼는다.

4.2. 도구보다 설계를 선택하는 이유

1. AI 도구는 다른 개발 도구와 같은 위치에 있다

   1. 도구의 범주: Claude Code 같은 AI 에이전트 시스템도 기계식 키보드나 노트북처럼 사용할 수 있는 도구다.
   2. 기존 콘텐츠와의 관계: 채널은 과거에 키보드나 노트북 같은 도구를 다뤘지만, 이런 도구 자체가 핵심 관심사는 아니다.
   3. 흥미의 한계: 특정 도구를 소개하는 일은 유용할 수 있어도 지속적으로 열정을 느끼게 하지는 않는다.

2. 소프트웨어 설계가 창의적 문제 해결을 가능하게 한다

   1. 즐거움의 원천: 프로그래밍 언어가 제공하는 개념과 기능, Python 생태계를 활용해 특정 문제에 대한 창의적인 해법을 떠올리는 과정이 즐겁다.
   2. 더 근본적인 관심: 어떤 도구를 쓰느냐보다 어떤 개념으로 문제를 모델링하고 어떤 구조를 선택하느냐가 더 근본적이다.
   3. 콘텐츠의 자연스러움: 설계는 오랫동안 가르치고 실제 프로젝트에서 수행해 온 일이라 가장 자연스럽게 기여할 수 있는 영역이다.

3. AI 코딩도 결국 설계 판단을 필요로 한다

   1. 결정은 사람의 몫: AI가 코드를 작성하더라도 목표, 구조, 경계, 트레이드오프(trade-off)에 대한 결정은 사람이 한다.
   2. 과거 코딩과의 연속성: AI 코딩은 구현 주체가 달라졌을 뿐, 좋은 소프트웨어를 만들기 위해 설계에 관여해야 한다는 점에서 전통적인 코딩과 다르지 않다.
   3. 적용 범위: 사람이 모든 코드를 직접 쓰는 경우부터 여러 AI 에이전트에게 구현을 맡기는 경우까지 설계 원칙은 필요하다.

4.3. 비행기 조종과 소프트웨어 설계의 비유

1. 도구를 쓰려면 그 아래의 원리를 알아야 한다

   1. 비행기의 기본 물리: 비행기 조종사는 양력(lift), 항력(drag), 추력(thrust) 같은 물리 원리를 알아야 한다.
   2. 매번 계산할 필요는 없음: 비행 중에 직접 물리 계산을 수행하지 않더라도, 비행기가 어떻게 작동하는지 아는 일은 필요하다.
   3. 조종의 근거: 비행기에 들어간 모든 도구와 기계는 이 기본 원리 위에 만들어졌으므로, 원리를 알아야 제대로 운용할 수 있다.

2. 개발자에게 기본기는 시스템 사고다

   1. 설계 원리: 소프트웨어 설계와 시스템 사고는 개발자가 갖춰야 할 가장 중요한 기술 중 하나다.
   2. 도구의 의존성: AI 코딩 도구를 포함해 개발자가 사용하는 모든 도구는 설계와 시스템의 기본 원리 위에 있다.
   3. 실행의 차이: 기본기를 가진 개발자는 직접 코딩하든 AI가 만든 코드를 감독하든 도구를 목적에 맞게 운용할 수 있다.

4.4. 앞으로 다룰 콘텐츠의 범위

1. 오래 남는 기본기를 다룬다

   1. 설계 패턴(design patterns): 반복되는 문제를 해결하는 구조적 패턴을 다룬다.
   2. 설계 원칙(principles): 복잡성을 줄이고 변화에 대응하는 원칙을 가르친다.
   3. 시니어 엔지니어의 사고: 더 나은 소프트웨어를 설계하고 시니어 엔지니어처럼 생각하는 방법을 공유한다.

2. 특정 AI 도구 리뷰는 중심에서 제외한다

   1. 짧은 유효기간: 오늘의 AI 코딩 도구나 에이전트 시스템은 일주일이나 한 달 뒤에 이미 구식이 될 수 있다.
   2. 콘텐츠의 내구성: 특정 제품의 사용법보다 어떤 제품에도 적용할 수 있는 사고와 원칙을 선택한다.
   3. AI를 완전히 무시하지는 않음: AI가 설계·개발 원칙을 설명하는 데 의미가 있을 때는 당연히 다룬다.

3. AI 시대에도 개발자의 정체성을 돕는다

   1. 구현 방식의 불변성: 코드를 직접 쓰든, 팀이 AI 에이전트로 코드를 만들든, 그 사이의 어떤 방식을 택하든 설계 역량은 필요하다.
   2. 채널의 사명: 시청자가 더 나은 소프트웨어를 작성하도록 돕는 것이 채널이 지켜야 할 기준이다.
   3. 비판적 적용: 제시된 아이디어를 그대로 숭배하지 말고 비판적으로 성찰한 뒤 자신의 업무와 커리어에 적용해야 한다.

5. 성장률보다 깊이 있는 콘텐츠의 지속 가능성

기본기 중심의 선택은 대중적 AI 과열 콘텐츠만큼 빠른 성장을 만들지 않을 수 있지만, 깊이와 지속성을 위해 감수할 수 있는 비용이다.

5.1. 조회수와 분석 지표에 대한 태도

1. 채널 성장 속도는 느려질 수 있다

   1. AI 과열 콘텐츠의 부재: 매주 새 AI 이슈를 좇는 영상과 표면적인 사용법 영상을 만들지 않으면 폭발적인 성장이 어려울 수 있다.
   2. 얕은 교육의 거부: 실제로 의미 있는 것을 가르치지 않는 표면적 how-to 콘텐츠를 줄인다.
   3. 조회수 하락 가능성: 이 선택 때문에 영상 조회수가 떨어질 수도 있다.

2. 분석 지표를 최우선으로 두지 않는다

   1. 개인적 수용: 채널이 미친 듯이 성장하지 않더라도 괜찮다고 생각한다.
   2. 앱 확인 빈도: YouTube 앱에서 분석(analytics)을 거의 확인하지 않는다.
   3. 판단 기준: 조회수보다 자신이 관심을 갖고 도움을 줄 수 있는 주제인지가 콘텐츠 판단의 중심이다.

5.2. 시청자 참여가 채널을 지탱한다

1. 깊이 있는 영상을 원한다면 행동이 필요하다

   1. 좋아요: 영상에 좋아요를 누르는 행위가 채널의 지속 가능성에 기여한다.
   2. 댓글과 공유: 자신의 생각을 댓글로 남기고 영상을 공유하면 AI 과열에 기대지 않는 채널이 발견될 가능성이 높아진다.
   3. 구독: 무료인 구독은 채널이 장기적으로 콘텐츠를 계속 올릴 수 있도록 돕는다.

2. 댓글은 다음 콘텐츠를 개선하는 자료다

   1. 모든 댓글을 읽음: 모든 댓글에 답하지는 못해도 댓글 자체는 읽는다.
   2. 응답과 독해의 차이: 답글을 남기지 못하는 것이 의견을 보지 않는다는 뜻은 아니다.
   3. 개선 방향: 시청자의 의견은 다음 영상에서 무엇을 개선할지 결정하는 데 쓰인다.

6. 후원 중단과 수익 모델의 재편

채널은 콘텐츠의 기본기 중심 방향과 맞지 않는 후원 구간을 잠시 중단하고, 더 근본적인 교육 프로그램 하나로 사업을 통합한다.

6.1. 스폰서 구간을 당분간 완전히 중단한다

1. 후원 자체를 부정하는 것은 아니다

   1. 시청자에게 유용한 소개: 많은 YouTube 제작자에게 스폰서 구간은 시청자가 흥미를 느낄 만한 새 제품을 소개하는 좋은 방법이 될 수 있다.
   2. 선별의 책임: 제작자는 자신의 채널과 시청자에게 맞는 후원인지 신중하게 판단해야 한다.
   3. 현재의 결정: ArjanCodes는 당분간 영상 안의 스폰서 구간을 완전히 중단한다.

2. 기존에도 후원 기준은 매우 엄격했다

   1. 거절 비율: 받은 제안 1,000건 가운데 약 999건을 거절할 정도로 선별했다.
   2. 빈도: 이미 스폰서 영상이 많은 채널은 아니었고, 목표 빈도도 대략 한 달에 한 번 정도였다.
   3. 수익의 역할: 후원은 전업으로 채널을 운영하는 데 보조 수입을 제공했다.

3. 기본기 중심 채널과 후원 업무가 맞지 않는다

   1. 주제 적합성: 앞으로 채널이 설계 기본기에 집중하면 특정 제품을 홍보하는 구간이 채널의 방향과 어울리지 않는다.
   2. 시간 비용: 브랜드와 소통하고, 지급을 처리하고, 후원 구간을 검토하고, 제품을 시험하고, 어떤 말을 할지 정하는 데 시간이 든다.
   3. 기회비용: 그 시간을 설계 콘텐츠를 연구·제작하는 데 쓰는 편이 더 낫다고 판단한다.

6.2. 전업 채널의 현실적 제약

1. 채널은 사업이자 생계 수단이다

   1. 전업 운영: ArjanCodes는 취미 채널이 아니라 Arjan의 전업 직업이다.
   2. 고용 관계: 직원 한 명도 이 일을 전업으로 하고 있다.
   3. 지출 책임: 수익으로 청구서를 내고, 가족을 부양하고, 회사가 계속 운영되도록 해야 한다.

2. 후원을 없애려면 다른 수익원이 필요하다

   1. 실용적 걱정: 깊이 있는 방향을 선택하는 것과 사업이 돈을 벌어야 한다는 현실 사이에 긴장이 있다.
   2. 기존 수익원: 지금까지 주요 수익원은 여러 온라인 강의였다.
   3. 새로운 해법: AI 시대에도 유효한 설계 기본기를 가르치는 새 프로그램이 이 공백을 채운다.

6.3. Software Design Mastery로 강의를 통합한다

1. 새 프로그램을 약 1년 동안 준비했다

   1. 개발 기간: 지난 1년 동안 기존 강의보다 더 근본적이고 AI가 업무에 미치는 영향을 반영한 완전히 새로운 프로그램을 만들었다.
   2. YouTube와의 연결: 프로그램은 YouTube에서 공유하는 설계 중심 콘텐츠의 자연스러운 확장이다.
   3. 단일 제품화: 앞으로 제공할 강의는 Software Design Mastery 하나다.

2. 기존 강의를 하나의 새 과정으로 대체한다

   1. 이전 강의: Software Designer Mindset, Software Architect Mindset을 포함해 여러 온라인 강의를 운영했다.
   2. 소규모 과정: 과거에 더 작은 강의도 몇 개 제공했다.
   3. 변경 내용: Software Design Mastery가 과거의 모든 강의를 사실상 대체하는 완전히 새로운 프로그램이 된다.

3. 과정은 설계의 전체 여정을 따른다

   1. 핵심 기본기: 소프트웨어 설계의 핵심 기본기부터 시작한다.
   2. 시스템 설계(system design): 개별 코드 구조를 넘어 시스템 전체를 설계하는 단계로 나아간다.
   3. 트레이드오프: 설계자가 내려야 하는 선택과 트레이드오프를 다룬다.
   4. 성장 목표: 학습자가 더 시니어한 엔지니어로 변화하고, 시스템과 시니어 디자이너처럼 생각하는 방식을 익히도록 구성한다.

4. 학습 경험을 강의 영상 이상으로 확장한다

   1. 인증서: 프로그램의 주요 파트마다 수료 인증서를 받을 수 있다.
   2. 커뮤니티: 학습자 커뮤니티가 제공된다.
   3. 추가 콘텐츠: 더 깊이 파고들 수 있는 부가 콘텐츠가 있고, 전체 라이브러리에 계속 콘텐츠를 추가한다.
   4. 라이브 세션: 함께 설계 연습(design exercise)을 수행하는 실시간 세션이 있다.

5. YouTube와 유료 과정의 관계

   1. 깊이의 차이: YouTube 영상을 즐기는 사람은 Software Design Mastery에서 같은 주제를 더 깊이 학습할 수 있다.
   2. 공개 상태: 프로그램은 현재 이용 가능하다.
   3. 안내 주소: 자세한 내용은 https://arjan.codes/mastery에서 확인할 수 있다.

7. 개인적 메시지와 다음 단계

채널의 사업·콘텐츠 방향을 설명하는 일은 시청자에게 완벽한 제작자 이미지보다 변화 속에서 판단하는 한 사람의 모습을 보여 주려는 시도다.

7.1. 평범한 사람으로서 변화기를 공유한다

1. 개인적인 영상을 가끔 만들 수 있다

   1. 성격: 이번 콘텐츠는 평소의 코드 중심 영상과 달리 개인적인 업데이트다.
   2. 공유의 이유: 시청자가 화면 뒤에도 여러 일을 해결하며 살아가는 평범한 사람이 있다는 점을 알게 하려 한다.
   3. 시청자에 대한 배려: 이런 영상을 가끔 만드는 것을 시청자가 불편해하지 않기를 바란다.

2. 현재의 시대는 모두에게 혼란스럽다

   1. 불확실성: 집과 사무실, 채널과 사업, AI 변화가 동시에 일어나 방향을 정하기 어렵다.
   2. 공통된 경험: Arjan 역시 지금의 미친 듯한 시대를 헤쳐 나가며 여러 결정을 내리는 평범한 사람이다.
   3. 핵심 태도: 완벽한 해답을 이미 가진 척하기보다 변화 속에서 무엇을 지킬지 판단한다.

7.2. 시청자에게 던지는 질문

1. 채널이 미래에 어떻게 도울 수 있는지 묻는다

   1. 주제 제안: 앞으로 채널이 시청자에게 가장 큰 도움을 주려면 무엇을 다뤄야 하는지 댓글로 알려 달라고 요청한다.
   2. 설계 주제: 특정한 소프트웨어 설계 패턴이나 원칙을 다뤄 달라는 제안도 환영한다.
   3. 창의적 요청: 다음 영상에서 다뤄 볼 ‘이상한 패턴(crazy pattern)’이나 원칙이 있다면 공유해 달라고 한다.

2. AI 소음에 휩쓸리지 않기를 바란다

   1. 시청자의 상태: 시청자가 잘 지내고 있기를 바란다.
   2. 소음과 집중: AI 관련 과열된 뉴스와 예측이 실제 학습과 일상에서 지나치게 집중력을 빼앗지 않기를 바란다.
   3. 기본기로의 회귀: 도구의 소음보다 설계 원리와 자신이 해결하려는 문제에 집중하는 것이 장기적으로 유익하다.

3. 마지막에는 다음 추천 영상으로 넘어간다

   1. YouTube 추천: YouTube가 다음에 볼 만한 영상을 추천한다는 안내로 마무리한다.
   2. 의미: 특정 추천 영상의 내용보다, 이번 업데이트에서 제시한 방향을 생각해 보고 다음 콘텐츠로 이어가라는 열린 결말이다.

주요 발언 모음

“이 채널의 핵심은 언제나 소프트웨어 설계와 Python, 그 순서일 것이다.”

“생성형 AI가 하는 일은 좋은 소프트웨어 설계와 근본적으로 맞지 않는 방향일 때가 있다.”

“우리는 왜 이 모든 것을 해야 하는지, 이것으로 실제로 무엇을 달성하는지 묻는 일을 잊는다.”

“AI가 우리를 더 나은 일을 하도록 돕는 의미 있는 도구가 아니라 슬롭 엔진이 될 수 있다.”

“비행 중에 물리 계산을 할 필요는 없지만, 비행기가 어떻게 작동하는지 알려면 양력·항력·추력 같은 기본 원리를 알아야 한다.”

“사람이 직접 코드를 쓰든, AI 에이전트 팀이 코드를 쓰게 하든, 그 사이의 무엇이든 설계 기본기가 필요하다.”

“나는 AI를 완전히 무시하지는 않겠지만, 특정 도구를 다루는 데 콘텐츠의 초점을 맞추고 싶지는 않다.”

“내가 이 일을 계속할 수 있도록 깊이 있는 영상을 좋아한다면 좋아요를 누르고, 생각을 댓글로 남기고, 영상을 공유하고, 채널을 구독해 달라.”

“후원 제안은 1,000건 중 999건을 거절할 정도로 신중하게 골라 왔다.”

“Software Design Mastery는 과거에 제공하던 모든 강의를 대체하는 완전히 새로운 프로그램이다.”

핵심 데이터 & 수치

• 영상 길이: 18분 49초다.
• 채널 운영 기간: 채널을 시작한 지 약 5년이다.
• 집 철거 기간: 세 겹의 천장과 오래된 설비를 제거하는 데 약 4개월이 걸렸다.
• 건물의 오래된 전기 케이블: 약 100년 된 전기 케이블을 철거했다.
• 인터넷 인프라: 약 30년 전의 인터넷 인프라가 남아 있었다.
• 현재 사무실 체류 기간: 오래된 교도소 건물의 사무실에서 약 반년 일했다.
• 새 사무실 이전 시점: 집을 옮긴 뒤 약 한 달 후 새 사무실로 이동할 예정이다.
• 새 영상 배경 변화: 새 사무실을 꾸미면서 약 한두 달 안에 배경이 바뀔 예정이다.
• 후원 거절 비율: 도착한 후원 제안 약 1,000건 가운데 999건을 거절해 왔다.
• 기존 후원 빈도: 후원 구간은 대략 한 달에 한 번을 목표로 했다.
• 새 강의 준비 기간: Software Design Mastery를 약 1년 동안 개발했다.
• 프로그래밍 언어 경험: 대학에서 Python뿐 아니라 C++와 Java를 주로 가르쳤다.
• drop_date 확인: yt-dlp upload_date=20260911, timestamp=1789138815로 확인했다. 원본 게시 시각은 2026-09-11 15:00:15 UTC, 한국 표준시로 2026-09-12 00:00:15다.

결론 및 시사점

1. 채널의 장기 정체성을 기본기로 고정한다: Python은 핵심 실습 언어로 남고, 소프트웨어 설계와 시스템 사고가 더 넓은 중심축이 된다.
2. AI를 도구로 상대하되 주제로 숭배하지 않는다: Claude Code와 에이전트 같은 제품은 필요할 때 다루지만, 일주일이나 한 달 뒤 바뀔 기능보다 설계 원칙을 가르친다.
3. 생성량보다 목적과 제거를 먼저 점검한다: 여러 에이전트를 돌려 거대한 변경을 만들기 전에 왜 필요한지, 실제로 무엇을 달성했는지, 아무도 쓰지 않을 결과를 만들고 있지 않은지 확인한다.
4. 설계 역량은 구현 주체와 무관하게 남는다: 사람이 직접 작성한 코드, 개발자가 AI를 보조적으로 쓴 코드, AI 에이전트 팀이 생성한 코드 모두 도메인 모델·아키텍처·트레이드오프 판단을 필요로 한다.
5. 기본기는 비행기의 물리 원리와 같다: 모든 개발 도구가 그 위에 세워진 설계·시스템 원리를 이해하면 도구가 바뀌어도 적절히 운용할 수 있다.
6. 깊이 있는 콘텐츠는 참여를 필요로 한다: AI 과열과 클릭베이트를 거부하는 채널은 조회수만으로 버티기 어렵기 때문에 좋아요·댓글·공유·구독이 사업의 지속 가능성과 직접 연결된다.
7. 후원보다 교육 제품의 방향을 맞춘다: 스폰서 업무에 쓰던 시간을 설계 콘텐츠에 돌리고, 기존 강의를 Software Design Mastery 하나로 통합해 콘텐츠와 수익 모델의 일관성을 높인다.
8. 시청자는 다음 주제를 함께 정한다: 어떤 설계 패턴·원칙·문제가 필요한지 댓글로 제안하면, 채널은 AI 유행이 아니라 실제 개발자의 성장에 맞춰 다음 콘텐츠를 조정할 수 있다.