PM 주요 용어 정리, SQL 개념 정리 & 엑셀과 차이점

• PM 직무 주요 용어 정리 및 내식대로 예시 들어보기
  • PM 주요 사용 언어
  • 개발자와 소통할 때, 주요 사용 언어
  • UI/UX 디자이너와 소통할 때 주요 사용 언어
• SQL 개념 정리 + 엑셀(스프레드시트)와 차이점

 

---

 

PM 직무에 대한 견해와 주요 용어 정리

 

기획자는 시장 트렌드 파악, 요구사항 정의, 비용 대비 리스크 최소화, 비즈니스 목표 달성을 고민한다.

개발자는 기능 구현과 데이터 최적화/유지보수, 논리적 문제 해결에 집중한다(기능 > 디자인).

디자이너는 사용자 경험과 화면 구성을 바탕으로 직관적이고 편리한 서비스를 고려한다(디자인 > 기능).

 

이처럼 각 팀은 같은 프로젝트를 진행하면서도 서로 다른 우선 순위와 언어로 소통하기 때문에 갈등이 생기기 쉽다.

PM은 이들의 중간관리자로서 다수의 의견을 적극 반영하여 프로젝트가 원활히 완료될 수 있도록 돕는다(Like 길잡이).

따라서 이 글은 각 팀 간 협업을 위해 PM이 주로 사용하는 용어를 정리하고,

직접 해석하며 효과적으로 학습하는 것을 목표로 한다.

용어	설명
Agile (애자일)	짧은 주기로 개발하고 사용자의 피드백을 반영하여 반복적인 작업을 통해 점진적으로 개선하는 방식 🗨️ 이번 프로젝트는 빠른 사용자 요구 사항 반영과 오류 해결을 목적으로 애자일 방식을 채택했습니다.
Scrum (스크럼)	빠르게 개발하는 애자일 방식 중, 원활한 작업을 위해 작업 중 발생한 문제에 대한 보고와 업무 진행 상황을 데일리/위클리 미팅을 통해 점검하는 것 🗨️ 오늘 스크럼에서 ~한 문제가 파악됐습니다. 해당 담당자는 동료와 소통하여 빠른 해결 바랍니다.
Sprint (스프린트)	1~2주 단위로 짧은 기간 동안 목표를 설정하고 기능 구현 후, 배포 가능한 상태로 만드는 것(짧고 반복적인 개발 주기) 🗨️ 이번 스프린트 작업 후 QA 진행 바랍니다.
MVP (Minimum Viable Product)	핵심 기능만 뾰족하게 설정하여 빠르게 배포 후, 사용자 반응을 파악하고 검증하는 것 🗨️ MVP로 시장 반응 먼저 파악하고, 기능 추가/보완하고자 합니다.
PMF (Product Market Fit)	특정 시장의 고객 문제를 제품이 충분히 잘 해결해 지속적인 수요와 성장 신호가 나타나는 상태  - 단순 사용이 아니라 재사용/추천/지불 의사 포함  - 자연스럽게 계속 소비되는 상태 🗨️ 결제 전환은 이루어지고 있지만, 반복 사용률이 낮아서 PMF를 달성하기 위해 방법을 모색해야 합니다.
QA (Quality Assurance)	제품/서비스가 요구사항과 품질 기준을 충족하도록 사전에 프로세스 중심으로 테스트하여 품질을 보장하는 활동(문제 발견 보다 문제 예방에 초점) 🗨️ 해당 이슈는 QA 단계에서 잡혔어야 하는 케이스라고 생각합니다.
Beta Test (베타 테스트)	정식 출시 전, 제한된 실제 사용자에게 제품을 공개해 실사용 환경에서 버그/사용성/시장 반응을 검증하는 단계 🗨️ 베타에서 주요 버그 나오면 출시 일정을 조정하려 합니다.
AARRR	사용자의 전환 흐름을 5단계로 나눠 성장 지표를 관리하는 프레임워크 1. Acquisition(유입) : 유저가 유입되는 경로 2. Activation(활성화) : 첫 경험의 질 3. Retention(유지) : 재방문·재사용 여부 4. Referral (유지/수익) : 자발적 추천 발생 여부 5. Revenue (수익) : 실질적 수익 발생 여부 🗨️ AARRR로 보면 병목은 Activation 단계입니다.
KPI	목표 달성 정도를 측정하기 위해 설정한 핵심 성과 지표(지금 잘 가고 있는지 측정하는 기준) 🗨️ 현재 KPI 기준으로 보면 실험 방향 수정이 필요합니다.
ROI (Return on Investment)	투자한 비용 대비 얻은 이익의 비율  - 수익성 판단의 가장 기본 지표 🗨️ ROI 계산해보고 진행 여부 결정하겠습니다.
RnR (Roles and Responsibilities)	조직이나 프로젝트에서 각 구성원의 역할(Role)과 책임(Responsibility)을 명확히 정의한 것 🗨️ 현재 RnR 기준으로 보면 이 작업은 개발팀 담당입니다.
Funnel (퍼널)	사용자가 특정 목표(가입, 구매 등)에 도달하기까지의 과정을 단계별로 나누고, 각 단계 전환율을 분석하는 구조 🗨️퍼널 데이터 기준으로 우선순위 재정리하겠습니다.

 

