IT 서비스 기획자가 알아야 할 핵심 용어 7개

"버튼 하나만 추가하면 되는 거 아닌가요?"라는 질문에 개발자가 여러 작업을 설명하기 시작한 적 있나요? 사용자가 보는 화면과 실제 처리, 데이터 저장은 서로 연결되어 있어요. 기획자가 모든 코드를 알 필요는 없지만, 아래 7개를 알면 요청의 범위와 확인할 조건을 더 정확히 이야기할 수 있어요. 상품을 주문하는 기능을 예로 들어 볼게요.

1. 프론트엔드란 무엇일까요?

사용자가 보고 조작하는 화면과 그 동작을 구현하는 부분이에요. 입력창과 버튼뿐 아니라 로딩, 오류 안내와 빈 화면도 포함돼요. 같은 기능이라도 사용자가 어떤 상태를 보게 할지 정해야 해요.

쉽게 비유하면

식당의 홀과 안내판이에요. 주문을 받는 방법과 기다리는 동안 무엇을 알려 줄지도 여기서 결정돼요.

예를 들면 주문 버튼을 누른 뒤 처리 중 표시를 보여 주고, 다시 누르지 않도록 하는 화면 동작이 있어요. 다만 화면 제어만으로 중복 주문이 완전히 방지되지는 않아요.

회의에서는 이렇게 "정상 화면뿐 아니라 로딩, 실패, 재시도 상태도 기획에 포함할게요."

2. 백엔드란 무엇일까요?

화면 뒤에서 업무 규칙을 적용하고 데이터를 처리하는 부분이에요. 가격과 재고 확인, 주문 저장처럼 사용자가 요청한 일을 실제로 처리해요. 화면에서 입력을 검사했어도 서버 쪽에서 필요한 검증을 다시 해야 해요.

쉽게 비유하면

주문을 받아 재료와 조리 조건을 확인하고 실제 음식을 만드는 주방이에요.

예를 들면 할인 금액을 화면에서 보여 주는 것과, 결제 시점의 유효한 할인 금액을 확정하는 것은 다른 작업이에요.

회의에서는 이렇게 "할인 규칙이 바뀌면 화면 표시와 백엔드 계산 중 어디까지 수정해야 하나요?"

3. API란 무엇일까요?

프로그램끼리 기능과 데이터를 요청하고 응답하는 약속된 인터페이스예요. 기획에서는 무엇을 보내고 무엇을 받는지, 실패하면 어떤 상태가 오는지가 중요해요. 화면만 정해도 필요한 데이터가 자동으로 생기는 것은 아니에요.

쉽게 비유하면

홀과 주방이 같은 내용을 이해하도록 정해 둔 주문서 양식과 전달 창구예요.

예를 들면 주문 조회 API가 배송 예정일을 주지 않으면 화면에 그 날짜를 표시하기 위한 데이터 제공부터 검토해야 해요.

회의에서는 이렇게 "이 화면에 필요한 항목을 기존 API가 주나요? 누락과 오류일 때의 응답도 확인하고 싶어요."

4. 데이터베이스란 무엇일까요?

회원, 상품과 주문 정보를 체계적으로 보관하고 찾아 쓰는 데이터의 모음이에요. 관련 관리 시스템이 조회와 변경을 처리해요. 기획자는 어떤 기록을 남기고 어떤 기준으로 연결할지 함께 생각해야 해요.

쉽게 비유하면

고객 명부와 주문 장부를 고객 번호로 연결해 둔 자료실이에요.

예를 들면 상품의 현재 이름만 보관하면 이름이 바뀐 뒤 과거 주문에 무엇을 보여 줄지 문제가 될 수 있어요. 주문 당시 정보를 남길지 결정해야 해요.

회의에서는 이렇게 "상품 정보가 바뀌어도 주문 당시 가격과 상품명은 이력에서 확인할 수 있어야 해요."

5. 인증이란 무엇일까요?

사용자나 프로그램이 주장하는 신원이 맞는지 확인하는 과정이에요. 로그인은 대표적인 사례예요. 신원 확인인 인증과, 해당 데이터에 접근해도 되는지 정하는 인가는 구분해야 해요.

쉽게 비유하면

신분증을 확인하는 일과, 그 사람이 들어갈 수 있는 방을 정하는 일은 달라요.

예를 들면 로그인한 회원이라도 다른 회원의 주문을 볼 수는 없어요. 내 주문인지와 관리자 권한이 있는지 등을 서버에서 확인해야 해요.

회의에서는 이렇게 "로그인 여부 외에 일반 회원과 관리자가 각각 볼 수 있는 정보도 정의할게요."

6. 배포란 무엇일까요?

개발한 결과물을 시험이나 운영 같은 대상 환경에 반영하는 과정이에요. 개발 완료, 배포 완료와 사용자 공개는 같은 시점이 아닐 수 있어요. 배포 후 동작 확인과 문제가 생겼을 때의 복구도 고려해요.

쉽게 비유하면

새 설비를 현장에 설치하고 정상 작동을 확인하는 일이에요. 손님에게 공개하는 시점은 따로 정할 수 있어요.

예를 들면 새 주문 기능을 운영 환경에 먼저 반영한 뒤, 기능 설정으로 일부 사용자에게만 공개할 수 있어요.

회의에서는 이렇게 "운영 반영 시점과 전체 공개 시점을 나누고, 이상이 있으면 어떤 기준으로 중단할지도 정하죠."

7. 버그란 무엇일까요?

프로그램이 의도한 요구나 기대 동작과 다르게 작동하게 하는 결함이에요. 멈춤뿐 아니라 틀린 계산과 저장 누락도 포함돼요. 요구가 모호하다면 먼저 기대 동작부터 합의해야 해요.

쉽게 비유하면

주문한 메뉴와 실제 나온 음식이 다른 상황이에요. 무엇을 주문했는지 분명해야 차이를 확인할 수 있어요.

예를 들면 쿠폰 적용 뒤 배송비가 잘못 계산된다면 입력 조건, 기기와 재현 순서, 기대 금액을 함께 전달해요.

회의에서는 이렇게 "이 계정에서 이 순서로 주문하면 배송비가 0원이 되어야 하는데 3,000원으로 나와요."

주문 기능의 기획 질문으로 연결하기

확인할 질문	관련 용어
사용자는 어떤 화면과 상태를 보나요?	프론트엔드
어떤 규칙으로 처리하고 무엇을 주고받나요?	백엔드, API
어떤 현재 값과 과거 이력을 남기나요?	데이터베이스
누가 사용할 수 있고 무엇을 볼 수 있나요?	인증
언제 반영·공개하고, 무엇을 정상 동작으로 보나요?	배포, 버그

요청서에는 기능 이름과 함께 입력 조건, 기대 결과, 예외 상황과 공개 시점을 적어 보세요. 개발자와 확인할 쟁점이 훨씬 구체적으로 드러나요.