기획자가 알아두면 좋은 개발 용어 정리 — 협업 시 자주 쓰는 단어 모음

개발팀과 회의를 하다 보면 익숙하지 않은 단어들이 오간다. 스프린트, API, 레거시, 배포, 마이그레이션처럼 맥락은 파악되는데 정확한 의미를 모르는 채로 넘어가는 경우가 많다. 대화에서 틀리게 쓰거나 의미를 잘못 이해하면 기획 의도가 다르게 전달될 수 있다. 반드시 개발 전문가 수준으로 알 필요는 없지만, 자주 쓰이는 단어의 의미와 맥락 정도는 파악해 두는 것이 협업에 도움이 된다. 실무에서 기획자가 자주 접하는 개발 용어를 분야별로 정리해 보려고 한다.

 

1. 개발 일정·프로세스 관련 용어

기획자가 가장 자주 마주치는 영역이다. 일정 조율과 진행 상황 파악에 직접 연결된다.

스프린트 (Sprint) 애자일 개발 방식에서 쓰는 단위 개발 기간을 말한다. 보통 1~2주 단위로 구성되고, 스프린트마다 목표 기능을 정해 개발한다. 기획서를 스프린트 단위로 준비해야 하는 이유가 여기에 있다.

배포 (Deploy / Release) 개발한 코드를 실제 서비스에 반영하는 작업이다. 개발 서버(dev), 테스트 서버(staging), 실서버(production) 순으로 단계를 거치는 것이 일반적이다. 기획자가 QA를 요청하는 환경이 어디인지 확인할 때 필요한 개념이다.

핫픽스 (Hotfix) 운영 중인 서비스에서 긴급하게 수정이 필요한 오류가 발생했을 때 빠르게 배포하는 것이다. 정해진 배포 일정과 별개로 진행된다.

마이그레이션 (Migration) 데이터나 시스템을 한 환경에서 다른 환경으로 옮기는 작업이다. 예를 들어 서버를 교체하거나 데이터베이스 구조를 변경할 때 사용하는 용어다. 기획자 입장에서는 서비스 개편 시 기존 데이터 처리 방식을 협의할 때 자주 나온다.

레거시 (Legacy) 오래되어 유지보수가 어렵거나 현재 기술 기준에 맞지 않는 코드나 시스템을 말한다. 개발팀이 특정 기능 구현이 어렵다고 할 때 레거시 때문이라는 말이 자주 나온다.

리팩토링 (Refactoring) 기능은 그대로 두고 코드의 구조를 개선하는 작업이다. 사용자 눈에는 변화가 없지만 개발팀에서 내부 정비를 요청할 때 사용하는 표현이다.

 

2. API·서버 관련 용어

기획자가 기능을 정의할 때 개발팀과 API 기준으로 대화하는 경우가 많다.

API (Application Programming Interface) 서로 다른 시스템이 데이터를 주고받을 때 사용하는 연결 방식이다. 예를 들어 기획서에 카카오 지도를 넣겠다고 하면, 카카오 지도 API를 연동하는 방식으로 구현된다. 외부 서비스를 연결할 때는 해당 API가 제공되는지 확인하는 것이 필수다.

엔드포인트 (Endpoint) API가 요청을 받는 주소다. 로그인 기능이라면 /api/login 같은 주소가 엔드포인트다. 기획자가 기능 명세를 작성할 때 어떤 엔드포인트를 만들어야 하는지 개발팀과 협의하게 된다.

응답 속도·레이턴시 (Latency) 요청을 보내고 응답이 오기까지 걸리는 시간이다. 기획서에서 로딩 상태(스켈레톤 UI, 로딩 스피너)를 설계할 때 이 개념이 연결된다.

서버 에러 코드 기획자가 알아두면 좋은 주요 HTTP 상태 코드다.

코드의미기획 관점

200	성공	정상 응답
400	잘못된 요청	입력값 오류 처리 필요
401	인증 실패	로그인 필요 안내
403	권한 없음	접근 제한 화면 설계
404	찾을 수 없음	404 페이지 설계
500	서버 오류	서버 오류 안내 화면 설계

에러 코드별로 사용자에게 보여줄 메시지와 화면을 기획서에 미리 정의해 두면 개발 및 QA 단계에서 누락이 줄어든다.

 

3. 프론트엔드·화면 관련 용어

화면 설계와 직결되는 용어들이다.

컴포넌트 (Component) 화면을 구성하는 재사용 가능한 UI 단위다. 버튼, 카드, 입력창, 모달처럼 여러 화면에서 반복적으로 쓰이는 요소를 컴포넌트로 관리한다. 기획자가 새로운 UI 요소를 요청할 때 기존 컴포넌트를 활용할 수 있는지 먼저 확인하는 게 효율적이다.