개발자와 소통할 때, 주요 사용 언어

용어	설명
클라이언트 (Client)	서버에 요청을 보내고, 응답을 받아 사용자에게 UI/UX로 보여주는 쪽(사용자와 직접 맞닿는 영역) - 웹 : 브라우저 (HTML, CSS, JS) - 앱: iOS/Android 앱 - 역할: 데이터 요청 + 화면 렌더링 🗨️ 클라이언트에서 요청은 가는데 응답 처리 로직이 문제로 보이는데 확인바랍니다.
서버 (Server)	클라이언트의 요청을 받아 비즈니스 로직 처리 + 데이터 저장/조회 후 응답을 반환하는 시스템(실제 일을 처리하는 백엔드) - 역할 : 데이터 처리, 인증, 계산, DB 접근 - 결과 : API 형태로 응답 반환 🗨️ 서버 부하가 커서 성능 최적화가 필요합니다.
DB (Database)	데이터를 구조적으로 저장하고, 필요할 때 조회/수정/삭제할 수 있도록 관리하는 시스템 - 단순 저장이 아니라 검색/처리까지 가능 - 서버가 데이터를 다룰 때 핵심 기반 🗨️ 이건 DB 설계 단계에서 고려가 필요합니다.
클라이언트-서버 흐름	1. 클라이언트 요청(Request) 2. 서버 수신 및 처리 (Logic + DB 접근) 3. 서버 응답 (Response) 4. 클라이언트 화면 반영 ※ 요청 → 처리 → 응답 → 표시 🗨️ 응답은 오는데 클라이언트에서 렌더링이 안 되고 있습니다.
SQL (Structured Query Language)	데이터베이스에 저장된 데이터를 조회(SELECT), 추가(INSERT), 수정(UPDATE), 삭제(DELETE)하기 위한 표준 언어 ※ DB에 원하는 데이터를 요청하는 질의어 🗨️ JOIN 구조가 복잡해서 성능 이슈가 있습니다.
★ ★ ★   API (Application Programming Interface)	서로 다른 시스템(클라이언트-서버)이 정해진 규칙으로 데이터를 주고 받을 수 있게 하는 인터페이스 - 요청을 보내고, 정해진 방식으로 응답을 받는 통로 [PM 관점 포인트] - 기능 = 결국 API 단위로 구현됨 - API 설계 = 기능 설계와 직결 - 클라이언트/서버 협업의 기준점 ex. 유저 가져오기 → /users/{id} 같은 API 필요 🗨️ 현재 API 응답 구조가 클라이언트 요구사항과 맞지 않습니다.
Endpoint	API에서 특정 기능에 접근하기 위한 구체적인 URL(접근 지점/기능마다 별도로 존재) - API에서 실제로 요청을 보내는 '주소' 🗨️ 이 기능은 별도 Endpoint로 분리하는 게 좋겠습니다.
Deploy (배포)	개발이 완료된 코드를 운영 환경(Production)에 반영하여 실제 사용자에게 제공하는 과정 ※ 개발 → 테스트 → 실제 서비스 반영 🗨️ 배포 전에 QA 한 번 더 진행부탁드립니다.
Log	시스템(서버/클라이언트)에서 발생하는 이벤트, 상태, 오류 등을 시간 순서대로 기록한 데이터 → 문제 발생시, 과거 상황을 추적하는 근거 🗨️ 사용자 행동 로그 분석해서 이탈 원인 보겠습니다.
Debugging (디버깅)	프로그램에서 발생한 오류(버그)의 원인을 분석하고 수정하는 과정 → 로그와 코드를 따라가며 어디서 잘못됐는지 찾는 작업 🗨️ 로그 기반으로 디버깅해서 원인 파악해주세요.
Legacy (레거시)	과거에 구축되어 현재까지 사용 중인 구형 시스템, 코드, 구조 → 쉽게 건드리지 못하는 오래된 기반 코드/시스템 [왜 문제가 되는가?] - 코드 구조 복잡/비일관 → 수정 어려움 - 문서 부족 → 이해 비용 큼 - 변경 시 사이드 이펙트 발생 가능 - 최신 기술/아키텍처와 호환 어려움 [PM 관점 포인트] - 기능 추가 속도 ↓ - 버그 발생 가능성 ↑ - 리팩토링 필요하지만 비용 큼 🗨️ 기존 레거시 구조 건드리면 다른 기능에 영향 갈 수 있습니다.

 

