소개: AI에게 “만들어줘”라고만 말하던 방식에서 벗어나기
이번 스터디에서는 AI 개발 도구를 단순히 코드 생성기로 쓰는 것이 아니라, 실제 개발 워크플로우 안에 어떻게 녹여낼 수 있는지를 중심으로 실습을 진행했다.
처음에는 Claude Code나 Codex 같은 도구를 사용할 때마다 같은 설명을 반복해야 했다.
디자인은 Figma에서 가져오지만, 실제 개발 코드에서는 디자인 컨벤션과 코딩 컨벤션이 맞아야 했고, AI가 만든 결과물을 매번 다시 확인하고 수정해야 했다. 여러 세션을 동시에 돌리면 시간이 지날수록 컨텍스트가 흐트러져 엉뚱한 답을 내는 문제도 있었다.
이번 실습의 핵심은 이 문제를 해결하기 위해 워크스페이스를 프로젝트 단위로 분리하고, 반복 작업을 스킬로 만들고, 검증 조건을 명확히 설계하는 것이었다.
진행 방법: 워크스페이스와 스킬을 나누고, 개발팀처럼 움직이게 만들기
가장 먼저 배운 것은 하나의 워크스페이스는 하나의 프로젝트에 집중하게 만드는 것이었다.
기존에는 하나의 워크스페이스 안에 여러 프로젝트를 넣고 관리했지만, 그렇게 하면 AI가 맥락을 헷갈릴 수 있었다. 그래서 프로젝트별로 워크스페이스를 분리하고, 각 프로젝트에 맞는 문서와 규칙을 정리했다.
이후에는 실제 개발팀의 흐름을 AI 에이전트 구조로 옮겨보는 실습을 했다.
예를 들면 다음과 같은 역할을 나누었다.
- 기획 에이전트
- 디자이너 에이전트
- 아키텍처 에이전트
- 안드로이드 개발 에이전트
- 코드 리뷰 에이전트
- QA 에이전트처음부터 MD 파일을 완벽하게 직접 쓰기는 어려웠기 때문에, AI와 질의응답을 주고받으며 필요한 내용을 채워 나가는 방식으로 구성했다. 예전에는 “그냥 만들어줘”라고 요청했다면, 이번에는 AI가 나에게 질문하고, 나는 그 질문에 답하면서 워크스페이스 문서를 함께 만들어가는 방식이었다.
반복되는 작업은 스킬로 묶었다. 대표적으로는 Figma 디자인을 구현 계획으로 변환하는 스킬, 코드 리뷰 스킬, QA·UI·디자이너 관점의 병렬 리뷰 스킬, 기획 내용을 에픽/스토리로 분해하는 스킬 등을 만들었다. 다만 스킬 문서가 너무 길어지면 AI가 내용을 무시할 수 있기 때문에, 최대한 짧고 명확하게 작성하는 것이 중요하다는 점도 배웠다.
실습에서 가장 인상 깊었던 부분: “검증 조건”이 개발 품질을 좌우한다
이번 수업에서 가장 크게 와닿은 부분은 AI 개발에서 진짜 중요한 것은 코드 생성이 아니라 검증 설계라는 점이었다.
단순히 “이 기능 만들어줘”라고 하는 것이 아니라, 먼저 스펙을 정리하고 그 스펙에 맞춰 테스트 조건을 세밀하게 설계해야 했다. 수업에서는 이를 SDD 기반의 TDD, 즉 스펙을 먼저 만들고 그 안에서 테스트 기반 개발을 정교하게 가져가는 방식으로 설명했다. 검증 조건이 명확할수록 AI가 만든 결과물도 더 안정적으로 통과할 수 있었다.
특히 성공 케이스만 테스트하는 것이 아니라, 실패 테스트와 회귀 테스트를 반드시 포함해야 한다는 점이 중요했다. AI에게 테스트 케이스를 만들라고만 하면 보통 성공하는 케이스 위주로 작성하기 쉽다. 그래서 의도적으로 실패 케이스를 요청하고, 어떤 조건에서 문제가 재현되는지 확인하는 방식이 필요했다.
실습 흐름은 대략 이렇게 정리할 수 있었다.
1. 피처 단위로 작업을 나눈다.
2. 유저 워크플로우를 에픽/스토리로 정리한다.
3. 각 단계의 기대 결과를 명확히 쓴다.
4. 검증 조건을 MD, JSON, XML 등 AI가 읽기 쉬운 구조로 만든다.
5. 실패 테스트와 QA 조건을 포함한다.
6. 통과하지 못하면 원인을 다시 분석하고 반복한다.이렇게 구조화하면 AI가 단순히 코드를 만드는 수준을 넘어, 작업 → 검증 → 수정 → 재검증의 흐름 안에서 움직이게 된다.
프런트엔드와 앱 개발 실습에서 배운 점
프런트엔드나 앱 개발에서는 실제 화면에서 기능이 제대로 작동하는지 확인하는 과정이 중요했다.
백엔드 관점에서는 코드가 맞아 보여도, 실제 프런트엔드와 연결했을 때는 문제가 생길 수 있다. 그래서 브라우저 스킬, 인앱 테스트, 컴퓨터 유즈 등을 활용해 실제 사용자 흐름에 가까운 방식으로 검증하는 방법도 다뤘다.
또한 E2E 테스트를 할 때는 각 기능이 어떤 사용자 흐름으로 동작하는지 먼저 가상 시나리오를 만들고, 그 시나리오를 기준으로 테스트하는 방식이 소개되었다.
예를 들어 이런 식이다.
사용자 시나리오:
- 사용자가 로그인한다.
- 특정 페이지로 이동한다.
- 버튼을 클릭한다.
- 결과 화면이 정상적으로 표시된다.
- 실패 상황에서는 어떤 에러 메시지가 나와야 하는지 확인한다.이 과정에서 중요한 것은 “AI가 알아서 잘하겠지”가 아니라, AI가 확인해야 할 기준을 사람이 먼저 명확히 정해주는 것이었다.
결과와 배운 점: AI 개발은 자동화가 아니라 구조화다
이번 실습을 통해 느낀 가장 큰 변화는 AI 개발을 바라보는 관점이었다.
이전에는 AI에게 더 좋은 프롬프트를 던지는 것이 중요하다고 생각했다.
하지만 실제로는 프롬프트 하나보다 더 중요한 것이 있었다.
바로 워크스페이스 구조, 스킬 설계, 검증 조건, 실패 테스트, 단계별 승인 흐름이었다.
특히 피처 워크플로우 안에 커밋 차단 훅을 넣고, 기획·디자인·개발·리뷰 단계마다 결과물을 확인한 뒤 다음 단계로 넘어가게 만든 부분이 인상 깊었다. 이렇게 하면 AI가 빠르게 작업하더라도 사람이 중요한 지점에서 품질을 확인할 수 있다.
결국 AI 개발은 “AI가 다 해준다”가 아니라,
AI가 잘 움직일 수 있는 구조를 사람이 설계하는 일에 가깝다는 생각이 들었다.
다음에 더 해보고 싶은 것
앞으로는 이번에 배운 내용을 바탕으로 다음 실습을 더 해보고 싶다.
- 프로젝트별 워크스페이스 분리 고도화
- 자주 쓰는 작업을 스킬로 패키징하기
- 실패 테스트 템플릿 만들기
- 에픽/스토리 기반 개발 흐름 자동화
- 브라우저 자동화나 컴퓨터 유즈를 활용한 E2E 테스트
- 코드 리뷰 기준을 MD 파일로 정리하기특히 “성공한 케이스를 스킬로 묶되, 너무 큰 단위가 아니라 낮은 레벨에서 작게 패키징하는 것이 좋다”는 설명이 기억에 남았다. 스킬을 무작정 많이 만드는 것이 아니라, 실제로 잘 작동했던 흐름을 작고 명확한 단위로 정리해야 한다는 점이 중요했다.
마무리: AI를 잘 쓰는 사람은 구조를 잘 만드는 사람
이번 스터디는 단순한 도구 사용법 수업이 아니었다.
AI에게 일을 시키는 방법을 넘어, AI가 일할 수 있는 환경을 어떻게 설계할 것인가를 배운 시간이었다.
워크스페이스를 나누고, 스킬을 만들고, 검증 조건을 정리하고, 실패 테스트까지 설계하는 과정은 처음에는 복잡해 보였다. 하지만 한 번 구조를 만들어두면 반복 설명이 줄고, 결과물의 품질도 훨씬 안정적으로 관리할 수 있다는 가능성을 보았다.
AI 개발의 핵심은 더 이상 “얼마나 빨리 코드를 만들 수 있느냐”만이 아니다.
이제는 어떤 기준으로 만들고, 어떻게 검증하고, 어떻게 반복 개선할 것인가가 더 중요해지고 있다.
이번 실습을 통해 그 흐름을 조금 더 선명하게 이해할 수 있었다.
