개발업무란?
아래는 위 내용을 기반으로 정리한 개발 업무 워크플로우(Development Workflow)의 상세한 설명입니다. 협의부터 배포까지 단계별로 명확하게 구성해드릴게요.
⸻
[1] 요구사항 협의 및 수집 (Stakeholder Discussion & Requirements Gathering)
• 목적: 고객 또는 기획자와 소통하여 무엇을 만들 것인지 정의.
• 활동:
• 미팅을 통해 고객 니즈 파악
• 레퍼런스 조사
• 경쟁 서비스 비교
• 문제 상황/배경/제약 조건 파악
• 산출물:
• 회의록, 요구사항 문서 (Notion, Confluence 등 활용)
⸻
[2] 요구사항 정리 및 기능 정의 (Requirement Refinement & Feature Listing)
• 목적: 수집한 정보를 기반으로 실질적인 개발 기능 도출
• 활동:
• 핵심 기능/보조 기능 분류
• 기능 우선순위 설정 (Must / Should / Could / Won’t)
• 사용자 시나리오 작성 (User Flow, Use Case)
• 산출물:
• 기능 정의서, 기능 명세서
⸻
[3] 고객과의 범위 협의 및 확정 (Scope Confirmation)
• 목적: 전체 기능 중 실제 개발 범위를 결정
• 활동:
• MVP 범위 정리
• 일정/예산 고려한 협의
• 변경 관리 프로세스 정의
• 산출물:
• 확정된 개발 스펙 문서
• 스코프 문서
⸻
[4] DB 설계 및 기술 구조 논의 (Database & Architecture Design)
• 목적: 데이터 흐름과 구조 정리
• 활동:
• ERD 작성 (엔터티 관계도)
• 테이블 및 컬럼 정의
• API 대략 설계 (REST, GraphQL 등)
• 백엔드-프론트엔드 구조 합의
• 산출물:
• ERD 문서, 기술 명세서
⸻
[5] 설계 검토 및 수정 (Design Review & Feedback)
• 목적: DB 및 기능 설계의 실현 가능성 검토
• 활동:
• 개발자/디자이너 간 협업 회의
• 기술 부채나 보완점 점검
• 업무 일정과 로드맵 재정비
• 산출물:
• 수정된 설계안, 회의 기록
⸻
[6] 기본 틀 개발 (Project Skeleton Setup)
• 목적: 개발을 위한 환경 및 구조 구성
• 활동:
• 사내 프레임워크 적용
• 프로젝트 구조 정의 (디렉토리, 레이어 구조)
• 공통 모듈 셋업 (Auth, Exception, Logging 등)
• 산출물:
• 기본 코드 구조 (Git Repo)
⸻
[7] 업무 분배 및 작업 시작 (Task Assignment & Development Start)
• 목적: 구성원이 역할을 명확히 하고 병렬 개발 시작
• 활동:
• Jira / Trello / Notion 등으로 업무 분배
• 작업 단위별 Git Branch 생성
• 커뮤니케이션 채널 구성 (Slack, Discord, 회의 등)
• 산출물:
• 업무 할당표, 스프린트 백로그
⸻
[8] 자유로운 협업 및 커뮤니케이션 (Team Communication & Sync)
• 목적: 유연한 협업과 적극적 피드백을 통한 프로젝트 완성도 향상
• 활동:
• 데일리 스탠드업
• 주간 회고 (Retrospective)
• 코드 리뷰 / 기술 리뷰
• 중간 데모 및 사용자 테스트
• 핵심 가치:
• 의견 충돌도 건강한 방향으로 유도
• 리더가 명확한 방향을 제시하되, 불명확할 경우 확정된 부분 위주로 우선 개발
⸻
[9] 테스트 및 QA (Testing & Quality Assurance)
• 목적: 릴리즈 전 완성도 점검
• 활동:
• 단위 테스트 / 통합 테스트 / 사용자 테스트
• QA 시나리오 작성 및 실행
• 버그 리포트 및 수정
• 산출물:
• QA 시트, 버그 트래커
⸻
[10] 배포 및 유지보수 (Deployment & Maintenance)
• 목적: 실제 운영 환경에 서비스 배포 및 안정성 확보
• 활동:
• Staging → Production 순 배포
• Docker / CI-CD 파이프라인 구축
• 장애 모니터링, 로그 수집
• 사용자 피드백 수집 및 개선
• 산출물:
• 배포 가이드, 운영 매뉴얼, 유지보수 로그
⸻
이런 흐름이 실제 실무에서 가장 흔히 쓰이고 안정적인 개발 운영 방식입니다.
⸻
추가 팁:
• “불확실할 땐 확정된 것부터” → 이는 애자일의 핵심 사고방식 중 하나입니다.
• 명확한 디렉션을 주기 어려울 때는 POC(Proof of Concept)로 빠르게 확인해보는 것도 좋은 전략입니다.
⸻
필요하면 워크플로우 다이어그램도 그려드릴 수 있어요.
