스킬 시트에 '기본 설계'라고 적는 사람은 드물지 않다.
하지만 내용을 들어보면, 정해진 내용을 베껴 쓰는 작업이었던 경우가 많았다.
기본 설계의 본질은 사용하는 사람의 경험(UX)을 화면과 움직임의 규칙으로 구현하는 것이다.
가상의 EC 사이트에서 '재고 3점에 4점 주문'이라는 하나의 상황을 공정별로 추적하며 정리한다.
이 글은 기본 설계 경험이란 무엇인가? AI 시대에 요구되는 설계력과 스킬 시트 작성법의 요약본이다.
두 명의 주문이 겹치는 경우의 고려 사항이나, AI로 설계를 연습할 때 주의해야 할 점은 위의 전체 버전을 참고해 달라.
다루는 소재는 티셔츠를 판매하는 가상의 EC 사이트이다.
상품을 장바구니에 담고, 수량을 확인하여 주문한다.
여기서는 수량과 재고에만 초점을 맞춘다.
| 공정 | 한마디로 말하면 | 재고 부족 시에는 |
|---|
| 요구사항 정의 | 무엇을 할 수 있게 할지 결정 | 매장에 오지 않아도 주문할 수 있도록 함 |
| ... | | |
| 같은 주문 기능이라도, 생각하는 깊이가 다르다. | | |
기본 설계는 '어떻게 움직여야 하는가', 상세 설계는 '어떻게 만들 것인가'이다.
물론 공정명으로 일을 명확히 나눌 필요는 없다.
실제 기본 설계에는 시스템 방식 등도 포함된다.
자신의 현장에서 어떤 설계서에 무엇을 쓰고, 누가 확인하는지 알면 충분하다.
여기서가 기본 설계의 본질에 다가가는 부분이다.
선택지는 최소 3가지가 있다.
- 3점만 접수한다
- 부족분을 예약 처리로 한다
- 주문을 중단하고 수량을 다시 선택하도록 요청한다
어떤 안을 골라도 시스템적으로는 작동한다.
하지만 구매자의 경험은 완전히 다르다.
조용히 3점으로 줄여버리면, 배송받고 나서 '주문한 수량과 다르다'고 깨닫는 사람이 나온다. 이로 인해 문의나 반품이 늘어나 매장의 부담이 된다.
'작동만 하면 된다'는 시점에서는 이 차이를 발견하기 어렵다.
많은 엔지니어는 기능이 작동하면 설계가 끝났다고 생각한다.
반면, PO(Product Owner)나 비즈니스 측에서 보는 것은 사용자가 어떻게 느끼는지이다.
기본 설계는 바로 이 UX를 화면과 움직임의 규칙으로 구현하는 일이다.
그러므로 구현 담당자가 만들기 쉬운 것만으로 결정해서는 안 된다.
이 예시에서는 매장 측에 확인하여 다음과 같이 결정했다고 가정한다.
- 재고 범위 내에서만 주문할 수 있다
- 부족 시 수량을 임의로 줄이지 않고, 구매자에게 수정 요청을 한다
- 장바구니에 담는 것만으로는 재고를 확보하지 않는다
방침이 정해지면 화면 움직임으로 구현한다.
| 상황 | 화면 움직임 |
|---|
| 재고가 부족할 때 | 주문 확정 없이 '재고가 부족합니다. 수량을 변경해 주세요'라고 안내 |
| ... | |
| 설계서상의 '입력 검사'나 '에러 발생 시 동작'이다. | |
쉽게 말해 '무엇을 입력해도 되는지', '살 수 없을 때 무엇을 알려줄 것인지'가 된다.
안내 문구 하나만으로도 구매자가 다음에 무엇을 해야 할지 알면 경험이 달라진다.
의문점을 발견하면 리더를 통해 확인하면 된다.
스스로 결정할 권한이 없더라도, 결정해야 할 필요성에는 깨달을 수 있다.
그 깨달음을 설계서로 연결하는 것도 설계와 관련된 일이다.
기본 설계에서 정한 움직임을 백엔드 처리로 구현하는 것이 상세 설계이다.
여기서 강조하고 싶은 것은, 화면의 제한만으로는 부족하다는 점이다.
화면상에서 1~3점만 선택할 수 있게 해도, 화면을 거치지 않고 데이터가 전송되는 경우가 있다.
OWASP의 입력 검증 가이드에서도, 화면 측 확인은 UX를 위해, 서버 측 확인은 안전을 위해 역할을 분리하고 있다.
게다가 장바구니에 담고 나서 주문하기 전까지, 다른 사람이 구매할 수도 있다. 매장에서는 예약 처리를 하지 않으므로, 주문을 받는 시점의 재고를 확인한다.
① 수량이 1 이상의 정수가 아니면, 주문을 받지 않고 수정 요청을 한다
② 재고가 부족하면, 주문을 확정하지 않고 안내를 반환한다
③ 조건을 충족하는 경우, 재고 확보와 주문 기록을 수행한다
...
이 4줄로 상세 설계가 완성되는 것은 아니다.
재고만 줄어들고 주문은 남지 않는 등의 실패에 대비책도 필요하다.
처음에는 선배의 리뷰를 받으면서, 확인 범위를 넓혀나가면 된다.
설계 내용은 그대로 테스트 관점으로 연결된다.
재고 3점 상태에서 각각 시도해 본다.
| 시도할 것 | 확인하고 싶은 결과 |
|---|
| 2점을 주문 | 주문이 가능하며, 재고는 1점이 된다 |
| ... | |
| 재고 부족 시 안내가 정해져 있지 않다면, 테스트 담당자가 그 자리에서 결정하는 것이 아니다. | |
기본 설계 담당자에게 돌아가서, 어떻게 움직여야 할지 확인한다.
▶ 두 명의 주문이 겹치는 경우의 고려 사항이나, AI로 설계를 연습할 때 주의해야 할 점은 여기를 참고 → 기본 설계 경험이란 무엇인가?
AI에게 '상품을 주문하는 기능을 만들어 달라'고 요청했다고 가정한다.
재고 부족 시, 수량을 말없이 재고 수량까지 줄이는 방식으로 만들어져 있었다.
동작 자체는 올바르다.
테스트를 작성하게 해도 그대로 통과해 버린다.
하지만 매장이 정한 '구매자에게 수정을 요청하는' 경험과는 다르다.
AI는 지시된 범위 내에서 합리적으로 만들지만, 누구의 경험을 우선할지는 결정하지 못한다.
여기서 UX(User Experience) 관점이 판단의 자(measure)가 된다.
AI를 사용하는 데 어려운 것은 결과물의 좋고 나쁨을 판단하는 것이다.
자(measure) 없이 AI를 사용하면, 작동하는 것만 양산하는 것으로 끝난다.
기본 설계(Basic Design)를 이해하고 있다면, '사용자에게 무엇이 불편할지'를 확인할 수 있다.
상세 설계(Detailed Design)를 이해하고 있다면, 그 규칙이 백그라운드 처리에도 있는지 추적할 수 있다.
AI에게 구현을 맡기는 현장일수록, 이 판단력이 사람에게 남는다.
여기서 처음의 질문으로 돌아가 보자.
수량란 설명을 지시된 문구로 변경했다.
이것은 정해진 내용을 정확하게 반영한 경험이다.
재고를 초과하는 주문 처리가 미정임을 깨닫고 확인했다.
이는 사양(specification)의 누락을 발견하여 설계에 반영한 경험이기도 하다.
구매자가 당황할 만한 장면을 미리 찾아낸, UX 경험이라고도 할 수 있다.
둘 다 적어도 좋다. 다만 '기본 설계서 수정'이라는 한 줄로는 이 차이가 전달되지 않는다.
| 기술 | |
|---|
| Before | EC 사이트의 기본 설계·상세 설계·제조·테스트를 담당함. |
| After | EC 사이트 주문 수량 체크를 담당함. 재고 부족 시 수량을 자동으로 줄이지 않는 방침을 리더를 통해 확인함. 구매자가 수량을 수정할 수 있는 조건과 안내를 기본 설계서에 반영함. 상세 설계에서는 주문 접수 시 수량과 재고를 확인할 처리안을 작성함. 선배의 리뷰 후 구현하고, 재고 이내/재고 초과 주문을 테스트함. |
대상·확인 내용·담당 범위를 나누면 경험의 내용이 보인다.
After에는, 사용자의 경험을 어떻게 지켰는지도 포함되어 있다.
리뷰를 받았다는 것을 숨길 필요는 없다.
기본 설계에 관여한 것과, 혼자서 기본 설계를 진행할 수 있는 것은 별개다.
'고객과의 조정을 주도했다' 등 실제 담당하지 않은 역할은 추가하지 않는다.
'나는 수정만 했다'라고 느껴져도, 지금의 경험을 지울 필요는 없다.
담당하는 버튼이나 입력란에 대해 다음 세 가지를 확인해 본다.
- 사용자는 무엇이 되면 불편함을 느끼지 않을까
- 입력을 잘못하거나, 재고가 부족하면 어떻게 작동할까
- 그 규칙을 코드의 어디에서 확인하고 있을까
처음부터 답을 가지고 있을 필요는 없다.
수량란이라면, 이렇게 물어볼 수 있다.
'재고 부족일 때는 수량을 자동으로 줄이지 않고, 다시 입력하도록 하는 방침인가요?'
답변을 들었다면, 왜 그 방침인지도 묻는다.
설계서의 어디에 적고, 구현의 어디에 반영할지까지 추적한다.
질문만 하고 끝내지 않고, 다음 작업으로 연결하는 것이 중요하다.
AI에게 확인 누락을 찾아달라고 하는 것도 좋다.
다만 고객사의 코드나 설계서, 개인 정보를 무단으로 입력해서는 안 된다.
연습에는 가상의 EC 사이트를 사용한다.
이렇게 확인한 범위는 담당 범위의 변화로 남기고 싶다.
Skillsheet-Port에서는 건별 담당 공정을 폼에 넣어두면, 차이점을 더해 재출력할 수 있다.
'무엇을 확인했고, 어디까지 담당했는지'를 나중에 설명할 수 있는 형태로 쌓아둘 수 있다.
- 기본 설계는 '어떻게 작동해야 하는가', 상세 설계는 '어떻게 만들 것인가'.
생각하는 깊이가 다르다 - 기본 설계의 본질은,
사용자의 경험(UX)을 화면과 움직임의 규칙으로 구체화하는 것이다 - 재고 3점에 4점 주문 처리는 어떤 안으로도 작동한다.
차이가 나는 것은 구매자의 경험이다 - 상세 설계에서는
서버 측에서도 확인한다. 화면 제한만으로는 부족하다 - 테스트에서 미정의 움직임이 발견되면,
그 자리에서 결정하지 않고 기본 설계로 되돌린다 - AI는 작동하는 것을 만들지만,
누구의 경험을 우선할지는 결정하지 못한다. 그 판단력이 사람에게 남는다 - 스킬 시트는
대상·확인 내용·담당 범위를 나누어 쓴다. 담당하지 않은 역할은 추가하지 않는다.
갑자기 어려운 설계를 떠맡을 필요는 없다.
눈앞의 수량란이나 버튼 하나를 골라, '사용자에게 왜 이 움직임이어야 하는지'를 확인해 보길 바란다.
그 하나가, 다음에 맡겨질 범위를 넓힌다.
▶ 완전판 가이드 보기 → 기본 설계 경험이란 무엇인가? AI 시대에 요구되는 설계력과 스킬 시트 작성법
▶ 무료로 스킬 시트 만들어보기 → https://skillsheet-port.com/
