개체와 관계 탐험: 속성·의존성, CRUD, 데이터 따라가기

개념

개체 중심으로 보는 관점

지금까지는 주로 "화면 흐름"을 탐험했다. 이 레슨은 관점을 바꿔, 시스템이 다루는 개체(Entity) — 사용자, 주문, 상품, 쿠폰 같은 "것들" — 을 중심으로 탐험한다. 각 개체는 속성(예: 주문의 금액, 상태)을 가지고, 다른 개체와 관계(예: 주문은 사용자에 속하고, 여러 상품을 포함한다)를 맺는다.

말이 어렵게 들리지만 실제로는 간단하다. 화면에 목록으로 나오는 것들이 대개 개체다. 주문 목록, 상품 목록, 회원 목록. 그리고 상세 화면에 적힌 항목들이 속성이고, "이 주문의 상품 보기" 처럼 넘어가는 링크가 관계다. 전부 화면에서 눈으로 찾을 수 있다.

비유하자면 지금까지는 길을 따라 걸었고, 이 레슨부터는 지도에서 지명을 짚어 본다. 화면 흐름은 길이고, 개체는 그 길이 이어 주는 장소다. 길만 걸으면 안 가 본 골목이 남지만, 지명을 짚으면 "여기는 어느 길로도 안 가 봤네" 가 드러난다.

먼저 개체 지도를 그린다

탐험 전에 10분짜리 그림 하나면 충분하다. 완벽할 필요 없고, 틀려도 된다 — 틀린 것을 확인하는 과정에서 질문이 나온다.

       사용자 ──┬── 주문 ──┬── 주문상품 ── 상품
                │          │
                │          └── 결제 ── 환불
                │
                ├── 장바구니 ── 장바구니상품
                ├── 리뷰 ──────────────┘
                ├── 쿠폰(보유)
                └── 배송지

그리고 나서 선마다 질문 하나씩을 붙인다.

• 사용자 ─ 주문: 사용자를 지우면 주문은? 주문이 500건이면 화면이 버티나?
• 주문 ─ 상품: 상품을 지우면 과거 주문의 상품명은?
• 사용자 ─ 리뷰: 탈퇴한 사람의 리뷰는 누구 이름으로 보이나? 삭제는 되나?
• 주문 ─ 환불: 부분 환불이면 주문 금액은 어느 값이 되나?
• 사용자 ─ 장바구니: 로그인 전에 담은 것은 로그인 뒤 어떻게 되나?
• 주문 ─ 결제: 결제는 됐는데 주문 생성이 실패하면 어느 상태로 남나?

선의 개수만큼 질문이 나온다. 그리고 이 질문 대부분은 요구사항에 답이 없다 — 모듈 2에서 본 "당연해서 안 적힌 것" 이 여기 몰려 있다.

그림을 어디서 얻나. 개발자에게 물으면 10분이면 그려 준다. 화면을 보고 추측해서 그린 뒤 맞는지 확인받는 편이 더 빠르기도 하다 — 틀린 그림을 보여 주면 사람들은 고쳐 주고 싶어 한다.

CRUD로 탐험하기

각 개체에 대해 생성(Create)·조회(Read)·수정(Update)·삭제(Delete) 를 탐험하되, 연결된 다른 개체에 무슨 일이 일어나는지까지 함께 본다.

개체: 사용자

• Create: 사용자를 만들면 프로필, 장바구니가 자동으로 함께 생성되는가?
• Update: 이메일을 바꾸면 과거 주문 내역의 연락처 정보도 바뀌는가, 그대로 남는가?
• Read: 다른 사용자가 이 사용자의 정보를 조회할 수 있는가? 어디까지?

• Delete: 사용자를 삭제하면 그 사용자의 주문·리뷰·쿠폰은 어떻게 되는가?

같이 지워지는가, 남아서 "탈퇴한 사용자"로 표시되는가, 아니면 참조가 끊긴 채(고아 레코드) 남는가?

삭제가 특히 흥미로운 지점이다 — 부모 개체를 지웠을 때 자식 개체가 멀쩡히 참조 없이 남아있는("고아 레코드") 결함은 화면상으로는 잘 안 보이다가 나중에 이상한 곳(예: 관리자 페이지에서 "알 수 없는 사용자"가 쓴 리뷰)에서 드러난다.