렌더링 (Rendering) 서버나 클라이언트에서 화면을 그려내는 방식이다. SSR(서버사이드 렌더링)은 서버에서 화면을 먼저 만들어 보내는 방식으로 초기 로딩이 빠르고 SEO에 유리하다. CSR(클라이언트사이드 렌더링)은 브라우저에서 화면을 그리는 방식으로 인터랙션이 많은 서비스에 적합하다. SEO가 중요한 서비스라면 렌더링 방식이 기획 방향에 영향을 준다.

반응형 (Responsive) 하나의 화면이 PC, 태블릿, 모바일 등 다양한 해상도에 맞춰 자동으로 레이아웃을 바꾸는 방식이다. 반응형 여부는 기획 초기에 정해야 하는 항목 중 하나다.

네이티브 / 하이브리드 / 웹앱 앱의 개발 방식을 구분하는 용어다. 네이티브는 iOS, 안드로이드 각각 별도로 개발하는 방식이고, 하이브리드는 웹 기술로 만든 앱을 앱처럼 감싸는 방식이다. 기획자는 어떤 방식인지에 따라 설계 가능한 기능의 범위가 달라진다는 것을 알고 있어야 한다.

딥링크 (Deeplink) 앱의 특정 화면으로 바로 이동할 수 있는 링크다. 푸시 알림을 탭했을 때 특정 상품 상세 화면으로 바로 이동하는 것이 딥링크를 활용한 사례다. 알림이나 마케팅 기획 시 딥링크 여부를 개발팀과 사전에 협의해야 한다.

 

4. 데이터·DB 관련 용어

기획자가 기능 명세를 작성하거나 데이터를 다룰 때 필요한 기본 용어다.

DB·데이터베이스 (Database) 서비스에서 사용하는 데이터를 저장하는 공간이다. 기획자가 특정 정보를 화면에 보여주거나 저장해야 할 때, 그 데이터가 DB에 어떻게 담기는지 개발팀과 협의하게 된다.

스키마 (Schema) DB에 데이터를 어떤 구조로 저장할지 정의한 설계도다. 예를 들어 회원 테이블에 이름, 이메일, 가입일 같은 항목이 어떻게 구성되는지가 스키마다. 기획 초기에 어떤 데이터를 저장할지 명확히 정의해야 스키마 설계가 원활하다.

로그 (Log) 서비스에서 발생하는 사용자 행동이나 시스템 이벤트를 기록한 데이터다. 화면 조회, 버튼 클릭, 구매 완료처럼 어떤 행동을 로그로 남길지 기획 단계에서 정의해 두면 이후 데이터 분석이 가능해진다.

배치 (Batch) 정해진 시간에 대량의 데이터를 한꺼번에 처리하는 방식이다. 예를 들어 매일 자정에 쿠폰 만료 처리를 하거나, 주간 리포트를 자동 생성하는 것이 배치 작업이다. 기획서에 특정 작업의 실행 주기가 있다면 배치 처리가 필요한지 개발팀과 확인해야 한다.

 

5. 협업 방식·방법론 관련 용어

개발팀의 업무 방식을 이해하면 일정 조율과 요청이 수월해진다.

애자일 (Agile) 짧은 주기로 개발하고 피드백을 반영하며 반복적으로 개선해 나가는 개발 방법론이다. 기획도 한 번에 완성하기보다 우선순위 높은 기능부터 단계적으로 정의하는 방식이 잘 맞는다.

스크럼 (Scrum) 애자일 방법론 중 하나로, 스프린트 단위로 목표를 정하고 매일 짧은 회의(데일리 스크럼)를 통해 진행 상황을 공유하는 방식이다.

백로그 (Backlog) 개발해야 할 기능이나 작업의 목록이다. 기획자가 요구사항을 정리해서 백로그에 등록하면 개발팀이 우선순위에 따라 작업을 진행한다.

PR (Pull Request) 개발자가 작업한 코드를 메인 코드에 합치기 전에 검토를 요청하는 과정이다. 기획자가 직접 관여하지는 않지만, PR 리뷰가 지연되면 배포 일정에 영향을 준다는 것을 알아두면 일정 조율 시 도움이 된다.

QA (Quality Assurance) 서비스 출시 전에 기능이 기획 의도대로 동작하는지 검증하는 과정이다. 기획자가 QA 시나리오를 작성하고 테스트를 주도하는 경우가 많다.

 

 

개발 용어를 모두 외울 필요는 없다. 다만 자주 듣는 단어의 의미를 정확히 알고 있으면 회의에서 불필요한 오해가 줄고, 개발팀과의 신뢰도 자연스럽게 높아진다. 각자의 업무별로 특정 단어들을 자주 사용하는 것들이 있을 것이다. 그에 대해 더 찾아보거나 연관된 다른 용어들도 찾아보고 이해해 두면 좋을 것 같다.