빠른 프로토타이핑

Source: Dev.to

프로토타이핑을 할 때, 내 목표는 간단합니다: 아이디어가 작동한다는 것을 사랑에 빠지기 전에 증명하는 것. 완벽한 코드는 필요 없고, 배울 수 있을 정도면 충분합니다.

명확하게 시작하기

편집기를 열기 전에, 나는 몇 가지 질문에 평이한 언어로 답하려고 합니다:

• 내가 해결하려는 문제는 무엇인가?
• 대상은 누구인가?
• 이 앱이 반드시 잘 해야 하는 한 가지는 무엇인가?
• 어떻게 사용자를 확보할 것인가?

제품을 한두 문장으로 설명할 수 없다면, 아직 만들 준비가 된 것이 아니다. 코드가 불명확한 사고를 구제해 주지는 않는다.

나는 보통 아주 작은 PRD를 작성한다: 목표, 주요 사용자 흐름, 그리고 그것이 정상 작동하고 있음을 어떻게 알 수 있는지. 이것만으로도 많은 낭비를 방지한다.

먼저 골격을 구축한다

나는 기능을 만들면서 시작하지 않는다. 구조를 만드는 것부터 시작한다.

그 의미는 다음과 같다:

• 라우팅
• 기본 레이아웃
• 데이터 흐름
• 폴더 구조
• 명명 규칙

아직 비즈니스 로직이나 추상화는 없다. 이것이 프로젝트에 골격을 제공한다. 이것이 자리 잡으면, 다른 모든 것이 더 빨리 진행되고 덜 혼란스럽게 유지된다.

부트스트랩된 템플릿에서 시작하기

이제는 빈 프로젝트에서 시작하는 경우가 드물다. 좋은 스타터나 템플릿은 이미 지루한 부분들을 처리해 놓는다:

• 프로젝트 구조
• 인증 또는 기본 사용자 모델(사용되지 않더라도)
• 린팅, 포맷팅, 환경 설정
• 라우팅 및 레이아웃
• 기본 설정

이는 첫날에 몇 시간을 절약하고 의사결정 피로도를 줄여준다. 핵심은 템플릿과 싸우지 않는 것이다: 필요 없는 것은 제거하고, 도움이 되는 것은 유지한 뒤 진행하라. 우리는 우아함보다 속도에 집중한다. 빠르게 구축하고 있다면, 약간은 의견이 반영된 설정이 무한한 자유 설정보다 낫다.

UI 라이브러리를 사용하세요. 언제나.

나는 더 이상 이 문제에 대해 논쟁하지 않는다. 버튼, 입력, 모달, 테이블… 나는 그것들에 대해 생각하고 싶지 않다. 좋은 UI 라이브러리는 프로토타입 단계에서 가치가 없는 수백 가지 작은 결정을 없애준다.

“사용자는 내 테두리 반경이 독특한지 여부가 아니라 가치에 관심을 갖는다.”

픽셀 완벽주의 충동을 억제하기

이 부분이 가장 힘든 부분입니다. 저는 간격을 조정하고, 색상을 바꾸고, 글꼴 두께를 바꾸고, 반응형을 조정합니다. 어느새 두 시간이 지나고 의미 있는 변화는 없었습니다.

그래서 이제 규칙을 강제합니다:

• 이것이 사용자의 이해를 방해하고 있나요? 고치세요.
• 이것이 미관상의 문제인가요? 무시하세요.

픽셀 완벽함은 검증 이후에 찾아야 합니다. 디자인 다듬기는 입증된 수요에 대한 보상입니다.

한 번에 모든 것을 구축하지 말고, 변화를 위한 구조 만들기

나는 첫 번째 버전에서 가능한 모든 미래 기능을 모두 제공하려고 하지 않는다. 대신, 나중에 기능을 추가하더라도 부담스럽지 않도록 프로젝트를 구조화한다.

구축을 피하는 것:

• 플러그인 시스템
• 이벤트 버스
• 무거운 도메인 레이어

내가 하는 일:

• 기능 간 경계를 명확히 유지한다
• 파일과 함수 이름을 그들이 하는 일에 기반해 짓고, 앞으로 될 일에 기반해 짓지 않는다
• 함수를 작고 교체 가능하게 만든다
• 하나의 흐름에 얽매이게 하는 하드코딩된 가정을 피한다
• 변경될 수 있는 부분(인증, 결제, 통합)을 격리한다
• 미래 확장이 명확한 곳에 짧은 주석을 남긴다

새로운 기능, 외부 서비스/제공자, 그리고 다른 도구들을 재작성 없이 추가할 수 있기를 원한다.

이미 알고 있는 것을 선택하세요

Shiny tech는 재미있지만, 속도가 중요할 때는 친숙함이 승리한다. 내가 이미 이해하고 있는 도구를 사용할 때:

• 디버깅이 더 빠릅니다
• 버그가 적게 발생합니다
• 더 나은 결정을 내립니다

항상 다시 작성할 수는 있지만, 낭비된 시간을 되돌릴 수는 없습니다.

AI가 실제로 도움이 되는 경우

AI는 시작점이 아니라 가속점입니다. 구조가 마련되면 AI가 매우 유용해집니다:

• PRD 초안 작성
• 흐름 정제
• 보일러플레이트 생성
• 테스트 작성
• 버그 탐지

나에게 맞는 워크플로우:

1. 아이디어와 사양을 명확히 하는 도구를 사용한다.
2. 코딩 어시스턴트를 활용해 부분을 더 빠르게 구현한다.
3. 버그 중심 도구로 검토하고 문제를 잡는다.

또한 다음을 유지한다:

• 규칙
• 가이드라인
• 프로젝트 컨텍스트
• 폴더 구조 문서

이렇게 하면 AI 응답이 더 정확하고 혼란스러움이 줄어듭니다.

Documentation is leverage

Light documentation saves heavy refactors. I usually keep:

• a PRD
• a simple flow diagram
• a structure doc (folders, APIs, contracts)
• a list of assumptions

초기에 검증하고, 그 다음에 결정하기

프로토타입이 엔드‑투‑엔드로 작동하면, 나는 더 이상 빌드를 진행하지 않는다. 사용자 앞에 두고, 그들을 관찰하고, 듣는다.

검증이 끝난 뒤에 나는 다음을 결정한다:

• UI 다듬기
• 아키텍처 리팩터링
• 기능 추가
• 아이디어 폐기

빠른 프로토타이핑은 대충 만드는 것이 아니라 시간에 대한 정직함에 관한 것이다. 실제로 뭔가를 가르쳐 줄 수 있는 가장 작은 것을 만든다. 그 외의 모든 것은 잡음이다.