삭제는 네 가지 결과가 있다

"지웠다" 는 한 단어지만 시스템에서 일어나는 일은 네 가지로 갈린다. 어느 쪽인지 확인하지 않으면 테스트한 것이 아니다.

두 번째가 실무에서 가장 흔하고 가장 많이 샌다. 목록에서는 사라졌는데 검색에는 나오거나, 상세 주소로 직접 들어가면 열리거나, 통계에는 계속 잡히는 식이다. 법적으로 탈퇴한 사용자의 정보가 조회되면 안 되는 경우도 있어서 가볍게 볼 문제가 아니다.

네 번째도 확인할 것이 있다. 화면에서 막혀도 다른 경로로 지울 수 있으면 막은 의미가 없다. 관리자 화면, 일괄 처리, 창구 직접 호출 같은 경로가 있다.

고아가 생기면 어떻게 드러나나

"참조가 끊긴 채 남은 것" 은 당장 아무 일도 안 일어난다. 나중에 엉뚱한 곳에서 터진다.

마지막 줄이 핵심이다. 고아 레코드는 화면에서 안 보이는 것이 정상이다. 그래서 이 결함은 저장소를 직접 보거나(모듈 61), 다른 화면에서 같은 것을 조회해야 드러난다. 레슨 4의 "세 번째 겹" 이 여기서 필요해진다.

데이터 따라가기 (Data Trail)

한 값이 시스템 여러 곳에 걸쳐 일관되게 나타나는지 추적한다.

"할인 10%"라는 값 하나를 따라가보자 — 체크아웃 화면에 표시된다, 주문 확인 이메일에도 나온다, 주문 상세 페이지에도 나온다, 관리자 대시보드 매출 통계에도 반영된다. 이 네 곳의 숫자가 전부 같은가?

네 곳이 다른 코드로 만들어진다는 점이 핵심이다. 체크아웃은 화면이 계산하고, 메일은 템플릿이 만들고, 주문 상세는 저장된 값을 읽고, 통계는 집계가 따로 돈다. 같은 값이 네 번 따로 만들어지면 어긋날 자리도 네 군데다.

따라가는 요령이 하나 있다. 값을 특이하게 만들어 두면 찾기 쉽다. 할인율을 10%가 아니라 13% 로, 금액을 10,000원이 아니라 12,347원 으로 해 두면 화면을 훑기만 해도 눈에 띈다. 흔한 값은 다른 값과 섞여도 모른다.

이름도 마찬가지다. 시험 계정 이름을 "홍길동" 대신 "테스트1004가나다" 처럼 해 두면, 목록·메일·영수증 어디에 나타나는지 검색만으로 추적된다.

한 곳에서만 확인하면 절대 못 잡는, 화면 간 데이터 불일치 결함을 찾는 유일한 방법이 이 "따라가기"다. 재무 관련 값(금액, 할인, 포인트)일수록 불일치의 파장이 크다.

값이 어긋나는 네 가지 이유

"같은 값인데 화면마다 다르다" 는 것은 결과이고, 원인은 넷 중 하나다. 원인을 짚을 수 있으면 리포트의 값이 달라진다.

두 번째와 세 번째는 결함이 아닐 수도 있다. 주문 시점의 가격을 그대로 보관하는 것은 의도된 설계인 경우가 많다 — 나중에 가격이 올랐다고 과거 주문 금액이 바뀌면 안 되기 때문이다.

그래서 값 불일치를 발견하면 "이게 의도인가" 를 먼저 묻는다. 의도라면 그 규칙이 어디에 적혀 있는지를 묻는다. 적힌 데가 없으면 그것 자체가 요구사항 공백이고, 사람마다 다르게 구현하게 된다.

따라갈 가치가 큰 값들

모든 값을 따라갈 수는 없다. 어긋났을 때 비싼 것부터 본다.

