소프트웨어 개발 방식이 바뀌었다.
프론트엔드와 백엔드가 분리되었다. React, Vue, Next.js가 화면을 담당하고, 뒤에서는 수십 개의 마이크로서비스(MSA)가 API로 데이터를 공급한다. 두 세계는 API 계약서 하나를 사이에 두고 독립적으로 움직인다.
이 구조 변화가 QA에 던지는 질문이 있다. UI와 백엔드가 따로 배포된다면, 무엇을 기준으로 품질을 관리해야 하는가.
UI가 먼저 바뀌는 시대 The age of frequent UI facelifts
자동차 업계에는 '페이스리프트(Facelift)'라는 개념이 있다. 완전 신모델을 내놓기 전에, 외관과 실내를 부분적으로 바꾸는 중간 업데이트다. 엔진과 플랫폼은 그대로지만, 사용자가 보고 만지는 부분이 달라진다.
소프트웨어에서 UI는 점점 더 이 페이스리프트처럼 작동하고 있다. 백엔드 API는 안정적으로 유지되는 반면, 사용자 화면은 자주 바뀐다. 디자인 시스템이 업데이트되고, 버튼 위치가 바뀌고, 폼 필드가 재배치된다. 기능은 같은데 생김새가 달라지는 것.
문제는 이런 UI 변경이 테스트를 조용히 망가뜨린다는 점이다. 셀렉터 기반 테스트는 버튼 ID가 바뀌면 실패한다. 화면 경로 기반 테스트는 라우팅 구조가 바뀌면 흔들린다. 기능은 아무것도 바뀌지 않았는데, 테스트 스크립트가 무너진다. 이 반복이 쌓이면 팀은 테스트를 신뢰하지 않게 된다.
SOM의 5계층은 이 문제를 염두에 두고 설계되었다.
SOM의 5계층 The five layers of SOM
위에서 아래로 내려갈수록 단위가 작아지고 변화의 빈도가 높아진다. 아래에서 위로 올라갈수록 단위가 커지고 비즈니스 의미가 강해진다.
1계층 — Project
가장 큰 단위. 하나의 소프트웨어 시스템 전체를 가리킨다.
'공공기관 민원 포털', '사내 인사 관리 시스템', '전자상거래 플랫폼'처럼 조직이 발주하고 납품받는 단위가 Project다. 품질 관리의 가장 바깥 경계선이다.
2계층 — Module
Project를 기능 영역으로 나눈 단위.
'회원 관리', '주문 처리', '통계 및 보고서', '관리자 설정'처럼 업무 도메인으로 묶인 영역이다. 개발팀에서 보통 팀 또는 스쿼드 단위로 나뉘는 것과 일치하는 경우가 많다. Module은 영향도 분석의 기준이 된다. 특정 모듈에서 결함이 반복된다면, 그 모듈의 설계나 개발 방식에 구조적 문제가 있다는 신호다.
3계층 — Program (SOM ID 부여 단위)
SOM에서 가장 핵심적인 계층이다.
Program은 사용자가 하나의 목적으로 접근하는 화면 또는 프로세스 단위다. '회원가입 화면', '비밀번호 변경', '주문 내역 조회', '월별 매출 리포트'. 기획자가 화면 정의서를 작성하는 단위, 개발자가 Controller 하나를 만드는 단위, QA가 테스트 시나리오를 작성하는 단위와 대체로 일치한다.
이 계층에 SOM ID가 부여된다. SOM-0042처럼 고유 번호가 붙는 순간, 이 Program은 자산이 된다. 기획·개발·테스트·산출물이 이 ID 아래 연결된다.
UI가 페이스리프트처럼 바뀌어도 Program은 변하지 않는다. '비밀번호 변경'이라는 기능의 정체성은 버튼 색깔이 바뀌거나 입력 필드가 재배치되어도 유지된다. SOM ID는 UI 변화에 흔들리지 않는 안정적인 기준점이 된다.
4계층 — Component
Program을 구성하는 UI 요소 단위.
'이메일 입력 필드', '비밀번호 확인 버튼', '오류 메시지 영역'처럼 사용자가 직접 상호작용하는 단위다. 프론트엔드 개발자가 컴포넌트로 만드는 것들이 여기에 해당한다.
Component 계층은 페이스리프트의 영향을 가장 직접적으로 받는다. 버튼이 아이콘으로 바뀌고, 드롭다운이 토글로 바뀌는 변화가 Component 수준에서 일어난다. 이 변화가 상위 Program의 SOM ID에는 영향을 주지 않는다. 변화의 파급 범위를 Component 안에서 관리할 수 있다.
5계층 — Action
Component와의 상호작용 중 가장 원자적인 단위.
'클릭', '입력', '선택', '스크롤', '드래그'. 사용자가 취하는 하나의 행동이 Action이다. 자동화 테스트 코드에서 click(), fill(), select()에 해당하는 것들.
Action은 테스트 자동화의 최소 단위다. SOM의 5계층 중 가장 기술적이고, 가장 자주 바뀐다. 그러나 Action이 바뀌어도 Component는 유지되고, Program도 유지되고, SOM ID도 유지된다. 아래 계층의 변화가 위 계층을 흔들지 않는 구조.
계층이 만드는 내성 How layers absorb change
MSA 구조에서 백엔드 API가 변경되면 어떨까. API는 Program 계층에서 추적된다. 어떤 Program이 이 API를 사용하는지 SOM으로 파악하면, 영향받는 테스트 범위를 즉시 특정할 수 있다. 전체를 재검증하는 게 아니라, 영향받는 Program만 정밀하게 재검증하면 된다.
5계층은 소프트웨어의 변화를 흡수하는 구조다. 변화를 막는 것이 아니라, 변화가 파급되는 범위를 계층별로 통제하는 것.