[TIL] PM에게 필요한 IT 용어 정리

오늘은 보물찾기 형식을 통해 PM에게 필요한 IT 용어를 찾아보고 공부하는 시간을 가졌다.

귀여운 강아지나 작은 꽃이 퀴즈를 내준다

26가지의 퀴즈를 풀었는데, 알고 있는 용어도 있고 처음 접하는 용어도 있었다. 하나씩 정리해보려고 한다.

1. ROI(Return Of Investment)

— 투자 대비 수익률

비단 돈으로만 접근하는 것이 아니라, 투자한 시간이나 리소스 대비 아웃풋이 어떤지 이야기 할 때도 쓰인다.

예시: “이 프로젝트를 진행했을 때 ROI 나와요?”

2. WBS(Work Breakdown Structure)

— 업무 분류 체계, 복잡한 프로젝트 목표 달성을 위해 하위 작업 단위로 세분화한 구조도

프로젝트를 시작하기 전에 보통 엑셀 등으로 프로젝트를 작은 범위까지 나누고 RnR을 명시, 예상 기간 등을 적은 구조도다.

3. RnR(R&R, Roles and Responsibilities)

— 팀에서 각 구성원의 역할과 책임

예시: “이 프로젝트는 RnR을 확실히 하시죠”

위의 예시는 해당 프로젝트에서 어떤 사람이 어떤 일을 하는지 명확히 일의 구역을 나누자는 뜻이다.

4. QA(Quality Assurance)

— 개발이 완료되고 배포되기 전에 이상이 없는지 진행하는 테스트

삼성 같은 대기업은 QC라고도 표현한다. 큰 조직의 경우 QA 팀이 따로 있으며, 이 경우엔 PM이 특별히 QA 엔지니어가 신경써서 봐주어야 하는 것을 전달하는 것이 좋다. 별도의 팀이 없다면 PM이 QA 시나리오를 작성해 테스트한다.

5. AARRR(Acquisition — Activation — Retention — Revenue)

— Product에서 고객의 처음 방문부터 수익(결제)까지의 모든 여정을 추적하고 최적화하는 개념

Acquisition(획득) — Activation (활성화)— Retention(유지) — Revenue(수익)의 약자로, 마케팅에서도 많이 쓰인다.

6. EOD(End Of Day)

— 오늘까지 마감 기한을 뜻하는 축약어

예시: “이 문서 EOD까지 부탁드립니다”

위처럼 전달 받았을 경우, 오늘 퇴근 전까지 부탁한다고 이해하면 된다.

7. MVP(Minimum Viable Product)

— 서비스의 수요를 확인하고 피드백을 받아 개선할 목적으로 최소한의 기능만 담고 있는 제품

해당 프로덕트에서 검증하고 싶거나 핵심이 되는 기능만 넣어서 시장에서 검증받는 최소한의 제품 수준이다. POC와 비슷하나 MVP가 비즈니스 / PM단에서 더 많이 쓰인다.

8. PMF(Product Market Fit)

— 제품/ 서비스가 시장의 요구를 잘 충족시키는 상태, 제품이 시장과 핏이 잘 맞는지 확인하는 개념

PMF를 찾을 때까지 지속적으로 피봇하고 개선하는 작업을 한다.

9. Beta Test(베타 테스트)

— 최종 출시 전 실 사용자 혹은 일부 사용자에게 배포하여 버그, 오류, 개선점을 발견하게 하는 테스트

QA 이후에 진행되는 것이 보통이다.

10. POC(Proof of Concept)

— 아이디어나 프로덕트가 실제로 가능한 수준으로 작동하는지 검증하고 테스트하는 과정

보통 사내에서도 POC를 하지만, 회사끼리도 POC로 협업하는 경우가 있다.

11. 애자일(Agile)

— 작은 주기로 개발하며 처음 기획한 것, 처음 개발한 것을 고수하지 않고 유연하게 변경하는 프로젝트 진행 방식이자 개발 문화를 지칭

보통 ‘애자일하게’라고 표현한다면 짧은 주기로 개발하고 반응보고 개선한다는 뜻으로 이해하면 된다.

12. 스크럼(Scrum)

— 팀이 협력하여 프로젝트를 애자일하게 관리하는 방법론

빠른 사이클로 진행하는 프로젝트의 팀워크, 진행 상황을 극대화 하는 업무 진행 방식이다. 매일 혹은 주기적으로 프로젝트 진행 상황을 체크하는 미팅을 가지며 장애물이나 리스크를 확인한다.

13. 스프린트(Sprint)

