바이브 코딩을 최대한 활용하는 방법

채널 아이콘
Y Combinator 구독자 1,700,000명

요약

이 영상에서 Tom은 AI 기반 코딩(바이브 코딩)을 극대화하기 위한 구체적 베스트 프랙티스를 제시합니다. 창업자들이 추천하는 Cursor와 Windsurf 병행 사용법부터, AI를 새로운 프로그래밍 언어로 접근하고 테스트 주도 개발로 코드 안정성을 높이는 전략을 강조합니다. Git 버전 관리, 통합 테스트 작성, 마크다운 계획 수립, 모듈화·리팩토링, 스크린샷·음성 입력, 비코딩 작업 자동화 등 전문가 관점의 실용 팁을 다룹니다. 마지막으로 다양한 LLM 모델을 실험하며 지속적 개선과 시청자 참여를 독려합니다.

주요 키워드

vibe coding LLM 테스트 주도 개발 버전 관리 통합 테스트 모듈화 리팩토링 API Git 마크다운

하이라이트

  • 🔑 AI를 새로운 프로그래밍 언어처럼 간주하고 체계적 컨텍스트를 제공합니다.
  • ⚡️ Cursor와 Windsurf를 동시에 활용해 서로 다른 코드 버전을 비교합니다.
  • 🌟 먼저 Markdown으로 프로젝트 계획을 세우고 단계별로 구현합니다.
  • 📌 Git을 철저히 사용해 클린 슬레이트에서 커밋하고 필요 시 리셋합니다.
  • ✅ 통합 테스트를 활용해 사용자 관점으로 기능 회귀를 방지합니다.
  • 🐛 발생한 에러 메시지를 그대로 LLM에 복사해 빠르게 버그를 수정합니다.
  • 🚀 DevOps·디자인 등 비코딩 작업도 AI에게 맡겨 생산성을 높입니다.
  • 🔄 코드가 완성되면 자주 리팩토링해 품질과 가독성을 개선합니다

용어 설명

vibe coding

AI 언어 모델과 상호작용하며 코드를 생성하는 개발 방식

LLM

대규모 언어 모델(Large Language Model)을 의미합니다

테스트 주도 개발

먼저 테스트를 작성한 뒤 코드를 구현하는 개발 방식

버전 관리

Git 같은 도구로 코드 변경 이력을 관리하는 것

통합 테스트

사용자 관점에서 기능 동작을 검증하는 테스트

모듈화

코드를 작은 단위로 분리해 유지보수성을 높이는 설계 원칙

리팩토링

기능 변경 없이 코드 구조를 개선하는 과정

API 경계

서비스 간 명확한 인터페이스를 정의하는 개념

[00:00:09] 영상 소개 및 개요

Tom은 자신을 YC 파트너로 소개합니다. vibe coding 개념과 목표를 설명합니다.

[00:09] YC의 파트너 톰이 한 달간의 바이브 코딩 실험 경험을 소개하며, 이 방법이 효과적이고 실력 향상이 가능한 방법이라고 설명합니다.
[00:27] 바이브 코딩은 1-2년 전의 프롬프트 엔지니어링처럼 계속 발전하고 있으며, 전문 소프트웨어 엔지니어링 기법과 유사하다고 설명합니다.
[00:53] YC 스프링 배치 창업자들이 AI 도구 활용에 대한 실제 경험과 팁을 공유합니다.
[00:01:05] 도구 조합 활용 팁

Cursor와 Windsurf를 동시에 실행하세요. 서로 다른 구현 결과를 비교합니다.

[01:05] AI IDE 사용 시 막힘이 있을 때는 LLM 웹사이트를 직접 활용하면 더 나은 결과를 얻을 수 있다는 팁을 공유합니다.
[01:23] Cursor와 Warp를 동시에 활용하여 각각의 장점을 살린 효율적인 개발 방법을 설명합니다.
[02:05] AI를 새로운 프로그래밍 언어로 보고, 자연어로 프로그래밍하는 새로운 접근 방식을 제안합니다.
[00:02:07] AI 언어 관점과 TDD

AI를 새로운 프로그래밍 언어로 간주합니다. 먼저 테스트 케이스를 작성해 정확도를 높입니다.

[02:23] 테스트 케이스를 먼저 직접 작성하는 것부터 시작하는 방법론을 설명합니다.
[02:36] 테스트 케이스를 기반으로 LLM에게 명확한 가이드라인을 제공하여 코드를 생성하고, 테스트 통과 여부로 완성도를 판단합니다.
[02:57] LLM 사용 시 먼저 충분한 시간을 들여 프로젝트의 범위와 아키텍처를 설계한 후, 코딩 도구를 활용하는 것이 중요합니다.
[00:03:01] 프로젝트 계획 수립

