planning ·
기획자를 위한 웹/앱 구조 ⑦ 이슈 소통 도구 — 상태코드, 외부 연동, 개발자 통역표
HTTP 상태코드: 숫자 세 개로 읽는 응답
서버의 응답에는 항상 세 자리 결과 코드가 붙는다. 세 개만 알면 이슈 소통이 된다.
| 코드 | 뜻 | 기획자의 해석 |
|---|---|---|
| 200 | 성공 | 정상. “200 떨어져요” = 서버는 제대로 응답했다는 뜻 — 그런데도 화면이 이상하면 프론트 쪽 이슈일 가능성 |
| 404 | 찾을 수 없음 | 주소가 없거나 삭제됨. 링크 오타, 지워진 게시물. “404 떠요”는 잘못된 주소로 안내되고 있다는 신호 |
| 500 | 서버 내부 오류 | 백엔드에서 예상 못한 에러. 사용자가 고칠 수 없음 — 개발팀에 로그 확인 요청이 정답 |
이 밖에 401/403(권한 없음), 502/504(서버 사이 연결 문제)도 종종 등장한다 — “권한 문제”와 “서버 연결 문제”로 이해하면 충분하다.
우리 서버 밖의 세계 — 외부 연동
결제(PG), 문자·알림톡, 소셜 로그인, 지도는 대부분 남의 서버(서드파티) 를 빌려 쓰는 기능이다.
- 우리 서비스 → 외부사 API 호출 → 결과 수신 구조라, 외부사가 장애면 우리도 그 기능만 멈춘다. “결제만 안 돼요”가 우리 잘못이 아닐 수 있는 이유.
- 외부 연동 기능의 기획서에는 실패 시나리오(외부사 응답 없음·거절)가 반드시 필요하다 — 개발자가 가장 먼저 물어보는 부분.
- 비용 구조도 다르다: 호출 건수·문자 발송 건수 단위 과금이 흔해서, 기획이 곧 비용에 직결된다.
개발자가 이렇게 말하면 — 통역 표
| 개발자의 말 | 뜻 + 기획자가 알면 좋은 것 |
|---|---|
| ”그건 프론트에서 처리할게요” | 서버 수정 없이 화면 로직만으로 해결. 보통 배포 부담이 작다 |
| ”API 스펙부터 정해야 해요” | 화면과 서버가 주고받을 데이터 형식 약속. 이게 정해져야 프론트·백이 병렬로 작업 가능 — 일정 단축의 핵심 |
| ”DB 마이그레이션이 필요해요” | 데이터 금고의 칸 구조(테이블)를 바꾸는 작업. 실데이터를 건드려서 신중해야 하고, 되돌리기 어렵다. 시간이 걸리는 게 정상 |
| ”포트가 안 열려 있어요” | 방화벽이 그 호수(포트)를 막고 있음. 보통 인프라 담당에게 개방 요청이 필요 — 코드 문제가 아님 |
| ”캐시 때문에 그래요. 강력 새로고침 해보세요” | 예전 응답의 복사본(캐시)이 남아 옛 화면이 보이는 것. 버그가 아닐 수 있음 |
| ”롤백했습니다” | 배포에 문제가 있어 직전 버전으로 되돌림. 방금 나간 기능은 다시 사라진 상태 |
| ”트래픽이 몰려서 서버 증설이 필요해요” | 동시 사용자가 많아 서버(WAS)를 여러 대로 늘려야 함. 이벤트 기획 시 미리 공유하면 좋은 정보 |
| ”세션이 만료돼서 로그아웃된 거예요” | 서버가 기억하는 “로그인 상태”에 유효시간이 있음. 정책(몇 분?)은 기획 결정 사항 |
| ”그건 하드코딩돼 있어서 배포해야 바뀌어요” | 값이 코드에 박혀 있음. 운영자가 관리화면에서 바꿀 수 있게 하려면 별도 개발(어드민)이 필요 |
| ”500 떨어지는데 로그 봐야 알 것 같아요” | 서버 내부 오류. 원인은 로그를 봐야 앎 — 재현 경로(어느 화면에서 뭘 눌렀는지)를 알려주면 추적이 훨씬 빨라짐 |
| ”그건 PG사 쪽 이슈라 저희가 할 수 있는 게 없어요” | 외부(서드파티) 서버 장애. 우리 코드 문제가 아니라 기다리거나 외부사에 문의해야 함 |
외우기보다 “어느 구성요소 이야기인지”를 떠올리는 연습이 핵심이다.
시리즈 전체 보기: ① 요청과 응답 · ② 정적/동적 웹 · ③ 다섯 명의 등장인물 · ④ 라이브러리와 프레임워크 · ⑤ 서버의 층위와 MSA · ⑥ 주소와 환경 · ⑦ 상태코드와 통역표 · ⑧ UML과 용어사전