planning ·
기획자를 위한 웹/앱 구조 ⑧ 부록 — UML 읽는 법과 용어사전
다이어그램(UML) 읽는 법
개발 문서에는 표준화된 그림 언어(UML 등)가 자주 등장한다. 종류별로 “무엇을 그린 그림인지”만 알면 처음 보는 문서도 읽을 수 있다.
| 종류 | 무엇을 그리는가 | 기획자가 만나는 순간 |
|---|---|---|
| 시퀀스 | 시간 순서대로 누가 누구에게 무엇을 요청/응답하는지 | 로그인·결제 같은 흐름 설계 리뷰 |
| 플로우차트 (액티비티) | 작업의 진행과 분기 (마름모 = 조건 분기) | 기획서의 프로세스 정의 — 기획자가 직접 그리는 일이 가장 많은 종류 |
| 유스케이스 | 어떤 사용자(액터)가 어떤 기능을 쓰는지 관계도 | 기능 범위·권한 정의 초기 단계 |
| 컴포넌트/배포도 | 시스템이 어떤 덩어리들로 구성되고 연결되는지 | 아키텍처 설명 자료 (이 시리즈의 구조도들이 이 계열) |
| 상태(state) | 하나의 대상이 거치는 상태와 전이 | 상태값 정의 회의 — “취소는 어느 상태에서만 가능한가”의 지도 |
| ER | DB 표(테이블)들과 그 관계 (1:N 등) | 데이터 구조 리뷰. “이 정보 저장되나요?”의 근거 문서 |
| 클래스 | 코드 내부의 객체 구조 | 기획자가 볼 일은 드묾 — 개발 내부 설계용 |
기획자가 직접 그릴 일이 많은 것은 플로우차트·상태·유스케이스, 읽을 줄 알면 되는 것은 시퀀스·컴포넌트·ER.
상태 다이어그램은 기획 품질을 크게 올리는 도구다. 기능에 상태값이 있다면(주문·게시글·회원 등급) 상태 전이도를 기획서에 직접 그려보자 — “환불은 배송중에도 되나요?” 같은 빠진 정책이 그림에서 바로 드러난다.
생김새 미리보기 (같은 “주문” 예시로)
시퀀스 — 시간순 요청/응답
플로우차트 — 진행과 분기
유스케이스 — 누가 어떤 기능을 쓰는가
컴포넌트 — 구성과 연결
상태 — 주문의 일생과 전이
ER — 테이블 관계 (1:N)
클래스 — 코드 내부 구조 (참고용)
용어사전
| 용어 | 뜻 |
|---|---|
| 클라이언트/서버 | 요청하는 쪽(사용자 기기)/응답하는 쪽(회사 컴퓨터). 모든 통신의 기본 구도 |
| 요청/응답 | 클라이언트가 보내는 부탁 / 서버가 돌려주는 결과 |
| API | 서버가 제공하는 기능 창구의 묶음 |
| 엔드포인트 | API의 개별 주소 하나 (/api/orders 같은 것) |
| JSON | 프론트와 백엔드가 데이터를 주고받는 표준 포장 형식 |
| 배포(deploy) | 새 버전 코드를 서버에 올려 사용자에게 내보내는 일 |
| 롤백 | 배포를 직전 버전으로 되돌리기 |
| 빌드 | 사람이 쓴 코드를 실행 가능한 산출물로 변환·포장하는 과정 |
| 정적 파일 | 누가 요청해도 내용이 같은 파일(이미지·JS·CSS) |
| 리버스 프록시 | 웹서버가 요청을 받아 뒤의 WAS에 대신 전달하는 교통정리 방식 |
| HTTPS/인증서 | 통신 암호화(주소창 자물쇠). 인증서는 유효기간이 있어 만료되면 접속 경고 |
| 방화벽 | 허가된 포트만 통과시키는 문지기 |
| 캐시 | 한 번 받은 응답의 복사본을 재사용해 속도를 높이는 장치. 갱신 지연의 흔한 원인 |
| 세션/쿠키 | 서버가 로그인 상태를 기억하는 방법 / 브라우저에 남기는 작은 메모 |
| 테이블/스키마 | DB 안의 표 하나 / 표들의 전체 설계도 |
| 마이그레이션 | DB 표 구조를 바꾸는 작업. 실데이터를 다뤄 신중함 |
| 로그 | 서버가 남기는 일지. “로그 확인해볼게요” = 사건 기록을 뒤져보겠다는 뜻 |
| 트래픽 | 서비스로 들어오는 요청의 양 |
| 스케일 업/아웃 | 서버 한 대를 키우기 / 서버 대수를 늘리기 |
| 클라우드 (AWS 등) | 서버를 빌려 쓰는 서비스 |
| CDN | 전 세계에 복사본을 두는 배달 대행망. 이미지·영상을 빠르게 주는 용도 |
| 어드민 | 운영자가 데이터·설정을 직접 관리하는 내부 화면. 별도 기획·개발 대상 |
| 물리 서버/VM/인스턴스 | 실제 컴퓨터 / 그걸 쪼개 빌려 쓰는 가상 서버 / 클라우드에서 가상 서버 한 대 |
| 컨테이너/도커 | 프로그램을 칸막이 포장해 어디서든 똑같이 실행되게 하는 기술 / 그 표준 도구 |
| 정적/동적 페이지 | 누가 봐도 같은 내용 미리 제작 / 요청 시마다 WAS가 생성 |
| SPA | 화면 틀은 한 번 받고 이후 데이터만 갈아끼우는 요즘 웹 방식 |
| 상태코드 | 응답에 붙는 세 자리 결과 번호 — 200 성공, 404 없음, 500 서버 오류 |
| 서드파티/PG | 남의 회사가 제공하는 외부 서비스 / 그중 결제 대행사 |
| HTTP 메서드 | 요청의 행위 종류 — GET(조회)·POST(생성)·PUT/PATCH(수정)·DELETE(삭제) |
| 멱등성 | 같은 요청을 여러 번 보내도 결과가 한 번과 같은 성질. POST는 멱등하지 않아 중복 제출 방지 필요 |
| REST/RESTful | URL은 자원(명사), 행위는 메서드로 표현하는 API 설계 관례 / 그걸 잘 따랐다는 뜻 |
| Swagger | API 목록·형식을 자동으로 보여주는 문서 화면 |
| 모놀리식/MSA | 백엔드를 한 덩어리로 / 기능별 여러 서비스로 나눠 만드는 구조 |
마지막 요약 — 사용자의 요청은 [도메인→DNS→IP:포트]로 서버에 도착하고, [웹서버→WAS→DB]를 거쳐 응답으로 돌아온다. 화면은 프론트엔드, 규칙은 백엔드, 저장은 DB의 일이다. 서비스는 dev→스테이징→운영 세 벌로 존재하며, 검수는 스테이징에서 한다.
시리즈 전체 보기: ① 요청과 응답 · ② 정적/동적 웹 · ③ 다섯 명의 등장인물 · ④ 라이브러리와 프레임워크 · ⑤ 서버의 층위와 MSA · ⑥ 주소와 환경 · ⑦ 상태코드와 통역표 · ⑧ UML과 용어사전