이 영상에서 코드팩토리는 AI 코딩을 손코딩의 대체재가 아니라, 여러 에이전트를 지휘하는 개발 방식으로 설명한다. 초반 서비스는 코덱스와 크로드 코드를 섞어 쓰고, 딥리서치·다이나믹 워크플로우·GPT를 엮어 리서치와 구현 속도를 올리면서도, 결국에는 실제로 돈이 되는 작은 문제를 계속 출시하는 쪽으로 방향을 잡는다.

flowchart LR
A[AI 코딩을 어떻게 써야 하나] --> B[코드 읽기보다 에이전트 활용과 리서치 자동화]
B --> C[오케스트레이터처럼 AI를 지휘하며 하이레벨 지식으로 방향 제어]
C --> D[작고 돈 되는 문제를 빠르게 빌드하고 반복 출시]

핵심 요약

  • [01:55] 초반에는 코덱스를 쓰고, [02:00] 지금 굴리고 있는 서비스들은 전부 크로드 코드로 쓴다고 말한다.
  • [02:10] 그 이유로 UI가 편하고 패스트 모드가 있다는 점을 든다.
  • [07:30] “저 코드 하나도 안 보고서 하잖아요”라고 말하고, [07:48] 코드 확인이 오히려 병목이 된다고 잘라 말한다.
  • [08:12] 딥리서치는 작업을 페이즈로 나누고 스텝 바이 스텝으로 진행하며, [08:18] 여러 개의 에이전트를 동시에 써서 리서치를 더 빠르게 만든다고 설명한다.
  • [08:34] 이 흐름은 다이나믹 워크플로우와도 연동되고, [08:40] 앞으로 워크플로우들이 전부 그쪽으로 들어갈 거라고 말한다.
  • [08:49] 이제 자신은 오케스트레이터가 된 느낌이라고 하고, [08:59] AI를 주니어 개발자로 보면 사람은 팀장·시니어 개발자·PM 같은 역할이 된다고 정리한다.
  • [11:33] 코드 읽기를 배우는 건 좋지만, [11:41] 지금은 AI를 써서 하고 싶은 걸 해 보는 쪽이 더 중요하다고 말한다.
  • [12:07] 로우레벨 지식보다 하이레벨 지식이 더 도움이 된다고 보고, [12:12] 쿠버네티스나 CI/CD 파이프라인도 예전처럼 깊게 파기보다 개념을 이해하고 GPT에게 설명할 수 있으면 된다고 말한다.
  • [12:59] 대부분의 사람들은 AI 코딩을 보고 바로 “개발자 필요 없겠다”고 생각하지만, [13:19] 배우겠다는 생각이 들었다면 이미 앞서 있는 것이라고 강조한다.
  • [01:47:04] 결국 해결해야 할 것은 “실제로 돈이 되는 문제”이고, [03:06:23] 이후에는 “아주 사소한 문제”를 해결하는 아이디어를 하나씩 빌드하겠다고 방향을 다시 잡는다.

왜 지금 중요한가

이 영상은 AI 코딩 툴을 어떻게 고르느냐보다, 개발자가 어디에 시간을 써야 하는지에 더 무게를 둔다. 코드 한 줄씩 읽는 일, 쿠버네티스 세팅을 몸으로 익히는 일, 큰 제품을 오래 준비하는 일보다, 여러 에이전트를 굴리며 작은 문제를 빠르게 만들고 검증하는 쪽으로 중심이 이동하고 있다는 얘기다.

주요 내용

1. 코덱스와 크로드 코드를 쓰는 기준은 속도와 작업감이다

초반에는 [01:55] “코덱스만 써요”라고 말하지만, 이어서 [02:00] “지금 굴리고 있는 서비스들은 전부 크로드 코드로” 쓴다고 설명한다. [02:10] 이유는 단순하다. UI가 편하고 패스트 모드가 있기 때문이다. 툴의 철학보다도 실제 작업 속도와 인터페이스가 선택 기준으로 나온다.

2. 딥리서치와 다중 에이전트는 리서치 단계 자체를 바꾼다