— 보통 1~4주, 평균적으로 2주동안 진행되며 한 스프린트 내에 목표한 기능이나 작업을 완료 및 배포 가능한 상태로 만드는 업무 단위이다.

PM은 스프린트를 운영하는 사람이다. 스프린트를 진행할 때, 앞서 설명한 스크럼을 함께 돌리며 프로젝트를 진행한다.

14. 디자인 시스템

— 제품을 만들 때 사용하는 디자인 원칙, 규칙, 구성 요소를 체계적으로 정리한 디자인 가이드북

피그마에 디자인 시스템 폴더를 따로 만들어 놓는 경우가 많고, 해당 디자인 시스템에 따라서 이후 개선 작업이 진행될 때 폰트 크기, 버튼 모양 등을 따르게 된다.

15. Padding

— 텍스트와 이미지 사이의 여백, 컨텐츠와 컨텐츠 사이의 여백

16. 와이어프레임

— 웹이나 앱의 기초 설계도로, 레이아웃과 주요 기능을 가볍게 디자인한 초안

색상이나 이미지 같은 건 생략하고 뼈대만 그린 경우가 많다.

17. 프로토타입(Prototype)

— 제품의 초기 모형, 서비스 / 프로덕트의 초기 디자인

UI/UX를 확정하기 전에, 실제 서비스처럼 동작하게 제작한 시제품이다.

18. GUI(Graphical User Interface)

— UI보다 작은 단위로, 가벼운 아이콘 디자인이나 버튼 디자인을 의미한다.

19. GNB(Global Navigation Bar)

— 앱에서 맨 하단줄에 있는 내비게이션 바

GNB로 해당 서비스의 핵심 기능과 의도한 기능을 알 수 있으므로 매우 중요하다.

20. 클라이언트(Client)

— 서비스, 명령을 요청하는 쪽

유저단에서 보이는 영역이다. 일대일 맵핑은 어렵지만, 대략 프론트 화면이라고 이해할 수 있다.

21. 서버(Server)

— 유저에겐 보이지 않지만 Product가 돌아가기 위한 뒷 작업, 데이터를 처리하고 응답을 보내주는 쪽

클라이언트와 서버의 예시:

이커머스 애베서 사용자가 제품을 검색하면(클라이언트),

서버가 DB에서 보낸 정보를 찾아 결과를 보내고(서버),

보낸 데이터를 다시 유저의 화면에 보여준다(클라이언트).

22. SQL

— 데이터베이스에서 데이터를 저장, 조회, 수정, 삭제할 때 사용하는 언어

쉽게 말해, 데이터베이스에게 “필요한 데이터를 줘” 혹은 “이 데이터를 이렇게 바꿔줘”라고 명령하는 방법이다.

23. JSON

— 데이터를 교화나기 위해 사용하는 가볍고 읽기 쉬운 형식

사람에게는 읽기 쉽고 컴퓨터는 처리하기 쉬운 구조로, 키-값 쌍으로 데이터를 표현한다. 예를 들어, { “name” : “Alice”, “age” : 25 } 처럼 name이라는 항목 내에 Alice가 있고, 나이는 25세라는 것을 알 수 있다. DB 구조에 name과 age가 따로 있다는 것까지 유추해볼 수 있다.

24. DB(Data Base)

— 데이터를 체계적으로 저장하고 관리하는 공간

보통 행과 열로 구성되어있는 경우가 많고, 비정형일 경우 Mongo DB 같은 곳에 무작위로 저장하는데, 이 부분은 개발자와 논의하면서 해당 product의 DB 구조를 파악하는 것이 중요하다.

DB와 MongoDB는 따로 심화 정리해보았다. (링크)

25. 레거시

— 오래된 시스템, 기술, 코드 등을 의미

일반적으로 현재 사용 중이지만 유지보수하기 어렵거나 최신 기술과 호환되지 않는 경우를 가리킨다. 보통 ‘레거시 코드’라고 이야기 하는 것을 많이 들을 수 있다.

26. 디버깅

— 프로그램에서 발생하는 오류(버그)를 찾아내고 수정하는 과정

코드가 원하는 대로 작동하지 않을 때, 문제의 원인을 분석하고 해결책을 적용해 정상적으로 동작하도록 만드는 작업이다.

이번에 26가지 IT 용어를 정리하며 느낀 점은, 기획자에게 용어는 단순한 지식이 아니라 사고의 도구라는 것이다.

한 번 읽고 끝낼 수 있는 개념이 아니기에, 지속적으로 탐색하고 실제 서비스 맥락 속에서 이해해 나간다면 보다 정확한 언어로 문제를 정의하고 협업할 수 있는 기획자로 성장할 수 있을 것이라 생각한다.