프론트엔드에서 풀스택으로의 전환: 아키텍처 사고법 정복

카테고리

프로그래밍/소프트웨어 개발

서브카테고리

DevOps

대상자

프론트엔드 개발자 → 풀스택 개발자 전환을 준비하는 개발자. 중급 이상의 실무 경험을 가진 개발자에게 추천.

핵심 요약

• 아키텍처 사고법은 문제 해결의 방향성과 트레이드오프 분석을 기반으로 한다.
• 기능 요구사항과 비기능 요구사항(예: "업로드 속도 2초 이내")을 명확히 정의하여 기술적 결정을 내린다.
• 시퀀스 다이어그램, 컴포넌트 다이어그램, 엔티티 다이어그램을 통해 서비스 간 상호작용을 시각화한다.
• 분리된 책임(Separation of Concerns) 원칙을 적용하여 코드의 가독성과 확장성을 유지한다.

섹션별 세부 요약

1. 문제 정의와 제약 조건 분석

• 사용자의 문제, 성공 기준, 예산, 시간, 팀 구성 등 제약 조건을 명확히 파악한다.
• PRD(제품 요구사항 문서)를 분석하여 실제 요구사항과 기술적 결정을 연계한다.

2. 요구사항 정의

• 기능 요구사항: "사용자가 파일을 업로드하면 XP를 얻는다."
• 비기능 요구사항: "80%의 사용자에게 업로드 속도는 2초 이내."
• 이 요구사항은 스토리지, 캐싱, 로드 처리 등 기술적 결정에 영향을 준다.

3. 데이터 및 상호작용 흐름 시각화

• 시퀀스 다이어그램: 사용자 → 프론트엔드 → API → 서비스 → 데이터베이스
• 컴포넌트 다이어그램: 인증, 캐시, 외부 서비스 등의 박스형 구조
• 엔티티 다이어그램: 테이블 또는 문서 구조와 관계 정의
• 이 단계는 시스템 설계의 핵심이며, 코드 작성보다 더 많은 시간을 할애해야 한다.

4. 책임 분리 원칙 적용

• 프론트엔드에서 컴포넌트, 훅, API 호출의 분리와 유사하게, 백엔드에서도 라우트, 서비스, 데이터베이스를 분리한다.
• 이는 테스트 가능성과 코드의 확장성을 높인다.

5. 아키텍처 트레이드오프 분석

• 모노리스 vs 마이크로서비스: 모노리스는 배포가 간단하지만 확장성에 한계, 마이크로서비스는 유연하지만 복잡성 증가.
• SQL vs NoSQL: PostgreSQL은 구조적, MongoDB는 유연하지만 스케일링 시 검증 어려움.
• 자체 호스팅 vs PaaS: Vercel은 빠른 배포 가능, 자체 호스팅은 DevOps 관리 필요.
• 간단한 로직 vs 확장성: 단기적으로는 간단한 로직이 빠르지만, 장기적으로는 추상화된 모듈 설계가 유리.

결론

• 아키텍처 사고법은 최적의 기술 선택을 위한 핵심이며, 현재 문제와 제약 조건을 기반으로 결정해야 한다.
• 작은 내부 대시보드 예시에서 볼 수 있듯, 복잡한 마이크로서비스보다 간단한 모노리스가 초기에 더 효율적일 수 있다.
• 코드는 추후 따라오고, 아키텍처 사고법이 기술적 결정의 핵심이다.