[실무 심화]"그림보다 글로 보여주는 로직" - 복잡한 조건문을 기획서에 담는 법

기획서는 단순히 예쁜 와이어프레임이나 플로우차트의 집합이 아닙니다. 특히 복잡한 비즈니스 로직이나 수많은 조건문은 그림만으로는 한계가 있습니다. 개발자가 코드를 짤 수 있을 만큼 명확하게, 글로써 로직을 정의하는 능력이야말로 기획자의 진정한 실력입니다. 1. 왜 그림만으로는 복잡한 로직 전달에 한계가 있는가? 단순한 사용자 흐름은 플로우차트로 충분합니다. 하지만 분기가 너무 많거나, 조건이 중첩되는 복잡한 로직은 그림만으로는 오히려 혼란만 가중될 수 있습니다. 시각적 한계: 화면에 모든 조건을 담기 어렵고, 선이 얽히면서 가독성이 떨어집니다. 세부 조건 누락: 그림에서는 'YES/NO'로만 표현되기 쉬워, 'A이면서 B일 때'와 같은 복합 조건이나 예외 상황이 누락되기 쉽습니다. 개발자와의 오해: 개발자는 그림만 보고 코드를 짜기 어려워 결국 구두 질문이 많아지고, 이는 곧 비효율적인 소통으로 이어집니다. 2. 그림과 글의 장점을 결합한 '복잡한 조건문' 기획 노하우 3가지 1단계: 큰 그림은 플로우차트로, 세부 조건은 '단계별 글로 풀기' (Flow + Step-by-step) 실행: 전체적인 흐름은 시각화하여 공유하되, 각 단계별로 발생하는 조건과 로직은 글로 상세히 서술합니다. 핵심 기술: 메인 플로우: 플로우차트를 사용하여 서비스의 주요 흐름(Happy Path)과 주요 분기점들을 한눈에 파악할 수 있게 합니다. 각 분기점별 상세 로직: 플로우차트의 특정 분기점에서 "상세 로직 [링크/페이지]"와 같이 연결하고, 해당 페이지에서 글로 상세하게 풀어냅니다. 단계별 설명: 특정 기능의 작동 방식을 1단계, 2단계, 3단계와 같이 순서대로 설명하며, 각 단계에서 발생하는 조건과 결과(Then)를 명확히 기술합니다. 2단계: "표"와 "목록"을 활용한 조건 정의 (Table & List) 실행: 복잡한 조건들을 한눈에 비교하고 파악할 수 있도록 표(Table)나 목록(List) 형태로 정리하여 가독성을 높입니다. 핵심 기술: 조건표 (Decision Table): 언제: 여러 개의 조건(IF)이 동시에 존재하고, 그 조합에 따라 다른 결과(THEN)가 나올 때 유용합니다. 작성법: | 조건 1 (사용자 로그인 여부) | 조건 2 (상품 재고 여부) | 조건 3 (할인 쿠폰 소지 여부) | 결과 (버튼 활성화/메시지) | | :---------------------- | :------------------- | :------------------- | :------------------ | | 로그인 | 있음 | 있음 | 구매하기 (쿠폰 적용) | | 로그인 | 있음 | 없음 | 구매하기 | | 로그인 | 없음 | - | 품절 안내 | | 비로그인 | 있음 | - | 로그인 후 구매하기 | 장점: 모든 조합의 경우의 수를 빠짐없이 커버하고, 한눈에 로직을 파악할 수 있습니다. 불릿/넘버링 목록: 언제: 조건이 순차적으로 적용되거나, 특정 액션에 대한 여러 가지 결과가 있을 때. 작성법: IF (사용자가 [X] 버튼을 클릭하면): AND (로그인 상태인 경우): AND (상품 재고가 있는 경우): [A] 액션 실행 [B] 메시지 노출 ELSE (상품 재고가 없는 경우): [C] 액션 실행 [D] 메시지 노출 ELSE (비로그인 상태인 경우): 로그인 페이지로 이동 로그인 완료 후 원래 페이지로 리다이렉트 장점: 복잡한 if-else 구문을 계층적으로 표현하여 개발자가 코드 구조를 상상하기 쉽습니다. 3단계: "변수"와 "값"을 명확히 정의 (Data Definition) 실행: 로직에 사용되는 모든 변수(데이터)와 그 변수가 가질 수 있는 '값'을 명확히 정의하여 혼란을 방지합니다. 핵심 기술: 데이터 필드 정의: (예: user_status는 active, dormant, blocked 값을 가질 수 있음) enum (열거형) 정의: 특정 변수가 가질 수 있는 고정된 값의 목록을 미리 정의하여, 개발팀이 데이터 처리 시 오류를 줄이도록 돕습니다. 오류 코드와 메시지 매핑: 특정 조건 발생 시 반환될 오류 코드와 사용자에게 보여줄 에러 메시지를 함께 정의합니다. (예: E001_INVALID_INPUT → "입력하신 정보가 올바르지 않습니다.") 3. 기획자가 놓치기 쉬운 '글로 보여주는 로직' 디테일 모든 예외 케이스 포함: 정상적인 흐름뿐만 아니라, 예상 가능한 모든 예외 상황(엣지 케이스)에 대한 로직을 빠짐없이 정의해야 합니다. 개발자와의 사전 소통: 복잡한 로직은 기획서 작성 전, 개발팀과 먼저 구두로 논의하여 기술적인 제약이나 더 효율적인 구현 방안을 확인합니다. 업데이트 관리: 로직이 변경될 경우, 반드시 변경 이력(Change Log)을 명확히 남기고 관련 팀에 공유합니다. 포스팅 마무리 꿀팁 "기획서의 로직은 개발자의 '설계 도면'입니다. 그림은 참고 자료일 뿐, 글로써 완벽한 도면을 제공하라!" 좋은 기획서는 개발자가 질문 없이 코드를 짤 수 있게 만들어줍니다. 시각적인 요소로 사용자 경험을 전달하되, 그 아래 숨겨진 복잡한 로직은 명확하고 상세한 글로써 정의하는 훈련을 게을리하지 마세요. 여러분의 기획서는 더 이상 단순한 '스토리'가 아닌, 견고한 '설계 도면'이 될 것입니다!