• 금액 계열 — 상품 가격, 할인, 배송비, 세금, 최종 결제액, 환불액. 네댓 곳에 걸쳐 나타나고 한 군데만 틀려도 정산이 어긋난다
• 개수 계열 — 재고, 장바구니 수량, 포인트 잔액, 쿠폰 남은 횟수. 두 곳에서 동시에 줄이면 음수가 되기도 한다
• 상태 계열 — 주문 상태, 결제 상태, 배송 상태. 화면마다 다른 상태를 보여 주면 고객센터가 가장 먼저 안다
• 시각 계열 — 주문 시각, 만료 시각. 시간대가 섞이면 하루 차이가 난다
• 이름 계열 — 상품명, 사용자명. 바뀐 뒤 과거 기록에 어느 이름이 남는가

이 다섯이 레슨 3의 "분야별 악몽" 과 겹친다는 점에 주목한다. 뉴스가 되는 결함은 거의 다 이 다섯 중 하나다.

어디까지 따라가나

화면만 보는 것은 반쪽이다. 같은 값이 나타나는 자리를 넓게 잡으면 이렇다.

검색 결과도 자주 빠진다. 상품명을 바꿨는데 검색에서는 옛 이름으로만 찾아지는 식이다. 색인을 다시 만드는 주기가 따로 있기 때문이고, "언제 반영되나요" 를 물어 두면 기다릴 시간인지 결함인지 가려진다.

메일과 내려받는 파일이 가장 자주 샌다. 화면을 고칠 때 템플릿을 같이 안 고치는 일이 흔하고, 사용자는 영수증 금액이 다르면 바로 문의한다.

마지막 줄은 QA 가 직접 못 보는 경우가 많지만, "그쪽에 어떤 값이 나가나요" 를 묻는 것만으로 공백이 드러나기도 한다.

이 관점이 비싼 이유 — 준비가 필요하다

솔직히 적어 두면, 이 레슨의 탐험은 앞 레슨들보다 비용이 크다.

• 개체 지도를 그려야 한다(10분, 그리고 개발자 시간)
• 연결된 데이터를 미리 만들어 둬야 한다(주문 2건·리뷰 1건·쿠폰 1장…)
• 삭제처럼 되돌릴 수 없는 동작을 해야 해서 시험 계정을 소모한다
• 저장소나 관리자 화면 접근 권한이 필요한 경우가 많다

그래서 매 릴리즈마다 돌릴 종류는 아니다. 언제 하는가를 정해 두는 편이 낫다.

마지막 줄이 숨은 효용이다. 개체 지도를 그리면 그 제품이 무엇을 다루는 시스템인지 단번에 보인다. 레슨 11의 레거시 정찰과 같은 쓰임이다.

실무에서 왜 필요한가

화면 흐름 중심으로만 탐험하면, "이 화면은 잘 동작한다"는 확인은 되지만 "이 화면과 저 화면의 숫자가 서로 맞는가" 는 확인이 안 된다. 실무에서 발생하는 심각한 결함 중 상당수가 이런 데이터 불일치다 — 특히 결제·정산처럼 여러 화면·시스템에 걸쳐 같은 값이 반복 표시되는 영역에서 자주 터진다. 개체 중심 탐험은 이런 결함을 정면으로 겨냥한다.

그리고 이런 결함에는 공통된 특징이 하나 더 있다. 발견이 늦을수록 복구가 비싸다. 화면 결함은 고치면 끝이지만, 데이터가 어긋난 채 몇 달이 지나면 이미 쌓인 데이터를 따로 바로잡아야 한다. 모듈 1 레슨 1에서 "6번이 특히 무섭다" 고 한 것 — 잘못된 로직으로 생성된 데이터가 쌓이는 문제 — 가 바로 이 레슨의 결함들이다.

운영팀이 매달 손으로 고치고 있는 것이 있다면 거의 항상 이 종류다. 그 수작업을 찾아내 원인을 짚는 것만으로 QA 가 조직에 주는 값이 크다.

관계의 종류를 알면 질문이 좁혀진다

선을 다 똑같이 보면 질문이 막연하다. 관계에 세 종류가 있고, 종류마다 위험한 지점이 다르다.

하나, 하나에 여럿이 달린 관계. 사용자 하나에 주문 여럿, 주문 하나에 상품 여럿. 여기서는 부모를 지우거나 바꿀 때 자식이 어떻게 되는지가 핵심이다. 그리고 자식이 아주 많을 때(주문 500건) 화면과 성능이 버티는지도 본다.