UI/UX 디자이너와 소통할 때, 주요 사용 언어

용어	설명
User Flow (유저 플로우)	사용자가 특정 목표(가입, 구매 등)를 달성하기까지의 행동 흐름을 단계별로 시각화한 것 → 사용자가 목표까지 가는 이동 경로 지도 🗨️ 유저 플로우 단순화해서 단계 줄이는 방향으로 가는 게 좋겠습니다.
Use Case (유즈 케이스)	특정 사용자(User)가 특정 목표를 달성하기 위해 시스템을 어떻게 사용하는지 단계별로 설명한 시나리오 → 실제 상황 기준의 사용 패턴 설명서 ※ 누가(Actor) → 무엇을 하려고 → 어떻게 사용하는지 🗨️ 유즈 케이스 기준으로 보면 예외 상황 처리가 부족합니다.
와이어프레임 (Wireframe)	화면의 레이아웃, 정보 구조, 주요 요소 배치를 단순한 형태로 표현한 UI 설계 초안 → 색/스타일 없이 배치와 흐름만 정의한 초안 🗨️우선 와이어프레임으로 구조 먼저 잡고 방향 확인하겠습니다.
프로토타입 (Prototype)	제품/서비스의 UI와 인터랙션을 실제처럼 구현하여 사용자가 사용해볼 수 있도록 만든 테스트용 모델(Like 미리보기) [언제 사용하는가?] - 복잡한 사용자 흐름 검증 - 신규 기능 UX 테스트 - 이해관계자 설득/공유 [PM 관점 포인트] - 실제 개발 전에 UX 검증 가능 - 사용자 테스트(UT) 핵심 도구 - 개발 리스크 줄이는 단계 🗨️ 개발 전에 프로토타입으로 UX 리스크 줄이겠습니다.
UI (User Interface)	사용자가 제품과 상호작용할 때 접하는 시각적 요소와 인터페이스(사용자가 직접 조작하는 화면) → 버튼, 텍스트, 이미지 등 보이는 모든 것 [PM 관점 포인트] - UI는 단순 디자인이 아니라 행동 유도 수단 - 좋은 UI = 사용자가 고민 없이 행동함 - UX 문제의 일부는 UI에서 발견 🗨️ 이 UI에서는 사용자 시선 흐름이 끊깁니다.
UX (User Experience)	사용자가 제품/서비스를 이용하면서 겪는 전체적인 경험과 인식 → 사용자가 어떻게 느끼고, 얼마나 쉽게 목표를 달성하는가 [UX 구성 요소] - 사용성 (Usability) - 접근성 (Accessibility) - 일관성 (Consistency) - 효율성 (Efficiency) [PM 관점 포인트] - UX는 기능이 아니라 경험 설계 - 좋은 UX = 적은 생각 + 빠른 행동 - 퍼널, 리텐션과 직접 연결 🗨️ UX 개선하려면 플로우 단순화가 필요합니다.
Interaction (인터랙션)	사용자의 행동(입력)에 대해 시스템이 어떻게 반응하고 피드백을 주는지에 대한 설계 (사용자 행동 ↔ 시스템 반응의 방식) → 클릭, 스와이프 등에 대해 즉각적으로 반응하는 방식 [왜 중요한가?] - 인터랙션이 자연스러워야 UX가 좋아짐 - 피드백이 없으면 → “동작 안 하는 느낌” - 작은 인터랙션이 사용성 크게 좌우 [PM 관점 포인트] - 인터랙션 = 단순 애니메이션 아님 - 행동 유도 + 상태 전달 역할 - 퍼널 전환율에도 직접 영향 🗨️ 이 버튼은 인터랙션 피드백이 부족해서 클릭 여부가 불명확합니다.
Component (컴포넌트)	UI를 구성하는 요소를 재사용 가능하도록 나눈 독립적인 단위 (여러 화면에서 반복 사용되는 UI/기능 단위) [왜 중요한가?] - 디자인 일관성 유지 - 개발 생산성 ↑ (재사용) - 수정 시 전체 반영 가능 [PM 관점 포인트] - 기능 요청 시 “새로 만들지 / 기존 컴포넌트 재사용할지” 판단 중요 - 컴포넌트 많을수록 유지보수 효율 ↑ - 디자인 시스템과 연결됨 🗨️ 공통 컴포넌트로 분리해서 관리하는 게 좋겠습니다.
Design System (디자인 시스템)	제품 전반에 걸쳐 일관된 UI/UX를 유지하기 위해 컴포넌트, 스타일, 가이드라인을 체계화한 시스템( 디자인 + 컴포넌트 + 규칙의 집합) → 팀이 같은 기준으로 만들게 하는 공통 언어 [왜 중요한가?] - 일관성 유지 (브랜드 경험) - 작업 속도 ↑ (재사용) - 커뮤니케이션 비용 ↓ [PM 관점 포인트] - 기능 추가 시 디자인 시스템 준수 필요 - 디자인/개발 협업 기준점 - 시스템 없으면 → UI/UX 불균형 발생 🗨️ 개발과 싱크 맞추려면 디자인 시스템 기준으로 가야 합니다.
CTA (Call To Action)	사용자가 특정 행동(가입, 구매, 클릭 등)을 하도록 유도하는 버튼, 링크, 문구 등의 요소 → 행동을 끌어내는 트리거  [PM 관점 포인트] - CTA는 전환율과 직결되는 핵심 요소 - 위치, 문구, 디자인에 따라 성과 크게 변함 - 퍼널/유저 플로우와 반드시 연결되어야 함 🗨️ 현재 CTA는 사용자 의도를 충분히 반영하지 못하고 있습니다.
Error State (에러 상태)	시스템이나 사용자 입력에서 오류가 발생했을 때, 사용자에게 문제 상황과 해결 방법을 전달하는 UI/UX 상태 [왜 중요한가?] - 에러는 반드시 발생 → UX 품질 차이 만드는 포인트 - 잘못 설계하면 사용자 이탈 직결 - “문제 발생”보다 “대응 방식”이 중요 [PM 관점 포인트] - 정상 흐름만 설계하면 UX 불완전 - 에러 케이스까지 포함해야 실제 서비스 완성 - QA/디버깅과도 연결됨 🗨️ 에러 발생 시 다음 행동을 유도하는 UI가 필요합니다.

 