코드 작성 전 AI와 함께 계획을 세웁니다. 마크다운 파일로 단계별 구현을 관리합니다.

[03:21] LLM이 문제 해결에서 벗어나거나 반복적인 오류가 발생할 때는 한 발 물러서서 전체적인 접근 방식을 재검토해야 합니다.
[04:12] 코딩 초보자는 Replet이나 Lovable 같은 시각적 도구로 시작하고, 경험자는 Cursor나 Claude Code를 직접 사용할 수 있습니다.
[05:04] 프로젝트 시작 시 즉시 코딩하지 말고, LLM과 함께 포괄적인 계획을 수립하고 문서화하여 참조해야 합니다.
[05:20] 프로젝트 구현 시 한 번에 모든 것을 처리하려 하지 말고, 단계별로 계획을 세우고 실행하는 것이 중요합니다. 불필요한 기능은 제외하고, 나중을 위한 아이디어는 따로 기록해두세요.
[05:43] 계획이 완성되면 섹션별로 구현하고, 각 단계마다 테스트와 커밋을 진행합니다. 현재 AI 모델은 복잡한 제품을 한 번에 완벽하게 만들어내기는 어려운 상황입니다.
[00:06:26] 버전 관리 & Git 활용

Git을 활용해 변경 이력을 철저히 관리합니다. 클린 슬레이트에서 리셋하고 다시 시도합니다.

[06:26] 버전 관리 시스템(Git)을 적극적으로 활용하세요. AI 도구의 되돌리기 기능보다는 Git을 통한 버전 관리가 더 안정적입니다.
[06:51] AI에게 같은 문제를 반복해서 요청하면 나쁜 코드가 쌓일 수 있습니다. 대신 좋은 해결책을 찾으면 깨끗한 상태에서 다시 구현하는 것이 좋습니다.
[07:21] 테스트 작성은 중요하며, 단위 테스트보다는 높은 수준의 통합 테스트를 작성하는 것이 효과적입니다. AI는 불필요한 코드 변경을 할 수 있으므로 테스트가 필수적입니다.
[00:07:23] 통합 테스트 작성

LLM에게 고수준 통합 테스트 작성을 요청합니다. 기능 동작을 사용자 관점에서 검증합니다.

[08:04] 테스트 스위트의 중요성과 LLM의 불필요한 변경을 감지하고 초기화하는 방법에 대해 설명합니다.
[00:08:16] 비코딩 작업 자동화

DevOps나 디자인 등 비코딩 작업도 AI에 맡깁니다. DNS 설정과 이미지 리사이징을 자동화합니다.

[08:16] LLM을 코딩 외의 작업에도 활용하는 방법을 소개합니다. DNS 설정, 호스팅 구성, 파비콘 제작 등 실제 사례를 공유합니다.
[08:57] 버그 수정 시 에러 메시지를 LLM에 직접 입력하는 것만으로도 효과적인 해결이 가능하며, 향후 자동화될 것으로 예상됩니다.
[00:09:39] 버그 수정과 디버깅

에러 메시지를 복사해 LLM에 입력합니다. 빠르게 버그 원인을 파악하고 수정합니다.

[09:51] 복잡한 버그 해결을 위한 전략으로 여러 가능성 분석, 초기화 후 재시도, 그리고 불필요한 코드 누적 방지 방법을 설명합니다.
[10:15] 다양한 AI 모델을 활용하고 깨끗한 코드베이스에서 버그를 수정하는 것의 중요성을 강조합니다.
[00:10:44] LLM 지침 파일 작성

Cursor 규칙이나 Markdown에 상세 지시를 기록합니다. AI 코딩 에이전트를 효율적으로 만듭니다.

[10:51] AI 코딩 에이전트를 위한 지시사항 작성의 중요성과 각 도구별 이름 지정 규칙의 차이점에 대해 설명합니다.
[00:11:09] 문서 로컬화 전략

API 문서를 로컬에 다운로드해 LLM에 제공합니다. 최신 문서를 참조해 정확도를 높입니다.

[11:09] 문서화 작업에서 웹 문서 참조의 한계와 로컬 문서 활용 방안에 대해 논의합니다.
[11:42] LLM을 교육 도구로 활용하는 방법과 코드 설명을 통한 학습 효과에 대해 설명합니다.
[12:04] 복잡한 기능 구현 시 독립 프로젝트로 시작하여 참조 구현을 활용하는 방법을 제안합니다.
[12:39] 모듈화의 중요성과 서비스 기반 아키텍처의 장점에 대해 설명하고, Ruby on Rails 프로젝트에서의 AI 활용 경험을 공유합니다.
[13:34] Ruby on Rails는 20년된 프레임워크로, 잘 정립된 관례와 일관된 코드베이스 구조를 가지고 있어 AI가 특히 잘 다룰 수 있습니다.
[14:11] 개발 시 스크린샷을 활용하면 UI 버그 확인과 디자인 참고에 매우 유용합니다.
[00:14:15] 스크린샷·음성 입력 활용

