00:00:00사실 AI는 소프트웨어 개발 프로세스를 결코 혁신하지 못할 것입니다. 적어도 여러분이 생각하는 방식으로는요.
00:00:05확실히 모든 것을 더 빠르게 만들고, 문제가 생겼을 때 복구하는 것도 더 쉽게 만들어 줍니다.
00:00:10하지만 60년 이상의 제품 개발 과정에서 정립된 프로세스는 오늘날에도 여전히 중요합니다. 다만 그 이유가 달라졌을 뿐이죠.
00:00:16과거에는 인간이 이러한 제품을 개발할 수 있도록 구조화된 방법을 보장하기 위해 프로세스가 도입되었습니다.
00:00:21하지만 이제는 AI 에이전트가 인간처럼 일할 수 있도록 돕는 것으로 그 역할이 옮겨갔습니다.
00:00:25따라서 AI 에이전트가 제대로 작동하게 하려면, 그들이 실제로 프로세스를 따를 수 있도록 환경을 올바르게 설정해야 합니다.
00:00:32이제 개발을 시작하기 전에 거쳐야 하는 모든 단계들을 살펴보겠습니다.
00:00:36단 한 줄의 프롬프트를 작성하기 전에 요구 사항을 제대로 기획하는 것이 가장 중요합니다.
00:00:41이 부분은 모델이 아무리 좋아지더라도 여러분이 반드시 시간을 투자해야 하는 영역입니다.
00:00:45기획에는 여러 가지 방법이 있습니다.
00:00:46Claude Code의 기획 모드를 사용할 수도 있지만, 이는 제품 중심이라기보다 기술적인 측면에 매우 치우쳐 있습니다.
00:00:52이전 영상에서 언급했듯이 에이전트 기술이 발전함에 따라,
00:00:56기획 모드는 예전만큼 세부적이거나 기술적일 필요가 없으며, 대신 제품 측면에 집중해야 합니다.
00:01:01새로운 모델들은 강력하기 때문에, 성능이 낮았던 초기 모델 시절과는 기획 방식이 달라져야 하기 때문입니다.
00:01:07따라서 Claude의 기획 모드 대신, 앱 기획을 도와줄 별도의 에이전트를 만들 수 있습니다.
00:01:11여기에는 제대로 된 PRD를 작성하기 위한 지침과 템플릿이 포함되어 요구 사항이 무엇인지 Claude를 안내합니다.
00:01:18에이전트를 설정하고 나면 Claude에게 프롬프트를 주어 여러분이 만들고 싶은 앱을 기획하게 할 수 있습니다.
00:01:23그러면 기획자 에이전트를 로드하고 모든 요구 사항을 이해할 때까지 질문을 계속 던집니다.
00:01:28여러분이 기획 내용에 만족할 때까지 질문은 계속됩니다.
00:01:32MVP(최소 기능 제품)를 이해하기 위해 에이전트는 많은 질문을 하도록 설계되었습니다.
00:01:36마지막에는 앱에 추가로 필요한 기능이 더 있는지 물어볼 것입니다.
00:01:40만약 있다면, 에이전트가 구현해주길 바라는 것들을 추가하면 됩니다.
00:01:43모든 답변에 만족하고 에이전트가 계획을 잘 이해했다고 생각되면, 그냥 "그게 다야"라고 말하면 됩니다.
00:01:49질의응답 세션이 끝나면 PRD 문서를 생성하여 프로젝트 폴더에 저장합니다.
00:01:54이 문서에는 논의된 모든 요구 사항에 대한 세부 내용이 담겨 있습니다.
00:01:57구현 과정은 단계별로 나뉘어 있으며, 주요 설계 결정 사항과 앱에 필요한 모든 정보가 포함됩니다.
00:02:04어떤 앱을 만들지 구체화했다면, 다음 단계는 Claude.md 파일을 제대로 정의하는 것입니다.
00:02:10이 파일은 에이전트가 따라야 할 모든 지침을 담고 있기 때문에 매우 중요합니다.
00:02:15PRD 문서를 여기에 연결하면 에이전트가 앱 요구 사항에 직접 접근할 수 있어 내용을 반복할 필요가 없습니다.
00:02:21이 파일에는 에이전트가 이미 아는 것들이 아니라, 에이전트가 모르는 것들만 포함해야 합니다.
00:02:27프로젝트가 따르길 원하는 규칙들을 참조하게 됩니다.
00:02:30프로젝트 컨벤션이나 Claude가 앱을 구현할 때 특별히 지켜야 할 지침들을 추가할 수 있습니다.
00:02:37이상적인 접근 방식은 init 명령어로 Claude.md를 생성하는 것이 아니라 직접 만드는 것입니다.
00:02:43init 명령어는 실제 필요한 정보가 아니라 단순히 기존 코드베이스를 바탕으로 파일을 생성하기 때문입니다.
00:02:49하지만 이 파일은 한 번 쓰고 잊어버리는 파일이 아닙니다.
00:02:53작업을 진행하면서 앱 빌드 프로세스를 점진적으로 개선할 수 있도록 내용을 계속 추가해야 합니다.
00:02:58지난 영상에서 말했듯이, 이 파일은 한 번 로드되면 컨텍스트에 영구적으로 남아 작업 중 가이드라인 역할을 합니다.
00:03:05따라서 실제로 필요하지 않은 내용이나 특정 구현 영역에만 국한된 내용이 포함되지 않도록 주의하세요.
00:03:12이 파일에 추가해야 할 것들은 프로젝트의 모범 사례, 코딩 컨벤션, 작성 스타일 및 규칙 등입니다.
00:03:19하지만 프로젝트 구조처럼 AI가 스스로 파악할 수 있는 것들은 넣지 마세요.
00:03:24그런 부분은 AI가 파일 구조를 읽고 스스로 이해할 수 있습니다.
00:03:28그러니 실제로 앱을 구현하기 전에 충분한 시간을 들여 프로젝트와 요구 사항에 맞게 이 파일을 작성하세요.
00:03:36다음으로 설정할 것은 실제 빌드 전에 프로젝트에서 사용할 기술(Skills), 에이전트, 그리고 MCP입니다.
00:03:42MCP는 연결하기가 더 쉽습니다.
00:03:44에이전트가 접근하길 원하는 외부 서비스를 연결하고 설치 명령어를 실행하기만 하면 됩니다.
00:03:50예를 들어, 저희는 백엔드를 Supabase로 구축하고 싶어서 프로젝트 에이전트에 Supabase MCP를 연결했습니다.
00:03:57UI 컴포넌트로 Shadcn UI를 사용하고 브라우저 테스트로 Playwright를 사용한다면,
00:04:01에이전트가 빌드 중에 이러한 도구들에 접근할 수 있도록 미리 연결해 두어야 합니다.
00:04:07이것들이 외부 서비스 연결을 위한 것이라면, 에이전트 자체도 구성해야 합니다.
00:04:12필요한 만큼 많은 에이전트를 구성할 수 있습니다.
00:04:14이미 기획을 담당하는 전용 기획자 에이전트가 있습니다.
00:04:16커밋을 담당하며 사전 체크를 수행하고 규칙에 맞는 커밋 메시지를 작성하는 커밋 에이전트도 만들 수 있습니다.
00:04:23코드를 리팩토링하고 전반적인 성능을 개선하는 리팩토링 에이전트도 둘 수 있죠.
00:04:28또한 Playwright MCP 도구를 사용하여 UI와 사용자 흐름이 의도대로 작동하는지 검증하는 검증 에이전트도 가능합니다.
00:04:39에이전트 외에도 기술(Skills)을 구성해야 합니다.
00:04:42오픈 소스 GitHub 저장소에 있는 Skill Creator를 사용하여 필요한 만큼 쉽게 기술을 만들 수 있습니다.
00:04:49원하는 만큼 참조를 추가하고 스크립트를 포함시켜, 에이전트가 직접 실행하고 그 결과물을 사용하게 할 수 있습니다.
00:04:55에이전트와 기술의 사용 시점을 구분하자면, 반복 가능하고 가이드와 참조가 필요한 워크플로우를 기술로 구현하세요.
00:05:04예를 들어 프론트엔드 기술은 반복적인 워크플로우이며 앱 전반에 걸쳐 일관된 지침을 따라야 하므로 기술로 만드는 게 좋습니다.
00:05:11에이전트는 전용 컨텍스트 창이 필요한 작업에 사용하세요.
00:05:14Claude Code의 제작자가 직접 활발히 사용 중인 오픈 소스 프론트엔드 기술을 활용할 수도 있습니다.
00:05:20또한 앱의 특정 측면에 대한 경로별 규칙(Path specific rules)도 추가해야 합니다.
00:05:23이 규칙들은 해당 규칙이 적용될 경로를 정의하고 그 부분을 구현하는 데 필요한 모든 지침을 포함합니다.
00:05:29이런 규칙들을 원하는 만큼 구성하고 Claude.md에 연결하면 에이전트가 해당 지침을 따라야 함을 알게 됩니다.
00:05:36앞서 언급했듯이 Claude.md는 광범위한 원칙을 위한 것이고, 경로별 규칙은 특정 부분에 맞춘 상세 지침을 위한 것입니다.
00:05:46저희 채널에서는 이러한 설정과 AI로 제품을 만드는 더 많은 방법을 다루고 있으니 구독하고 계속 지켜봐 주세요.
00:05:54하지만 이러한 모든 긍정적인 지침(Positive instructions)만으로는 여전히 격차가 존재합니다.
00:05:58에이전트는 행동 지향적이라서 긍정적 제약 사항이 명시한 범위를 넘어서는 것을 구현할 수도 있기 때문입니다.
00:06:03따라서 에이전트에게 하지 말아야 할 일을 명시적으로 알려주어야 합니다.
00:06:06이 파일을 docs 폴더에 만들고 Claude.md에 링크하면 에이전트가 이러한 제약 사항이 있음을 알게 됩니다.
00:06:12여기에는 프로젝트에 맞춰 에이전트가 생성하지 않기를 바라는 모든 사항을 담아야 합니다.
00:06:19부정적 제약(Negative constraints)은 중요합니다. 긍정적 명세는 빈틈을 남기지만, 부정적 제약은 그 틈을 메워 모호함을 없애줍니다.
00:06:29이는 결과물이 어떤 모습이 아니어야 하는지에 대한 더 명확한 목표를 제공합니다.
00:06:32예를 들어 AI가 자주 쓰는 보라색이나 파란색 조합을 원치 않는다면, 그냥 암시하지 말고 명시적으로 거부하세요.
00:06:41다음으로 넘어가기 전에, 저희 후원사인 Way in Video에 대해 잠시 말씀드리겠습니다.
00:06:44긴 영상을 작업해 보셨다면 그 고충을 아실 겁니다. 좋은 장면 하나 찾으려고 몇 시간씩 돌려보고 편집해야 하죠.
00:06:52Way in Video가 이 모든 걸 해결해 줍니다. 여러분의 영상을 실제로 이해하는 AI 비디오 플랫폼입니다.
00:06:56OpenClaw의 AI 클리핑 기술은 긴 영상에서 가장 바이럴될 만한 순간을 찾아 세로형으로 변환하고 자막까지 달아줍니다.
00:07:04코딩도 설정도 필요 없습니다. 기술을 실행하기만 하면 클립이 바로 준비됩니다. 정말 간단하죠.
00:07:08특정 장면을 원한다면 평범한 영어로 검색할 수도 있습니다. "웃긴 반응"이나 "명언"을 치면 바로 그 위치로 점프합니다.
00:07:16화자 레이블이 포함된 영상 요약과 전사 기능도 제공하여 팟캐스트, 강의, 스트리밍 영상에 완벽합니다.
00:07:22콘텐츠를 재가공하든 워크플로우를 자동화하든, Way in Video는 매주 수시간을 절약해 줍니다.
00:07:27수동 편집에 시간을 낭비하지 마세요. 고정 댓글의 링크를 클릭해 시작해 보세요.
00:07:32이제 대부분의 AI 프레임워크가 어떤 식으로든 사용하는 한 가지 방식은 여러 용도로 문서를 나누는 것입니다.
00:07:38하지만 그 모든 문서의 핵심은 바로 진행 상황(Progress) 및 학습(Learning) 문서입니다.
00:07:42진행 상황 파일은 매우 중요합니다. 여러 기능이 있는 대규모 앱을 개발할 때 에이전트는 이미 구현한 기능을 잊기 쉽기 때문입니다.
00:07:52이 파일이 없으면 에이전트는 무엇이 완료되었는지 파악하기 위해 코드를 다시 읽고 문서와 비교해야 합니다.
00:07:58이는 오버헤드를 발생시키고 시간과 토큰을 낭비하게 만듭니다.
00:08:01따라서 에이전트가 한눈에 정확한 현황을 파악할 수 있는 진행 상황 파일을 만드세요.
00:08:07하지만 진행 상황 추적만으로는 부족합니다. 에이전트는 무엇이 잘못되었는지도 알아야 합니다.
00:08:11그래서 에이전트가 오류와 원인, 해결 방법을 기록하는 학습 파일이 필요합니다.
00:08:17이렇게 하면 나중에 비슷한 상황을 마주했을 때 같은 실수를 두 번 반복하지 않게 됩니다.
00:08:22이 두 파일은 앱 구현 중에 에이전트가 활발히 업데이트해야 하는 파일들이므로,
00:08:26Claude.md에 명시적으로 지시하여 에이전트가 빌드 과정에서 이 파일들을 계속 보완하도록 해야 합니다.
00:08:34이 두 파일은 모든 설정에 필요한 가장 필수적인 것들입니다.
00:08:38여러분만의 코딩 환경을 구축할 때 이 방식들을 활용해 보세요.
00:08:41프레임워크를 직접 구축하는 방법에 대해서는 이전 영상에서도 다룬 적이 있으니 채널에서 확인하실 수 있습니다.
00:08:46하지만 직접 설정하는 번거로움을 피하고 싶다면,
00:08:49기존 코딩 프레임워크를 신뢰하고 그들이 사용하는 메커니즘을 직접 구현하여 활용할 수도 있습니다.
00:08:56또 다른 흔한 실수는 개발이 다 끝난 후에야 테스트를 구현하는 것입니다.
00:09:00기능이 다 만들어진 후 에이전트에게 테스트 작성을 시키면 문제가 생깁니다.
00:09:05미리 작성했을 때만큼 테스트가 효과적이지 않기 때문입니다.
00:09:09테스트를 작성할 때 에이전트가 여러분이 만든 PRD를 참고하여 기능이 어떻게 작동해야 하는지 추론하게 해야 합니다.
00:09:16그런 다음 에이전트는 이러한 추론된 요구 사항을 바탕으로 테스트를 작성해야 합니다.
00:09:19본질적으로 PRD를 통해 기능과 오류 가능성을 역설계하는 과정인 셈입니다.
00:09:24테스트가 준비되면 마지막에 이를 실행하여 구현이 요구 사항을 충족하는지 교차 검증할 수 있습니다.
00:09:29테스트를 먼저 써야 하는 이유는, 사후에 구현하면 에이전트가 실제 구현된 내용만 알기 때문입니다.
00:09:35그러면 에이전트는 요구 명세가 아닌, 현재 존재하는 기능에 맞춰 테스트를 최적화해 버립니다.
00:09:41이로 인해 명세에는 있었지만 제대로 구현되지 않은 기능을 놓칠 수 있습니다.
00:09:46에이전트는 구현된 방식에 맞춰 최적화하려는 경향이 있어 철저한 테스트를 소홀히 할 수 있고,
00:09:50명세에서 직접 도출했다면 잡았을 에지 케이스(Edge cases)들을 놓칠 수 있습니다.
00:09:55Claude에게 "애플리케이션을 테스트해줘" 같은 막연한 지시를 내려서는 안 됩니다. Claude는 구현 내용에만 맞추려 할 것입니다.
00:10:02대신 명세에 기반한 적절한 테스트를 구현하여 에이전트가 무엇을 최적화해야 할지 정확히 알게 하세요.
00:10:07저희 콘텐츠가 마음에 드신다면 하이프(hype) 버튼을 눌러주세요. 더 많은 분들께 영상을 전하는 데 큰 힘이 됩니다.
00:10:14많은 이들이 앱 개발 중에 겪는 또 다른 문제는 사전에 이슈 트래킹을 하지 않는다는 점입니다.
00:10:19이게 없으면 이슈는 쌓여가는데 원인이나 발생 시점을 알 수 없게 되고, 앱이 커질수록 추적은 더 힘들어집니다.
00:10:26따라서 테스트 중에 적절한 로그를 유지하는 것이 매우 중요합니다.
00:10:29많은 분들이 GitHub를 사용하시는데, 이슈를 추적하고 관리하기에 아주 훌륭한 플랫폼입니다.
00:10:34구조화된 Git 커밋 메시지와 결합하면 Claude에게 각 커밋에서 무엇이 수행되었는지 안내하고 진행 상황을 추적하게 할 수 있습니다.
00:10:42Git의 가장 좋은 기능 중 하나는 변경 사항이 코드를 망가뜨렸을 때 커밋을 되돌릴 수 있다는 점입니다.
00:10:47실험적인 것을 테스트하고 싶다면 워크트리(worktree)를 사용하여 격리된 상태에서 진행할 수 있습니다.
00:10:51매 구현이 끝날 때마다 명확성을 위해 상세한 메시지와 함께 에이전트가 커밋하도록 설정을 구성할 수 있습니다.
00:10:58하지만 GitHub는 기술적인 사용자에게 적합하며, 비기술직 팀원들은 이슈 제출을 어려워할 수 있습니다.
00:11:03따라서 그들에게는 에이전트를 Trello나 Notion 같은 프로젝트 관리 도구에 연결하는 것이 이상적입니다.
00:11:08이를 통해 이슈를 기록하고, 진행 상황을 추적하며, 수정 사항에 대해 협업할 수 있습니다.
00:11:12해당 도구의 MCP를 연결하여 에이전트가 이슈에 접근하고, 보드 간에 이동시키며, 효율적으로 보고를 관리하게 하세요.
00:11:20또한 Claude.md에 에이전트가 버그와 이슈를 제대로 추적하기 위해 Notion MCP를 사용해야 한다는 지침을 추가해야 합니다.
00:11:28프로젝트가 커지고 여러 사람이 함께 개발하기 시작할 때, 처음에 이를 설정해 두는 것은 모든 것을 효율적으로 기록하고 추적하는 데 매우 소중한 가치를 지닙니다.
00:11:36하지만 앱이 테스트에서 완벽하게 작동하더라도, AI가 생성한 코드가 본질적으로 다수의 동시 사용자를 처리하도록 설계되지는 않습니다.
00:11:43이것이 많은 사람들이 AI로 구현한 앱이 운영 환경에서 성능 저하를 겪는 이유입니다.
00:11:47따라서 그 부분에 대해서도 대비가 필요합니다.
00:11:49예상되는 사용자 수가 있다면 에이전트에게 이를 알려주고 다수의 사용자가 동시에 앱을 사용할 것임을 명시하세요.
00:11:56그러면 에이전트는 이 정보를 바탕으로 부하 테스트(Stress testing)를 위한 테스트 케이스를 작성해야 합니다.
00:12:01사용할 수 있는 테스트 도구는 많으니 요구 사항에 맞는 것을 선택하시면 됩니다.
00:12:05저희는 Next.js 앱에 구현이 쉽고 요구 사항에 잘 맞는 K6를 사용했습니다.
00:12:10상세한 기술 계획이 필요한 이 단계에서는 Claude의 기획 모드를 사용하여 앱에 대한 여러 접근 방식을 설계할 수도 있습니다.
00:12:17Claude는 PRD와 예상 동시 사용자 수를 기반으로 계획을 세웁니다.
00:12:23Claude는 다양한 관점에서 여러 질문을 던지고 운영 환경에서 발생할 수 있는 잠재적 이슈들을 명확히 합니다.
00:12:29이는 문제가 발생하더라도 앱이 우아하게 실패(Fail gracefully)하도록 돕고 사용자 경험을 최적화합니다.
00:12:34이 모드를 통해 의도를 명확히 하고 에이전트가 확장성(Scalability)까지 계획하게 할 수 있습니다.
00:12:39이 계획은 아이디어를 실제 운영 가능한 수준으로 끌어올리는 마지막 퍼즐 조각이 됩니다.
00:12:43여기서 언급된 모든 에이전트와 기술은 AI Labs Pro에서 제공되며, 여러분의 프로젝트에 다운로드하여 사용하실 수 있습니다.
00:12:53저희 채널을 지원하고 싶으시다면 이 서비스를 이용해 보시는 것이 가장 좋은 방법입니다.
00:12:57링크는 설명란에 있습니다.
00:12:59이제 영상의 끝에 다다랐네요.
00:13:00채널을 후원하고 이런 영상을 계속 제작하는 데 도움을 주고 싶으시다면 아래의 Super Thanks 버튼을 이용해 주세요.
00:13:07언제나 시청해 주셔서 감사드리며, 다음 영상에서 뵙겠습니다.