둘, 서로 맞물린 관계. 사용자와 상품 사이의 "찜", 사용자와 그룹 사이의 "소속". 양쪽 어디서나 끊을 수 있어서 한쪽에서 끊었는데 다른 쪽에 남는 일이 생긴다. 양방향을 다 확인해야 한다.

셋, 선택적 관계. 주문에 배송지가 있을 수도 없을 수도(매장 수령), 결제에 쿠폰이 붙을 수도 안 붙을 수도. 없는 경우를 안 만들어 둔 화면이 많다 — 레슨 5의 "목록이 0건일 때" 와 같은 함정이다.

셋 중 두 번째가 가장 조용히 샌다. 찜을 취소했는데 상품 쪽 찜 수가 안 줄거나, 그룹에서 뺐는데 그 사람 화면에는 아직 보이는 식이다. 양쪽을 다 열어 보지 않으면 모른다 — 레슨 6의 두 창 띄우기가 여기서도 쓰인다.

사례 — 탈퇴가 만든 세 가지 결함

개체 관점이 왜 다른 것을 찾는지 한 흐름으로 보자. 회원 탈퇴 하나를 개체 지도 위에서 따라간 결과다.

준비. 탈퇴할 계정에 주문 2건, 리뷰 1건, 쿠폰 1장, 장바구니 상품 3개를 만들어 둔다. 탈퇴 전 상태를 먼저 기록해 둔다 — 비교할 기준이 없으면 무엇이 달라졌는지 모른다.

탈퇴 후, 선을 하나씩 따라간다.

세 건이 나왔고, 셋 다 화면 흐름을 따라가는 탐험으로는 안 나온다. 탈퇴 화면 자체는 완벽하게 동작했기 때문이다. "탈퇴되었습니다" 가 떴고 로그인도 안 된다.

그리고 셋의 성격이 다르다. 리뷰 실명은 개인정보 문제, 장바구니는 다른 사용자에게 영향(재고), 통계는 수치 신뢰성이다. 한 번의 탐험에서 세 종류가 나온 셈이고, 선을 따라갔기 때문이다.

다른 개체에도 같은 방식이 통한다

탈퇴만이 아니다. "지우거나 바꾸면 주변이 어떻게 되나" 를 묻는 것이 이 레슨의 전부이고, 아래가 그 질문이 잘 통하는 자리들이다.

"가격을 바꾼다" 가 특히 생산적이다. 장바구니에 담아 둔 사이 가격이 바뀌면 어느 값으로 결제되는지, 사용자에게 알려 주는지 — 요구사항에 답이 없는 경우가 대부분이고, 그래서 구현도 제각각이다.

채용시장에서의 위치

개체·데이터 관점은 주니어와 그 위를 가르는 지점 중 하나다. 면접 질문에서 드러나는 방식이 분명하다.

• "화면 테스트 말고 또 무엇을 보셨나요?" — 데이터 정합성을 말할 수 있으면 범위가 넓은 사람으로 읽힌다
• "탈퇴 기능을 테스트한다면?" — "탈퇴되는지 확인한다" 는 초급 답이다. "연결된 주문·리뷰·장바구니가 어떻게 되는지 본다" 가 이 레슨의 답이다
• "데이터 정합성 검증 경험이 있나요?" — 금융·커머스 공고에 특히 자주 나오는 문구이고, 이 레슨과 모듈 61·41 의 내용을 묻는 것이다

그리고 이 역량은 저장소를 조회할 줄 아는 능력과 짝이다. "값을 따라가 봤습니다" 에 "어떻게 확인하셨나요" 가 이어지는데, 이때 조회로 확인했다고 답할 수 있으면 신뢰도가 다르다(모듈 9 레슨 5·모듈 61).

실습 과제

과제 1 — 삭제 영향 추적하기 (12분)

"쿠폰" 개체를 삭제(또는 만료 처리)했을 때, 연결되어 있을 법한 다른 개체(주문, 사용자, 통계 등) 세 가지를 떠올리고 각각에 어떤 영향이 있을지 예상해 적는다.

과제 2 — 데이터 따라가기 (10분)