스크린샷으로 UI 버그나 디자인을 제시합니다. Aqua로 음성 명령을 빠르게 입력합니다.

[14:31] Aqua와 같은 음성 입력 도구를 사용하면 타이핑 속도의 두 배인 분당 140단어로 명령을 입력할 수 있습니다.
[15:06] 코드 리팩토링은 테스트가 구현된 후에 자주 수행해야 하며, 작고 모듈화된 코드를 유지하는 것이 중요합니다.
[15:39] AI 모델들은 빠르게 발전하고 있어 Gemini, Sonet 3.7, GPT 4.1 등 각각의 강점을 파악하고 적절히 활용하는 것이 중요합니다.
[00:15:56] 리팩토링·실험·마무리

테스트 완료 후 코드 리팩토링을 수행하세요. 다양한 모델을 실험해 최적 워크플로우를 찾습니다.

타임라인 정보가 없습니다.

[00:01] [음악]
[00:09] 안녕하세요, 저는 YC의 파트너 톰입니다.
[00:11] 지난 한 달 동안 몇 가지 사이드 프로젝트에서
[00:14] 바이브 코딩을 실험해 봤는데,
[00:16] 놀랍게도 매우 효과적일 뿐만 아니라
[00:19] 실력을 측정 가능할 정도로
[00:21] 향상시킬 수 있는 방법이라는 걸 발견했습니다.
[00:23] 새로운 시도와 베스트 프랙티스를
[00:25] 받아들일 준비만 되어있다면 말이죠.
[00:27] 이 영상에서는 바이브 코딩으로
[00:29] 훌륭한 결과를 얻을 수 있는 방법들을 공유하고자 합니다.
[00:31] 이는 1-2년 전의 프롬프트 엔지니어링과
[00:34] 비슷한 상황입니다.
[00:35] 사람들이 매주 새로운 것을 발견하고
[00:37] 소셜 미디어에 공유했죠.
[00:40] 가장 좋은 테크닉은 전문 소프트웨어 엔지니어가
[00:42] 사용하는 것과 동일한 테크닉입니다.
[00:44] 어떤 사람들은 '그건 바이브 코딩이 아니잖아,
[00:46] 그냥 소프트웨어 엔지니어링 아닌가요?'라고 합니다.
[00:48] 하지만 저는 그게 중요한 게 아니라고 봅니다.
[00:50] 우리는 이 도구들을 사용해서
[00:51] 최고의 결과를 얻으려 하는 것이니까요.
[00:53] YC 스프링 배치가 몇 주 전에 시작됐는데,
[00:55] 제가 조언을 드리기 전에,
[00:57] 현재 AI 도구들을 최대한 활용하는 방법에 대해
[00:59] 창업자들의 팁을 들어보겠습니다.
[01:01] 이들은 오늘날 AI 도구를 최대한 활용하는
[01:03] 방법에 대해 이야기해 줄 것입니다.
[01:05] AI IDE가 구현하지 못하거나
[01:06] 디버깅이 안 되는 상황에서 막혔을 때,
[01:08] 계속 같은 루프를 돌고 있다면
[01:10] 때로는 LLM 웹사이트로 직접 가서
[01:13] UI에 코드를 붙여넣고
[01:14] 같은 질문을 하면
[01:16] IDE에서는 얻지 못했던 결과를
[01:18] 얻을 수 있습니다.
[01:19] 이런 방식으로 문제를 해결할 수 있죠.
[01:21] 저는 같은 프로젝트에
[01:23] Cursor와 Warp를 동시에 사용하는 걸 추천합니다.
[01:25] Cursor는 좀 더 빠르기 때문에
[01:28] 프론트엔드나
[01:30] 풀스택 작업에 적합하고,
[01:31] 프론트엔드와 백엔드를 연결하는 데 좋습니다.
[01:33] Warp는 생각하는 시간이 좀 더 깁니다.
[01:35] 예전에는 그냥 폰을 보면서
[01:36] 에이전트를 만들거나
[01:38] 프롬프트를 수정하기를 기다렸는데,
[01:40] 스크롤하고 수정하고를 반복했죠.
[01:42] 지금은 Warp가 생각하는 동안
[01:44] Cursor에서 프론트엔드를
[01:46] 업데이트할 수 있습니다.
[01:48] 때로는 둘 다 동시에 실행하고
[01:49] 같은 컨텍스트를 제공합니다.
[01:51] 프론트엔드를 업데이트할 때는
[01:53] 파일의 스타일에 맞춰서
[01:54] 스타일링을 하고
[01:56] 양쪽 모두에서 실행하면
[01:58] 약간씩 다른 버전의
[02:00] 프론트엔드 결과물을 얻을 수 있어서
[02:02] 더 마음에 드는 것을 선택합니다.
[02:04] 제 조언은
[02:05] AI를 새로운 종류의
[02:07] 프로그래밍 언어로 생각하고
[02:09] 바이브 코딩을 새로운 타입의
[02:11] 프로그래밍 방식으로 보는 겁니다.
[02:13] 코드로 프로그래밍하는 대신
[02:15] 자연어로 프로그래밍하는 거죠.
[02:16] 그래서 좋은 결과를 얻으려면
[02:19] 필요한 맥락과
[02:21] 정보를 매우 상세하게 제공해야 합니다.
[02:23] 저는 보통 반대 방향에서
[02:26] 바이브 코딩을 시작합니다.
[02:28] 먼저 테스트 케이스부터 시작하는데,
[02:30] 테스트 케이스는 직접 만듭니다.
[02:31] 테스트 케이스 작성에는 LLM을 사용하지 않죠.
[02:34] 테스트 케이스를 직접 작성합니다.
[02:36] 테스트 케이스가 완성되면
[02:39] LLM이 따라야 할 강력한 가이드라인을 가지고 있어서
[02:42] 코드를 생성할 수 있죠.
[02:44] 그렇죠? 그러면 LLM이
[02:45] 원하는 대로 코드를 자유롭게 생성할 수 있고
[02:47] 테스트 케이스에서 초록불이 들어오면
[02:49] 작업이 완료된 겁니다. 코드베이스를
[02:51] 일일이 관리할 필요가 없어요. 그저
[02:53] 코드의 모듈성만 검토하면 되죠.
[02:55] 그 외에는 괜찮습니다.
[02:57] 네, 매우 중요한 것은
[02:59] 처음에는 순수하게 LLM과 함께
[03:01] 비합리적일 정도로 많은 시간을 들여서
[03:04] 범위와 실제
[03:06] 구축하려는 것의 아키텍처를
[03:08] 설계한 뒤에 Cursor나
[03:10] 다른 코딩 도구에 위임하는 거예요.
[03:12] 그리고 코드베이스에서
[03:14] 무작위로 작동하지 않는 것들을
[03:16] 만들도록 놔두지 마세요. 따라서
[03:18] 실제로 무엇을 만들려는지
[03:19] 목표를 이해해야 합니다. 제 조언은
[03:21] LLM이 질문에 답할 때
[03:24] 토끼굴에 빠지지 않도록
[03:26] 잘 모니터링하라는 것입니다. 만약
[03:28] 계속해서 코드를 재생성하고
[03:30] 이상해 보인다면, 그건
[03:33] 해결책을 찾지 못하고 있다는 거죠.
[03:34] 에러 메시지를 계속
[03:36] 복사해서 붙여넣어야 한다면,
[03:38] 뭔가 잘못되었다는 신호입니다.
[03:41] 한 발 물러서서
[03:42] LLM에게 "이봐, 잠깐
[03:45] 한 발 물러서서
[03:46] 왜 실패하는지 살펴보자.
[03:49] 이게 당신이
[03:51] 충분한 컨텍스트를 제공하지 않아서인지,
[03:53] 아니면 LLM이 이해하지 못해서인지,
[03:55] 또는 단순히 운이 없어서
[03:57] 요청을 수행할 수 없는 건지 확인해보자"라고 하세요. 여기서
[04:00] 핵심은 LLM이 전문
[04:03] 소프트웨어 개발자가 사용하는
[04:05] 프로세스를 따르도록 하는 것입니다. 자,
[04:07] 제가 본 최고의 바이브 코딩
[04:09] 조언들을 살펴보겠습니다. 먼저,
[04:12] 어디서부터 시작할지 말씀드리겠습니다. 코딩을
[04:14] 전혀 해본 적이 없다면, Replet이나
[04:17] Lovable 같은 도구를 추천합니다. 이들은
[04:19] 사용하기 쉬운 시각적 인터페이스를 제공하고
[04:22] 새로운 UI를 코드로 직접 시도해볼 수 있는
[04:25] 좋은 방법입니다. 많은 제품 관리자와
[04:28] 디자이너들이 실제로
[04:29] 새로운 아이디어를 바로 코드로 구현하고 있는데,
[04:32] Figma 같은 도구로 목업을 만드는 대신
[04:34] 너무나 빠르기 때문입니다.
[04:35] 제가 이것을 시도해봤을 때, UI는 인상적이었지만
[04:38] Lovable 같은 도구들은
[04:40] 순수한 UI 변경이 아닌 백엔드
[04:43] 로직을 더 정확하게 수정하고 싶을 때 어려움을 겪었습니다.
[04:46] 버튼을 이쪽에서 변경하면
[04:48] 백엔드 로직이 이상하게 바뀌었죠.
[04:50] 그래서 코딩 경험이 있다면, 저처럼
[04:53] 약간 서툴더라도
[04:55] Windsurf Cursor나 Claude Code 같은
[04:57] 도구들을 바로 사용해볼 수 있습니다.
[04:59] 사용할 도구를 선택했다면
[05:02] 바로 코딩을 시작하지 마세요.
[05:04] 대신, LLM과 함께
[05:06] 포괄적인 계획을 세우는 것을 추천합니다.
[05:08] 이 계획을 프로젝트 폴더 내 마크다운 파일에 저장하고
[05:12] 계속 참조하세요.
[05:14] 이는 AI와 함께 개발한 계획이며
[05:16] 단계별로 진행하면서
[05:18] 프로젝트를 구현하는 것입니다.
[05:20] 프로젝트를 구현하는 동안
[05:22] 전체를 한 번에 처리하려 하기보다는
[05:23] 단계적으로 진행하세요. 제가 추천하는 방법은
[05:26] 초기 계획 초안을 만든 후에
[05:28] 검토하면서 불필요한 부분을 삭제하고
[05:30] 너무 복잡한 기능들은
[05:32] '구현하지 않음'으로 명확히 표시하세요
[05:34] 또한 나중을 위한
[05:36] 아이디어 섹션을 따로 만들어두면 좋습니다
[05:39] AI에게 '이건 고려했지만
[05:41] 지금은 범위를 벗어난다'고 알려주세요
[05:43] 계획이 완성되면, AI와 함께
[05:45] 섹션별로 구현해 나가세요
[05:48] 예를 들어 '지금은 섹션 2만
[05:50] 구현하자'고 명시적으로 말하세요. 그다음
[05:52] 작동을 확인하고 테스트를 실행한 뒤
[05:54] 커밋하세요. 그리고 AI에게 돌아가서
[05:56] 섹션 2를 완료로 표시하게 하세요
[05:58] 현재로서는 AI 모델이 전체 제품을
[06:00] 한 번에 완벽하게 만들어내길 기대하긴 어렵습니다
[06:04] 특히 복잡한 제품의 경우에는요
[06:06] 저는 조각별로 나누어서
[06:08] 각 단계마다
[06:09] 제대로 작동하는지 확인하고
[06:10] Git에 커밋하는 것을 선호합니다
[06:12] 다음 단계에서 문제가 생겼을 때
[06:14] 되돌릴 수 있도록 말이죠. 하지만 솔직히
[06:17] 이 조언은 2-3개월 후면 달라질 수 있습니다
[06:19] AI 모델들이 너무나 빠르게 발전하고 있어서
[06:22] 가까운 미래에 어떻게 될지
[06:23] 예측하기 어렵네요. 다음 팁은
[06:26] 버전 관리를 사용하라는 것입니다. 버전 관리는
[06:28] 여러분의 동반자예요. Git을 철저하게 사용하세요
[06:32] AI 도구들에도 되돌리기 기능이
[06:34] 있지만, 아직은 신뢰하기 어렵습니다
[06:36] 그래서 저는 항상
[06:38] 새로운 기능을 시작하기 전에
[06:39] 깨끗한 Git 상태에서 시작하여
[06:41] AI가 잘못된 방향으로 나아갈 경우
[06:44] 정상 작동하는 버전으로 되돌릴 수 있게 합니다
[06:46] 작동하지 않으면 git reset --hard를 사용해서
[06:49] 다시 시도하는 것을 두려워하지 마세요
[06:51] 제가 발견한 건, AI에게 같은 문제를
[06:54] 여러 번 프롬프트로 요청하면
[06:57] 제대로 작동하게 만들려고 할 때
[06:58] 나쁜 코드가 계속 쌓이는 경향이 있다는 겁니다
[07:01] 근본적인 원인을 이해하지 못한 채
[07:04] 코드만 쌓이게 되죠
[07:06] 4-5-6번 다른 프롬프트를 시도해서
[07:09] 마침내 해결책을 찾았다면
[07:11] 저는 실제로 그 해결책을 가지고
[07:12] git reset으로 초기화한 다음
[07:15] 깨끗한 코드베이스에서 AI에게 그 해결책을 주어
[07:17] 불필요한 층들 없이
[07:19] 깔끔한 해결책을 구현하도록 합니다
[07:21] 다음으로 해야 할 것은
[07:23] 테스트를 작성하거나 AI에게 작성하게 하는 것입니다
[07:26] AI는 이런 작업을 잘하는 편이에요
[07:28] 다만 종종 매우 낮은 수준의
[07:30] 단위 테스트만 작성하려 하는데
[07:33] 저는 이런 테스트를 매우 높은 수준으로
[07:35] 유지하는 것을 선호합니다. 기본적으로
[07:38] 사이트나 앱을 클릭하면서
[07:40] 기능들이 종단간에 잘 작동하는지
[07:43] 확인하는 것이 좋습니다. 개별 함수 단위의
[07:45] 테스트보다는 전체적인 흐름을 테스트하고
[07:48] 다음 기능으로 넘어가기 전에
[07:50] 높은 수준의 통합 테스트를 작성하세요
[07:52] AI는 관련 없는 로직을
[07:55] 불필요하게 변경하는 나쁜 습관이 있습니다
[07:57] 여기 있는 문제를 수정하라고 하면
[07:59] 아무 이유 없이
[08:01] 저기 있는 로직을 바꿔버리죠
[08:02] 그래서 이런 테스트들이 있으면
[08:04] 테스트 스위트를 구축해두면 이러한
[08:06] 리그레션을 초기에 발견할 수 있고
[08:09] LLM이 불필요한 변경을
[08:10] 했을 때도 파악할 수 있어서
[08:13] 초기화하고 다시 시작할 수 있습니다. 기억하세요.
[08:16] LLM은 코딩에만 쓰이는 게 아닙니다.
[08:18] 사이드 프로젝트를 만들 때
[08:20] 비개발 작업에도 많이 활용합니다.
[08:21] 예를 들어, Claude 3.7을 사용해서
[08:25] 늘 귀찮았던 DNS 서버 설정과
[08:27] Heroku 호스팅을 커맨드라인으로 설정했죠.
[08:30] DevOps 엔지니어 역할을 대신해서
[08:32] 제 작업 속도를
[08:34] 10배나 향상시켜줬어요. ChatGPT로는
[08:37] 사이트의 파비콘 이미지를 만들었는데,
[08:40] 브라우저 상단에 표시되는
[08:41] 작은 아이콘이죠.
[08:44] 그리고 Claude가 그 이미지를 가져와서
[08:46] 간단한 일회용 스크립트를 작성해
[08:48] 6가지 다른 크기와
[08:50] 모든 플랫폼용 파비콘 포맷으로 변환했죠.
[08:53] 이제 AI가 디자이너 역할도
[08:55] 하고 있는 셈이죠. 자, 이제
[08:57] 버그 수정에 대해 알아보겠습니다.
[09:00] 버그를 발견하면 가장 먼저 하는 것은
[09:03] 에러 메시지를 그대로
[09:05] LLM에 복사 붙여넣기 하는 겁니다.
[09:07] 서버 로그 파일이나 브라우저의
[09:10] 자바스크립트 콘솔에서 나온 것일 수 있죠.
[09:13] 보통 이 에러 메시지만으로도 AI가
[09:15] 문제를 찾아 해결합니다.
[09:17] 무엇이 잘못됐는지
[09:18] 설명할 필요도 없이
[09:20] 에러 메시지만으로 충분하죠.
[09:22] 이게 너무 강력해서
[09:24] 곧 주요 코딩 도구들이
[09:26] 사람이 복사 붙여넣기 할 필요 없이
[09:29] 에러를 직접 처리할 것 같아요.
[09:30] 생각해보면 우리가
[09:32] 복사 붙여넣기 기계 역할을 하는 게
[09:35] 좀 이상하죠?
[09:36] 생각은 LLM에 맡기고
[09:38] 복사 붙여넣기는
[09:39] 곧 사라질 것 같아요.
[09:41] LLM 도구들이 로그를 추적하거나
[09:44] 헤드리스 브라우저를 실행해서
[09:46] 자바스크립트 에러를 검사할 거예요.
[09:48] 더 복잡한 버그의 경우,
[09:51] LLM에게 코드를 작성하기 전에
[09:52] 3-4가지 가능한 원인을 분석하도록 할 수 있습니다.
[09:55] 버그 수정 시도가 실패할 때마다
[09:58] 초기화하고 다시 시작하세요.
[10:00] 그래야 코드가
[10:01] 불필요하게 쌓이지 않습니다.
[10:03] 초기화 없이 여러 번 버그를 수정하려 하지 마세요.
[10:06] LLM이 계속해서
[10:08] 불필요한 코드를 추가할 뿐입니다.
[10:10] 로깅을 추가하세요. 로깅은 정말 유용합니다.
[10:13] 잘 안 된다면 망설이지 말고
[10:15] 다른 모델로 바꿔보세요. Claude 3.7일 수도 있고,
[10:18] OpenAI 모델이나
[10:20] Gemini일 수도 있죠. 경험상
[10:23] 어떤 모델은 다른 모델이
[10:25] 실패한 곳에서 성공하기도 합니다.
[10:27] 까다로운 버그의 원인을 찾았다면,
[10:29] 모든 변경사항을 초기화하고
[10:32] LLM에게
[10:34] 정확한 버그 수정 방법을
[10:36] 깨끗한 코드베이스에서 지시하세요.
[10:39] 이렇게 하면 불필요한 코드가
[10:41] 쌓이는 걸 방지할 수 있습니다.
[10:44] 다음 팁은 LLM을 위한
[10:46] 지침을 작성하는 것입니다.
[10:48] 이 지침들을 Cursor rules, WindSurf rules, Claw markdown에
[10:51] 각 도구마다 약간씩 다른 이름 지정 규칙이 있습니다.
[10:53] 하지만 제가 아는 창업자들 중에는
[10:55] AI 코딩 에이전트를 위해
[10:57] 수백 줄의 지시사항을 작성한 분들이 있는데
[11:00] 이를 통해 훨씬 더 효과적으로
[11:02] 작업할 수 있게 되었습니다. 온라인에는
[11:04] 이러한 지시사항 파일에
[11:06] 무엇을 포함해야 하는지에 대한
[11:07] 많은 조언들이 있습니다. 이는 직접 찾아보시기 바랍니다.
[11:09] 자, 이제 문서화에 대해 이야기해 보겠습니다.
[11:12] AI 에이전트가 온라인 웹 문서를
[11:14] 참조하는 것은 아직도
[11:17] 다소 불안정합니다.
[11:18] 일부는 MCP 서버를 사용하여
[11:21] 문서에 접근하는 것을
[11:22] 제안하고 있고, 일부에게는 효과가 있지만
[11:24] 제게는 좀 과하다고 생각됩니다.
[11:26] 그래서 저는 주로 모든 API 문서를
[11:28] 다운로드받아서
[11:31] 작업 폴더의 하위 디렉토리에 저장하여
[11:33] LLM이 로컬에서 접근할 수 있게 합니다.
[11:35] 그리고 지시사항에
[11:37] '구현하기 전에 문서를 읽어보라'고
[11:38] 명시합니다.
[11:40] 이렇게 하면 훨씬 더 정확해집니다.
[11:42] 참고로, LLM을 교사처럼 활용할 수 있는데,
[11:44] 특히 프로그래밍 언어에
[11:47] 익숙하지 않은 사람들에게 좋습니다.
[11:48] 무언가를 구현한 다음
[11:50] AI에게 그 구현 내용을
[11:52] 한 줄씩 설명하도록 할 수 있습니다.
[11:54] 새로운 기술을 배우는 데 아주 좋은 방법이죠.
[11:57] 이전처럼 Stack Overflow를
[11:59] 스크롤하는 것보다 훨씬 낫습니다.
[12:02] 자, 이제 더 복잡한
[12:04] 기능에 대해 살펴보겠습니다. 새로운 기능이나
[12:06] AI에게 맡기기에는
[12:08] 너무 복잡한 기능을 작업할 때는
[12:10] AI에게 맡기기보다는,
[12:13] 완전히 새로운 코드베이스에서
[12:15] 독립 프로젝트로 진행하는 것이 좋습니다.
[12:19] 기존 프로젝트의 복잡성 없이
[12:21] 작은 참조 구현을 먼저 만들거나
[12:22] 다른 사람이 작성해서
[12:25] GitHub에 올린 참조 구현을
[12:26] 다운로드하세요. 그런 다음
[12:29] LLM에게 그 구현을 참조하여
[12:32] 더 큰 코드베이스 내에서
[12:34] 재구현하도록 지시하면 됩니다.
[12:37] 놀랍게도 잘 작동합니다.
[12:39] 작은 파일과 모듈화가 중요하다는 것을 기억하세요.
[12:42] 이는 사람이 코딩할 때도 마찬가지입니다.
[12:44] 앞으로는 더 모듈화되거나
[12:46] 서비스 기반 아키텍처로
[12:48] 전환될 수 있을 것 같습니다. LLM이
[12:51] 명확한 API 경계 내에서 작업하면서
[12:53] 일관된 외부 인터페이스를
[12:55] 유지할 수 있기 때문입니다.
[12:58] 거대한 모노레포와
[13:00] 복잡한 상호의존성을 가진 구조는
[13:02] 사람과 LLM 모두에게 어렵습니다.
[13:05] 한 곳의 변경이
[13:07] 코드베이스의 다른 부분에
[13:09] 어떤 영향을 미칠지 알기 어렵죠. 그래서
[13:11] 일관된 외부 API를 가진
[13:13] 현대적 아키텍처를 사용하면
[13:16] 외부 인터페이스와
[13:18] 테스트만 통과하면 내부를 변경해도
[13:19] 문제없습니다.
[13:21] 이제 적절한 기술 스택 선택에 대해 말씀드리겠습니다.
[13:24] 저는 Ruby on Rails로
[13:26] 프로젝트를 구축했는데,
[13:28] 이전에 전문 개발자로
[13:30] 일할 때 익숙했기 때문입니다.
[13:32] 하지만 AI의 성능에 정말 놀랐습니다.
[13:34] Ruby on Rails 코드를 작성할 때
[13:37] Rails는 20년 된 프레임워크로
[13:40] 잘 정립된 많은 관례가 있기 때문에
[13:42] 대부분의 Rails 코드베이스가
[13:45] 매우 유사한 형태를 보이고
[13:47] 경험 많은 Ruby on Rails
[13:49] 개발자라면 특정 기능이
[13:50] 어디에 위치해야 하는지
[13:53] Rails 방식으로 특정 결과를
[13:55] 달성하는 방법을 알 수 있죠. 이는
[13:57] 온라인에 일관성 있고 높은 품질의
[14:00] Rails 코드베이스 학습 데이터가 많다는 뜻입니다.
[14:03] 제 친구들은 Rust나 Elixir 같은
[14:05] 언어에서는 성공률이 낮았는데
[14:07] 이는 학습 데이터가 충분하지 않기 때문이죠.
[14:09] 하지만 이는 곧 변할 수 있겠죠.
[14:11] 다음 조언으로 넘어가면, 스크린샷을 활용하세요.
[14:15] 요즘은 대부분의 코딩 에이전트에
[14:18] 스크린샷을 복사하여 붙여넣을 수 있는데
[14:19] UI에서 발견된 버그를 보여주거나
[14:22] 시각적으로 확인할 때
[14:24] 매우 유용합니다. 또한
[14:26] 다른 사이트의 디자인 영감을
[14:30] 프로젝트에 적용할 때도 좋죠.
[14:31] 음성은 이러한 도구들과 상호작용하는
[14:35] 또 다른 멋진 방법입니다. 저는
[14:37] YC 회사인 Aqua를 사용하는데
[14:40] 컴퓨터에 말하면 Aqua가
[14:43] 제가 말하는 내용을 사용 중인
[14:46] 도구에 옮겨 적어줍니다. 저는
[14:48] Winding Surf와 Cloud Code를
[14:49] 번갈아 사용하고 있는데, Aqua로
[14:52] 분당 140단어로 명령을 입력할 수 있어
[14:54] 타이핑 속도의 두 배나 됩니다.
[14:56] AI는 문법이나
[14:58] 구두점 실수에 매우 관대해서
[15:00] 전사가 완벽하지 않아도
[15:02] 전혀 문제가 되지 않습니다.
[15:04] 실제로 이 발표 전체를
[15:06] Aqua로 작성했죠. 다음으로,
[15:09] 자주 리팩토링하세요. 코드가 작동하고
[15:11] 특히 테스트가 구현되어 있다면
[15:13] 마음껏 리팩토링할 수 있습니다.
[15:16] 테스트가 있어서
[15:17] 회귀를 잡아낼 수 있기 때문이죠.
[15:19] LLM에게 코드베이스에서
[15:21] 반복적이거나 리팩토링이 필요한
[15:23] 부분을 찾아달라고 할 수도 있습니다.
[15:25] 이것 역시 모든
[15:27] 전문 개발자들이 따르는
[15:29] 조언이죠. 수천 줄이 넘는 파일을
[15:32] 만들지 말고
[15:34] 작고 모듈화된 상태로 유지하세요.
[15:35] 이렇게 하면 사람과 LLM 모두
[15:37] 이해하기가 훨씬 쉽습니다.
[15:39] 마지막으로, 계속 실험하세요.
[15:42] 이 분야의 최신 기술은
[15:44] 매주 변화하는 것 같습니다. 저는 새로운 모델이
[15:46] 나올 때마다 각각 다른 시나리오에서
[15:48] 어떤 것이 더 나은지 시도해봅니다.
[15:50] 디버깅, 장기 계획 수립, 기능 구현,
[15:53] 리팩토링에서 각각 다른 강점이 있죠.
[15:54] 예를 들어, 현재 Gemini는
[15:57] 전체 코드베이스 인덱싱과
[15:59] 구현 계획 수립에 가장 좋고
[16:01] 제가 보기에 Sonet 3.7은
[16:03] 실제 코드 변경을 구현하는 데
[16:05] 선두 주자인 것 같습니다. 며칠 전에
[16:08] GPT 4.1을 시도해봤는데
[16:10] 솔직히 그다지 인상적이지 않았어요.
[16:11] 너무 많은 질문을 하고
[16:13] 구현도 자주 잘못했거든요.
[16:15] 하지만 다음 주에 다시 시도해보면
[16:17] 상황이 또 달라져 있을 거예요.
[16:19] 시청해주셔서 감사합니다.
[16:21] 여러분이 이러한 모델들을 활용하는
[16:24] 팁이나 트릭이 있다면
[16:26] 댓글로 공유해주시면 감사하겠습니다.
[16:27] [음악]
[16:31] [음악]