이론은 충분히 이야기했다. 이제 실제로 해보자.
SOM을 프로젝트에 도입할 때 가장 먼저 해야 할 일은 하나다. 프로그램 목록을 만드는 것. 이것이 SOM의 BOM이다. 부품표 없이 조립이 없듯, 프로그램 목록 없이 SOM은 시작되지 않는다.
왜 프로그램 목록이 먼저인가 Why the program list comes first
도요타 공장에서 신차 생산을 시작할 때 가장 먼저 하는 일은 BOM 확정이다. 어떤 부품이 몇 개 들어가는지 정해지지 않으면, 구매도 생산도 품질 검사도 시작할 수 없다.
소프트웨어 프로젝트도 마찬가지다. 어떤 화면이 존재하는지, 어떤 기능 단위가 있는지 목록이 없으면 — 무엇을 테스트해야 하는지 알 수 없다. 커버리지를 측정하려 해도 전체 분모를 모르면 퍼센트를 낼 수 없다.
프로그램 목록은 SOM 전체의 기준점이다. 이것이 확정되어야 테스트 시나리오를 설계할 수 있고, 영향도를 분석할 수 있고, 산출물을 자동으로 연결할 수 있다.
프로그램 목록에 담을 것들 What to put in the list
최소한의 항목부터 시작하는 것이 좋다. 처음부터 완벽한 구조를 만들려다 지치면 안 된다.
필수 항목
| 항목 | 설명 | 예시 |
|---|---|---|
| SOM ID | 고유 식별자 | SOM-0042 |
| 프로그램명 | 사람이 이해하는 이름 | 회원가입 화면 |
| Module | 속하는 업무 영역 | 회원 관리 |
| 유형 | 화면/프로세스/API | 화면 |
| 상태 | 개발 진행 상황 | 개발완료 / 개발중 / 미착수 |
추가 항목 (여유가 생기면)
| 항목 | 설명 |
|---|---|
| 담당 개발자 | 변경 시 연락 대상 |
| 관련 API | 연결된 백엔드 엔드포인트 |
| 우선순위 | P1(핵심) ~ P5(낮음) |
| 비고 | 특이사항, 제약조건 |
실제로 만들어보기 Building one in practice
공공기관 민원 포털 프로젝트를 예로 들자. 전자정부프레임워크 기반의 전형적인 한국 공공기관 시스템이다.
기획자가 화면 정의서를 열면 이런 화면들이 나열되어 있다.
1. 메인 페이지 2. 로그인 3. 회원가입 4. 비밀번호 찾기 5. 민원 신청 - 신청서 작성 6. 민원 신청 - 첨부파일 업로드 7. 민원 조회 - 목록 8. 민원 조회 - 상세 9. 민원 조회 - 처리 이력 10. 마이페이지 - 내 정보 수정 11. 마이페이지 - 신청 내역 12. 관리자 - 민원 접수 목록 13. 관리자 - 민원 처리 14. 관리자 - 통계 ...
이 목록이 SOM 프로그램 목록의 원재료다. 여기에 ID를 붙이고 Module로 묶으면 프로그램 목록이 완성된다.
Module: 인증 SOM-0001 메인 페이지 화면 SOM-0002 로그인 화면 SOM-0003 회원가입 화면 SOM-0004 비밀번호 찾기 화면 Module: 민원 신청 SOM-0010 신청서 작성 화면 SOM-0011 첨부파일 업로드 화면 Module: 민원 조회 SOM-0020 민원 목록 화면 SOM-0021 민원 상세 화면 SOM-0022 처리 이력 화면 Module: 마이페이지 SOM-0030 내 정보 수정 화면 SOM-0031 신청 내역 화면 Module: 관리자 SOM-0040 민원 접수 목록 화면 SOM-0041 민원 처리 화면 SOM-0042 통계 화면
이것이 이 프로젝트의 BOM이다. 43개 화면이라면 43개 SOM ID가 존재한다.
ID 부여 방식 How to assign IDs
ID 체계는 팀이 합의하면 된다. 다만 몇 가지 원칙이 있다.
번호는 의미를 담지 않는다. SOM-0001이 SOM-0002보다 중요하다는 뜻이 아니다. 순번일 뿐이다. ID로 우선순위를 표현하려 하면 나중에 반드시 꼬인다.
Module 번호대를 구분하면 읽기 쉽다. 인증은 0001~0009, 민원 신청은 0010~0019처럼 구간을 나눠두면 SOM-0021만 봐도 민원 조회 영역임을 직관적으로 알 수 있다. 필수는 아니지만 규모가 커질수록 유용하다.
폐기된 ID는 재사용하지 않는다. SOM-0011 화면이 없어졌다고 SOM-0011을 다른 화면에 주지 않는다. 자산 이력이 꼬이기 때문이다. 그냥 폐기 상태로 두면 된다.
흔히 하는 실수 Common mistakes
너무 잘게 쪼갠다. "로그인 화면의 아이디 입력 영역"을 별도 Program으로 만들면 안 된다. 그것은 Component다. Program은 사용자가 하나의 목적으로 접근하는 단위여야 한다. "로그인"이 Program이고, 아이디 입력란은 그 안의 Component다.
너무 크게 묶는다. "민원 관리 전체"를 하나의 Program으로 묶으면 안 된다. 그것은 Module이다. 목록, 상세, 처리 화면이 각각 별도 Program이 되어야 테스트와 추적이 가능하다.
완성된 이후에 만들려 한다. 개발이 끝나고 프로그램 목록을 만들면, 그것은 산출물 소급 작성과 다를 바 없다. 기획 단계에서, 화면 정의서를 작성하는 그 시점에 함께 만들어야 한다.
기존 프로젝트라면 For existing systems
신규 프로젝트가 아니라 운영 중인 시스템에 SOM을 도입하는 경우라면 어떻게 할까.
화면 정의서가 있다면 그것이 출발점이다. 없다면 실제 시스템을 열고 메뉴 하나씩 탐색하면서 목록을 만든다. 소스코드가 있다면 Controller 목록을 추출해서 대조하는 방법도 있다.
다음 단계 The next step
프로그램 목록이 완성되면 SOM의 뼈대가 세워진 것이다.
다음 단계는 이 목록 위에 테스트 시나리오를 설계하는 것. Program 하나가 하나의 테스트 시나리오 단위가 되고, 그 안에서 Component와 Action이 펼쳐진다.
다음 화에서는 SOM 프로그램 목록을 바탕으로 테스트 시나리오를 설계하는 방법을 구체적으로 다룬다.