기능을 늘리기 전에
업무와 기준을 고정합니다
Business Logic은 “무엇을 만들지”보다 먼저, 어떻게 운영되고 판단되는지를 고정하는 설계입니다. 개발을 시작하기 전에 업무 규칙과 예외를 문서로 정리해, 팀이 같은 기준으로 움직이게 만듭니다.
기준이 고정되지 않은 상태에서 기능이 늘어나면, 중간에 요구가 바뀌면서 수정·역기획 비용이 급격히 커집니다. 그래서 우리는 구현 전에 업무 흐름(To-Be)·범위·졸업 조건을 먼저 확정합니다.
업무 흐름(To-Be)·범위·졸업 조건을 문서로 고정합니다
“대충 이런 흐름” 수준으로 개발에 들어가면, 중간에 해석이 갈리고 기능이 불어나며 일정이 흔들립니다. 우리는 개발 전에 아래 3가지를 명확히 고정합니다.
- To-Be: 사용자가 어떤 순서로 업무를 처리해야 하는가(정상 흐름)
- Scope: 이번 버전에 포함/제외되는 기능과 예외는 무엇인가(경계선)
- Done: 언제 “완료”로 볼 것인가(졸업 조건/수용 기준)
이 기준이 잡히면 개발 속도가 빨라지는 이유는 단순합니다. “만들면서 정하는” 비용이 줄어들고, 팀 내부 커뮤니케이션이 논쟁이 아니라 검증으로 바뀌기 때문입니다.
요구사항 정리(PRD)와 우선순위를 결정합니다
요구사항은 “기능 목록”이 아니라 문제·사용자·상황·제약·성공 기준까지 포함한 의사결정 문서여야 합니다. 그래야 개발/디자인/운영이 같은 목표를 바라봅니다.
- 요구사항을 “문제 → 해결 방식 → 수용 기준” 형태로 정리
- 필수/선택을 가르는 우선순위 기준(ROI/리스크/의존성) 확정
- 일정이 흔들릴 때도 판단 가능한 ‘버릴 기준’까지 문서화
우선순위가 없으면 기능은 계속 늘고, 일정이 부족하면 핵심이 아닌 부분부터 급하게 만들어 품질이 무너집니다. 그래서 우리는 “무엇을 먼저 만들지”보다 무엇을 이번에는 안 만들지를 먼저 고정합니다.
정산/권한/상태값 같은 핵심 로직을 먼저 정의합니다
서비스가 커질수록 가장 큰 비용은 화면이 아니라 규칙(로직)의 변경에서 발생합니다. 특히 아래 3가지는 뒤집기 어렵기 때문에 초기에 정의하는 것이 안전합니다.
- 정산: 가격/수수료/환불/정산 주기/정산 상태의 규칙
- 권한: 누가 무엇을 볼 수 있고, 무엇을 바꿀 수 있는가(역할/범위)
- 상태값: 진행 단계(대기/진행/완료/취소)와 전이 조건(언제 바뀌나)
우리는 “상태값 표”와 “권한 매트릭스”처럼 팀이 공통으로 참조할 수 있는 형태로 로직을 정리해, 개발 이후에도 기능 확장이 가능하도록 기반을 만듭니다.
운영 관점의 관리자 기능·로그·권한을 설계합니다
운영을 고려하지 않으면, 출시 후 문제를 해결할 수 있는 수단이 없습니다. 그래서 우리는 “사용자 화면”만이 아니라 운영자가 시스템을 통제할 수 있는 구조를 함께 설계합니다.
- 관리자 기능: 조회/수정/승인/차단/재처리 등 운영 시나리오 기반 정의
- 로그/이력: 누가/언제/무엇을/어떻게 바꿨는지 추적 가능한 기록
- 운영 권한: 역할별 접근 범위, 위험 작업(삭제/정산)의 보호 장치
운영 설계가 포함되면, 장애/문의/정산 오류 같은 이슈가 생겼을 때 “개발자 호출” 없이도 운영이 해결할 수 있는 범위가 넓어집니다.
기준이 고정되면, 팀이 같은 방향으로 빨라집니다
Business Logic의 결과물은 문서 자체가 아니라 같은 기준으로 의사결정이 가능한 상태입니다. 무엇을 만들지, 어디까지인지, 언제 끝나는지, 어떤 예외가 있는지 팀이 동일한 언어로 합의할 수 있어야 개발이 빨라지고 수정이 줄어듭니다.