"회원 등급(일반/VIP)"이라는 값이 시스템 어느 화면들에 걸쳐 나타날 수 있을지 최소 4곳을 나열하고, 이 값이 한 곳에서만 바뀌고 다른 곳엔 반영이 안 되는 결함이 생긴다면 어떤 문제가 생길지 적는다.

과제 3 — 개체 지도 그리기 (15분)

자주 쓰는 서비스 하나를 골라 개체 지도를 그린다. 완벽하지 않아도 된다.

1. 눈에 보이는 "것들" 을 6~8개 적는다(사용자·주문·상품·댓글 등)
2. 서로 이어진 것을 선으로 잇는다
3. 선마다 질문 하나씩을 붙인다 — "한쪽을 지우면 다른 쪽은?"
4. 질문 중 답을 모르는 것에 표시한다

자가 체크리스트

• 개체·속성·관계를 예시로 구분해 설명할 수 있다
• CRUD 탐험 시 연결된 다른 개체까지 함께 확인해야 하는 이유를 설명할 수 있다
• "고아 레코드" 결함이 무엇이고 왜 화면만 봐서는 안 보이는지 설명할 수 있다
• 하나의 값을 여러 화면에 걸쳐 추적하는 "데이터 따라가기"를 직접 해볼 수 있다
• 개체 지도를 그리고 선마다 질문을 붙일 수 있다
• 삭제의 네 가지 방식(진짜·표시만·보관 후·거부)을 구분해 확인할 수 있다
• 값이 어긋나는 네 원인(계산 위치·읽은 시점·복사 저장·캐시)을 짚을 수 있다
• 값이 나타나는 자리를 화면 밖(메일·내려받는 파일·외부 전송)까지 셀 수 있다
• 값 불일치를 발견했을 때 "의도인가" 를 먼저 묻고 근거 문서를 확인할 수 있다

흔한 실수

• 삭제(Delete)를 테스트하고 "삭제됐다"는 화면 메시지만 확인하고 끝낸다. 연결된 다른 개체까지 확인해야 진짜 결함을 잡는다.
• 한 화면에서 값이 맞으면 다른 화면도 맞을 거라 가정한다. 값이 화면마다 다른 곳(다른 API, 다른 캐시)에서 오는 경우, 한쪽만 갱신되고 다른 쪽은 안 되는 불일치가 실무에서 흔하다.
• 개체 관계도를 전혀 모른 채 탐험한다. 최소한 "이 시스템에 어떤 개체들이 있고 서로 어떻게 연결되는지" 대략적인 그림은 먼저 그려두는 게 효율적이다.
• "지웠다" 를 한 가지로 생각한다. 네 가지 방식이 있고, 표시만 지우는 경우가 가장 흔하며 가장 많이 샌다. 목록·검색·통계·직접 주소를 전부 본다.
• 값이 다르면 바로 결함으로 단정한다. 주문 시점 값을 보관하는 것은 의도인 경우가 많다. "의도인가, 어디에 적혀 있나" 를 먼저 묻는다.
• 화면만 세고 메일·영수증·외부 전송을 안 센다. 템플릿은 따로 만들어져 갱신이 누락되기 쉽고, 사용자는 영수증 금액이 다르면 바로 문의한다.
• 탈퇴·삭제 전 상태를 기록하지 않는다. 비교 기준이 없으면 무엇이 달라졌는지 알 수 없다.

참고 자료

• 이 커리큘럼 안: 레슨 4(네 겹 관찰 — 저장소를 보는 법), 레슨 8(상태와 전이), 레슨 5(숨은 변수 — 조합 기준)
• 이 커리큘럼 안: 모듈 61(데이터 확인 — 저장소를 직접 조회), 모듈 2(요구사항 공백 — 선마다 나온 질문의 행선지), 모듈 41(원장 정합성 — 같은 발상의 금융판)
• Elisabeth Hendrickson, Explore It! — 개체·관계 탐험 기법을 다룬 장
• ISTQB Glossary — Data Integrity Testing — 데이터 일관성 검증의 공식 개념과 연결된다
• 이 레슨에서 그린 개체 지도는 레슨 8(상태와 전이)에서 각 개체가 어떤 상태를 거치는지로 이어진다. 지도가 가로 방향이면 상태는 세로 방향이다