코드 작성 전에 실제 프로젝트를 어떻게 구조화하는지

Source: Dev.to

Pre‑coding Process

대부분의 개발자는 VS Code를 너무 일찍 켭니다. 저도 예전엔 똑같이 했습니다: 클라이언트가 아이디어를 설명하면, 몇 시간 안에 Laravel 컨트롤러, React 컴포넌트, 데이터베이스 테이블을 만들기 시작했죠. 몇 달 뒤 프로젝트는 엉망이 되고, 요구사항이 바뀌면서 저는 실제 문제는 코딩 실력이 아니라 사고 구조라는 것을 깨달았습니다.

이제는 엄격한 사전 코딩 프로세스를 따릅니다. 프로젝트가 머리속에 설계될 때까지 한 줄도 작성하지 않습니다.

Shifting from Features to Problems

클라이언트는 기능 중심으로 말합니다:

• “대시보드가 필요해요”
• “결제 시스템을 추가해 주세요”
• “이 웹사이트처럼 만들어 주세요”

엔지니어는 문제 중심으로 생각해야 합니다. 저는 이렇게 묻습니다:

• 이 시스템을 누가 사용할까요?
• 이 소프트웨어가 어떤 결정을 도와줄까요?
• 현재 어떤 불편함이 있나요?

그 후 한 줄로 정리합니다:

This project helps [user] achieve [goal] by solving [problem].

Entity Modeling

테이블이나 API를 만들기 전에 연구자처럼 엔터티를 나열합니다.

Example: E‑commerce Project

• User
• Product
• Order
• Payment
• Shipment

관계를 자연어로 설명합니다:

• User는 여러 Order를 생성합니다.
• Order는 여러 Product를 포함합니다.
• Payment는 Order에 속합니다.

이것이 MySQL이 등장하기 훨씬 전에 형성되는 제 머릿속 데이터베이스가 됩니다.

Endpoint Drafting

UI부터 시작하지 않습니다. 대신 질문을 던집니다:

• 프론트엔드가 필요로 하는 데이터는 무엇인가?
• 어떤 행동이 가능해야 하는가?
• 어떤 상황에서 안전하게 실패해야 하는가?

프레임워크에 얽매이지 않은 계약 형태로 엔드포인트를 초안합니다:

POST /api/orders

이렇게 하면 “프레임워크에 종속”되는 상황을 방지할 수 있습니다.

Flow Diagram

간단한 흐름도를 그립니다:

User → Frontend → API → Database → API → User

각 단계마다 다음을 적어 둡니다:

• Validation
• Authentication
• Business rules
• Possible errors

이 메모들이 나중에 미들웨어와 서비스가 됩니다.

Non‑functional Requirements

대부분의 튜토리얼은 이 부분을 무시하지만, 실제 프로젝트는 반드시 다루어야 합니다:

• Performance
• Security
• Scalability
• Logging
• Backups

작은 섹션을 만들어 목표를 명시합니다:

• 2초 이내 응답 시간
• Role‑based access control
• Daily DB backup
• API rate limiting

Final Structure

머릿속 모델이 확고해진 뒤에야 코드 구조를 고민합니다:

• Controllers
• Services
• Repositories
• DTOs
• Tests

Laravel이든 Node이든 Django이든 사고 방식은 동일합니다.

코드를 실제로 작성할 때는:

• 엔드포인트는 이미 정해져 있다
• 엔터티가 명확하다
• 검증 로직이 결정돼 있다
• 보안 계획이 세워져 있다

코딩은 혼란이 아니라 번역 작업이 됩니다.

What Changed for Me

• 리팩터링 횟수 감소
• 더 깔끔한 API
• 추정치에 대한 자신감 상승
• 클라이언트 만족도 향상

“시작하고 보자”에서 “설계하고 구축하자”로 전환했습니다.

진정한 풀스택 개발자는 아는 프레임워크 수가 아니라, 코딩 전에 생각할 수 있는 능력으로 정의됩니다.