00:00:00우리는 소프트웨어 개발의 새로운 시대에 와 있습니다. 개발자들은 이전에는
00:00:04본 적 없는 속도로 제품을 출시하고 있죠. 하지만 문제가 하나 생겼습니다. 에이전트가
00:00:08개입되면서 기존의 워크플로우가 더 이상 통하지 않게 된 것입니다. 여기서 중요한 질문이 생깁니다. 이제
00:00:13개발자의 역할은 어떤 모습일까요? 최근 Linear의 CEO가 쓴 글이 제 이목을 끌었습니다. Linear는
00:00:18현대적인 소프트웨어 개발에 특화된, 팀의 업무 조직과 추적을 돕는 프로젝트 관리 도구입니다.
00:00:23이러한 통찰은 전통적인 워크플로우에서 오늘날의 AI 기반 시스템으로의 전환을 직접 겪은 이로부터 나온 것입니다.
00:00:27이 글은 단순히 우리가 사용하는 도구뿐만 아니라, 제품을 만드는
00:00:33방식 전체를 다시 생각하게 만들었습니다. 오늘 이야기할 내용이 아주 많습니다.
00:00:37이 정보가 AI로 개발하는 방식을 근본적으로 바꾸기 때문입니다. 소프트웨어 작업의 “중간” 과정이
00:00:43사라지고 있고, 소프트웨어의 중심이 이동하고 있습니다. 이 “중간”이 무엇인지 이해하기 위해
00:00:47AI 개발 이전의 업무 분담 방식을 살펴보겠습니다. 먼저 시작 단계가 있습니다. 여기에는
00:00:52모든 요구 사항 수집과 기획 단계가 포함됩니다. 이 단계에서 우리는 무엇을
00:00:57만들 것인지에 대한 계획을 세웠습니다. 그다음은 중간 단계였습니다. 계획을 실제 제품으로
00:01:01변환하는 곳이었으며, 코드를 작성하는 과정이 포함되었습니다. 이 부분이
00:01:05전체 과정 중 시간을 가장 많이 잡아먹었습니다. 제대로 작동하는 고품질의 결과물을 내기까지 수주, 수개월, 때로는 1년이 걸리기도 했죠.
00:01:11또한 의도를 번역하거나 아이디어를 전달하는 과정에서 세부 사항이 가장 많이 뒤섞이는 부분이기도 했습니다.
00:01:16코드가 작성된 후의 마지막 단계는 원래 요구 사항과 대조하며 다양한 형태의
00:01:20테스트와 검토를 거치는 것이었습니다. 중간 단계는 마찰이 가장 심한 부분이었지만,
00:01:25CEO는 이제 더 이상 그렇지 않을 것이라고 말합니다. 구현과 코딩이라는
00:01:30중간 작업이 사실상 AI로 대체되고 있기 때문입니다. 이제 우리는 코드를 직접 건드릴 필요가 없습니다.
00:01:35코딩 에이전트가 매우 강력해져서 컨텍스트와 작업 계획만으로도 코드를
00:01:40생성할 수 있게 되었기 때문입니다. 이제 코드를 쓰는 것보다 에이전트를 올바르게 사용하고 감독하는 것이 더 중요해졌습니다.
00:01:45저희 영상을 꾸준히 보셨다면, 상용 수준의 앱을 제작하기 위해 코딩 워크플로우를
00:01:50사용하는 다양한 방법들을 이미 시연하고 가르쳐 드린 것을 아실 겁니다.
00:01:55단 한 줄의 코드도 직접 짤 필요 없이 에이전트를 감독하는 것만으로 가능합니다. 이제 IDE는
00:01:59작성 도구라기보다 코드 뷰어에 가까워졌습니다. 개발자로서 저에게도 이 변화는
00:02:04매우 뚜렷하게 다가옵니다. 코드를 쓰기 위해 즐겨 쓰던 도구가 이제는
00:02:09에이전트가 만든 코드를 검토하는 도구가 되었기 때문입니다. 이제 저는 VS Code에서 검토를 하거나
00:02:14주석을 달아 AI 에이전트가 주석 처리된 기능을 구현하도록 만듭니다. 에이전트의 능력이 워낙 뛰어나서
00:02:19제가 직접 코드를 쓰거나 수정해야 할 일이 거의 없습니다. 하지만 이는 에이전트가
00:02:23의도를 제대로 이해했을 때만 가능합니다. 따라서 개발자로서 우리의 업무는 코드를 쓰는 것에서 감독하는 것으로 완전히 옮겨갔습니다.
00:02:28눈치채셨겠지만 저희는 영상에서 많은 것을 만듭니다. 영상 중간에 멈추고 화면에서 복사해야 했던
00:02:33모든 프롬프트, 템플릿, 자료들을 한데 모았습니다. 최근 AI Labs Pro를 런칭하여
00:02:38이번 영상은 물론 이전의 모든 영상 속 자료들을 이용하실 수 있게 했습니다. 저희가 하는 일이 가치 있다고 느끼고
00:02:43채널을 후원하고 싶으시다면 이 방법이 가장 좋습니다. 링크는 설명란에 있습니다. 이제 AI가
00:02:48대부분의 코딩 작업을 대신하게 되었으니 질문이 하나 남습니다. 우리에겐 무엇이 남았을까요? 정답은
00:02:53무엇을 만들지에 대한 “의도”를 정교화하는 새로운 기술에 집중하는 것입니다. 이를 위해서는
00:02:59기획을 여러분의 주된 업무로 삼아야 합니다. 해결하려는 문제가 무엇인지 명확히 이해해야 합니다.
00:03:03고객이 정말로 원하는 것이 무엇인지, 사람들이 여러분의 앱을 어떻게 사용할지도 알아야 하죠.
00:03:07이런 것들이 이제 훨씬 더 중요해졌습니다. 더 이상 부실한 기획에서도 의도를 알아차리는 인간에게
00:03:12의존하는 게 아닙니다. 대신, 여러분이 지시하는 것을 맹목적으로 구현하는 AI 에이전트에게
00:03:17의존하게 됩니다. 모바일 앱을 만들든 웹 앱을 만들든, 무엇을 만들고 싶은지 정확히 알아야 합니다.
00:03:23그런 명확함 없이는 에이전트의 기획 모드를 활용해 의미 있는 기획을 할 수 없습니다. 기획이 핵심입니다.
00:03:27이전 영상들에서 강조했듯이, 좋은 계획만이 좋은 구현으로 이어집니다. 어떤 에이전트를
00:03:32사용하든 상관없습니다. 기획은 에이전트의 결과물을 제어하기 때문에 매우 중요합니다. 필요한 만큼
00:03:38시간을 들이세요. 계획이 여러분의 필요와 기대를 충분히 만족시킬 때까지 계속 다듬어야 합니다.
00:03:42그래야만 앱이 원하는 대로 완성될 것입니다. 불과 3개월 전만 해도
00:03:47저희는 '권한 우회(bypass permission)' 모드에 의존하지 않았습니다. 좋은 기획이 있어도 에이전트가 환각 현상을 일으켰기 때문이죠.
00:03:52이제 에이전트는 매우 신뢰할 만해졌습니다. 기획을 다듬은 후 '권한 우회' 모드를 켜고
00:03:56에이전트가 한 번에 사양을 구현하도록 내버려 둡니다. 또한 Claude Code의
00:04:02개발자조차도 기획 모드에서 구현을 시작하는 것을 보았습니다. 기획이 충분히 훌륭하다면
00:04:06지저분한 구현을 걱정할 필요 없이 에이전트가 한 번에 앱을 만들게 할 수 있습니다. 저는 또한
00:04:12제가 만드는 것이 완벽하게 문서화되도록 상당한 시간을 할애합니다. 모든 내용을
00:04:16한 문서에 몰아넣지 않아야 에이전트가 계획을 쉽게 파악할 수 있습니다. 위험 평가, 완화 전략,
00:04:21기술 사양 등 카테고리별로 별도의 문서를 사용합니다. 제약 조건과 트레이드오프는 별도 문서에 나열합니다.
00:04:26이렇게 해야 에이전트가 성능, 비용, 시간 측면에서 무엇이 허용되는지 이해합니다.
00:04:31이러한 접근 방식은 훨씬 더 통제된 개발로 이어집니다. 모든 요구 사항이 검증되면, 다음 단계는
00:04:35실제로 에이전트를 관리하여 원하는 것을 얻는 것입니다. 그 이야기를 하기 전에, 오늘 후원사인
00:04:40Dart AI를 잠시 소개하겠습니다. 복잡한 소프트웨어 프로젝트를 관리할 때는 실제 코딩보다 행정적인 오버헤드가
00:04:45더 많이 발생하곤 합니다. Dart는 평범한 프로젝트 관리 도구가 아닙니다. 개발자의 단순 반복 업무를
00:04:50자동화하기 위해 설계된 AI 네이티브 워크스페이스입니다. 컨텍스트를 인식하는 AI 채팅을 통해
00:04:56자연스럽게 말하는 것만으로 작업을 생성하고 문서를 편집할 수도 있습니다. AI 채팅뿐만 아니라,
00:05:00Cursor와 같은 에이전트를 온보딩하여 작업을 실행할 수도 있습니다. Dart가 에이전트에게 코드를 작성할 수 있는 컨텍스트를 제공하죠.
00:05:05진정한 위력은 'AI 가이드라인' 기능에 있습니다. AI가 기술 사양을 작성할 때 항상 특정 목표와
00:05:11요구 사항 헤더를 사용하도록 전역 규칙을 설정할 수 있고, Dart는 생성되는 모든 채팅과 작업, 문서에 이 구조를 강제합니다.
00:05:16저희에게 'AI 스킬' 기능은 혁신적입니다. '프로젝트 생성' 스킬 같은 맞춤형 명령어를 정의하면
00:05:22자동으로 채워진 작업 목록을 만들고, 우선순위를 배정하고, 규모를 산정하고, 프로젝트 개요를 몇 초 만에 작성합니다.
00:05:27고정 댓글의 링크를 통해 Dart AI를 확인하고 오늘부터 프로젝트 관리 자동화를 시작해 보세요.
00:05:33여러분은 이제 단순한 코더가 아닙니다. 여러분의 업무는 직접 코드를 쓰는 것보다 에이전트를 감독하는 것에 더 치중되어 있습니다.
00:05:38코드를 쓰는 것은 해결책을 구축하는 것이라기보다 좋은 해결책이 나올 수 있는 조건을 설정하는 것에 가까워졌습니다.
00:05:44그렇다면 에이전트가 양질의 결과물을 낼 수 있는 올바른 환경을 어떻게 만들까요? 정답은 컨텍스트 엔지니어링입니다.
00:05:49다음에 배워야 할 중요한 기술은 MERN이나 MEAN 같은 특정 웹 개발 스택이 아닙니다.
00:05:54대신 컨텍스트 관리입니다. 적절한 컨텍스트 관리가 없으면 에이전트가 프롬프트한 기능을
00:05:58구현은 하지만, 지켜야 할 제약 조건이나 규칙을 따르지 않는 경우를 계속해서 보아왔습니다.
00:06:03컨텍스트가 제대로 관리되도록 보장해야 합니다. 에이전트에게 노이즈가 최소화된
00:06:08정확한 정보가 주어지면 작업을 더 명확하게 이해합니다. 그러면 더 나은 구현물을 만들고
00:06:14정확히 원하는 결과를 제공합니다. 컨텍스트 관리는 재사용 가능한 명령어, 스킬, 마크다운 파일,
00:06:18MCP, 서브 에이전트와 같은 구성 요소 세트를 사용하는 것을 포함합니다. 정해진 단 하나의 정답은 없습니다.
00:06:22만들고자 하는 것에 잘 맞는 여러 방법을 혼합해서 사용해야 합니다. 프로젝트에 적합한
00:06:27워크플로우를 직접 만들어야 합니다. 컨텍스트 관리를 통해 워크플로우를 구축하는 방법을
00:06:32설명하는 영상을 따로 준비했습니다. 이를 통해 여러분이 사용하는 모델이 적절한 컨텍스트를 얻고
00:06:37고품질의 애플리케이션을 생산할 수 있게 됩니다. 같이 해보고 싶으시다면, 해당 영상의 모든 리소스는 AI Labs Pro에서 확인하실 수 있습니다.
00:06:43에이전트의 작업물은 그것이 작동하는 컨텍스트 중심 환경의 수준에 달려 있습니다. 고객의 피드백에 직접 연결되고
00:06:47구조화된 워크플로우의 지원을 받을수록 에이전트는 더 잘 작동할 수 있습니다. 이러한 환경은 자동으로 만들어지지 않기에
00:06:52우리가 직접 구축해야 합니다. 이런 이유로 Claude는 팀원들이 오류를 직접 보고할 수 있도록
00:06:56Slack과 연동됩니다. 이는 가치 있는 피드백 루프를 생성하며, Claude Code의 개발자조차도 이를 활용했습니다.
00:07:01대규모 팀들은 이미 고품질의 AI 생성 코드를 생산하고 있습니다. Claude Code의 개발자는 지난 한 달 동안
00:07:06본인 기여분의 100%가 사실상 Claude Code에 의해 작성되었다고 주장했습니다. 이것은 단순히 프롬프트를 넣는다고
00:07:11되는 것이 아닙니다. 이를 가능하게 하는 일련의 워크플로우와 오케스트레이션 패턴이 필요합니다.
00:07:16Microsoft의 CEO조차도 이제 모든 언어에 걸쳐 Microsoft 통합 코드의 20~30%를 AI가
00:07:20생성한다고 인정합니다. 특히 Python과 C++에서 눈에 띄는 진전이 있습니다.
00:07:25도구의 구조화는 인간과 에이전트 모두에게 똑같이 작용합니다. 기대치가 무엇인지, 어떤 능력이 존재하는지
00:07:30명확히 정의함으로써 불확실성을 줄여줍니다. 구조 없이 AI 에이전트를 사용하고 있다면,
00:07:35그 잠재력의 아주 일부만 사용하고 있는 셈입니다. 구조는 여러 형태를 가질 수 있습니다.
00:07:41전체 프로젝트 가이드를 위한 Claude.md 파일이나 변경 사항을 추적하는 변경 로그 등이 포함됩니다.
00:07:46재사용 가능한 명령어(slash commands)나 스크립트와 참조가 담긴 특화된 skill.md 파일을 사용할 수도 있습니다.
00:07:52게다가 플러그인과 MCP 도구를 사용하여 에이전트의 능력을 확장할 수도 있습니다.
00:07:58하지만 이러한 도구들을 아는 것만으로는 부족합니다. 올바른 조합이 중요합니다. 프로젝트마다
00:08:03필요한 설정이 다르므로, 프로젝트의 요구 사항에 따라 구축해야 합니다. 적절한 균형을 찾으면
00:08:08원하는 결과를 얻을 수 있을 것입니다. 기획하고 업무를 에이전트에게 위임했다고 해서 작업이 끝난 것이 아닙니다.
00:08:13앞서 언급했듯이 저는 Claude Code가 위험할 수도 있는 권한 건너뛰기 모드로 작동하게 둡니다. 이는 시간을 많이 아껴주지만,
00:08:19대신 다른 부분에 우리의 시간과 주의를 집중할 것을 요구합니다. 압박은 사이클의 마지막 단계로 이동합니다.
00:08:25코드 검토가 더욱 중요해지는 것이죠. 검토되지 않은 코드는 성능 저하와 높은 비용으로 이어질 수 있습니다.
00:08:29구조화된 워크플로우를 사용하면 검토를 더 쉽게 만들 수 있습니다. 이는 버그를 줄이고 나중에 생길 문제를 방지해 줍니다.
00:08:34이제 테스트는 단순히 에이전트에게 가서 모든 문제를 테스트해달라고 말하는 것이 아닙니다. 프로세스를 개선하기 위한
00:08:39여러 접근 방식이 포함됩니다. 한 가지 방법은 테스트 주도 개발(TDD)입니다. 구현하고 싶은 기능에 대해
00:08:44처음에는 코드를 전혀 쓰지 않고 에이전트에게 테스트 케이스부터 작성하도록 요청합니다.
00:08:49테스트가 작성되면 컨텍스트를 지우고 새 창을 엽니다. 이렇게 하면 에이전트가 테스트를 어떻게 작성했는지에 대한
00:08:53컨텍스트를 잃게 됩니다. 그다음 Claude에게 테스트를 실행하라고 시키면, 작성된 코드가 없으므로 실패할 것입니다.
00:08:58테스트가 올바르게 작동하는 것을 확인했으니, 이제 Claude에게 라우트를 구현하라고 요청합니다. 이때
00:09:02테스트 코드는 수정하지 못하게 합니다. 이런 방식으로 에이전트는 반복하며 나아갈 명확한 목표를 갖게 됩니다.
00:09:07TDD에서는 코드보다 테스트를 먼저 쓰지만, 테스트는 코드가 작성된 후에도 이루어져야 합니다.
00:09:12이를 위해 다양한 형태의 테스트가 존재합니다. 저는 블랙박스 테스트를 사용하고 사용자 스토리를 만듭니다.
00:09:17이것은 사용자가 실제로 시스템과 상호작용하는 방식과 그 과정에서 어떻게 오류가 발생할 수 있는지에 대한 상세한 가이드 역할을 합니다.
00:09:22블랙박스 테스트는 코드 자체를 보지 않고 요구 사항을 기반으로 애플리케이션의 기능을 평가합니다.
00:09:26그런 다음 Claude Chrome 확장 프로그램을 사용해 테스트를 수행하고, 각 사용자 스토리의 섹션별로 반복 테스트를 요청합니다.
00:09:31블랙박스 테스트는 주로 기능적인 문제를 찾아냅니다. 성능 테스트를 위해서는 화이트박스 테스트도 필요합니다.
00:09:36단순히 출력값만 보는 것이 아니라 실제로 코드를 들여다보는 과정이죠. 코드가 어떻게 구현되었는지 추적하고
00:09:41그 아키텍처를 추론합니다. 화이트박스 테스트를 위해 저는 여러 테스트 섹션과 하위 섹션이 포함된 XML 문서를 사용했습니다.
00:09:46이 문서는 Claude가 작성된 코드를 탐색하고 아키텍처 문제를 찾는 방법을 안내하는 가이드 역할을 합니다.
00:09:51테스트를 단순화하기 위해, 테스트 폴더에 둔 문서 내의 테스트를 실행하는 커스텀 명령어를 사용했습니다.
00:09:56이 명령어에는 테스트 초기화 지침, 결과를 구조화된 형식으로 파일에 기록하는 방법,
00:10:00그리고 마지막에 최종 보고서를 생성하는 방법이 나열되어 있습니다. 이 슬래시 명령에는 테스트를 위한
00:10:05구조화된 프롬프트가 포함되어 있어 화이트박스 테스트가 아주 쉬워졌습니다.
00:10:10이제 중간 과정이 사라지고 초점은 시작과 끝으로 옮겨가고 있으므로, 우리의 우선순위를 재고해야 합니다.
00:10:16우리가 지금 우선시해야 할 것은 기획과 요구 사항 평가를 통해 올바른 의도를 형성하는 것입니다.
00:10:21또한 철저한 테스트와 검토 과정을 통해 결과물이 기대에 부합하는지 확인해야 합니다.
00:10:25이러한 원칙을 마스터하는 개발자들이 미래를 주도하게 될 것입니다. 이것으로 이번 영상을 마칩니다.
00:10:31채널을 지원하고 이런 영상을 계속 제작하는 데 도움을 주고 싶으시다면, 아래의 Super Thanks 버튼을 이용해 주세요.
00:10:36언제나 시청해 주셔서 감사하며, 다음 영상에서 뵙겠습니다.
00:10:41which I placed in the testing folder. This command lists the instructions for initializing the tests,
00:10:46how to log the results into a file in a structured format, and at the end, how to generate a final
00:10:51report. This slash command made whitebox testing easy for me because it contains the structured
00:10:56prompt for testing. Since the middle is disappearing and the focus is shifting more toward the beginning
00:11:01and the end, we need to rethink our priorities. What we need to prioritize now is forming the
00:11:05right intent through planning and requirement assessment. We must also ensure that the outcome
00:11:10meets expectations through thorough testing and review processes. Those developers who master these
00:11:15principles will be the ones leading the future. That brings us to the end of this video. If you'd
00:11:20like to support the channel and help us keep making videos like this, you can do so by using
00:11:24the super thanks button below. As always, thank you for watching and I'll see you in the next one.