[08:12] 딥리서치를 돌리면 작업을 “페이스로 나눠”서 “스텝바이 스텝”으로 진행해 준다고 한다. 여기에 [08:18] “여러 개의 에이전트”를 동시에 사용하니 리서치를 더 빠르게 할 수 있다고 말한다. [08:25] 구글 딥서치도 좋지만, 이 방식은 시각화가 잘 돼서 재미있다고 덧붙이고, [08:34] 다이나믹 워크플로우와도 연동되기 때문에 익숙해지는 게 좋다고 권한다.

3. 개발자는 손코더보다 오케스트레이터에 가까워진다

[07:30] “저 코드 하나도 안 보고서 하잖아요”라는 말 뒤에는 [07:48] “보면은 그게 병목이야”라는 판단이 붙는다. 그래서 [08:49] 자신을 오케스트레이터라고 부르고, [08:59] AI가 코드를 잘 쓰는 주니어 개발자라면 사람은 팀장, 시니어 개발자, PM 역할을 하게 된다고 설명한다. [10:01] 예전에는 개발자를 고용하거나 외주를 주고 직접 코드를 쳤던 일을, 앞으로는 아예 모르는 세대도 생길 거라고 말하는 대목이 이 변화의 방향을 잘 보여준다.

4. 지금 필요한 건 로우레벨 숙련보다 작은 문제를 계속 출시하는 감각이다

[11:33] 코드 읽기를 배우면 좋다고 하면서도, [11:41] 지금은 “기회의 시기”라서 AI를 써서 하고 싶은 걸 해 보라고 말한다. [12:07] 도움이 되는 건 로우레벨보다 하이레벨 지식이고, [12:12] 쿠버네티스나 CI/CD 파이프라인도 예전처럼 지옥 같은 러닝 프로세스를 거칠 필요 없이 개념만 이해한 뒤 GPT에게 물어보면 된다는 입장이다. 그래서 [12:43] “쿠버네티스 10분 만에 설명” 같은 수준의 이해만 있어도 모델에게 지시할 수 있다고 말한다. 이 판단은 [01:47:04] “실제로 돈이 되는 문제”를 풀어야 한다는 기준과 이어지고, [03:06:23] 결국에는 “아주 사소한 문제”를 하나씩 빌드하겠다는 결론으로 모인다. [03:06:33] 이미 12일차를 찍었고, [03:06:39] 너무 크고 멋진 것은 지금 자기 사이즈에서 갈 수 없다는 확신을 얻었다고 정리한다.

원문 발화 하이라이트

  • [07:30] “저 코드 하나도 안 보고서 하잖아요.”
  • [07:48] “보면은 그게 병목이야.”
  • [08:49] “이제 그냥 제가 오케스트레이터가 된 느낌이다.”
  • [11:41] “기회의 시기잖아요. 지금 AI를 썼을 때 그냥 하고 싶은 걸 하세요.”
  • [01:47:04] “실제로 돈이 되는 문제를 해결해 줘야 되는데.”

바로 실행해 보기

  • 지금 맡은 기능 하나를 고른 뒤, 구현부터 들어가지 말고 딥리서치처럼 조사 단계를 페이즈별 질문으로 쪼개 본다. 각 페이즈마다 무엇을 확인할지 한 줄씩 적어 두면, 여러 에이전트에 병렬로 던질 준비가 된다.
  • 막힌 코드 파일을 처음부터 끝까지 읽는 대신, 지금 필요한 주제가 인프라인지 배포인지 워크플로우인지 먼저 이름 붙여 본다. 그다음 그 개념만 하이레벨로 정리해서 GPT에게 “이 개념 기준으로 만들어 달라”고 요청해 본다.
  • 오늘 안에 만들 수 있는 아주 사소한 문제 하나를 정하고, 큰 제품 기획은 잠시 접어 둔다. 첫 버전을 만든 뒤 바로 “이게 실제로 돈이 되는 문제인가”만 따져 보면서 다음 빌드 후보를 이어서 적어 본다.

참고

영상 메타

수집 품질

  • 자막 세그먼트: 1741개
  • 자막 문자수: 24808자
  • 챕터 추출: 0개
  • 콘텐츠 생성: Subagent 기반

AI 생성 도구를 활용해 초안을 구성했고, 원영상 발화와 공개 자료를 교차 확인해 정리했습니다.