---

 

데이터베이스와 SQL, 엑셀과의 차이점

 

• 데이터베이스 개념 : SQL을 사용해, DBMS에 데이터를 구축, 관리하고 활용하기 위해서 사용하는 언어
  - DBMS를 통해 중요한 정보들을 입력, 관리하고 추출할 수 있음
• SQL : 직역하자면 '구조화된 질의 언어'/DBMS에서 사용하는 언어
  예)미국 문화(DBMS)를 완전히 이해하려면, 언어인 영어(SQL)를 먼저 배워야...

---

• file이 가진 보안, 편의성의 한계를 극복하기 위해서 고안된 전문화된 소프트웨어(데이터의 집합)
• 매우 방대한 기능을 가진 정보 도구(표면적이 넓음)
• 정보를 어떻게 입력(input)하고 어떻게 출력(output)할 것인가 따져봐야 함
  - input : 생성(create), 수정(update), 삭제(delete) 작업
  - output : 읽음(read) 작업
  → 위 4가지 방법은 앞글자를 따서 CRUD라고 부름(핵심 작업)
• SQL(관계형 데이터베이스) : 엑셀처럼 생김 + NoSQL(비 관계형 데이터베이스) : 복합구조로 이루어짐
  예) 엑셀 용어와 Mysql 용어 비교

/	Excel	SQL
표	sheet	table
열	column	column
행	row	row
차이점	작은 용량/수동 작업	대용량/자동화 가능/ 다양한 기능 사용 가

• 스프레드시트와 데이터베이스의 차이
  - 프로그래밍적으로 또는 컴퓨터 언어를 이용해서 데이터를 추가하고 수정하고 삭제하고 읽을 수 있음
  - 장점 : 자동화 가능(수동으로 작성하지 않고도 어떠한 조건에 따라서 자동으로 데이터를 생성하고
• 수정하고 삭제하고 읽을 수 있음
  - 권한 기능으로 여러 사람을 등록&관리할 수 있음
     · 예) A라는 사람은 B라는 부분만 수정할 수 있게/C라는 사람은 열람만 가능하게 차등적 권한 부여
  - 보안

 

• 데이터베이스, 스키마 : 서로 연관된 데이터(표)를 grouping할 때 사용하는 일종의 폴더
• 테이블(릴레이션) : 특정한 형태의 데이터로 이루어져 구조화된 목록(관련 데이터 항목의 모음)
• 식별자(Key) : 하나의 테이블에 있는 속성 중, 대표할 수 있는 속성
• 차수(Degree) : 테이블 내, 열의 수
• 카디널리티(Cadinality) : 테이블 내, 행의 수

 

• RDBMS : 관계형 데이터베이스 관리 시스템(소프트웨어)
  - 대용량
  - 여러 사용자와 공유+접속(ex. 은행 예금 계좌 데이터서비스)