노사수의 기획일기 | 서비스기획자, PM 홀로서기

AWS에서 자주 쓰는 주요 서비스 정리

노사수 — Mon, 23 Mar 2026 15:13:55 +0900

AWS를 사용하는 팀/회사의 경우라면 회의나 업무 시간에 AWS 관련 서비스 용어를 자주 접하게 된다. 기획 직군에 종사할 경우, 개발자들의 대화에서 어떤 주제로 이야기 하고 있는지 파악하기 위해서는 관련 용어를 미리 알아두면 좋을 것 같다.

AWS 주요 서비스 목록

1. 서버 / 실행

EC2: 가상 서버. 직접 서버를 띄워서 웹앱, API, 배치 작업 등을 운영할 때 많이 씀
Lightsail: 간편형 서버. EC2보다 단순해서 개인 프로젝트나 소규모 서비스에 적합
Lambda: 서버 없이 코드만 실행하는 서버리스. 간단한 API, 자동화, 이벤트 처리용

2. 저장소 / 데이터

S3: 파일 저장소. 이미지, 첨부파일, 백업, 정적 파일 보관용
RDS: 관리형 관계형 DB. MySQL, PostgreSQL 같은 DB 운영용

3. 네트워크 / 배포

VPC: AWS 내 네트워크 공간. 서버들을 어떤 망 안에 둘지 정하는 기본 구조
Route 53: 도메인과 DNS 관리
CloudFront: CDN. 정적 파일이나 이미지, 영상 등을 더 빠르게 전달

4. 권한 / 운영관리

IAM: 사용자·서버·서비스 권한 관리
CloudWatch: 로그, 모니터링, 알람 관리

[추천도서] 프로덕트 오너: 책을 통해 얻을 수 있는 값진 간접 경험

노사수 — Sun, 22 Mar 2026 23:04:41 +0900

기획자로 여러 회사에서 다양한 제품팀을 만나보지 못한 것이 혹시나 독이될까 우려수러워 다양한 커뮤니티에서 정보도 얻고 여러 책을 읽으며 간접 경험을 쌓으려고 노력했다.

서비스를 기획하다 보면 자주 드는 생각이 있다.

“이 기능이 정말 필요한가?”

“지금 이게 우선순위가 맞나?”

“우리는 왜 이걸 만들고 있지?”

김성한 저자의 『프로덕트 오너』는 이런 질문에 대해 다시 생각하게 해준 책이었다.

이 책을 읽으며 가장 크게 느낀 건, 프로덕트 오너는 단순히 할 일을 정리하는 사람이 아니라는 점이다.

무엇을 만들지보다, 왜 만들어야 하는지를 계속 붙들고 있는 사람에 더 가깝다.

특히 인상 깊었던 부분은 우선순위에 대한 관점이었다.

실무에서는 모든 요청이 다 중요해 보이지만, 결국 중요한 건 많이 하는 것이 아니라 제품 방향에 맞는 일을 하는 것이다.

이 책은 그 기준을 계속 점검하게 만든다.

또 하나 좋았던 점은 사용자 관점을 조금 더 현실적으로 보게 해준다는 점이다.

“사용자 입장에서 생각하자”는 말은 익숙하지만, 실제로는 기능 자체보다 사용자의 문제를 제대로 이해하고 있는가가 더 중요하다는 걸 다시 느꼈다.

읽고 나서 든 생각은 명확했다.

좋은 프로덕트 오너, 그리고 좋은 기획자는 정답을 빨리 내리는 사람보다 좋은 질문을 놓치지 않는 사람에 더 가깝다는 것이다.

저자가 다양한 기업의 PO로 근무하며 겪었던 에피소드나 그의 인사이트, 철학에 대해 간접적으로 경험할 수 있어 좋았고, 특히 기획 직군이 그들과 함께 협업하는 디자이너, 개발자를 바라보는 시선과 그들을 대하는 태도가 어때야 하는지 다시 한 번 깨달을 수 있었다.

기획자로서 제품의 방향, 우선순위, 사용자 문제를 더 깊게 고민해보고 싶다면 한 번쯤 읽어볼 만한 책이라고 느꼈다.

[추천도서] 린 스타트업: 서비스기획자, PM이 읽어야할 필독서

노사수 — Sat, 21 Mar 2026 15:56:46 +0900

기획자로 일하다 보면 열심히 기능을 정의하고, 화면을 설계하고, 우선순위를 정했는데도 막상 출시 후 반응은 기대와 다를 때가 있다.

우리는 정말 고객이 원하는 것을 만들고 있었을까?

린 스타트업은 이 질문에 대해 꽤 현실적인 답을 주는 책이었다.

특히 기획자 입장에서 이 책이 좋았던 이유는, 제품을 처음부터 완벽하게 설계하는 방식보다 빠르게 가설을 세우고, 검증하고, 수정하는 방식을 더 중요하게 보기 때문이다.

기획자는 “무엇을 만들지”보다 “무엇을 먼저 검증할지”를 배운다

기획자는 흔히 요구사항을 정리하고 기능을 설계하는 사람으로 보인다. 하지만 실제로는 그보다 더 앞단에서 고민해야 할 일이 많다.

이 문제가 진짜 문제인지
고객이 이 기능을 실제로 원하는지
지금 이 기능이 최우선인지
얼마나 작게 만들어도 검증이 가능한지

『린 스타트업』은 바로 이 지점을 계속 강조한다.

처음부터 완성도 높은 제품을 만드는 것이 아니라, 가장 작은 형태로 시장 반응을 확인하는 것이 중요하다고 말한다.

기획자 입장에서는 이 메시지가 특히 크게 다가온다. 왜냐하면 많은 조직에서 기획은 종종 “문서를 잘 만드는 일”로 오해되지만, 실제로 중요한 것은 정확한 문서보다 정확한 학습이기 때문이다.

MVP를 보는 시선이 달라진다

보통 MVP라고 하면 “기능이 부족한 첫 버전” 정도로 생각하기 쉽다. 그런데 이 책을 읽고 나면 MVP는 단순히 대충 만든 제품이 아니라, 가장 적은 비용으로 가장 중요한 가설을 검증하는 도구라는 점이 분명해진다.

이 관점은 기획자에게 꽤 큰 도움을 준다.

이 기능도 넣고 싶고, 저 예외 처리도 반영하고 싶고, 사용자 경험도 처음부터 완벽하게 만들고 싶다. 하지만 그렇게 하다 보면 정작 중요한 질문, “이 제품이 진짜 필요한가?”를 확인하기 전에 시간과 리소스를 너무 많이 써버리게 된다.

『린 스타트업』은 기획자에게 이렇게 묻는다.

지금 만들려는 이 기능이 정말 검증에 필요한가? 아니면 그냥 완성도를 높이고 싶은 마음 때문인가? 이 질문 하나만으로도 기획의 우선순위가 훨씬 선명해진다.

데이터와 학습을 중심으로 사고하게 된다

기획자는 종종 직관에 의존한다. 물론 경험에서 오는 감각은 중요하다. 하지만 감각만으로는 제품이 성공하는지 설명할 수 없다.

『린 스타트업』은 “만들기” 자체보다 학습을 더 중요한 성과로 본다.

기능을 출시했다는 사실보다, 그 기능을 통해 무엇을 배웠는지가 더 중요하다는 관점이다. 이건 기획자에게 아주 실용적인 태도를 준다.

예를 들어 어떤 기능을 출시했다고 하자. 이전에는 “출시했으니 일단 끝”이라고 생각했다면, 린 스타트업식 관점에서는 그 다음이 더 중요하다.

사용자는 실제로 이 기능을 썼는가
기대한 행동이 발생했는가
이탈률은 줄었는가
전환율은 올라갔는가
아니라면 무엇을 수정해야 하는가

즉, 기획자는 더 이상 기능의 설계자에만 머무르지 않고 가설을 운영하고 학습을 축적하는 사람이 된다.

실패를 덜 두려워하게 된다

기획 일을 하다 보면 실패는 꽤 무겁게 느껴진다. 열심히 준비한 프로젝트가 기대만큼 성과를 내지 못하면, 그 과정 전체가 잘못된 것처럼 느껴질 때도 있다.

그런데 『린 스타트업』은 실패를 다르게 해석한다.

실패는 무능의 증거가 아니라, 검증을 통해 잘못된 가정을 빨리 발견한 결과일 수 있다는 것이다.

이건 기획자에게 꽤 큰 위로이자 실무적인 태도 변화로 이어진다.

모든 것을 맞히려는 압박 대신, 틀릴 수 있다는 전제를 가지고 더 빨리 실험하는 쪽으로 사고가 바뀐다. 그 결과 기획도 훨씬 가벼워진다.

결국 기획자에게 필요한 건 ‘완벽한 정답’이 아니라 ‘빠른 학습’이다

『린 스타트업』을 읽고 가장 크게 남은 건 기획이란 결국 정답을 미리 알고 설계하는 일이 아니라, 불확실성 속에서 더 빨리 배우는 구조를 만드는 일이라는 점이었다.

특히 새로운 제품을 만들거나, 아직 검증되지 않은 기능을 기획하거나, 리소스가 제한된 환경에서 우선순위를 정해야 하는 기획자에게 이 책은 꽤 실질적인 도움을 준다.

무엇을 먼저 만들어야 하는지
무엇을 나중으로 미뤄도 되는지
어떤 지표를 봐야 하는지
실패를 어떻게 해석해야 하는지

이 질문들에 대해 한 번쯤 기준을 세우고 싶다면, 린 스타트업은 충분히 읽어볼 가치가 있다.

마무리

기획자는 종종 “문제를 정의하는 사람”이라고 말한다. 그런데 『린 스타트업』을 읽고 나면 한 가지가 더 보인다.

기획자는 문제를 정의하는 사람인 동시에, 가설을 검증하는 과정을 설계하는 사람이기도 하다.

그 관점에서 보면 이 책은 스타트업 창업자만을 위한 책이 아니라, 불확실한 제품과 시장을 상대해야 하는 모든 기획자에게 꽤 유용한 책이다.

TPS(Transaction per Second)란?

노사수 — Wed, 28 Jan 2026 13:53:00 +0900

TPS란 무엇인가?

개발자랑 얘기하다 보면 꼭 나오는 말이 있다.

“이 기능 TPS 얼마나 나와요?”

문과 입장에서는 대충 “빠르다는 건가?” 혹은 “서버 성능 얘긴가?” 이 정도로 들린다.

반은 맞다. 그런데 정확히는 ‘속도’라기보단 ‘처리량’에 가깝다.

TPS 한 줄 정의

TPS = 1초에 처리할 수 있는 요청 수

T : Transaction (요청)
P : Per (당)
S : Second (초)

**“이 시스템은 1초에 몇 명까지 상대할 수 있냐”**는 질문이다.

문과식 비유 ① : 은행 창구

은행 창구가 있다고 치자.

창구 직원 1명
한 사람 처리하는 데 5초

그렇다면,

1초에 0.2명
TPS = 0.2

직원 5명으로 늘리면?

1초에 1명
TPS = 1

즉, TPS는 직원이 얼마나 빠르냐가 아니라, 동시에 얼마나 많이 처리할 수 있는지를 의미한다.

문과식 비유 ② : 식당 주문

주문 하나 받는 데 10초
주방이 한 번에 10개 주문 처리 가능

→ 느려 보여도 TPS는 높을 수 있다

반대로,

주문은 빨리 받는데
주방이 하나뿐이면

→ TPS는 낮다

즉, “느린데 잘 버틴다” 혹은 “빠른데 잘 터진다”같은 말이 나온다.

TPS가 왜 중요하냐

사용자가 몰릴 때 버티는지

이벤트
할인
항공권 오픈
출근 시간대 트래픽

TPS가 낮으면?

로딩
오류
튕김

“서버가 터지느냐 마느냐”의 기준

개발자들이 말하는:

“이거 TPS 몇 잡고 설계했어요?”

는 사실

“사람 몰리면 욕먹을까?”를 묻는 말이다.

TPS ≠ 응답 속도

이게 제일 많이 헷갈린다.

응답속도: 한 명이 얼마나 빨리 처리되는가

TPS: 동시에 몇 명을 처리할 수 있는가

응답 1초 + TPS 1 → 줄 김
응답 3초 + TPS 100 → 안 터짐

실제 서비스에선 TPS가 더 중요한 경우가 많다.

실무에서 TPS는 이렇게 쓰인다

“이 기능은 TPS 10만큼만 허용”
“이 API는 TPS 제한 걸어야 함”
“배치로 돌리자 (TPS 아끼자)”

문과식 번역하면:

“한 번에 너무 많이 몰리면 안 되니까, 나눠서 처리하자”

개발자들이 TPS에 예민한 이유

TPS 초과 = 서버 과부하
과부하 = 장애
장애 = 공지 + 사과 + 야근

그래서 개발자는 TPS 얘기 나오면 표정이 진지해진다.

한 줄 요약

TPS는 ‘속도’가 아니라 ‘수용 인원’이다.

문과식으로 말하면

“이 시스템, 한 번에 몇 명까지 상대 가능?”

이 정도만 이해해도 개발자랑 얘기할 때 반은 먹고 들어간다.

스코프 크리프(Scope Creep)란?

노사수 — Fri, 31 Oct 2025 10:47:39 +0900

스코프 크리프란?

스코프 크리프(Scope Creep)는 프로젝트 진행 중, 처음 정의한 업무 범위(Scope)가 명확한 승인 없이 계속 확장되는 현상을 의미한다. 쉽게 말하면,

“애초에 하기로 한 범위 밖의 일이 계속 추가되는 상황”

대부분 일정 지연, 비용 증가, 품질 저하, 팀 번아웃을 일으킨다.

✅ 스코프 크리프가 왜 생길까? (원인)

요구사항 정의가 불명확함
이해관계자 요구/의견이 중간에 바뀜
PM의 조율/필터링 부족
의사결정 기록 부족 → 말로만 합의
고객/상사의 추가 요청 무분별 수용
팀 간 목표/방향 정렬 실패

✅ 어떤 문제가 생길까?

일정 지연
개발비/운영비 증가
품질 저하
설계/테스트 리소스 부족
팀 피로감 증가
책임 소재 불분명
제품 방향성 흐려짐

✅ 어떻게 예방할 수 있을까?

1) 초기 Scope 명확화

In-Scope / Out-of-Scope 정의
MVP 범위 확정

2) 요구사항 변경 프로세스

요청 → 영향도 분석 → 승인 → 반영

3) 요청 수락 기준 마련

사용자 가치 / 비용 / 난이도 고려

4) 문서화

의사결정 기록
Jira / Confluence 활용

5) PM의 역할 수행

“NO” 또는 “대신 ○○을 줄여야 한다”라고 말할 수 있어야 함

6) 우선순위 관리

기존 일정/범위와 트레이드오프 설정

7) Stakeholder Alignment

PO, Biz, Dev, Design 방향 맞추기

✅ 스코프 크리프는 항상 나쁜 걸까?

결과적으로는 No, 때로는 용자 가치를 높이는 방향의 변경이면 좋은 변화일 수 있다.

문제가 되는 건,

근거 없이, 우선순위 없이, 관리 없이 변경되는 것

즉, 나쁜 것은 변화 자체가 아니라, “관리되지 않은 변화(Unmanaged Change)” 이다.

✅ 이미 발생했다면? (대응 전략)

1) 사실 관계 정리

누가 / 무엇을 / 왜 변경하려는가

2) 영향도 분석

일정, 비용, 리소스, 리스크

3) 우선순위 재조정

기존 범위와 교환할 내용 결정

4) 승인 프로세스

Stakeholder 또는 PM/PO 결정

5) 문서 업데이트

스펙, Jira 티켓, 릴리즈 노트

✅ 예시로 보는 Scope Creep

초기 스코프

항공권 검색 + 예약

추가 요청

항공편 비교 기능도 추가하자
구매 완료 시 자동 메일 발송 기능을 추가하자
가격 추적 기능을 추가하자

→ 정당한 검토 없이 들어오면 Scope Creep

→ 일정 지연 + 집중력 상실

✅ PM 관점 한 줄 요약

PM의 일은 “전부 들어주는 사람”이 아니라,

우선순위를 정리하고 조율하는 것이다.

스코프 크리프는 자연스럽게 발생한다. 중요한 건 변화를 관리하는 태도다.

스코프 크리프는 PM이 초급 → 중급으로 으로 성장하는 과정에서 꼭 잡아야 하는 개념이다.

문서화
변경 관리
조율
우선순위
Alignment

이 다섯 가지가 프로젝트의 건강을 좌우한다.

핵심은, “변화를 금지”가 아니라 “변화를 관리”하는 것이다.

[AI 독학하기] 3. 바이브 코딩(Vive Coding)

노사수 — Sun, 27 Jul 2025 23:38:59 +0900

개발자가 아니라면 코딩은 어렵고 먼 이야기처럼 느껴지곤 한다. 하지만 최근에는 생성형 AI의 발전으로, 누구나 코드를 직접 쓰지 않고도 개발을 시작할 수 있는 시대가 열렸다. 그 중심에 있는 개념이 바로 바이브 코딩(Vive Coding)이다.

바이브 코딩, 정확히 어떤 개념일까?

바이브 코딩(Vibe Coding)은 공식 용어나 특정 브랜드명이 아니다.
GPT 같은 대형 언어모델을 활용해 자연어로 프로그램을 짜고 수정하고 완성해나가는 새로운 방식의 코딩 접근법을 뜻한다.

즉, 프로그래머처럼 문법을 일일이 외우기보다는,
“AI야, 이런 기능을 만들어줘”라고 말하고,
그 결과로 코드를 받아보며 피드백을 주고받는 흐름이다.

예를 들어,

“사용자 로그인 화면을 만들고 싶어”
→ GPT가 HTML과 JavaScript 코드 생성
→ “아이디 찾기 버튼도 넣어줘”
→ 버튼 코드 추가됨

이런 식의 ‘대화형 코딩’이 바로 바이브 코딩의 핵심이다.

바이브 코딩을 왜 주목해야 할까?

접근성	코딩을 배운 적 없어도 시작할 수 있음
빠른 실행	명령 → 결과까지 몇 초면 가능
피드백 학습	AI에게 왜 그런 코드인지 물어볼 수 있음
협업 도구	기획자·디자이너도 개발 흐름에 참여 가능

이제는 개발자만 코드를 이해하는 시대가 아니라, 누구나 ‘기능’ 단위로 직접 실험해볼 수 있는 환경이 된 것입니다.

어떤 툴을 사용할까?

바이브 코딩은 특정 앱이 아니라 어떻게 GPT를 쓰느냐에 가까운 개념이다.
다만 실습에 적합한 도구를 소개하자면 다음과 같다.

ChatGPT (gpt-4o 추천)

코딩 요청 + 수정 요청 가능
웹 기반, 별도 설치 불필요

VS Code + CodeGPT 플러그인

코드 편집기 안에서 바로 GPT 연결
실제 코드를 다뤄야 하는 경우 유용

Replit, Cursor, Gemini 등 개발 특화 AI툴

GPT 외에도 다양한 LLM을 이용한 툴 등장
실시간 실행과 디버깅 가능

바이브 코딩, 실제 흐름 예시

목표: 블로그 글 목록을 불러오는 웹페이지 만들기

“블로그 글을 목록 형태로 보여주는 웹페이지 코드를 만들어줘”
GPT가 HTML + CSS + JS 코드 생성
“각 글마다 썸네일 이미지도 보여줘” → 코드 수정
“폰트는 좀 더 부드럽게 바꿔줘” → CSS 조정
완성된 결과를 코드 편집기에서 붙여넣고 실행

이처럼 GPT를 통해 아이디어 → 구현까지의 간극을 빠르게 좁힐 수 있다.

단점이나 한계는 없을까?

물론 주의할 점도 있다.

코드 품질이 일정하지 않을 수 있음
→ GPT가 틀린 문법을 제안할 수도 있다.
모든 코드를 이해하지 않고 복붙만 하면 위험
→ 실행 전, 어떤 코드인지 해석해보는 노력이 필요하다.
보안 또는 민감한 시스템 코드엔 적합하지 않음
→ 학습에 쓰일 수 있는 민감한 데이터는 넣지 않는 게 좋다.

바이브 코딩은 어디까지나 ‘보조 도구’이지, AI가 모든 걸 완벽히 대신해주는 것은 아니다.

문과생에게 바이브 코딩이 갖는 의미

코딩을 전공하지 않아도, 기술 흐름을 이해할 수 있는 창구가 생겼다.
기획자, 마케터, 콘텐츠 크리에이터 등도 실제 작동하는 화면을 스스로 만들 수 있는 시대이다.
그리고 이 변화는 단지 개발자가 더 편해졌다는 차원이 아니라, 모든 창작자가 ‘코드’를 새로운 표현 도구로 쓸 수 있게 되었다는 것을 의미한다.

자주 묻는 질문

Q. GPT만 쓰면 되나? 따로 배워야 할 것도 있나?
→ 기본적인 HTML, JS 개념은 천천히 익히는 게 좋다. 이해 없이 결과만 붙여넣는 건 비효율적이다.

Q. 내 요청이 AI에게 잘 전달되지 않는다
→ “하고 싶은 일”을 구체적으로 표현하는 연습이 필요하다. 모호한 문장은 애매한 코드로 이어질 수 있다.

Q. 이게 진짜 실무에 쓰이나?
→ 초기 설계, 프로토타입, 테스트 코드, 자동화 스크립트 등엔 실제로 매우 자주 사용된다.

마무리하며

바이브 코딩은 AI와 사람 사이의 새로운 협업 방식이다.
GPT의 도움을 받아 코딩을 배우고, 구현하고, 문제를 해결하는 이 흐름은 앞으로 더욱 확장될 것이다.

“코딩은 복잡한 암기 게임이 아니라, 아이디어를 실현하는 언어다”라는 생각으로,
부담 없이 시작해보시길 추천한다.

[회고] 기능조직과 목적조직 경험담

노사수 — Sat, 5 Jul 2025 14:36:15 +0900

기능조직 vs 목적조직

조직을 어떻게 짜느냐에 따라 협업 방식, 속도, 책임 구조가 완전히 달라진다. 그중 가장 대표적인 두 가지 방식이 기능조직과 목적조직이다. 지난 번 성능우선주의와 고객우선주의 모두를 경험한 경험기를 작성했는데, 역시 운이 좋게도 동일한 제품을 기능조직에서, 목적조직에서 각각 기획해볼 수 있는 값진 경험을 했다. 우선 각각의 장단점과 실제 기업 사례를 통해 비교해고자 한다.

기능조직: 역할 중심 구조

기능조직은 기획팀, 개발팀, 사업개발팀, 마케팅팀처럼 기능별로 조직을 나누는 방식이다.
전문성을 키우고 일관된 프로세스를 유지하기에 적합하다.

장점

비슷한 일을 하는 사람끼리 모여 효율성 높음
역할과 책임이 명확함
전문성 강화 및 교육 시스템 구축 용이

단점

부서 간 소통과 협업이 어려움
전체 목표보다 부서 목표에 집중하게 됨
책임소재 불분명
의사결정 어려움
변화 대응 속도가 느릴 수 있음
사일로 현상 및 팀 이기주의 가능성

기업 예시: 시중은행, 전통적인 대기업

전통적인 금융 조직은 대게 기획, 마케팅, 영업, 리스크 등 기능별 본부로 나뉨
전통적인 대기업 역시 마케팅본부, 구매본부 등으로 기능 중심 구성

목적조직: 성과 중심 구조

목적조직은 제품, 고객, 지역, 프로젝트 등 어떤 ‘목표 대상’을 중심으로 나눈다.
하나의 팀에 기획, 디자인, 개발 등 다양한 기능이 함께 존재한다.

장점

목표 달성에 집중되므로 실행 속도 빠름
크로스기능 협업이 수월함
시장·고객 변화에 유연하게 대응 가능
빠른 의사결정
책임감과 동기부여

단점

기능 중복, 자원 낭비 가능성
기능별 전문성 관리 어려움

기업 예시: 스타트업, 애플

보통의 스타트업은 서비스별 하나의 독립적인 팀처럼 움직이는 경우가 많음 → 기능이 분산된 목적조직
애플은 ‘프로덕트 중심’ 조직으로, 아이폰, 맥, 애플워치 등이 각각 하나의 사업 단위로 운영됨

매트릭스 조직: 둘 다 섞은 하이브리드

요즘은 이 둘을 섞은 매트릭스 조직이 많음
예를 들어, 개발자는 개발팀(기능조직)에 소속되면서도 특정 제품팀(목적조직)에 파견돼 일하는 방식

기업 예시: 구글, 현대자동차

구글은 개발자들이 기능별 조직에 속하면서도 프로젝트별로 팀이 구성되어 목적 단위로도 움직임
현대차도 기능별 본부 구조지만, 전기차·자율주행 같은 목적 중심 태스크포스를 병행 운영

결론

안정성과 전문성이 중요하다면 기능조직
속도, 실행력, 시장 대응력이 중요하다면 목적조직
→ 결국 정답은 없고, 전략·문화·제품 특성에 따라 구조를 설계해야 한다. 다만 작은 규모의 IT 스타트업이라면 기능조직으로 팀 세팅을 한 경우 스타트업의 장점인 속도를 잃어버릴 수 있고 조직간의 경쟁 심화에 따른 정보 통제, 책임 떠밀기 등의 단점을 발견하는 것은 어렵지 않은 일이다. 왜 잘나가는 스타트업이 린 프로덕트 문화를 지향하는지는 곰곰히 생각해볼 필요가 있다.

[AI 독학하기] 2. 머신러닝(Machine Learning)과 딥러닝(Deep Learning)

노사수 — Sat, 5 Jul 2025 14:03:36 +0900

머신러닝과 딥러닝으로 자연어 처리하는 방법

전처리도 했고, 벡터화도 완료했다면 이제는 기계가 문장을 보고 뭔가 “판단”하거나 “생성”하는 단계
그 중심에 머신러닝(Machine Learning)과 딥러닝(Deep Learning)이 있음

머신러닝 vs 딥러닝 차이

항목	머신러닝	딥러닝
특징	규칙 기반 + 수작업 특징 추출	스스로 특징을 학습
예시 모델	Naive Bayes, SVM	RNN, LSTM, Transformer
장점	빠르고 단순	복잡한 문맥까지 처리 가능
단점	복잡한 문장에 약함	학습 시간이 오래 걸리고 데이터 많이 필요

주요 모델 소개

Naive Bayes

문장 안에 있는 단어들의 확률로 긍정/부정을 판단
예: “맛있다” 80%, “최고” 60% → 긍정일 확률이 높음

SVM (Support Vector Machine)

단어들의 벡터를 그래프로 그려서 경계선을 긋는 방식

RNN (Recurrent Neural Network)

문장을 왼쪽부터 차례로 읽으면서 기억함
“나는 오늘 기분이” → 다음에 “좋다” 올지 “나쁘다” 올지 예측

LSTM / GRU

RNN의 기억력 문제 보완한 모델
“나는 어제 너무 바빴고 오늘도…” → 맥락 기억하면서 분석

Transformer / BERT / GPT

요즘 주류!
문장을 한 번에 전체적으로 보고 의미 파악함
속도도 빠르고 문맥 이해도 정확

요약

모델	이해방식	장점	단점
Naive Bayes	단어 확률	빠름	문맥 무시
RNN	순차적으로 기억	흐름 이해	기억 약함
LSTM	기억력 강화	긴 문장도 OK	느림
Transformer	모든 단어 관계 계산	정확도&속도 최고	구조 복잡

언제 어떤 모델을 쓰냐?

간단한 분류 → Naive Bayes, SVM
긴 문장 감정 분석 → LSTM
번역/요약/질문응답 → Transformer 기반 (BERT, GPT 등)

정리

자연어처리는 “사람 말”을 기계가 이해하게 하는 일
그 중심엔 머신러닝/딥러닝 모델이 있고 지금은 Transformer 기반이 대세

[AI 독학하기] 1. 자연어 처리(NLP, Natural Language Processing)

노사수 — Fri, 4 Jul 2025 22:58:13 +0900

자연어처리란?

사람의 언어(말이나 글)를 컴퓨터가 이해하고 처리하게 만드는 기술

쉽게 말해, 사람의 언어를 이해하는 컴퓨터, 언어로 소통하는 인공지능 등을 만드는 게 자연어처리.

자연어처리 대표 기술

토큰화 (Tokenization)	문장을 단어/문장 단위로 쪼갬	"나는 밥을 먹었다" → ["나는", "밥", "먹었다"]
품사 태깅 (POS tagging)	각 단어의 품사 파악	"먹었다" → 동사
개체명 인식 (NER)	사람, 장소, 조직 등 찾아냄	"이순신은 조선 장군이다" → 이순신: 인물
문장 분류 (Text classification)	감정 분석, 카테고리 분류 등	"좋아요!" → 긍정
질의응답 (QA)	질문에 대한 답변 생성	"한글 만든 사람?" → 세종대왕
요약 (Summarization)	긴 텍스트 요약	기사 → 한 문장 요약
번역 (Translation)	한 언어 → 다른 언어	"Hello" → "안녕"
텍스트 생성 (Text generation)	문장을 이어서 생성	GPT, ChatGPT, Claude 등

예시 1: "오늘 날씨 어때?" → 날씨 알려주는 AI

날씨 앱에 아래와 같이 질문을 하면

"오늘 우산 챙겨야 해?"

자연어처리 기술은 이 문장을

질문인지
날씨에 대한 건지
우산 관련된 건지

파악해서,

"네, 서울은 오후에 비가 올 예정이에요."

라는 답변을 제공

예시 2: 유튜브 자동 자막

유튜브 보다가 영어 자막, 한국어 자막 자동으로 생기는 기술

사람이 말한 음성 → 글자로 바꾸기 (음성인식)
영어를 → 한국어로 바꾸기 (번역)
→ 이 두 가지도 전부 자연어처리

예시 3: 고객센터 챗봇

쇼핑몰 고객센터에 "반품하고 싶어요" 라고 입력하면,

"주문하신 상품을 선택해주세요. 반품 사유도 알려주세요."

라는 식으로 대답하는데, 이 또한 고객의 말 속에서 핵심 의도를 파악해서 반응하는 자연어처리의 기술

예시 4: 스팸 문자 자동 분류

“~대출 한도 조회 가능” 등의 스팸 문자,
문자의 말투, 단어, 문장 구조 등을 보고 컴퓨터가 스팸 메시지를 분류

예시 5: 감정 분석

리뷰나 댓글에서

“진짜 최고예요!” → 긍정
“다신 안 사요.” → 부정

이렇게 감정까지 분석해서, 마케팅에 활용

자연어처리(NLP) 기본 흐름

입력 수집 (Input)

예시: 텍스트, 음성 등
텍스트 입력: 이메일, 댓글, 뉴스기사
음성 입력: 대화, 전화 녹음 등

전처리 (Preprocessing)

문장을 컴퓨터가 처리하기 쉽게 정리
대표 작업:
- 토큰화(Tokenization): 문장을 단어/문장 단위로 자르기
- 정제(Cleaning): 특수문자 제거, 소문자 통일
- 불용어 제거(Stopword Removal): “은”, “는”, “이”, “가” 등 의미 적은 단어 제거
- 형태소 분석(Morphological Analysis): 어근, 품사 분석

벡터화 (Vectorization)

단어를 숫자로 바꾸기
예: Bag of Words, TF-IDF, Word2Vec, BERT 등

모델 처리 (Modeling)

머신러닝 or 딥러닝 모델로 분석/예측
예: 감정 분석, 문서 분류, 요약, 번역 등

출력 결과 (Output)

결과를 사람이 이해할 수 있게 표현
예: 긍정/부정, 분류 결과, 요약문, 응답 문장

자연어처리의 진짜 힘

예전엔 사람이 직접 일일이 판단하던 것들을 이젠 기계가 사람처럼 말하고, 읽고, 알아듣고, 요약까지 가능

기자 대신 기사가 요약되고
상담사 대신 AI가 응대하고
외국어 대신 자동번역기가 도와주고

자연어처리는 우리의 일상 속 '언어 감각 있는 AI'를 만드는 기술

[회고] 성능중심과 고객중심 사이에서 기획자의 고민거리

노사수 — Tue, 1 Jul 2025 00:31:55 +0900

성능우선주의와 고객우선주의

한 회사에서 기획자로 근무하면서 성능을 중시 조직과 고객 편의성을 중시하는 성향이 다른 두 조직에서 기획 업무를 경험할 수 있었다. 개발자가 PM인 B2B SaaS 제품팀, BDM이 팀장인 B2C 제품팀이였다. 각각 기획해볼 수 있었다. 우선 두 개념에 대해 대해 정리해보자면 다음과 같이 요약해볼 수 있다.

성능우선주의 (Performance-first)

핵심 가치: 기술적 완성도, 속도, 효율성, 안정성
예시: 빠른 응답속도, 적은 리소스 사용, 최대 성능 달성
장점: 기술적 우수성 확보, 경쟁력 있는 퍼포먼스
단점: 고객의 실제 니즈나 사용성은 뒷전이 될 수 있음

고객우선주의 (Customer-first)

핵심 가치: 고객 만족, 사용성, 문제 해결
예시: 사용하기 쉬운 UI, 친절한 안내, 피드백 기반 개선
장점: 충성 고객 확보, 제품 사용 지속성 증가
단점: 성능이나 기술적 완성도가 떨어질 수 있음

차이 요약

초점	기술/속도/안정성	고객경험/니즈/만족
주 타깃	개발자, 엔지니어링 관점	사용자, 마케팅 관점
방향성	“빠르고 완벽하게”	“쉽고 친절하게”
위험 요소	사용성 무시	기술적 한계 발생 가능

쉽게 말해 시스템 안정성에 무게를 두느냐, 고객 편의성에 무게를 두느냐에 대한 차이이다. 둘 다 중요하지만 둘 다 챙기기 어려운 부분이기도 하다.

실제 사례

성능우선주의 사례

Google 검색

핵심 가치는 “빠른 결과 제공”
페이지가 로딩되기 전에 검색 결과를 먼저 뿌릴 정도로 성능 최적화에 집중
광고 배치도 사용자 흐름 방해 최소화에 초점

AWS

개발자·기업 대상 (B2B 서비스)
기능 UI는 투박해도, 속도/안정성/확장성이 절대적 강점
콘솔 사용성이 불편하다는 의견 있음 → 고객우선보다 성능 중심

Zoom (초기)

팬데믹 초기에 Teams, Skype, Hangout보다 훨씬 안정적인 영상 품질 제공
UX는 투박했지만 “끊기지 않고 잘 되는 서비스”로 각광

고객우선주의 사례

Apple

성능보다 UX 중심: “누구나 직관적으로 쓸 수 있게”
심지어 사양 낮은 기기에 최신 OS를 배포할 때도 UX 우선순위로 결정
설정보다 기본값(Default)을 중요하게 설계

Airbnb

호스트/게스트 모두의 여정을 상세하게 설계
수많은 A/B 테스트, 피드백 기반 반복 개선 → 전형적인 고객우선 전략
안정성(서버 퍼포먼스)은 뒷단에서 커버하되 겉으론 '경험' 중심

토스

보안이나 기술적으로도 잘 되어 있지만, 진입 장벽 낮춤에 초점
"처음 쓰는 사람도 헷갈리지 않게" → UI/UX 간결하게
고객이 원하는 흐름대로 흘러가게 하고, 기술적 복잡성은 내부에서 해결

기획자/PM 입장에서 밸런스 잡는 팁

정확히 무 자르듯 이야기 할 순 없겠지만, 제품에 따라 아래와 같은 기준을 적용하면 고민의 시간을 줄일 수 있다.

B2B 제품은 성능 7 : 고객 3
B2C 제품은 고객 7 : 성능 3

B2B 기획 시

B2B 제품의 경우 성능, 최적화, 속도에 중점을 두며 버그를 최소화 하면 고객 만족도를 높일 수 있다. 사용감이 불편하고 직관적이지 않더라도 사용자 매뉴얼 제공, 반복 사용을 통해 제품에 익숙해질 수 있기 때문이다. 보통 B2B 제품은 계약에 따라 다르지만 한 번 계약 시 lock-in되는 경향이 강하기 떄문에 고객이 버그 없이 온전히 업무에 집중할 수 있는 환경을 제공해야 한다.

B2C 기획 시

반면 B2C의 경우, 유저는 첫 사용부터 이용에 불편함을 겪을 경우 당장 이탈로 이어질 수 있다. 커머스라면 구매 과정에서의 불편함을 최소화하고 편의성을 위해 엣지 케이스까지 대응할 필요가 있다.

제품 구분에 따른 밸런스가 중요

앞서 서술한 것과 같이 성능과 최적화에만 신경쓰다보면 고객 편의성에 대한 중요도가 상대적으로 낮아져 사용성 저하로 이어질 수 있으며 API 스펙이나 개발 리소스를 산정하지 않고 무한한 상상력을 발휘해 기획할 경우 마감 기한에 허덕이다가 제품이 불안정한 상태로 배포될 수 있다. 그렇기 때문에 PM은 성능과 사용성 두 가지 밸런스를 잘 조율하는 역할에 충실해야 한다.

세계 주요 개인정보 보호법: GDPR, CCPA 등

노사수 — Mon, 26 May 2025 19:00:22 +0900

디지털 환경에서 개인정보 보호는 이제 선택이 아닌 필수이다. 유럽의 GDPR 이후 전 세계적으로 개인정보 보호 규제가 빠르게 강화되고 있으며, 각국은 자국민의 데이터를 보호하고 데이터 주권을 확보하기 위해 독자적인 법률 체계를 마련하고 있다.

각국 개인정보 보호법 비교 표

국가법명주요 특징시행 연도비고

EU	GDPR (General Data Protection Regulation)	엄격한 동의 기반, 위반 시 고액 과징금	2018	글로벌 표준 역할
미국 (CA)	CCPA (California Consumer Privacy Act) / CPRA	옵트아웃 중심, 소비자 권리 강화	2020 / 2023	주 단위 법, 점차 확대 중
브라질	LGPD (Lei Geral de Proteção de Dados)	GDPR 기반 구조, DPO 지정 의무	2020	라틴아메리카 대표 사례
중국	PIPL (Personal Information Protection Law)	데이터 국외 이전 제한, 민감정보 구분	2021	통제가 강한 구조
일본	APPI (Act on the Protection of Personal Information)	EU 적정성 인정, 명확한 이용 목적 고지 요구	2003 → 개정 지속	아시아권 선도 국가
한국	PIPA (Personal Information Protection Act)	GDPR 유사 구조, 최근 개정으로 강화	2011 → 2023	AI/클라우드 환경 대응 중
캐나다	PIPEDA (Personal Information Protection and Electronic Documents Act)	민간 기업 중심, 옵트인 기반	2000	개정 논의 진행 중
호주	Privacy Act	연매출 기준 적용, 위반 시 보고 의무	1988 → 개정 중	기업 규모에 따라 적용 차이

법안별 핵심 비교 포인트

적용 범위
- 대부분 자국민 대상이지만, GDPR·PIPL·LGPD는 해외 기업에도 적용.
개인정보의 정의 및 민감정보 구분
- 각국 기준이 상이하며, 중국과 한국은 생체정보, 위치정보 등을 민감정보로 별도 분류.
정보주체의 권리
- 열람, 정정, 삭제, 처리 제한, 이동권 등 대부분 공통되나, 미국은 일부 권리만 보장.
국외 전송 조건
- GDPR은 ‘적정성 결정’ 또는 표준계약 필요.
- 중국은 매우 엄격한 심사와 허가 요구.
- 한국, 일본도 일정 조건 하에 국외 전송 가능.
제재 수위
- GDPR은 최대 글로벌 매출의 4%까지 과징금 부과 가능.
- 중국 PIPL도 벌금 한도가 매우 높음.
- 한국, 브라질, 일본도 점차 과징금 기준 강화 중.

기업이 고려해야 할 점

글로벌 서비스를 운영하는 기업이라면 단순히 GDPR만 준비해서는 부족하다. 국가별 개인정보 법제를 이해하고, 각 규정에 따라 적절한 동의 수단과 처리 방식을 갖추는 것이 중요하다.

또한 다음과 같은 포인트도 고려해야 한다:

개인정보 수집 최소화 및 목적 명확화
수집 동의 절차의 투명성
이용자 권리 보장을 위한 내부 절차 정비
국외 데이터 이전 시 법적 검토 및 계약 체결

마무리하며

개인정보 보호는 규제를 피하기 위한 법적 요건 그 이상으로, 사용자의 신뢰를 얻고 서비스의 지속 가능성을 확보하는 핵심 전략 중 하나라고 볼 수 있다. 특히 AI, 빅데이터, 클라우드 서비스가 확대되는 시점에 개인정보 보호에 대한 글로벌 대응력은 기업의 경쟁력을 좌우하는 요소가 될 수 있다.

공수 산정 방법론: 스크럼 포커(Scrum Poker)

노사수 — Tue, 20 May 2025 19:00:04 +0900

스크럼 포커(scrum poker)

개요

스크럼 포커(Scrum Poker) 또는 플래닝 포커(Planning Poker)는 애자일 팀이 작업 항목(User Story)의 난이도나 복잡도를 추정할 때 사용하는 협업 기반 추정 기법이다. 시간 단위 대신 스토리 포인트라는 상대적 기준을 사용하고, 각 팀원이 숫자 카드를 비공개로 제시한 뒤, 의견 차이가 있으면 토론 후 재조정하는 방식이 핵심이다.

유래

스크럼 포커는 2002년 애자일 방법론 전문가 Mike Cohn이 제안했으며 전통적 일정 추정 방식(팀장이 대충 정함)은 아래와 같은 문제점이 발생한다.

과소추정 / 과대추정 빈번
팀원들은 눈치 보며 동의하거나 입을 닫는 경우
강압적인(말도 안 되는) 산정

그래서 나온 해결책이 스크럼 포커(혹은 플래닝포커) 방식이다.

“모든 팀원이 각자의 관점에서 자유롭게 숫자를 제시하고,
차이가 크면 이야기해보는 방식.”
→ 이를 통해 민주적인 추정, 토론 기반의 공감이 가능해졌으며 납득 가능한 기간 산정이 가능해진다.

진행 방식

스크럼 포커는 보통 다음처럼 진행된다.

작업 항목 설명: PO나 PM이 기능을 설명
개별 추정: 팀원 각자가 숫자 카드(보통 피보나치수열 기반)를 선택
동시 공개: 동시에 카드 오픈
차이 토론: 추정 값 차이가 클 경우, 왜 그렇게 봤는지 서로 설명
재투표: 필요하면 다시 추정해서 결정

숫자는 보통 1, 2, 3, 5, 8, 13, 21 등 피보나치수열 사용
→ 차이가 클수록 논의 필요성이 크다는 뜻이다.

장단점

장점

눈치 보지 않고 솔직하게 추정 가능 (비공개 투표)
팀원 전체가 기능 이해도를 맞출 수 있음
토론을 통해 숨은 리스크, 사각지대 발견 가능
추정에 대한 책임과 참여감을 함께 가짐

단점

추정치 = 시간 아님 → 일정으로 오해하지 말 것
토론이 너무 길어지면 오히려 비효율
스토리 포인트 기준이 팀마다 달라 외부 비교 어려움
초보 팀에게는 학습 비용(러닝커브) 있음

사용 예시

실전 사용 예시

프론트엔드 개발자가 UI 기능의 복잡도를 추정할 때
백엔드 API 개발팀이 여러 스토리를 정리할 때
QA, 디자이너 포함한 전체 스프린트 플래닝 미팅에서
온라인 도구 사용: Jira 내 플러그인, PlanningPoker.com, Miro 등

마무리

아무리 좋은 방법론일지라도 팀에 맞는 방식은 따로 있는 법이다. 우리 팀에 맞는 방식인지 시도해 보고 개선해 가며 다양한 방법론을 시험해 보는 것이 중요하다.

DTO(Data Transfer Object)란? 문과생도 이해할 수 있는 초간단 설명

노사수 — Thu, 16 Jan 2025 19:00:02 +0900

오늘은 "DTO"라는 개발 용어를 문과생도 쉽게 이해할 수 있도록 풀어서 설명하려고 합니다. 개발자와 협업 할 때 이런 기본 개념을 알면 의사소통도 훨씬 수월해질 수 있습니다.

1. DTO의 정의: 데이터 전달용 '포장 상자'

DTO는 Data Transfer Object의 약자입니다. 한마디로 "데이터를 전달하기 위한 객체(포장 상자)"입니다.
쉽게 말해, 서버(백엔드)와 사용자(프론트엔드)가 데이터를 주고받을 때 쓰는 정해진 형식의 데이터 묶음입니다.

2. 일상 속 예시로 보는 DTO

예시: 온라인 쇼핑몰에서 주문하기

쇼핑몰에서 티셔츠를 주문했다고 가정해봅시다.
티셔츠를 담은 박스에 송장(주소, 주문자 정보, 연락처 등)을 붙여 택배 회사가 집까지 전달해줍니다.

여기서,
- 티셔츠는 전달해야 할 "실제 데이터"입니다.
- 박스는 데이터를 담아 전달하기 위한 DTO입니다.
- 송장 정보는 데이터의 구조(주소, 이름, 연락처 등 필수 항목)입니다.

즉, DTO는 데이터를 담는 포장 상자와 비슷한 역할을 합니다.
이 "포장 상자"가 없다면 데이터가 제대로 전달되지 않거나, 뒤죽박죽 엉망이 될 수 있습니다.

3. 왜 DTO가 중요한가요?

1) 명확한 데이터 구조 제공

DTO는 어떤 데이터가 주고받아질지 미리 정해져 있습니다.
- 예: {"name": "홍길동", "email": "hong@example.com", "age": 30}
정해진 데이터 구조 덕분에 서버와 클라이언트(웹, 앱) 간 데이터가 일관되게 전달됩니다.

2) 불필요한 데이터 보호

DTO는 필요한 데이터만 담아서 전달합니다.
예: 사용자 비밀번호, 내부 시스템 정보 등 민감한 데이터는 DTO에서 제외할 수 있습니다.
덕분에 보안도 강화됩니다!

3) 데이터 가공을 쉽게 처리

DTO는 서버에서 데이터를 미리 정리해 깔끔한 형태로 전달합니다.
예: "2025-01-16T10:00:00" 같은 복잡한 날짜를 "2025년 1월 16일"로 변환해서 보낼 수 있습니다.

4. DTO와 관련된 용어 알아두기

1) 도메인 모델

데이터베이스에서 쓰는 "진짜 데이터"를 가리킵니다.
예: 쇼핑몰의 "사용자 정보", "주문 정보" 등.

2) DTO와 도메인 모델의 차이

도메인 모델: 데이터베이스에서 직접 가져온 원본 데이터
DTO: 원본 데이터를 가공해서 전달용으로 만든 포장된 데이터

3) API와의 관계

API(애플리케이션 프로그래밍 인터페이스)는 서버와 클라이언트가 데이터를 주고받는 통로입니다.
DTO는 API가 데이터를 주고받을 때 쓰는 형식입니다.

5. DTO의 실제 사례

사례: 사용자가 회원가입할 때

사용자가 웹사이트에 입력한 정보
- 이름: 홍길동
- 이메일: hong@example.com
- 비밀번호: 123456
서버에서 필요한 DTO 구조

{
  "name": "홍길동",
  "email": "hong@example.com"
}

비밀번호는 민감한 데이터이므로 DTO에는 포함하지 않음.

DTO 없이 데이터를 보낸다면?
데이터 구조가 뒤죽박죽되어 서버가 읽을 수 없거나, 불필요한 데이터까지 포함되어 보안 문제가 생길 수도 있습니다.

6. 문과생이 알아야 할 요점 요약

DTO는 데이터를 담는 '포장 상자'로 이해하세요.
정해진 형식으로 서버와 앱/웹이 데이터를 주고받을 수 있게 해줍니다.
보안과 데이터 관리의 핵심 도구로, IT 팀과의 소통에서 중요한 개념입니다.

7. 마무리: 왜 알아두면 좋을까?

IT와 협업하거나 데이터 관련 업무를 하다 보면, DTO라는 용어를 꼭 듣게 됩니다.
DTO는 프로그래밍의 복잡한 개념처럼 보이지만, 본질적으로는 데이터를 잘 전달하기 위한 간단한 포장 상자에 불과합니다.

컨트롤러(Controller)와 서비스(Service)의 이해

노사수 — Tue, 26 Nov 2024 09:58:43 +0900

1. Controller

개념

애플리케이션의 입구 역할을 함.
사용자의 요청(Request)을 받아서, 이를 처리할 적절한 로직(Service)으로 전달.
HTTP 요청과 응답을 관리.

용도

URL 라우팅과 요청 처리.
요청 파라미터 검증(Validation).
적절한 Service를 호출하여 비즈니스 로직 수행.
Service에서 처리된 결과를 클라이언트에게 반환(Response).

예시 (Node.js/Express):

// controller/userController.js
const userService = require('../service/userService');

exports.getUser = async (req, res) => {
    const userId = req.params.id;
    const user = await userService.findUserById(userId);
    res.status(200).json(user);
};

2. Service

개념

비즈니스 로직을 처리하는 계층.
데이터베이스 작업이나 외부 API 호출 등 실제 처리해야 할 작업을 수행.
Controller는 Service에 로직 처리를 위임하고, Service는 구체적인 일을 함.

용도

비즈니스 규칙 구현.
데이터베이스 쿼리 호출.
외부 API와의 통신.
여러 도메인 로직을 조합하여 작업 처리.

예시 (Node.js):

// service/userService.js
const User = require('../models/user');

exports.findUserById = async (userId) => {
    return await User.findById(userId); // DB에서 사용자 정보 조회
};

3. Controller와 Service의 차이

구분	Controller	Service
주요 역할	요청 처리, 라우팅	비즈니스 로직 처리
관심사	요청과 응답, API 인터페이스	데이터 처리 및 도메인 로직
연결 대상	클라이언트 ↔ Service	Controller ↔ 데이터베이스/외부 시스템
위치	애플리케이션의 프레젠테이션 계층	애플리케이션의 도메인 계층

4. 왜 분리해야 할까?

관심사의 분리(SOC)

Controller는 클라이언트와의 상호작용에 집중. Service는 비즈니스 로직 구현에 집중.

재사용성 증가

Service는 다양한 Controller에서 재사용 가능.

유지보수성 향상

로직이 명확히 분리되어 있어서 디버깅 및 코드 수정이 쉬움.

5. 실제 예시:

요청: 특정 사용자의 프로필을 가져오는 API

Controller:
클라이언트의 요청을 받고 적절한 Service를 호출.
Service:
사용자 데이터 조회 로직 수행(DB에서 조회).

예시:

// Controller
exports.getUserProfile = async (req, res) => {
    const userId = req.params.id;
    try {
        const profile = await userService.getUserProfile(userId);
        res.status(200).json(profile);
    } catch (error) {
        res.status(500).json({ error: error.message });
    }
};

// Service
exports.getUserProfile = async (userId) => {
    const user = await User.findById(userId);
    if (!user) {
        throw new Error('User not found');
    }
    return { name: user.name, email: user.email };
};

요약

Controller는 클라이언트와 상호작용, Service는 실제 처리를 담당.
분리함으로써 코드의 유지보수와 재사용성이 향상됨.

로드 밸런서(Load Balancer)란? 고가용성과 성능 최적화를 위한 핵심 기술

노사수 — Tue, 3 Sep 2024 21:28:15 +0900

1. 로드밸런서의 정의

로드 밸런서(Load Balancer)는 네트워크 트래픽을 여러 서버로 분산하여 시스템의 성능과 가용성을 최적화하는 장치 또는 소프트웨어입니다. 로드 밸런서는 들어오는 요청을 여러 서버로 고르게 분산시켜, 각 서버가 과부하 상태에 빠지지 않도록 하고, 장애가 발생할 경우에도 서비스가 지속되도록 합니다.

2. 주요 역할과 기능

트래픽 분산:
- 로드 밸런서는 클라이언트의 요청을 여러 서버에 고르게 분배하여 특정 서버에 부하가 집중되는 것을 방지합니다. 이를 통해 전체 시스템의 성능을 향상시키고, 서버의 자원을 효율적으로 활용할 수 있습니다.
고가용성:
- 로드 밸런서는 서버 중 하나가 장애가 발생하더라도, 다른 정상적인 서버로 요청을 자동으로 전환함으로써 서비스의 지속성을 보장합니다. 이를 통해 서버 장애에도 불구하고 서비스가 중단되지 않도록 합니다.
세션 유지:
- 상태가 있는 세션을 사용하는 웹 애플리케이션에서는 동일한 클라이언트의 요청이 항상 같은 서버로 전달되도록 세션 유지(세션 지속성)를 제공할 수 있습니다. 이를 통해 사용자는 로그인 상태를 유지하거나, 특정 서버에 저장된 데이터를 지속적으로 접근할 수 있습니다.
보안 강화:
- 로드 밸런서는 클라이언트와 서버 간의 트래픽을 모니터링하고, 악의적인 공격을 방어하는 기능을 제공할 수 있습니다. 또한 SSL 인증서를 통해 HTTPS 트래픽을 처리하여, 클라이언트와 서버 간의 데이터가 암호화된 상태로 전송되도록 보장합니다.
스케일링 지원:
- 로드 밸런서는 수평 확장(스케일 아웃)을 지원하여, 트래픽이 증가할 때 서버를 추가하여 시스템의 처리 능력을 확장할 수 있습니다. 이로 인해 서비스가 더 많은 사용자에게 원활하게 제공될 수 있습니다.

3. 로드 밸런싱 알고리즘

로드 밸런서는 여러 가지 알고리즘을 사용하여 트래픽을 분산시킵니다. 주요 알고리즘은 다음과 같습니다:

라운드 로빈(Round Robin): 각 서버에 순차적으로 요청을 분배하는 가장 단순한 방법입니다.
가중 라운드 로빈(Weighted Round Robin): 각 서버에 가중치를 부여하고, 가중치에 따라 요청을 분배합니다. 서버의 성능에 따라 더 많은 트래픽을 처리할 수 있습니다.
최소 연결(Least Connections): 현재 가장 적은 연결을 처리 중인 서버로 요청을 전달합니다.
IP 해시(IP Hash): 클라이언트의 IP 주소를 해싱하여 요청을 특정 서버로 보내는 방식입니다. 세션 지속성에 유리합니다.

4. 로드 밸런서의 종류

로드 밸런서는 하드웨어 및 소프트웨어로 구현될 수 있으며, 클라우드 기반으로도 제공됩니다:

하드웨어 로드 밸런서: 전용 하드웨어 장비로, 높은 성능과 다양한 기능을 제공하지만 비용이 높습니다.
소프트웨어 로드 밸런서: NGINX, HAProxy와 같은 소프트웨어 솔루션으로, 유연성과 비용 효율성을 제공합니다.
클라우드 로드 밸런서: AWS, Azure, Google Cloud에서 제공하는 로드 밸런싱 서비스로, 자동 확장 및 관리가 용이합니다.

5. 결론

로드 밸런서는 대규모 웹 애플리케이션에서 필수적인 요소로, 시스템의 성능, 안정성, 확장성을 보장하는 데 중요한 역할을 합니다. 트래픽의 효율적인 분산, 장애 대응, 그리고 확장성을 통해 사용자에게 끊김 없는 서비스를 제공할 수 있습니다.

웹소켓(WebSocket)의 정의, 사용처, 구현 방식

노사수 — Tue, 3 Sep 2024 21:19:04 +0900

1. 웹소켓이란?

웹소켓(WebSocket)은 HTML5에서 소개된 통신 프로토콜로, 클라이언트와 서버 간의 전이중(Full-Duplex) 통신을 가능하게 합니다. 전통적인 HTTP 통신 방식은 클라이언트가 요청을 보내면 서버가 응답을 보내는 반이중(Half-Duplex) 방식입니다. 반면, 웹소켓은 초기 핸드셰이크 이후 클라이언트와 서버 간의 연결이 유지되어 양방향으로 데이터를 실시간으로 주고받을 수 있습니다.

2. 웹소켓의 사용처

웹소켓은 실시간 데이터 전송이 필요한 다양한 분야에서 사용됩니다. 주요 사용 사례는 다음과 같습니다:

실시간 채팅 애플리케이션: 사용자가 메시지를 입력하면 다른 사용자에게 실시간으로 전송되어야 하는 경우.
실시간 주식 거래 시스템: 주식 가격, 거래 정보 등을 실시간으로 제공해야 하는 경우.
온라인 게임: 플레이어 간의 실시간 데이터 동기화가 필요한 경우.
실시간 알림 시스템: 서버에서 클라이언트로 실시간 알림을 전달해야 하는 경우.
협업 도구: 여러 사용자가 동시에 작업하는 문서 편집, 화이트보드 등에서 변경사항을 실시간으로 반영해야 하는 경우.

3. 웹소켓의 구현 방식

웹소켓은 다음과 같은 방식으로 구현됩니다:

초기 핸드셰이크:
- 웹소켓 연결은 HTTP 요청으로 시작됩니다. 클라이언트는 서버에 웹소켓 연결을 요청하며, 이때 Upgrade 헤더와 Connection: Upgrade 헤더를 사용합니다.
- 서버가 이를 수락하면, HTTP에서 웹소켓으로 프로토콜이 전환됩니다. 이 과정이 성공적으로 이루어지면, 클라이언트와 서버 간에 웹소켓 연결이 성립됩니다.
데이터 전송:
- 연결이 성립된 후, 클라이언트와 서버는 양방향으로 데이터를 자유롭게 주고받을 수 있습니다. 이때, 별도의 요청 없이 서버가 클라이언트로 데이터를 푸시(push)할 수 있으며, 클라이언트도 서버로 데이터를 보낼 수 있습니다.
- 웹소켓 메시지는 프레임으로 나뉘어 전송되며, 메시지의 크기에 따라 여러 개의 프레임으로 쪼개질 수 있습니다.
연결 종료:
- 웹소켓 연결은 클라이언트 또는 서버에 의해 종료될 수 있습니다. 종료 요청이 수신되면, 연결은 정상적으로 닫히게 됩니다.

4. 웹소켓 사용 시 고려 사항

보안: 웹소켓은 ws://와 wss:// 프로토콜을 지원합니다. wss://는 SSL/TLS를 사용하여 보안을 강화하므로, 민감한 데이터를 다루는 경우 wss:// 프로토콜을 사용하는 것이 필수적입니다.
브라우저 지원: 대부분의 현대 브라우저는 웹소켓을 지원하지만, 구형 브라우저에서는 웹소켓이 지원되지 않을 수 있습니다. 이런 경우 폴리필(Polyfill) 또는 다른 대체 기술(예: Long Polling)을 사용할 수 있습니다.
부하 관리: 실시간 데이터를 다루기 때문에 서버에 부하가 집중될 수 있습니다. 따라서 부하 분산(Load Balancing) 및 스케일링에 대한 고려가 필요합니다.

5. 웹소켓의 대안

웹소켓이 항상 최적의 솔루션은 아닙니다. 특정 상황에서는 다른 기술이 더 적합할 수 있습니다:

SSE(Server-Sent Events): 서버에서 클라이언트로 실시간 데이터 스트림을 전달하는 데 최적화되어 있습니다. 단방향 통신이 필요한 경우에 유리합니다.
Long Polling: 클라이언트가 서버에 요청을 보내고, 서버가 새로운 데이터가 있을 때까지 응답을 지연시킨 후 데이터를 전송하는 방식입니다. 실시간성과 유사한 효과를 낼 수 있으나, 비효율적인 부분이 존재합니다.

6. 결론

웹소켓은 실시간 데이터 통신이 필요한 애플리케이션에 필수적인 기술입니다. 채팅, 게임, 주식 거래 등 다양한 분야에서 활용되며, HTTP 통신의 한계를 넘어서는 빠르고 효율적인 데이터 전송을 제공합니다. 그러나 보안, 서버 부하 관리 등 구현 시 고려해야 할 요소도 많으므로, 사용 상황에 따라 적절한 선택이 필요합니다.

웹소켓을 활용하여 실시간 웹 애플리케이션을 구축하려면, 프로토콜의 동작 원리와 구현 방법을 정확히 이해하고, 적절한 보안 및 성능 최적화를 고려하는 것이 중요합니다.

프론트엔드 vs 백엔드: 차이점과 역할 알아보기

노사수 — Sun, 30 Jun 2024 13:40:07 +0900

이번 포스팅에서는 프론트엔드와 백엔드에 대해 쉽게 이해할 수 있도록 설명해 드릴게요. 개발자와 소통하다보면 이런 말을 많이 들을 수 있는데요, "이건 프론트엔드 문제라 제가 처리할 수 없어요." 라던지, "이건 백엔드 API를 수정해야 해서 제 담당이 아니에요."라는 말을 심심찮게 듣게 됩니다. 도대체 그 둘은 무슨 차이가 있고 왜 서로 처리할 수 없다고만 하는지 설명하고자 합니다.

프론트엔드와 백엔드의 관계

우선 프론트엔드와 백엔드는 각각 클라이언트, 서버로도 불립니다. 여기서 클라이언트는 고객, 서버는 우리나라에서 흔히 '웨이터'라고 표현하지만 실제 영어권 국가에서는 서빙을 하는 사람을 뜻하죠. 고객은 서버에게 음식을 주문을 하고, 서버는 고객에게 음식을 가져다줍니다. 여기서 음식은 데이터라고 볼 수 있겠죠? 프론트엔드와 백엔드의 관계는 이처럼 데이터를 요청하는 측, 데이터를 제공하는 측으로도 설명할 수 있으며 프론트(앞단), 백(뒷단)으로 이해해도 좋습니다. 즉, 프론트엔드는 유저가 보는 화면, 백엔드는 유저가 보는 데이터를 관리하는 쪽이라고 이해할 수도 있습니다.

1. 프론트엔드 (Frontend)

프론트엔드는 사용자가 직접 보는 웹사이트의 부분을 말합니다. 웹페이지의 디자인, 레이아웃, 버튼, 이미지 등 시각적인 요소들이 포함됩니다. 주로 사용하는 언어는 HTML, CSS, JavaScript입니다.

HTML (HyperText Markup Language): 웹 페이지의 구조를 만듭니다. 예를 들어, 제목, 문단, 링크 등을 정의합니다. 쉽게 말해, 건물의 뼈대라고 생각하면 좋습니다.
CSS (Cascading Style Sheets): 웹 페이지의 스타일을 설정합니다. 색상, 글꼴, 레이아웃 등을 꾸미는 역할을 합니다. 쉽게 말해, 건물의 인테리어라고 생각하면 좋습니다.
JavaScript: 웹 페이지에 동적인 기능을 추가합니다. 버튼 클릭 시 발생하는 이벤트, 애니메이션 등을 구현합니다. 쉽게 말해, 엘레베이터라던지 초인종이라던지 건물의 다양한 기능들이라고 생각하면 좋습니다.

프론트엔드 프레임워크/라이브러리:

React: Facebook에서 만든 JavaScript 라이브러리로, 복잡한 UI를 쉽게 만들 수 있습니다.
Vue.js: 사용하기 쉬운 JavaScript 프레임워크로, 점진적으로 적용할 수 있습니다.
Angular: Google에서 만든 프레임워크로, 대규모 애플리케이션에 적합합니다.

2. 백엔드 (Backend)

백엔드는 웹사이트의 서버 측 부분을 말합니다. 데이터베이스 관리, 사용자 인증, 서버 로직 등이 포함됩니다. 주로 사용하는 언어는 Python, Java, Node.js 등이 있습니다.

서버: 클라이언트(사용자)의 요청을 처리하고 응답을 돌려주는 컴퓨터 시스템입니다.
데이터베이스: 데이터를 저장하고 관리하는 시스템입니다. MySQL, PostgreSQL, MongoDB 등이 대표적입니다.
API (Application Programming Interface): 프론트엔드와 백엔드가 통신하는 방법입니다. RESTful API, GraphQL 등이 있습니다.

백엔드 프레임워크:

Django: Python 기반의 프레임워크로, 빠른 개발과 보안에 강점이 있습니다.
Spring: Java 기반의 프레임워크로, 대규모 시스템에 적합합니다.
Express: Node.js 기반의 경량 프레임워크로, 간단한 웹 애플리케이션을 빠르게 만들 수 있습니다.

3. 프론트엔드와 백엔드의 협업

프론트엔드와 백엔드는 서로 협력하여 완전한 웹사이트를 만듭니다. 예를 들어, 사용자가 로그인 폼에 정보를 입력하면 프론트엔드에서 이를 백엔드로 전송합니다. 백엔드는 데이터를 처리하고 결과를 프론트엔드로 돌려줍니다. 이렇게 두 부분이 상호작용하며 동작합니다.

결론

프론트엔드와 백엔드는 웹 개발의 두 축입니다. 각자의 역할과 기술이 다르지만, 협력하여 완성도 높은 웹사이트를 만듭니다. 프론트엔드는 사용자 경험을, 백엔드는 데이터와 서버 로직을 책임집니다. 이 글이 프론트엔드와 백엔드에 대해 이해하는 데 도움이 되었길 바랍니다.

API(Application Programming Interface)란?

노사수 — Fri, 28 Jun 2024 23:52:35 +0900

API란?

IT에 대해 완전 무지했을 때, 개발자에게 처음 했던 질문이 API가 뭔가요? 였습니다. 기본 중의 기본이면서도 이해하는 것이 쉽지만은 않았던 기억이 있습니다.

API는 Application Programming Interface의 약자로, 소프트웨어 애플리케이션 간에 상호 작용할 수 있도록 하는 인터페이스입니다. 간단히 말해, API는 소프트웨어가 다른 소프트웨어와 대화할 수 있도록 도와주는 번역기 같은 역할을 합니다. 데이터를 담는 그릇이라고 표현해도 좋을 것 같습니다.

언젠가 API를 설명할 날이 온다면 꼭 이 이야기로 예시를 들어야겠다 생각했습니다.

영화 터미네이터에서 T-800이 과거로 이동할 때 타임머신을 이용하게 됩니다. 여기서 타임머신 자체를 API로 생각할 수 있습니다. 타임머신이라는 API는 유기체만 통과할 수 있습니다. 일종의 규칙이 있는 것이지요. 타임머신을 통과하는 T-800이나 카일 리스는 데이터라고 볼 수 있습니다. T-800은 Type이 "robot", 카일 리스는 "human"이라고 이해하면 좋습니다. 미래라는 곳에서 과거라는 곳으로 데이터를 보낼 때, type이 "robot과 "human"이라면 성공이라는 응답을, 아니라면 실패라는 응답을 하게 됩니다.

API의 기본 개념

API는 두 애플리케이션이 서로 정보를 교환하고 작업을 수행할 수 있도록 하는 방법을 제공합니다. 예를 들어, 날씨 앱이 날씨 데이터를 얻기 위해 날씨 제공 서비스의 API를 호출하는 경우를 생각해 볼 수 있습니다. 이 과정은 다음과 같습니다:

요청: 날씨 앱이 날씨 제공 서비스의 API에 데이터를 요청합니다.
응답: 날씨 제공 서비스가 요청된 데이터를 날씨 앱에 응답으로 보냅니다.

API의 종류

API는 다양한 형태로 존재하며, 몇 가지 주요 종류는 다음과 같습니다:

REST API: 웹 애플리케이션에서 가장 많이 사용되는 API 형태로, HTTP 프로토콜을 사용합니다. 간단하고 직관적이며, URL을 통해 자원에 접근합니다.
SOAP API: XML 기반의 API로, 더 복잡하고 보안이 강화된 서비스에 주로 사용됩니다.
GraphQL: Facebook에서 개발한 API로, 클라이언트가 필요한 데이터만 요청할 수 있게 설계되었습니다.

API 사용 사례

다양한 애플리케이션이 API를 통해 상호 작용합니다:

소셜 미디어 연동: 다른 웹사이트나 앱에서 Facebook, Twitter 등의 계정으로 로그인할 수 있게 해줍니다.
결제 처리: 온라인 상점에서 PayPal이나 Stripe 같은 결제 게이트웨이를 통해 결제를 처리합니다.
지도 서비스: Uber나 배달 앱이 Google Maps API를 사용하여 위치 데이터를 가져오고, 경로를 계산합니다.

API 사용의 장점

API를 사용하면 다음과 같은 이점이 있습니다:

재사용성: 이미 검증된 기능을 재사용함으로써 개발 시간을 단축할 수 있습니다.
확장성: 새로운 기능을 추가할 때 기존 시스템을 크게 변경할 필요 없이 API를 추가하면 됩니다.
유연성: 다양한 플랫폼과 애플리케이션 간의 상호 운용성을 높여줍니다.

API 요청과 응답의 예

아래는 간단한 REST API 요청과 응답의 예입니다:

요청:

GET /api/weather?city=Seoul HTTP/1.1
Host: weatherapi.example.com

응답:

{
  "city": "Seoul",
  "temperature": "25°C",
  "condition": "Sunny"
}

API 사용 시 주의사항

보안: API 키나 인증 토큰을 사용하여 권한이 없는 접근을 막아야 합니다.
문서화: API 사용법을 명확히 문서화하여 개발자들이 쉽게 사용할 수 있도록 해야 합니다.
버전 관리: API가 업데이트될 때마다 새로운 버전을 제공하여 호환성을 유지해야 합니다.

API는 현대 소프트웨어 개발에서 매우 중요한 역할을 하며, 그 개념과 사용 방법을 이해하면 더 효율적이고 유연한 애플리케이션을 개발할 수 있습니다. API를 잘 활용하여 프로젝트의 생산성과 품질을 높여보세요!

검색엔진 최적화(SEO)란?

노사수 — Mon, 24 Jun 2024 19:00:59 +0900

검색엔진 최적화(SEO)란?

검색엔진 최적화(SEO, Search Engine Optimization)는 웹사이트나 웹페이지가 검색엔진(구글, 네이버 등) 결과 페이지에서 더 높은 순위에 오르도록 하는 일련의 전략과 기술을 의미합니다. 이는 검색엔진을 사용하는 사용자에게 더 나은 경험을 제공하고, 비즈니스에 더 많은 유기적 트래픽을 유도하는 것을 목표로 합니다. 이번 블로그 포스팅에서는 SEO의 주요 요소와 그 중요성에 대해 알아보겠습니다.

SEO의 주요 요소

1. 키워드 리서치(Keywords Research)
키워드 리서치는 SEO 전략의 기본입니다. 사용자들이 검색엔진에 입력하는 단어나 구문을 찾아내고, 이를 웹사이트 콘텐츠에 적절하게 반영하는 것이 중요합니다. 키워드 선택 시 검색량, 경쟁 수준, 사용자 의도를 고려해야 합니다.

도구 추천: Google Keyword Planner, Ahrefs, SEMrush

2. 온페이지 최적화(On-Page Optimization)
온페이지 최적화는 웹페이지 내부 요소를 최적화하는 작업입니다. 여기에는 메타 태그, 제목 태그, 본문 콘텐츠, 이미지 ALT 속성, 내부 링크 구조 등이 포함됩니다.

메타 태그: 각 페이지의 title, description을 최적화하여 검색엔진과 사용자가 페이지의 내용을 쉽게 이해할 수 있게 합니다.
콘텐츠 최적화: 사용자에게 가치 있는 정보를 제공하고, 키워드를 자연스럽게 포함시키며, 가독성을 높이는 것이 중요합니다.
이미지 ALT 태그: 이미지 자체는 정보를 가지고 있지 않습니다. 크롤러가 데이터를 수집할 때. 해당 이미지에 대해 설명하는 대체 텍스트를 사용하여 검색엔진이 이미지를 인식하고 색인할 수 있도록 합니다.

3. 오프페이지 최적화(Off-Page Optimization)
오프페이지 최적화는 웹사이트 외부에서 이루어지는 모든 SEO 활동을 의미합니다. 여기에는 백링크(Backlinks) 구축, 소셜 미디어 마케팅, 브랜드 언급 등이 포함됩니다. 특히, 고품질의 백링크는 검색엔진에서 신뢰도를 높이는 데 중요한 역할을 합니다.

백링크: 다른 웹사이트에서 자신의 웹사이트로 링크를 연결하는 것. 권위 있는 사이트로부터의 백링크는 SEO에 긍정적인 영향을 미칩니다. 반대로, 신뢰하기 힘든 사이트를 통해 유입되는 경우 최적화에 좋지 않습니다.

4. 기술적 SEO(Technical SEO)
기술적 SEO는 웹사이트의 기술적 요소를 최적화하여 검색엔진이 사이트를 더 쉽게 크롤링하고 색인할 수 있도록 하는 것입니다. 이는 사이트 속도, 모바일 최적화, SSL 인증서 사용, 사이트 맵 제출 등을 포함합니다.

사이트 속도: 빠른 로딩 속도는 사용자 경험을 개선하고 검색엔진 순위에도 긍정적인 영향을 미칩니다.
모바일 최적화: 모바일 사용자의 증가에 따라, 반응형 웹 디자인을 통해 다양한 디바이스에서의 접근성을 높이는 것이 중요합니다.

SEO의 중요성

1. 트래픽 증가
SEO는 유기적인 검색 결과를 통해 웹사이트로 유입되는 트래픽을 증가시킵니다. 이는 광고비용 없이도 지속적인 트래픽을 유도할 수 있어 비용 효율적입니다.

2. 브랜드 인지도 향상
검색 결과 상위에 노출되면 사용자들에게 브랜드의 신뢰성을 높일 수 있습니다. 이는 브랜드 인지도를 향상시키고 더 많은 고객을 유치하는 데 도움이 됩니다.

3. 경쟁력 강화
효과적인 SEO 전략을 통해 경쟁사보다 더 높은 검색 순위를 확보할 수 있습니다. 이는 시장에서의 경쟁력을 강화하는 데 중요한 역할을 합니다.

4. 마케팅 비용 감소
검색엔진 최적화는 광고비용을 최소화하고 트래픽을 증가시킬 수 있는 기법입니다.

SEO 추적을 위한 도구

SEO 최적화를 위해 다양한 검색 엔진에서 제공하는 도구를 사용하는 것이 중요합니다. 대표적으로 구글 서치 콘솔(Google Search Console), 네이버 서치어드바이저(Naver Search Advisor), 빙 웹 마스터 툴(Bing Webmaster Tools)가 있으며 아래와 같은 특징과 장점이 있습니다.

검색 트래픽 데이터: 웹사이트의 클릭 수, 노출 수, 클릭률, 평균 순위 등의 검색 트래픽 데이터를 제공합니다.
인덱스 상태: 크롤러가 웹사이트를 어떻게 크롤링하고 인덱싱하는지 확인할 수 있습니다. 인덱스에 포함된 페이지 수와 제외된 페이지에 대한 정보도 제공합니다.
광범위한 데이터 제공: 다양한 검색 트래픽 데이터를 통해 웹사이트의 성과를 세부적으로 분석할 수 있습니다.
문제 해결 가이드: 인덱싱, 크롤링, 보안 문제 등 다양한 문제에 대한 해결책을 제공합니다.
무료 사용: 대부분 무료로 제공되며, 누구나 쉽게 접근할 수 있습니다.
사이트 등록 및 관리: 각 포털 검색 결과에 웹사이트를 등록하고, 사이트맵을 제출할 수 있습니다.
백링크 분석: 웹사이트로 연결된 백링크를 분석하고, 링크 프로필을 개선할 수 있는 방법을 제안합니다.
SEO 보고서: 웹사이트의 SEO 상태를 분석하고, 개선 사항을 제안하는 SEO 보고서를 제공합니다.
모바일 친화성: 모바일 사용성 문제를 확인하고, 이를 개선하기 위한 가이드를 제공합니다.

결론

검색엔진 최적화는 디지털 마케팅의 핵심 요소로, 효과적인 전략을 통해 웹사이트의 가시성을 높이고, 더 많은 트래픽을 유도하며, 브랜드 인지도를 향상시킬 수 있습니다. 지속적인 키워드 리서치, 온페이지 및 오프페이지 최적화, 기술적 SEO의 조합을 통해 성공적인 SEO 결과를 얻을 수 있습니다.

[회고] 시장 세분화와 고객 타겟팅이 서비스 기획자에게 미치는 영향

노사수 — Fri, 17 May 2024 23:40:46 +0900

오늘 하고자 하는 이야기는 오롯이 제품관리자, 서비스기획자 입장에서 시장 세분화(segment), 고객 타겟팅이 얼마나 중요한지 적고자 한다. 마케팅 관점에서의 STP의 중요성은 두 말하면 입 아플 정도. 하지만 서비스 기획자 입장에서 세분화와 타겟팅이 정해지지 않으면 앞으로 서술할 문제점을 겪을 수 있다.

1. 리소스 낭비

뚜렷한 고객이 정해지지 않은 경우, 즉 유저 페르소나를 정의하지 못하는 경우 화면 설계에 큰 어려움을 겪을 수 있다. 일반적으로 대중에게 노출되는 B2C 제품의 경우, 어느 정도 정형화된 포맷이 있고 그 틀에서 고민하다보면 좋은 결과를 도출해 내기 쉽다. 단, B2B이거나 특수한 도메인 제품을 기획하는 경우 명확히 타겟이 정해져야 길을 잃지 않고 좋은 결과를 도출할 수 있다. 예를 들면, 어떤 기업은 담당자가 여러 가지 직무를 모두 처리하는가 하면, 어떤 기업은 분업화가 잘 되어있어 한 두 가지 업무를 집중해서 처리한다. 이런 경우 화면 설계 시 양 측 니즈를 모두 맞추기란 쉽지 않다. 시장에 양 쪽 모두 기회가 있다면, 어떤 토끼를 먼저 잡아야 시장에서 임팩트를 낼 수 있을지 충분히 고민한 후 한정된 리소스를 집중하여 MVP를 만들고 지속적으로 고도화해야 한다. 하지만 대부분 이럴 때 양 쪽 모두를 만족시키기 위해 복잡한 화면을 설계하거나, 화면의 본수가 많아지게 된다. 이는 제한된 자원을 활용해 최적의 결과를 도출해 내는 것을 방해한다.

2. 의사결정의 어려움

또한, 회사나 제품팀이 특정 고객을 타겟하지 않는다면 의사 결정 시 지속적인 번복이 일어나고 의견도출이 쉽게 되지 않는다. 보통 의견이 양쪽으로 나뉘고 양쪽 모두 맞는 말을 할 경우가 많다. 단지 타겟팅한 고객이 다를 뿐, 내가 틀리다고 생각하기 쉽지 않기 때문에 회의가 쓸데없이 길어지고 업무에 비효율이 발생한다.

3. 고객 만족도 저하

타겟하는 고객층이 없는 경우, 당연하지만 실제 제품을 경험하게 될 고객들의 만족도가 낮을 수밖에 없다. 나에게 주어진 어빌리티가 한정적임에도 육각형 인재가 되고자 한다면 어떠한 한 분야에서 특출 난 사람이 될 수 있을까? 제품도 마찬가지라고 생각한다. 시장에서는 업무 자동화에 대한 니즈가 강함에도 그에 집중하지 않고 다른 분야(예를 들면 디자인이나 다양한 기능 편의 등)에 집중하여 리소스를 낭비한다면 자동화에 목마른 시장의 니즈에 100% 만족감을 줄 수 없을 것이다.

결론

제품 관리자에게 있어 고객 타겟팅은 선택이 아닌 필수라고 매번 느끼게 된다. 효율적인 자원 배분, 맞춤형 마케팅 전략, 고객 만족도 향상, 시장 경쟁력 강화, 데이터 기반 의사결정 등 다양한 이점을 제공하기 때문이다. 고객 타겟팅을 통해 제품의 성공을 극대화하고, 지속 가능한 성장을 이룰 수 있도록 해야 합니다.

성공적인 제품 관리를 위해 고객 타겟팅의 중요성을 인식하고, 이를 적극적으로 활용하는 것이 중요하다. 이를 통해 제품 관리자와 기업은 더 나은 성과를 달성하고, 경쟁이 치열한 시장에서 우위를 점할 수 있을 것이다.

[Notion] 노션으로 QA 테스트 하는 방법

노사수 — Sun, 17 Mar 2024 23:47:53 +0900

QA(Quality Assurance, 품질 보증)는 제품이나 서비스가 특정 품질 기준이나 고객의 기대치를 만족하도록 보장하는 과정이라고 보면 된다. 이는 기획, 설계, 개발 및 제조 단계에서의 시스템적인 활동을 포함하여, 결함을 예방하고 품질을 개선하는 데 목적을 둔다. QA는 품질 관리(QC)와 혼용되기도 하지만, QC가 제품 결함을 식별하고 수정하는 반면, QA는 결함이 발생하지 않도록 예방하는 데 초점을 맞춘다.

기획대로 작동하는지, 디자인한 대로 구현되었는지, 개발이 계획대로 되었는지를 체크하는 테스트라고 생각하면 쉽다.

환경별로 QA하기

제품을 릴리즈 하기 전, 우선 dev 환경이나 stage 환경에서 모든 테스트를 마무리 한 뒤 live 환경이나 production 환경에 배포하는 것이 일반적이다. 이렇게 환경을 구분해야 실제 운영중인 서비스에 차질이 생기지 않는다.

QA 툴 정하기

QA를 진행하는 툴은 무엇을 쓰든 상관 없다. 구글 스프레드 시트나 엑셀같은 표 형식을 사용하기도 하고, 노션이나 지라같은 협업툴을 사용하기도한다. 기획이나 디자인도 마찬가지지만 결국 툴이 중요한 것이 아니라 어떻게 협업할 것인가가 중요하기 때문에 회사에, 팀에 맞는 방식을 선택하는 것이 중요하다.

템플릿 만들기

우리 팀은 노션과 구글 스프레드 시트로 QA를 진행한다. 스프레드 시트의 장점은 Information Archtectur 기반으로 test case를 작성하여 빠짐없이 꼼꼼하게 QA를 진행할 수 있다는 점이다. 다만, QA 리스트 작성에 시간이 오래 걸리고 가시성이 떨어진다는 단점이 있다. 노션의 경우 빠르게 오류 케이스 작성을 할 수 있을 뿐만 아니라 표, 보드 등 다양한 보기 형식을 제공하고 협업에 최적화된 툴이기 때문에 노션을 주로 사용한다.

우선 노션에서 보드 형태의 페이지를 제작한다.

새 보기 클릭 후 테이블 형태 보기도 추가한다.

항목을 추가해준다. 제품에 따라 회사에 따라, 혹은 템플릿 제작자에 따라 들어가는 내용은 천차만별이다. 하지만 우리가 집중해야 하는 것은 어떻게 소통할 것인지, 어떻게 빠르게 오류를 잡아내고 개발자에게 전달할 수 있는지에 대한 고민이다.

상태 필터는 진행전, 진행중, 진행완료를 보기 좋게 수정한다. 보통 검수 항목 리스트업을 하고, 검수 결과를 표기한 뒤, 개발자 작업 이후 최종 status를 선택한다. FIXED로 변경되면 해당 행목에 대한 QA는 종료된다.

QA할 때 중요한 점

1. 꼼꼼함

QA는 제품이나 신규 기능 릴리즈 전 마지막 테스트 개념이다. 내부에서 QA로 걸러내지 못하면 결국 사용자가 해당 오류를 찾아내게 된다. 제품이나 회사 신뢰도를 떨어뜨릴 뿐만 아니라 치명적인 오류로 유저에게 외면받을 수 있다. 그러므로 꼼꼼한 케이스 정리가 무엇보다 중요하다.

2. 속도

속도는 무엇보다 중요하다. 예전에 제품을 릴리즈 할 때 QA가 신속하게 진행되지 못했던 적이 있다. 개발자는 작성된 목록이 전부인줄 알고 모든 시간을 투여해서 오류를 수정한다. 마무리된 줄 알았던 QA는 작업자의 느린 속도로 인해 더디게 오류 목록이 계속해서 추가되게 되고 이는 개발자의 사기저하로 이뤄질 수 있다. 물론 실제 운영을 하다 보면 미처 발견되지 못한 오류가 추가로 발생될 수 있다. 하지만 최대한 모든 케이스에 대해 테스트해보고, 개발자보다 더 빠르게 목록 작성을 마무리 하는 것이 중요하다.

3. 디테일

QA 항목 작성 시 최대한 디테일하게 발생 원인을 작성한다. 어떤 메뉴에서 어떤 행동을 했을 때 어떤 오류가 났는지를 최대한 자세히 적어주는 것이 좋다. 실제로 QA를 하다보면 개발자가 해당 오류를 재현하지 못해 해매는 경우가 많다. 개발자가 동일한 플로우로 해당 오류를 발견할 수 있도록 디테일하게 작성해주는 것이 중요하다.

마치며

QA는 신속하고 디테일하게 작성하고 빠르게 마무리 하는 것이 중요하다. 팀마다 선호하는 방식을 빠르게 찾아서 가장 fit한 방법론을 찾는 것이 중요할 것 같다.

노션 협업툴 사용하고 업무 효율화를 누리세요!

지금 바로 업무 효율성을 극대화해보세요! (노션 바로가기 클릭)

[추천도서] 인스파이어드(Inspired) : 좋은 PM이 되기 위해 읽어야 할 필독서

노사수 — Sun, 10 Mar 2024 22:54:42 +0900

인스파이어드 : Inspired

서비스 기획뿐만 아니라 Product Manager에 대한 갈망을 해소하기 위해 구매한 인스파이어드. 실리콘벨리에서 성공한 제품을 만든 PM들의 성공 방정식에 대해 소개하고 다양한 기업들의 실제 사례들을 간접 경험해 볼 수 있다.

크게 사람, 제품, 프로세스, 문화에 대해 다룬다.

1. 사람

첫 번째 챕터인 "사람"에서는 제품팀을 구성하는 다양한 롤, 예를들면 디자이너, 개발자, 마케터, 제품매니저 등 역할에 대해 소개하고 각 롤이 맡은 업무를 잘 수행하는 방식에 대해 설명한다.

2. 제품

두 번째 챕터인 "제품"에서는 제품의 비전과 원칙, 목표에 대해 다룬다. 로드맵의 중요성, 목표 설정 프레임워크인 OKR기법에 대해 자세히 다룬다.

3. 프로세스

세 번쨰 챕터인 "프로세스"에서는 본격적으로 제품을 만드는 방법에 대해 상세히 설명한다. 처음 비즈니스 기회를 창출하는 것부터 시작해 고객인터뷰, 프로토타이핑 제작, 출시 전 다양한 테스트 기법에 대해 소개한다.

4. 문화

네 번째 챕터인 "문화"에서는 앞서 다룬 이론적 내용과 다르게 실제 사례를 들어 설명한다. 좋은 제품팀과 그렇지 않은 제품팀에 대해, 혁신과 속도를 잃는 이유에 대해, 강력한 제품팀 문화 구축하는 방식에 대해 설명한다.

실제 서비스 기획자로 근무하면서, 사수 없이 일하는 과정에서 겪은 고민들, 현 제품팀 문화의 개선이 필요한 부분들을 책을 통해 간접 경험할 수 있어 매우 좋았다. 좋은 기획자 혹은 PM이 되려면 어떻게 해야 할지 고민이 될 때 읽기 좋은 도서.

PM은 아직 우리나라에서는 본격적으로 대학에서 다루지 않고 설령 다룬다 하더라도 PM은 이론이 아니라 경험의 차이가 실력을 가르는 것 같다. 그렇기 때문에 성공적인 제품팀 구축을 위한 사례를 통해 간접 경험을 많이 해 실무에 접목시키는 연습이 중요할 것 같다.

[회고] 오랜 기다림 끝에 맞이한 제품 출시 회고

노사수 — Thu, 7 Mar 2024 23:35:01 +0900

패키지여행 오퍼레이터로 커리어를 시작해 항공 솔루션 기획자로 커리어 전환하기까지의 과정은 "쉽지 않았다" 수준으로 정의하기엔 너무나 고되고 험난한 여정이었다.

지금 회사에 입사하고 개발자에게 했던 첫 질문은 "도대체 API가 뭐예요?"였다. 그만큼 급변하는 IT환경에 무지했고 아직도 배움은 끝이 없다는 걸 하루하루 느낀다. 하지만 모든 산업에서 디지털 전환이 일어나고 있고 IT기반 서비스가 시장을 장악하고 있다 보니 그 흐름에 편승하지 못하면 평생 우물 안 개구리처럼 살 수밖에 없다고 생각했기에 그 도전을 의심하지 않았고 날마다 새롭게 배우는 과정이 즐거웠다.

시작할 땐 무모하다고 생각했다. 도메인 전문가 없이 어떻게 업무용 솔루션을 개발할 수 있을지 막막했다. 전문가들이 모여 만든 시스템도 완벽하지 않은 시점에서 과연 우리가 해낼 수 있을까?라는 의구심이 들었다. 하지만 이해할 수 있다면, 모든 것을 만들 수 있다는 말이 있듯이 각 구성원들이 각자의 분야에서 쌓은 도메인 지식이 합쳐져 난제들을 풀어나갈 수 있었다.

지금 생각해 보면 구성원 전체가 더닝 크루거 곡선을 따라 여행하고 있는 것 같다. 무지했기 때문에 용감했고 그렇기 때문에 시작할 수 있었으며, 알아가는 과정에서는 절망했으나 깨달음의 비탈길을 손톱 빠지도록 기어오르다 보면 결국에는 지속가능성의 고원에 다다를 수 있지 않을까 싶다.

아주 긴 서사의 프롤로그 단계에 와있다는 생각이 들고, 아직 가야 할 길이 안드로메다만큼 멀지만 지금 이 순간에 동료들에게 꼭 해주고 싶은 말이 있다.

"우리 모두 수고했습니다 "

Privacy Policy

노사수 — Thu, 7 Mar 2024 20:59:47 +0900

Privacy Policy

Who we are
Our website address is: https://nosupport.tistory.com

Comments
When visitors leave comments on the site we collect the data shown in the comments form, and also the visitor’s IP address and browser user agent string to help spam detection.

An anonymized string created from your email address (also called a hash) may be provided to the Gravatar service to see if you are using it. The Gravatar service privacy policy is available here: https://automattic.com/privacy/. After approval of your comment, your profile picture is visible to the public in the context of your comment.

Media
If you upload images to the website, you should avoid uploading images with embedded location data (EXIF GPS) included. Visitors to the website can download and extract any location data from images on the website.

Cookies
If you leave a comment on our site you may opt-in to saving your name, email address and website in cookies. These are for your convenience so that you do not have to fill in your details again when you leave another comment. These cookies will last for one year.

If you visit our login page, we will set a temporary cookie to determine if your browser accepts cookies. This cookie contains no personal data and is discarded when you close your browser.

When you log in, we will also set up several cookies to save your login information and your screen display choices. Login cookies last for two days, and screen options cookies last for a year. If you select "Remember Me", your login will persist for two weeks. If you log out of your account, the login cookies will be removed.

If you edit or publish an article, an additional cookie will be saved in your browser. This cookie includes no personal data and simply indicates the post ID of the article you just edited. It expires after 1 day.

Embedded content from other websites
Articles on this site may include embedded content (e.g. videos, images, articles, etc.). Embedded content from other websites behaves in the exact same way as if the visitor has visited the other website.

These websites may collect data about you, use cookies, embed additional third-party tracking, and monitor your interaction with that embedded content, including tracking your interaction with the embedded content if you have an account and are logged in to that website.

Who we share your data with
If you request a password reset, your IP address will be included in the reset email.

How long we retain your data
If you leave a comment, the comment and its metadata are retained indefinitely. This is so we can recognize and approve any follow-up comments automatically instead of holding them in a moderation queue.

For users that register on our website (if any), we also store the personal information they provide in their user profile. All users can see, edit, or delete their personal information at any time (except they cannot change their username). Website administrators can also see and edit that information.

What rights you have over your data
If you have an account on this site, or have left comments, you can request to receive an exported file of the personal data we hold about you, including any data you have provided to us. You can also request that we erase any personal data we hold about you. This does not include any data we are obliged to keep for administrative, legal, or security purposes.

Where your data is sent
Visitor comments may be checked through an automated spam detection service.

SaaS(Software as a Service)란?

노사수 — Thu, 22 Feb 2024 00:05:00 +0900

최근 기업들은 더 빠르고, 효율적이며, 비용 효과적인 솔루션을 지속적으로 추구하고 있다. 소프트웨어 개발에는 인력 구성이 필수인데 IT기업이 아닌 이상 개발팀을 보유하고 있지 않은 경우가 많다. 외주업체를 통해 자체 구축 시 많게는 수백억 원까지 비용이 발생된다. 하지만 막대한 비용을 지불하고 나서도 제대로 활용되지 못하거나 내부 직원들에게 외면받는 경우도 적지 않게 본 것 같다. 이러한 요구에 부응하여, SaaS (Software as a Service), PaaS (Platform as a Service), IaaS (Infrastructure as a Service)와 같은 클라우드 서비스 모델들이 등장했고 소프트웨어 시장을 점령하다시피 하고 있다.

SaaS(Software as a Service)란 무엇인가?

SaaS, 즉 Software as a Service는 클라우드 기반 소프트웨어 제공 방식을 말한다. 이는 사용자가 소프트웨어를 소유하거나 직접 설치할 필요 없이 인터넷을 통해 접근하여 사용할 수 있게 한다. 이 방식은 효율성, 접근성 및 비용 절감 측면에서 매력적인 대안으로 떠오르고 있습니다. 장소에 구애받지 않고 인터넷만 사용 가능하면 어디에서나 작업을 이어나갈 수 있다. 작업물이 서버에 저장되기 때문에 저장을 못해서 작업물을 날렸던 지난날의 아픔은 겪지 않아도 된다.

SaaS의 장점과 단점

장점

비용 절감: 사용자는 필요한 서비스에 대해서만 비용을 지불하므로 구축비용 등 초기 투자 비용이 크게 줄어든다. 보통 월 구독형 과금 모델이 많으므로 사용을 원치 않을 경우 언제든지 해지할 수 있다.
유연성: 사용자는 언제 어디서나 인터넷이 연결된 환경에서 서비스에 접근할 수 있으며 로컬 저장이 아니기 때문에 작업물을 날릴 위험이 줄어든다.
자동 업데이트: 자체구축한 일반적인 소프트웨어는 업데이트가 필요할 경우 막대한 추가 비용을 지불하고 외주사에 견적을 의뢰하는 경우가 많다. 하지만 SaaS는 제공업체가 소프트웨어 업데이트와 유지보수를 담당하기 때문에 사용자의 부담을 줄여준다.

단점

보안 우려: 중요한 데이터가 외부 서버, 즉 제공업체 서버에 저장되어 있으므로 보안 문제가 발생될 수 있다. 실제로 이러한 이유 때문에 SaaS 서비스를 꺼려하는 대표님을 본 적이 있다.
제한된 커스터마이징: SaaS 제품은 커스터마이징이 불가하거나 극히 제한적인 경우가 많다. 주요 기능에 대해서는 제공업체가 사용자의 니즈 파악 후 업데이트 하긴 하지만 회사에 맞춤형으로 커스터마이징 하는 것은 불가하다.
인터넷 의존성: 인터넷 연결이 불안정하거나 없는 환경에서는 서비스 이용이 어렵다.

SaaS vs 온프레미스(On-Premises)

온프레미스 솔루션은 기업이 자체 서버와 인프라에서 소프트웨어를 직접 설치하고 관리하는 방식이다. 이에 비해 SaaS는 클라우드 기반으로 운영되어 더 빠르고 유연한 서비스 제공이 가능하다. 온프레미스는 높은 초기 투자비용과 유지보수가 필요하지만, 보안과 커스터마이징 측면에서 더 많은 제어권을 제공한다. 반면 SaaS의 경우 비용 절감 효과가 있지만 반대로 보안과 커스터마이징 측면에서는 온프레미스보다 단점이 많다.

SaaS 주요 제품들

Salesforce: CRM 분야에서 선두주자로, 클라우드 기반 서비스를 통해 맞춤형 고객 관리 솔루션을 제공한다.
Google Workspace (구 G Suite): 구글의 SaaS 제품군으로, 이메일, 문서 작성, 클라우드 스토리지 등 다양한 오피스 툴을 제공한다.
Slack: 팀 커뮤니케이션을 위한 플랫폼으로, 간편한 메시징과 통합 기능으로 업무 효율성을 크게 개선시킨다.
Notion : 클라우드 기반 메모 기능을 시작으로 칸반보드, 테이블, 캘린더 등 협업에 필요한 다양한 템플릿을 제공한다.
Figma : 제품 디자인 업계를 강타한 클라우드 기반 디자인 툴. 기획자, 디자이너, 개발자 간의 효율적인 협업을 가능케 한다.

PaaS와 IaaS

PaaS (Platform as a Service)

PaaS는 사용자가 소프트웨어 개발에 필요한 플랫폼과 도구를 클라우드에서 제공받는 서비스를 말한다. 개발자들은 PaaS를 통해 개발, 테스트, 배포, 관리 및 업데이트를 효율적으로 수행할 수 있다. 예시로는 Heroku, Google App Engine 등이 있다.

IaaS (Infrastructure as a Service)

IaaS는 기본적인 컴퓨팅 인프라 – 서버, 네트워킹 기능, 스토리지, 데이터 센터 공간 등을 인터넷을 통해 제공하는 서비스를 말한다. 사용자는 자체 하드웨어를 구매, 설치, 유지보수할 필요 없이 필요한 인프라 자원을 클라우드 서비스 제공업체로부터 임대하여 사용할 수 있다. 이는 확장성과 유연성을 크게 향상시키며 비용을 절감시킨다. 대표적인 예로는 Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform 등이 있다.

SaaS가 모든 기업에 무조건적으로 옳은 선택일 순 없다. 비용과 리소스가 충분한 기업의 경우 구축형 소프트웨어가 유리할 수 있다. 회사에 fit한 제품을 만들고 필요시마다 커스터마이징을 통해 입맛대로 업데이트할 수 있고 회사의 중요 데이터 외부에 노출하지 않아도 되기 때문이다. 하지만 비용을 절감하고 유연하게 제품을 선택하고자 한다면 SaaS는 최고의 선택이 될 것이다.

[draw.io] 가볍지만 효과적인 다이어그램 제작 툴

노사수 — Sat, 17 Feb 2024 20:44:06 +0900

서비스 기획을 하다 보면 복잡한 프로세스를 플로우차트로 표현해야 할 경우가 많다. 개발자는 데이터의 흐름을 UI가 아닌 플로우차트로 파악하는 것이 훨씬 직관적일 수 있기 때문이다. 피그마 같은 툴로도 제작이 가능하지만 템플릿을 찾아야 하고 하나하나 그려서 이어 붙이기가 여간 귀찮은 일이 아니다.

오늘 소개할 draw.io는 이러한 플로우차트를 효과적으로 제작하기 위한 웹베이스 무료 툴이다. Mac OS와 Windows 버전 응용프로그램도 제공한다.

draw.io 소개

draw.io는 웹 기반의 다이어그램 도구로, 복잡한 설치 과정 없이 바로 사용할 수 있다. 다양한 템플릿을 제공해서 초보자부터 전문가까지 누구나 쉽게 다양한 유형의 다이어그램을 만들 수 있다.

처음 접속하면 저장위치를 정하라는 팝업이 뜬다. 나중에 결정해도 된다.

draw.io의 다양한 기능들

draw.io는 플로우차트, 마인드맵, UML 다이어그램 등 다양한 형식을 지원한다. 드래그 앤 드롭 기능으로 간편하게 도형과 선을 추가하고 편집할 수 있어서 작업 효율성이 높다.

항목별로 다양한 템플릿을 제공하므로 목적에 맞게 빠른 작업을 서포트한다.

기본적인 인터페이스는 이렇게 생겼다. 좌측에는 다양한 도형들과 형식들, 중앙에는 작업 공간, 우측에 스타일 설정 기능이 있다. 처음부터 도형을 활용해 그릴 수도 있고 형식별 다양한 도형 및 아이콘으로 원하는 작업물을 제작할 수 있다.

다양한 컴포넌트를 제공하여 간단한 와이어프레임도 제작이 가능하다.

통합 및 호환성

Google Drive, OneDrive, Dropbox와 같은 클라우드 서비스와의 통합 기능이 있어서 작업을 쉽게 저장하고 공유할 수 있다. 또한, 여러 파일 형식으로 내보내기가 가능해서 다른 프로그램과의 호환성도 좋다.

draw.io의 장점

draw.io의 최대 장점은 무료라는 점이다. 무료임에도 다양한 기능을 제공하기 때문에 각광받는 것 같다. 또하나의 장점은 클라우드 서비스라는 것이다. 설치 파일도 제공하지만 공간 제약 없이 웹 베이스로 작업을 이어갈 수 있다.

마치며

draw.io는 누구나 쉽게 사용할 수 있는 다이어그램 도구다. 특히 클라우드 통합 기능은 협업에 아주 유용하다. 간단한 다이어그램부터 복잡한 프로젝트 계획까지 draw.io 하나면 충분하다.

싱글 사인온(SSO: Single Sign On)이란?

노사수 — Wed, 14 Feb 2024 00:38:45 +0900

한 번의 로그인으로 기업의 각종 시스템이나 인터넷의 여러 사이트 서비스에 접속할 수 있도록 해 주는 시스템. 1997년 IBM이 개발했으며 우리나라에서는 2000년 코리아닷컴이 처음 도입하였다.
[네이버 지식백과] 싱글 사인온 [Single Sign-On] (한경 경제용어사전)

SSO란 무엇일까?

SSO는 사용자가 다양한 서비스와 애플리케이션에 접속할 때 여러 번의 로그인 절차 없이 단 한 번의 인증으로 모든 서비스를 이용할 수 있게 해주는 기술이다. 이는 사용자의 편의성을 극대화하고, 비밀번호 관리의 복잡성을 줄여준다.

SSO의 장점은?

편리성: 사용자는 여러 개의 아이디와 비밀번호를 기억할 필요가 없다. 한 번의 로그인으로 여러 서비스를 이용할 수 있다.
보안성 강화: 비밀번호 노출 위험이 줄어들며, 중앙집중식 관리로 인해 보안 정책을 더욱 철저히 적용할 수 있다.
효율적인 자원 관리: 기업이나 조직에서는 사용자 관리와 보안 정책을 더욱 효율적으로 운영할 수 있다.

SSO 작동 원리

SSO는 주로 토큰 기반 인증 방식을 사용한다. 사용자가 처음 로그인할 때, 인증 서버는 인증 토큰을 발급한다. 이 토큰은 사용자가 다른 서비스에 접속할 때 인증 수단으로 사용되어, 별도의 로그인 과정 없이 서비스 이용이 가능하게 된다.

SSO 사례

구글(Google)의 SSO

구글은 아마도 가장 잘 알려진 SSO의 예시 중 하나일 것이다. 구글 계정으로 로그인하면, Gmail, Google Drive, YouTube, Google Maps 등 구글이 제공하는 다양한 서비스에 자동으로 접근할 수 있다. 이는 구글의 모든 서비스가 단일 구글 계정을 통해 연동되어 있기 때문이다.

마이크로소프트(Microsoft)의 SSO

마이크로소프트 역시 SSO를 제공한다. 예를 들어, 한 번의 로그인으로 Outlook, OneDrive, Office Online 등에 접근할 수 있다. 마이크로소프트의 SSO는 특히 기업 환경에서 유용하게 사용되고 있다.

소셜 미디어 로그인

Meta(구 Facebook) 같은 소셜 미디어 계정을 사용하여 다른 앱이나 서비스에 로그인하는 것도 SSO의 한 형태이다. 예를 들어, 새로운 웹사이트에 가입할 때 'Google로 로그인하기'나 'Meta 계정으로 로그인하기' 옵션을 선택하면, 별도의 계정 생성 없이 해당 소셜 미디어 계정의 인증 정보를 사용하여 서비스를 이용할 수 있다.

기업 환경에서의 SSO

많은 기업들이 직원들의 로그인 과정을 간소화하기 위해 SSO를 사용한다. 예를 들어, 한 기업의 직원이 회사의 인트라넷에 로그인하면, 그 회사에서 사용하는 다양한 내부 시스템(이메일, HR 시스템, 문서 관리 시스템 등)에 자동으로 접근할 수 있다.

행위주도 개발 (BDD): 사용자 중심의 개발 방식으로의 전환

노사수 — Tue, 6 Feb 2024 23:36:08 +0900

디스크립션 작성 요령에 대한 레퍼런스를 찾던 도중, BDD에 대해 알게 되었다. BDD의 경우 개발 방법론의 일환이지만 화면설계서에 부가적 정보로써 꽤나 효과적으로 활용할 수 있었다.

BDD의 개념

행위주도 개발(Behavior-Driven Development, BDD)은 소프트웨어 개발 방식 중 하나로, 기능의 행동을 중심으로 개발 프로세스를 진행하는 방법론이다. BDD는 사용자의 요구사항을 명확하게 이해하고, 이를 기반으로 소프트웨어를 개발하는 데 중점을 둔다. BDD는 테스트 주도 개발(Test-Driven Development, TDD)의 개념을 확장하여, 비즈니스 요구사항과 기술 사양이 긴밀하게 연결되도록 도와준다.

BDD의 중요성

BDD는 개발 과정에서 사용자의 관점을 최우선으로 적용한다. 이를 통해 개발자는 실제 사용자가 경험할 소프트웨어의 행동을 더 잘 이해하고, 이에 따라 보다 효과적으로 기능을 구현할 수 있다. 또한, BDD는 개발자와 비개발자 간의 의사소통을 강화하여, 모든 팀 구성원이 프로젝트의 목표와 요구사항을 명확하게 이해하도록 돕는다. 나 또한 디스크립션 작성 시 BDD를 통해 예외상황에 대한 설계를 강화할 수 있었다.

BDD의 프로세스

BDD의 프로세스는 몇 가지 핵심 단계로 구성된다:

요구사항 정의: 사용자 스토리와 시나리오를 통해 사용자의 요구사항을 정의한다.
시나리오 작성: Gherkin과 같은 도메인 특정 언어를 사용하여, 사용자의 행동과 예상되는 결과를 명확하게 서술한다.
테스트 구현: 시나리오를 기반으로 자동화된 테스트를 작성한다.
개발 및 리팩토링: 테스트를 통과하는 소프트웨어를 개발하고, 필요에 따라 지속적으로 개선한다.

BDD의 장점

사용자 중심의 접근 방식: 사용자의 요구와 경험을 우선시하여 보다 직관적이고 사용자 친화적인 소프트웨어를 개발할 수 있다.
향상된 커뮤니케이션: 비개발자도 이해할 수 있는 언어로 요구사항을 서술함으로써, 모든 이해관계자 간의 의사소통이 원활해진다.
품질 보증: 테스트를 중심으로 개발함으로써 소프트웨어의 품질을 지속적으로 관리하고 보증할 수 있다.

결론

BDD는 사용자의 요구사항을 정확히 이해하고 충족시키는 데 중점을 둔 개발 방식이다. 사용자 경험을 중심으로 한 소프트웨어 개발에 있어 매우 효과적인 접근법으로, 프로젝트의 성공률을 높이는 데 기여할 수 있다.

도메인 주도 설계의 핵심: 유비쿼터스 랭기지의 역할과 중요성

노사수 — Sun, 4 Feb 2024 23:43:26 +0900

gpt가 그림은 잘 그리는 만큼 스펠링도 자주 틀린다.

1. 유비쿼터스 랭기지란 무엇인가?

a. 정의와 기원

유비쿼터스 랭기지는 Eric Evans가 제시한 도메인 주도 설계(Domain-Driven Design, DDD)의 핵심 요소 중 하나이다. 이는 모든 팀 구성원이 공유하는 공통 언어로, 개발자와 비개발자 모두가 이해하고 사용하는 용어 집합을 의미한다.

b. 도메인 주도 설계와의 관계

유비쿼터스 랭기지는 도메인 주도 설계의 중심이다. 도메인 전문가와 개발자 간의 의사소통을 원활하게 하여, 프로젝트의 명확성과 효율성을 높이는 데 기여합니다. 특히 내가 담당하고 있는 프로젝트인 항공 부킹 엔진의 경우, 그 어떤 도메인보다 유비쿼터스 랭기지가 중요하다. 전문용어나 유사어가 많기도 하고 약어가 많아 커뮤니케이션이 어렵기 때문이다.

2. 유비쿼터스 랭기지의 중요성

a. 의사소통 향상

프로젝트의 성공은 팀원 간의 효과적인 의사소통에 달려 있다 해도 과언이 아니다. 유비쿼터스 랭기지를 통해 모호함을 줄이고, 오해의 소지를 최소화할 수 있다.

b. 효율적인 문제 해결

공통 언어를 사용함으로써, 복잡한 문제를 더 쉽고 효율적으로 해결할 수 있다. 이는 개발 프로세스를 가속화하고, 품질을 향상시킨다.

3. 유비쿼터스 랭기지 구현 방법

a. 도메인 전문가와의 긴밀한 협업

유비쿼터스 랭기지를 도입하기 위해서는 도메인 전문가와 개발자 간의 긴밀한 협업이 필수적이다. 이를 통해 도메인에 대한 깊은 이해를 바탕으로 언어를 구축할 수 있 다.

b. 지속적인 리파인먼트

유비쿼터스 랭기지는 프로젝트 초기에만 정의되고 끝나는 것이 아니라, 지속적으로 검토하고 수정해야 한다. 이는 프로젝트의 변화와 성장에 맞춰 언어를 발전시키는 과정이기 때문이다.

일정관리를 위한 WBS(Work Breakdown Structure) 프레임워크

노사수 — Sat, 3 Feb 2024 11:24:50 +0900

WBS는 프로젝트 관리에서 사용되는 핵심 도구 중 하나로, 'Work Breakdown Structure'의 약자이다. 프로젝트의 전체 범위를 더 작고 관리 가능한 단위로 나누는 방식을 말한다. 이 방법은 프로젝트 팀이 명확하고 구체적인 작업 목록을 이해하고 추적할 수 있게 도와준다.

WBS의 개념

WBS는 복잡한 프로젝트를 보다 쉽게 관리할 수 있도록 설계된 계층적 구조이다. 기본적으로 프로젝트를 여러 단계로 나누며, 각 단계는 추가적으로 세분화되어 특정한 작업이나 활동으로 구성된다. 이 구조는 프로젝트의 전체 범위를 시각적으로 나타내며, 각 작업의 관계와 기능별 일정을 쉽게 파악할 수 있다.

WBS 작성 방법

WBS를 작성할 때는 먼저 프로젝트의 최종 목표를 정의한다. 그 후, 이 목표를 달성하기 위해 필요한 주요 작업이나 단계로 분할한다. 각 주요 작업은 더 작은 작업으로 세분화되어야 하며, 이 과정은 필요한 모든 작업이 포함될 때까지 계속된다. 중요한 것은 각 하위 작업이 명확하고 구체적이어야 하며, 관리 가능한 수준이어야 한다는 것이다. 작업이 분류된 뒤에 작업자를 배정한다. 세분화된 작업을 전체 개발 일정 내에서 적절히 배분한다. 엑셀 같은 시트에 작성하는 경우가 흔한데, WBS라고 해서 무조건 엑셀에 정리해야 하는 것은 아니고 작업 분류의 한 방식으로써 어떠한 툴을 사용하든 상관없다.

WBS의 장점

WBS의 주요 장점 중 하나는 프로젝트를 체계적으로 조직할 수 있다는 것이다. 이는 프로젝트의 복잡성을 줄이고, 팀원들이 각자의 역할과 책임을 명확히 이해할 수 있도록 도와준다. 또한, WBS는 예산 책정, 자원 할당, 일정 관리 등 프로젝트 관리의 다른 측면에도 유용하다.

WBS의 단점

정확하고 효과적인 WBS를 작성하기 위해서는 프로젝트에 대한 깊은 이해가 필요하며, 때로는 과도한 세분화가 오히려 프로젝트 관리를 복잡하게 만들 수 있다. 또한 정확히 산출되지 않은 기한을 WBS로 쪼개 관리할 경우, 오히려 너무 느긋한, 혹은 반대로 너무 빠듯해서 모든 일정이 꼬여버리는 문제가 발생될 수 있다. 유연한 조직보다 체계적인 조직에 더 적합한 업무 분할 방식이라고 생각한다.

WBS로 일정 관리를 해도 결국 지속적인 팔로업과 관리가 병행되지 않을 때 흐지부지 되는 경우를 목격했다. 일정 관리는 결국 방식도, 업무툴도 그저 거두는 역할일 뿐 가장 중요한 건 작업자의 의지와 관리자의 부지런함일 것이다.

[회고] 불합리한 마감 기한이 불러오는 재앙에 대하여

노사수 — Wed, 31 Jan 2024 23:51:28 +0900

어디서부터 글을 시작해야 할지 모르겠다. 우선 현 상황에 대해 설명해 보자면, 우연찮은 비즈니스 기회가 굉장히 많은 상황이다. 속된 말로 줘도 못 먹는 상황까지 온 것 같다. 도메인에서 유니크한 사업 아이템을 남들보다 빠르게 캐치하여 영위해 나간 점이 유효했던 것 같다.

리소스는 한정되어 있는데 주는 대로 받아먹다 보니 급체가 온 상황이다. 같은 실수를 반복하지 않기 위해(물론 또 반복하겠지만), 또 이 경험을 누군가에게 간접경험이 될 수 있도록 회고를 진행하고자 한다.

직원들의 사기저하

우선 업무적이든 업무 외적이든 동서고금을 막론하고 불합리한 지시를 받았을 때 과연 조직에 대한 충성심이 발휘될 수 있을까? 나는 평소와 같이 열심히 하는데도 불구하고 내 몸을 갈아 넣어도 달성할 수 없는 목표가 주어진다면 동기부여가 될까? 불합리한 마감 기한이 주는 가장 큰 문제는 직원들의 사기저하, 퇴사욕구 등의 불만이 쌓인다는 점이다. 직원들의 사기는 기업의 성공에 있어 가장 중요한 요소 중 하나이다. 사기가 떨어진 군대가 전투에서 승리할 수 있을까? 사기가 저하된 스포츠 선수가 좋은 결과를 도출할 수 있을까? 사기가 높으면 능률이 오르고 반대로 사기가 낮으면 될 일도 안된다. 업무 지시자에 대한 불만도 쌓이게 되어 결국 팀워크도 망치게 된다.

팀 이기주의 발생

불합리한 마감기한이 불러오는 또 다른 문제는 팀 이기주의 즉, 사일로 현상이 발생한다는 점이다. 애초에 누구도 납득하지 못하는 기한이 주어졌고 번복할 수 없다고 느낄 때 모든 직원이 이 프로젝트는 기한 내 달성되지 못할 하나의 폭탄으로 취급하는 현상을 발견했다. 결국 실패는 100% 예상되는 상황에서 누구의 탓으로 돌아갈지 계산기를 두들기는 것이다. 그에 따라 협업이 핵심인 제품팀의 팀워크에 균열이 가고, 서로 책임을 전가하는 둥 여러 문제점이 발생되는 것을 목격했다. "팀 태스크만 잘 처리하면 되지 뭐."라는 둥 "나만 아니면 돼."라는 둥 팀, 개인 이기주의가 발생하여 가뜩이나 저하된 사기에 기름을 붓는 격이 되고야 만다.

제품 퀄리티 저하

결국 기능 구현에 초점을 맞추다 보니 기획대로, 디자인대로 개발되지 않는 경우가 많다. 일단 넘기고 보자 주의로 개발하게 된다. 개발할 때 충분한 시간적 여유가 주어진다면 개발과 기능 테스트를 병행할 수 있지만 기한이 말도 안 되게 타이트할 경우 선 구현 후 QA로 돌리는 경우가 많다. 어차피 모든 버그가 픽스되고 정상적인 제품으로 릴리즈 되기까지 오랜 시간이 소요되며 여유롭게 개발했을 때보다 작업 기간이 드라마틱하게 줄어들지 않는다.

시니컬한 태도

일단 스트레스에 놓인 직원들의 태도가 썩 긍정적이고 열린 자세이기도 힘들다. 일단 변화에 유연하게 대처하지 못한다. 내 작업에 영향이 조금이라도 가는 의사결정이 나온다면 굉장히 시니컬한 태도로 돌변한다. 직원 간 마음이 상할 수 있으며 이는 팀워크 저하로 직결된다. 여유가 없을 때 사람의 진면목을 볼 수 있다. 여유가 있을 땐 누구나 좋은 사람 코스프레 할 수 있다. 압박감이 그 가면을 벗겨낸다. 이런 면들이 아쉽게 다가온다.

결국 터지는 폭탄

아직 오지 않은 결말이다. 어떻게 될지 걱정되는 시기는 지났다. 결말은 다가오고 뚜껑은 곧 열린다. 직원들은 여전히 반 태업 분위기다. 누가 책임질까? 어떤 결과가 나를 기다릴까? 만약 정말 실패한다면 이 실패를 딛고 재도약할 수 있을까? 의사결정권자들은 이 실패를 통해 배우게 될까? 수많은 질문이 머릿속을 맴돌지만 결국 뚜껑은 열려봐야 안다.

닭 목아지를 비틀어도 새벽은 온다고 했다. 결과만을 기다려야겠다.

[추천도서] 비전공자를 위한 이해할 수 있는 IT지식 : 기획자 개발 지식 입문서

노사수 — Wed, 31 Jan 2024 00:00:26 +0900

기획자로 커리어 전환한 후 처음으로 구매한 책. 구매 목적은 부족한 IT 기술을 익히기 위함이었다.

기획자는 디자이너, 개발자와 유기적으로 소통해야 한다. 기획 업무지식뿐만 아니라 디자인 기초 지식과 개발 기초 지식이 뒷받침되지 않으면 회의 시간에 반절은 이해할 수 없는 상황이 발생된다. 자괴감에 빠지기도 하고 업무 평가를 제대로 받지 못할 수도 있으며 팀워크에 해가 될 수도 있다.

기획자 코딩공부 해야 할까?

이 책을 만난 건 어쩌면 행운이다. 사실 이 책을 구매하기 직전에 구매했던 책이 비전공자를 위한 파이썬 교본이었다. 누구나 처음 IT 환경에 노출되면 코딩을 먼저 배워야 한다고 생각하기 마련이다. 논리는 간단하다. 개발을 직접 해봐야 개발 지식을 쌓을 수 있다는 생각. 하지만 보통의 운영 업무와는 다르게, 개발 지식은 실질적 실무 지식 습득으로 빠른 기간 내에 얻을 수 있는 지식이 아니다. 또한 기획자는 실제 코딩을 하지 않는다. 데이터의 흐름을 파악하고 시스템적 사고를 기르는 것만으로도 개발자와 소통하는데 무리가 없다. 코딩으로 개발 지식을 쌓는 것이 나쁘단 것은 아니다. 하지만 input 대비 output이 좋지 않다. 시간은 금이거늘. 이 책의 핵심은 개발 지식을 쌓기 위해 무리한 코딩공부보다는 데이터 중심의 기획을 하기 위한 다양한 개념에 대해 설명한다.

개발자와의 소통을 위한 기초 지식

이 책은 비전공자가 이해할 수 있도록 기초부터 차근차근 설명한다. OS, 서버(백엔드), 클라이언트(프론트엔드), API, 프레임워크 등 기획에 필요한 기본 IT 지식을 습득하기 용이하다.

기획을 처음 접하거나 IT 환경에 처음 노출된 사람이라면 무조건 이 책을 읽기를 추천한다. 무분별한 코딩보다 개발자와의 원활한 소통, 데이터 흐름, 탄탄한 기획문서 작성을 위해 기초 지식을 쌓는 것이 좋다. 다만, 어느 정도 업무 프로세스를 익힌 단계라면 대부분 아는 내용일 수도 있다. 입문서로써 추천한다.

서비스 개발을 이끄는 사람들: 서비스 기획자 vs 프로덕트 매니저 vs 프로덕트 오너

노사수 — Mon, 29 Jan 2024 23:04:44 +0900

스마트폰이 본격적으로 보급된 이후, 우리나라 IT 기업, 스타트업에서 기획자, PM 관련 채용이 늘어났다. 나 역시 여행 기획자로 오퍼레이팅을 업무를 6년간 이어가다 코로나19를 계기로 서비스기획자로 전형한 사례라고 볼 수 있다.

채용 공고를 살펴보면 서비스 기획자, PM(Product Manager), PO(Product Owner) 등 포지션과 Job Description에서 약간의 차이를 보인다. 그래서 오늘은 세 포지션에 대해 내가 알고 있는 개념과 국내에서 보편적으로 정의하는 대로 적어보려고 한다.

서비스를 문서화하는 사람: 서비스 기획자

서비스 기획자는 말 그대로 서비스를 기획하는 사람이다. 서비스 기획자는 사용자 인터페이스(UI)와 사용자 경험(UX)을 설계하고 개선하는 역할을 한다. 보통 서비스 기획자를 채용하는 공고를 확인하다 보면 IA 작성, 와이어프레임 작성, 플로우 차트 작성 등 화면설계서 작성에 치중된 Job Description을 자주 확인할 수 있다. 아무래도 서비스 기획 본연의 업무를 충실히 수행할 수 있는 역할을 서비스 기획자로 정의할 수 있지 않을까 싶다. 애자일 개발 방법론보다 워터폴 개발 방법론에서 제품 개발의 시작점에서 문서화 작업을 많이 진행하는 포지션이다. 지금 내가 맡은 업무에 가장 근사한 직무라고 생각한다.

제품을 관리하는 사람: Product Manager (프로덕트 매니저)

프로덕트 매니저는 서비스 기획에 국한되지 않고 제품을 총괄하는 역할을 하는 경우가 많은 것 같다. 채용 공고를 살펴보면 프로덕트 매니저는 주로 일정관리, 칸반보드 관리, 스크럼 마스터 등 애자일 개발 방법론에서 쓰이는 여러 기법들에 대한 관리를 원하는 경우가 많았다. 고객 요구 사항을 이해하고 우선순위를 결정하여 제품 백로그를 관리하기도 한다. 프로덕트 매니징 관련 서적을 읽어봐도 프로덕트 매니저는 UIUX, 디자인, 서버 및 클라이언트 등 개발지식이 뒷받침 되어야 하는데 이러한 소프트, 하드 스킬이 갖춰져있지 않다면 기획자, 디자이너, 개발자 사이에서 커뮤니케이션 역할을 충실히 수행할 수 없기 때문이다.

프로덕트 매니저는 업무적 스킬 셋도 필요하지만 결국 제품 혹은 신규 기능이 정상적, 기한 내 배포될 수 있도록 중간 다리 역할을 하는 경우가 많으며 무엇보다 커뮤니케이션 능력이 필요한 직무이다. 앞서 서비스 기획자가 기획 본연의 업무에 집중한다면 프로덕트 매니저는 매니징 역할에 충실한다.

도메인을 총괄하는 사람: Product Owner (프로덕트 오너)

프로덕트 매니저와 가장 구분하기 어려웠던 포지션이 프로덕트 오너이다. 앞서 언급한 두 포지션보다 채용 공고가 덜 눈에 띄기도 한다. 서비스 기획자와 프로덕트 매니저, 프로덕트 오너 간 상하관계를 나열할 수 없지만 보통 프로덕트 오너가 좀 더 높은 위치에서 제품 전체를 관장하는 느낌이다. 프로덕트 오너는 제품 또는 서비스의 비즈니스 가치를 최대화하기 위해 책임을 지는 역할을 수행한다. 시장 이해관계를 파악하고 비즈니스 기회를 엿보며 많은 주요 의사결정을 내리게 된다. 그래서 일각에서 프로덕트 오너를 미니 CEO라고 칭하는 것 같다. 규모가 큰 회사에서는 여러 명의 프로덕트 오너가 각자의 도메인 혹은 제품을 도맡아 비즈니스 기회를 창출한다.

지금까지 정리한 개념은 정답이 아닐 수 있다. 애초에 프로덕트 매니저, 프로덕트 오너 같은 개념은 미국에서 국내로 들어온 지 얼마 되지 않은 개념이라 100% 정립된 개념은 아닌 것 같다. 또한 회사마다 정의하는 개념이 다르기 때문에 대략적인 직무에 대해 파악하면 될 것 같다. 어떤 회사에서는 서비스 기획자가 제품 총괄을 맡기도 하고, 어떤 회사에서는 프로덕트 오너가 백로그 및 스크럼을 관리하기도 한다. 중요한 건 제품에 대한 책임감과 성공적인 비즈니스를 위한 고민과 노력이 아닐까 싶다.

[소프트웨어 개발 방법론] 2탄: 폭포수(Waterfall) 방법론

노사수 — Mon, 29 Jan 2024 00:01:26 +0900

폭포수 개발 방법론 소개

워터폴 개발 방법론은 소프트웨어 개발의 초기에 사용되었던 전통적인 접근 방식 중 하나이 다. 워터폴 방법론은 제조업에서부터 발전해 온 선형적인 개발 프로세스로, 각 단계가 이전 단계의 결과물을 바탕으로 진행 된다. 그렇기 때문에 각 단계별 완성도가 그 다음 단계에 지대한 영향을 미치며 단계별 작업물 완성도가 떨어질 경우 다음 단계 작업에 난항을 겪는다. 초기에는 많은 기업들이 이 방법론을 선호했으나, 현대의 빠르게 변화하는 비즈니스 환경에 적응하기 어려운 측면이 있 다. 이를 타개하고자 애자일 방법론이 탄생한 것이기도 하다.

폭포수 개발 방법론의 단계

폭포수 개발 방법론은 일반적으로 다음과 같은 단계로 구성된다.

1. 요구 사항 정의 : 정책서, IA(정보구조), 와이어프레임 등의 기획문서 작성
2. 설계 : 플로우차트, 다이어그램, DB 설계 등
3. 구현 : 디자인, 개발 등
4. 테스트 : QA 등의 기능 테스트
5. 유지 보수 : 디버깅, 고도화 등

폭포수 개발론의 장단점

폭포수 개발 방법론의 장점은 초기에 요구 사항을 명확히 정의하고, 각 단계가 순차적으로 진행되기 때문에 일정과 예산을 쉽게 관리할 수 있다. 그러나 이 방법론은 변경에 취약하며, 요구 사항이나 디자인 변경이 필요할 경우 비용과 시간이 많이 소요될 수 있다.

적용 사례와 한계

폭포수 개발 방법론은 초기 소프트웨어 개발에 적합한 경우가 있으며, 특히 안정적이고 예측 가능한 프로젝트에 적합하다. 그러나 현대의 빠르게 변화하는 비즈니스 환경에서는 유연성이 부족하며, 고객 요구사항이 자주 변경되는 프로젝트에는 적합하지 않을 수 있다.

애자일 개발 방법론과의 비교

현대적인 소프트웨어 개발 방법론인 애자일, 스크럼 등은 워터폴 방법론의 단점을 극복하기 위해 개발되었다. 이러한 방법론들은 빠르게 변화하는 요구 사항에 대응할 수 있는 유연성을 제공하며, 작은 단위의 반복적인 개발을 통해 프로젝트의 품질과 속도를 향상시킨다. 다만, 폭포수와 애자일 중 어떤 개발론이 좋고 나쁘다고 단정 지을 수 없다. 조직의 구성, 제품의 유형 등에 따라 더 적합한 방법론을 선택하면 된다.

[소프트웨어 개발 방법론] 1탄: 애자일(Agile) 방법론

노사수 — Fri, 26 Jan 2024 23:59:44 +0900

애자일 방법론이란?

애자일 방법론은 소프트웨어 개발 및 프로젝트 관리에서 사용되는 체계적인 접근 방법론이다. 1900년대 초반 제조업에서 시작된 워터폴(폭포수) 방법론의 단점을 보완하기 위해 탄생한 방법론이다. 제조업에서는 설계서를 만들고 공정에 따라 다음 단계로 이동되면서 최종 제품이 만들어진다. 결함이 발생되면 이전 단계에서 수정을 거치게 되어 다음 작업이 보류된다. 애자일 방법론은 변화에 빠르게 대응하고 작동하는 소프트웨어를 위해 구성원 간의 원활한 커뮤니케이션, 계약 자체보다 고객과의 협력을 중시하는 방법론이다. 2000년대 초, 17명의 개발자가 공동 성명을 발표하며 공식 출범하였다.

애자일 소프트웨어 개발 선언

우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있다.
이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다.

공정과 도구보다 개인과 상호작용을
포괄적인 문서보다 작동하는 소프트웨어를
계약 협상보다 고객과의 협력을
계획을 따르기보다 변화에 대응하기를
가치 있게 여긴다.

이 말은, 왼쪽에 있는 것들도 가치가 있지만, 우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.
- Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler,
James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin
Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas
© 2001, 상기 저자들
이 선언문은 어떤 형태로든 자유로이 복사할 수 있지만, 본 고지와 함께 전문으로서만 가능하다.

애자일 선언에 입각한 주요 원칙과 가치

고객 만족을 최우선으로: 애자일은 고객의 요구를 이해하고, 그에 맞춰 제품을 개발하는 것을 중요시한다.
작동하는 소프트웨어 우선: 애자일은 일찍이 작동하는 소프트웨어를 개발하여 고객과의 빠른 피드백을 통해 제품을 지속적으로 개선한다.
개인과의 상호작용: 애자일은 팀 내부의 개인 및 팀 간의 원활한 소통과 협력을 강조한다.
변화에 대응: 애자일은 변화에 대한 대응력을 중요시하며, 유연한 계획과 개발 프로세스를 통해 적응한다.

주요 애자일 방법론 종류

스크럼(Scrum): 스크럼은 짧은 개발 주기를 통해 지속적으로 제품을 개발하는 방법론으로, 백로그 관리, 스프린트 계획, 일일 스탠드업 미팅 등을 포함한다.
익스트림 프로그래밍(XP): 익스트림 프로그래밍은 소프트웨어 품질을 향상시키기 위해 페어 프로그래밍, 테스트 주도 개발(TDD) 등의 실천 방법을 강조한다.
칸반(Kanban): 칸반은 작업을 시각화하고 작업 흐름을 관리하는 방법론으로, 작업 별로 칸반 보드를 활용하여 작업 상태를 추적한다.

애자일 방법론의 장단점

장점

빠른 피드백을 통한 제품 품질 향상 : 워터폴의 경우 완제품 수준의 기획, 디자인을 거쳐 개발 이후 제품을 릴리즈하게 된다. 하지만 오랜 공수를 들여 제품을 출시했다 하더라도 시장에서 외면받을 수 있으며 이런 경우 회사의 리소스를 낭비한 꼴이 된다. 애자일은 MVP 형태로 제품을 신속하게 출시하여 데이터와 고객 피드백을 기반으로 빠르게 제품을 변화시킬 수 있다.

요구사항 변화에 대응 용이 : 제품을 출시하기 전까지 무수히 많은 의사결정의 번복과 피봇팅이 일어날 수 있다. 보통의 조직은 그러한 변화에 민감하며 코드를 다시 짜야한다거나 지금까지의 작업물이 무용지물이 되는 것에 허탈감을 느낀다. 하지만 애자일 문화가 정착한 조직은 변화에 유연하게 대처하며 더 나은 방향을 위해 기꺼이 받아들일 수 있다.

단점

프로세스 변화에 대한 조직적 저항 : 기존 워터폴 방식을 채택한 제품팀에서는 전혀 다른 프로세스에 대한 의구심 및 저항심이 발생할 수 있다. 애자일 방법론을 통해 업무 효율성 향상, 성공적인 제품 출시 이전까지는 저항심은 계속될 수 있다.

맞지 않은 옷을 입는 경우 : 조직 구조가 수직적이고 탑다운 방식의 업무 지시가 일어나는 조직에서는 워터폴이 적합하다. 유행을 따른답시고 애자일 방식을 무턱대고 채택했다간 체계가 무너지고 개발이 난항에 빠질 수 있다.

잘못 적용된 사례 : 일각에서는 애자일이 정책도 문서도 없이 작업자들이 임기응변으로 후다닥 개발하면 된다고 착각하는 경우가 많다고 한다. 정책의 누락 시에도 기적의 단어 애자일을 외치며 "이제 정하면 되지 이게 애자일이잖아" 라며 자기 위로를 한다고. 이러한 사례 때문에 아직 국내에서는 애자일이 꿈같은 이야기라는 얘기가 나오는 게 아닌가 싶다.

애자일의 적용과 최적화

애자일 방법론은 유연성과 적응성을 통해 다양한 프로젝트에 적용할 수 있다. 그러나 프로젝트의 특성에 따라 적절한 애자일 방법론을 선택하고, 팀의 동료들과의 협력을 강화하며 지속적으로 프로세스를 개선하는 것이 중요하다. 또한 애자일과 워터폴 중 어떤 게 더 낫다고 할 수 없다. 조직마다, 프로젝트마다 더 맞는 방식이 있을 것이다. 다양한 방법론을 시도해 보고 조직에 맞는 방법론을 채택하는 것이 중요하다.

[회고] 팀워크를 향상시키는 데일리 스크럼(Daily Scrum)

노사수 — Wed, 24 Jan 2024 23:02:17 +0900

지겹지만 반복해야 하는 데일리 스크럼

데일리 스크럼은 애자일 소프트웨어 개발에서 사용되는 일일 회의로, 팀원 간의 협업과 작업 진행 상황을 효과적으로 공유하는 데 도움을 주는 회의 방식이다. 짧은 시간 내에 끝내는 것을 목표로 하며 스탠드 회의 형태로 진행되기도 한다.

데일리 스크럼 진행 방법

1. 시간 및 장소 설정

데일리 스크럼은 일정한 시간과 장소에서 진행되어야 한다. 일반적으로 업무 시작 전 진행되며 15분 이내 짧게 진행하는 편이 좋다. 회의 장소는 중요하지 않다. 보통 팀원 간 자리가 가까운 경우 사무실 내에서 진행해도 되고 인원이 많거나 집중해서 빠르게 끝내려면 회의실을 잡고 진행하는 것도 좋다. 사무실 한편에서 스탠드 미팅 형태로 진행하는 것도 불필요한 시간을 허비하는 것을 방지할 수 있다. 핵심은 빠르게 공유하고 해산하는 것이다.

2. 진행 상황 공유

각 팀원은 어제 한 일, 오늘 할 일, 그리고 장애물 또는 도움이 필요한 부분에 대해 간단하게 공유한다. 이는 구성원이 서로 to-do list를 공유하고 업무 진척율을 공유하며 서로 협업할 수 있는 방법을 찾기 위함이다.

3. 문제 해결 및 토론

앞서 언급했듯, 업무 공유 뿐만 아니라 각 구성원이 겪고 있는 문제를 빠르게 해결하기 위해 각자 막히는 부분을 공유하고 도움을 청할 수 있는 시간이 되어야 한다. 팀원들은 문제 또는 도움이 필요한 부분에 대해 토론하고, 다른 팀원들이 도움을 제공하거나 의견을 나눌 수 있어야 한다.

4. 목표 확인

팀은 현재 스프린트 또는 주기의 목표를 기억하고, 해당 목표에 도달하기 위한 계획을 공유해야 한다.

스크럼 마스터의 역할

데일리 스크럼은 스크럼 마스터가 주관한다. 스크럼 마스터는 데일리 스크럼이 원활하게 진행되도록 도와주는 진행자 역할을 수행한다.

시간제한은 필수

데일리 스크럼은 빠르게 진행되어야 하는 것이 핵심이다. 보통 15분 내에 끝나도록 노력해야 한다. 스크럼이 불필요한 회의라고 인식되어선 안되며 번거롭더라도 꼭 필요한 업무 절차임을 항상 주지시켜야 한다. 그러기 위해 빠르고 효율적인 스크럼 진행이 선행되어야 한다.

[회고] 스프린트 회고 방법론 4L 회고

노사수 — Tue, 23 Jan 2024 00:18:49 +0900

우선 회고란 무엇일까? 회고의 사전적 정의는 '뒤를 돌아봄', '지나간 일을 돌이켜 생각함'이다. 말 그대로 지난 일을 생각하며 실패의 원인을 찾거나 좋았던 점을 상기시키기 위함이다.

기획자에게 회고는 왜 중요할까?

첫째, 회고를 통해 이전 스프린트나 일련의 결정에 대한 경험을 평가하고 배울 수 있다. 무엇이 잘되었고 어떤 문제가 발생했는지를 분석하여 앞으로의 스프린트나 프로젝트에서는 더 나은 결과를 얻을 수 있다.
둘째, 회고는 향후 기획에 영향을 미칠 수 있는 중요한 통찰력을 제공한다. 이전 경험을 반영하면서 새로운 프로젝트를 계획할 때, 비슷한 도전에 대한 대비책을 마련하거나 성공 사례를 활용할 수 있다.
셋째, 팀 내 의사소통을 강화하는 데에도 도움이 된다. 회고를 통해 팀원들은 서로의 관점을 이해하고 개선점을 공유할 수 있다. 이는 효과적인 협업과 문제 해결에 도움이 된다.

회고의 중요성은 알겠는데, 회고는 어떻게 해야 할까? 우선 대표적인 회고 방법론으로는 KPT, 4L 등이 있다. 우리 팀에서는 4L 회고를 채택했으며, 자세한 내용은 아래와 같다.

4L 회고의 구성

Liked (좋았던 점): 프로젝트나 작업에서 성공적으로 진행된 부분이나 긍정적인 경험
Learned (배운 점): 새로운 지식, 기술, 또는 팀원 간의 협력에서 얻은 교훈
Lacked (부족했던 점): 부족한 자원, 정보, 또는 기술 등을 파악하고 개선할 수 있는 방안
Longed For (바라는 점): 미래에 개선되었으면 하는 부분이나 바라는 상황을 나누고, 그에 따른 목표를 설정

4L 말고도 KPT 회고 방법론도 많이 쓰이는데 결국 4L 회고 방법론과 맥락은 같다.

KPT 회고의 구성

Keep (유지할 점): 현재까지의 프로세스 중 유지해야 할 좋은 점
Problem (문제점): 발생한 문제나 도전에 대한 이해를 도출하고, 그 문제를 해결하기 위한 방안 논의
Try (시도할 점): 새로 시도해 볼 아이디어나 개선안을 공유하고, 다음 단계에서 시도해 볼 계획을 수립

회고 진행해야 방법

업무 툴 설명할 때도 언급했지만 결국 툴이 중요한 게 아니라 진행하는 사람이 중요한 것은 불변의 진리다. 툴은 도구로써 거들뿐, 중요한 건 귀찮은 회고를 유지하겠다는 의지와 회고의 중요성을 지속적으로 구성원들에게 상기시키는 것이다.

우리 팀은 노션을 통해 매 스프린트가 종료된 이후 약 한 시간 가량을 투자해 회고를 진행했다. 회고 템플릿은 직접 만들었으며 표 형태로 리스트업 하고, 세부 페이지를 보드 형태로 작성하였다.

스프린트 기간, 참여자, 회고 시간, 진행자를 설정하고 회고 보드에 4L 방법론에 따라 카드를 만든다. 카드 생성은 10분 가량 작성 시간을 할당하고 작성이 끝나면 회고 진행자가 카드를 하나씩 조회하며 지난 스프린트에 대한 회고를 공유한다.

사용하고 있는 툴이 없다면, 가장 전통적인 방식을 사용할 수 있는데, 구성원들에게 포스트잇을 나눠주고 화이트보드나 벽에 붙여서 공유하는 방식도 있다. 앞서 언급했듯 업무에 있어서 툴은 거두는 수준이다.

정말 제대로 진행하려면 회고에 대한 트래킹도 진행해야 한다. 좋았던 점이 지속적으로 유지되는지, 부족한 점이 다음 스프린트에도 이어지지는 않는지 리더가 관리하면 좋다.

요약

회고는 지난 경험을 돌아보고 배움으로써 향후 발전을 도모하는 과정이다.
기획자에게는 이전 결정과 경험을 평가하여 향후 계획에 적용하고, 팀 내 의사 소통 강화에 도움이 된다.
4L과 KPT는 대표적인 회고 방법론으로, 좋았던 점, 배운 점, 부족했던 점, 바라는 점을 고려한다.
회고는 노션 등의 툴을 활용하거나 포스트잇과 화이트보드를 활용하여 진행되며, 지속적인 트래킹이 중요하다.

[회고] 팀장의 다양한 유형: 각 유형의 장단점 살펴보기

노사수 — Sun, 21 Jan 2024 17:05:13 +0900

내가 겪은 팀장들

신입사원 시절 회사생활이 너무 힘들어 위안을 삼고자 드라마 미생을 시청한 적이 있다. 그때 느낀 건 신입사원 장그래 시점에서만 바라볼 것이 아니라, 중간에서 치이는 팀장, 자리를 지키기 위해 노력하는 임원 등 결국 회사라는 조직에서는 각 위치별 고충이 다를 뿐 누구나 힘들다는 것. 팀장이라는 직책의 고충을 처음으로 느낄 수 있었고 결국 조직에서 좋은 리더로 성장하기 위해 내가 섬겨온 팀장님들의 성향과 장단점 등을 회고해 보고 좋은 점은 배우고, 나쁜 점은 반면교사 삼기 위해 이 글을 작성한다.

1. 위임형 리더

부하 직원이 믿음직스럽든 그게 아니든 간에 부하직원에게 권한과 책임을 상당 부분 위임하는 타입. 직원이 스스로 동기부여할 수 있는 타입이거나 능동적인 태도를 보이는 직원과 잘 맞는다. 결정적 책임은 대신 져주되, 사소한 책임은 구성원 스스로가 가질 수 있도록 적절히 독려한다. 그로 인해 구성원의 책임감과 오너십이 쌓여 본인의 제품에, 혹은 프로젝트에 주인의식이 생기는 걸 볼 수 있었다. 다만 문제는 부하직원의 성향이 소극적이고, 일부 나태한 경향이 있을 때는 역효과를 보기 쉽다. 이건 육아와도 같은데 대충 키웠는데도 판검사 되는 사람이 있는 반면 스타강사를 아무리 붙여줘도 인생을 허무하게 사는 사람도 있기 마련이기 때문이다.

2. 마이크로매니징 리더

사소한 것 하나하나 간섭하며 부하 직원의 개성을 박살 낸다. 스스로 일을 찾는 능동적인 직원과 상성이 좋지 않다. 구성원이 이런저런 시도 끝내 본인만의 방법을 찾을 때까지 기다리지 못하고 본인의 성공 방정식을 부하직원에게도 투여한다. 성향에 따라 그게 잘 맞는 경우도 있지만 그렇지 않을 경우 의욕을 잃기 쉽다. 어렵게 낸 목소리가 반영되지 않고 내가 원하지 않는 방식을 강요하면 마치 꼭두각시가 된 기분이 들 것이다. 설령 그 방식이 옳다 하더라도 말이다. 다만, 위임형 리더와 상성이 좋지 않은 나태한 부하직원에게는 최고의 상사가(회사 관점에서만 보자면, 당연히 부하직원 입장에선 피곤하다) 될 수 있다. 그런 사람들은 채찍질해 줄 사람도 필요한 법이기 때문이다.

3. 회피형 리더

의사결정을 쉽게 내리지 못한다. 책임에 큰 부담을 느끼기 때문이다. 개인적으로는 위 두 타입보다 이 타입이 제일 리더 자격이 없다고 생각한다. 팀장의 자리가 그러하거늘 책임회피를 할 거면 왜 팀장을 하고 있는지 모르겠다. 위임형 리더의 경우 선택은 부하직원이 할 수 있도록 돕지만 책임은 리더 본인이 진다. 다만 회피형 리더는 선택도 부하직원이, 책임도 부하직원이 진다. 어느 정도 완충제 역할을 하지 않으면 지레 겁먹고 좋은 결과물을 도출할 수 없게 된다.

4. 사일로형 리더

이건 업무적 성향이라기보다는 의사소통의 문제인데, 우리 팀에 해가 되는 모든 원인을 원천적으로 봉쇄하는 타입이다. 협업하기 힘들고 방어적 자세로 나오다 보니 좋은 방향으로 흘러가지 못하는 경우가 많다. 물론 팀장이 본인 팀만 생각해야 하는 것도 맞지만 결국 회사의 목표가 각 팀의 성장이 아닌 회사의 성장이라는 점에 있어서 회사의 공동 목표에 저해되는 요소이기도 하다. 다른 팀에서 자기 팀원을 질책하는 것을 싫어하며 프로젝트에 문제가 발생할 경우 우리 팀 문제가 아니면 전혀 신경 쓰지 않는다.

좋은 리더란?

결국 좋은 리더란, 구성원들에게 적절한 권한과 책임을 동시에 줄 수 있는, 구성원이 감내하기 힘든 책임은 내가 질 수 있는, 구성원의 개성을 존중해 주고 부족한 구성원에게 길을 제시해 주는, 팀이 아닌 회사의 성장을 위해 적절히 커뮤니케이션할 수 있는, 빠르고 옳은 의사결정을 내려줄 수 있는, 공을 구성원과 나눌 수 있는 리더이지 않을까 싶다.

글로벌 OTA 트립닷컴 사용기

노사수 — Sun, 21 Jan 2024 16:22:49 +0900

세계 3대 OTA 트립닷컴

트립닷컴은 중국의 Ctrip 계열 OTA(Online Travel Agency)이다. 익스피디아 그룹, 부킹홀딩스(Booking.com)와 전 세계 여행 시장을 점령하다시피 하고 있다. 국내에 처음 선보였을 때 틸다 스윈튼과 이시언의 TV광고가 재밌게 다가온 기억이 난다.

홈 : 서치바

모든 메뉴를 둘러볼 순 없으니 호텔 구매 과정을 둘러보기로 했다. 우선 홈 영역의 서치바를 살펴보았다.

서치바의 여행지 입력 영역의 placeholder 내용처럼, 랜드마크 단위로의 검색도 가능하다, 예를 들면 파리, 런던 등 도시검색이 아닌 에펠탑, 런던아이 등 해당 도시의 관광지 혹은 랜드마크 주변 호텔을 검색할 수 있단 뜻이다.

다음은 DatePicker, 공휴일에 별도 표시가 되어있고 마우스오버(혹은 hover) 시 좌측 하단 영역에 공휴일명이 표시된다.

객실별 인원수 설정이 가능하고 어린이 동반 시 어린이 나이를 설정할 수 있다. 호텔 정책 상 3인실에 소아만 투숙 가능한 케이스나 별도의 엑스트라 베드 없이 더블베드에서 동반투숙 가능한 어린이를 구분하고자 하는 것 같다.

호텔 검색결과 화면

조건값 입력 후 검색버튼 클릭 시 검색결과 화면으로 전환된다. 좌측은 필터영역, 우측은 호텔 카드 영역인데 주로 쓰는 정렬값을 검색카드 상단으로 별도 분리해 원클릭으로 오더링 할 수 있도록 기획했다. 필터영역에서 눈에 띄는 점은 인기 검색 조건을 추려 최상단 배치했다는 점이다. 다년간의 유저 데이터 축적을 통해 기획했으리라 생각된다.

호텔 상세페이지

마음에 드는 호텔을 클릭하면 호텔 세부정보가 나온다. 호텔 주소와 연락처 정보, 호텔 및 객실, 부대시설 이미지, 편의시설과 주변 명소에 대한 정보가 서머리 형태로 표기된다. 호텔과 호텔을 비교할 때 유용한 정보를 우선 배치했다.

좌측이 트립닷컴, 우측이 부킹닷컴

스크롤을 조금 내리면 객실정보가 표시된다. 상단 호텔 정보에서 호텔을 확정한 다음 보통 객실을 선택하므로 적절한 플로우인 것 같다.

개인적으로 부킹닷컴 객실선택 UI를 굉장히 싫어하는데, 필요 이상으로 디테일한 정보들이 텍스트형태로 나오다 보니 가독성도 떨어지고 피로감이 쌓이는 반면 트립닷컴의 경우 객실 플랜 별 옵션을 요약 형태로 보여주고, 객실 투숙 정원 및 편의시설 정보를 아이콘 형태로 표기한다.

투숙객 정보 입력 화면

좌측은 새로운 이메일 주소, 우측은 회원가입된 이메일 번호를 기입했다.

예약이 비로그인 상태에서 진행되었는데, 투숙객 정보 입력 시 회원가입 이력이 없다면 좌측 이미지처럼 회원가입을 유도했으며 회원가입 이력이 존재할 경우 우측 이미지처럼 인증번호 입력 후 하나의 계정에 예약건을 쌓을 수 있도록 도와준다. 레퍼런스 삼기 좋은 기능인 것 같다. 회원가입 유도의 경우에도 비밀번호만 입력하면 바로 회원가입이 되기에 굉장히 편리한 것 같다.

결제정보 입력 화면

결제는 신용카드 키인(Key-in) 형태로 진행된다. 별도의 간편결제나 PG 결제창을 호출하지 않는 걸로 승인과 매입이 OTA가 아닌 현지 호텔로 처리되는 것으로 보인다.

총평

트립닷컴이 여행 도메인에서 가장 UIUX에 신경쓴 서비스라는 생각이 많이 든다. 때문에 서비스 기획을 할 때 트립닷컴을 레퍼런스로 많은 벤치마킹을 한다. 물론 주의해야 할 점도 있는데, 국내와 해외의 적용되는 법규가 다르므로, 무조건 적으로 차용하기보단 국내 적용 가능 여부를 재확인해볼 필요가 있다.

[Notion] 노션으로 프로덕트 관리하는 방법(Product Managing)

노사수 — Sun, 21 Jan 2024 15:42:59 +0900

우리 팀은 노션으로 프로덕트를 관리한다. 신규 기능 및 기존 제품의 기능 고도화할 때 관리가 용이해서다.

노션을 쓰는 이유

노션은 칸반보드, 테이블, 캘린더, 페이지 등 다양한 형태로 작업물을 작성, 보관할 수 있으며 클라우드 기반의 구독형 SaaS 제품이므로 큰 비용이 들지 않으며 실시간 협업이 가능해서 대만족 하며 사용하고 있다. 편집이 용이하고 사용성에도 신경을 많이 썼다. 서버에서 불러오는 속도도 빠르고 한국어 최적화도 figma에 비해 압도적으로 잘되어있다.

노션 템플릿 적용

우선 새 페이지를 작성하고 템플릿을 클릭한다. 노션은 다양한 카테고리의 수많은 템플릿을 무료로 제공하므로 처음부터 만들 필요가 없다.

추천 템플릿의 프로젝트, 작업, 스프린트 템플릿을 선택 후 우측 하단 템플릿 사용하기 버튼을 클릭한다.

SNB(좌측 메뉴)에 작업, 프로젝트, 스프린트보드, 스프린트 네 메뉴가 생성되었다. 하나씩 차근차근 살펴보고자 한다.

프로젝트 메뉴

우선 프로젝트 메뉴에 들어가 신규 프로젝트를 생성하자. 신제품 혹은 기존 제품의 추가 기능 혹은 고도화 단위로 생성하면 된다.

작업 메뉴

프로젝트가 생성되면 작업 메뉴에 들어가 해당 프로젝트의 작업물을 생성한다. 보통 큰 단위의 에픽을 생성하고 에픽의 하위 작업물을 생성해 관리한다. 제품 > 기능 > 에픽 > 작업 정도로 쪼갠 뒤 카드를 생성하면 좋다. 업무 단위를 작게 쪼개서 작업 성취감을 높이고 오너십을 스스로 느낄 수 있도록 도움을 주는 것이 좋다. 작업 카드를 생성한 뒤에는 작업다(담당자)를 배정해 준다.

스프린트 메뉴

다음으로 스프린트 메뉴에서 스프린트 기간을 설정한다. 스프린트란, 말 그대로 전력질주라는 말이다. 일종의 마일스톤, 로드맵과 같은 의미로 쓰일 수 있으며 목표를 달성하기 위해 전력질주할 기간이라고 이해하면 좋다. 보통의 스프린트는 2주에서 한 달 정도로 정한다. 구현하고자 하는 제품 혹은 기능의 로드맵을 작성하고 각 스프린트로 나눠 제품 진척률을 추적하면 좋다. 너무 방대한 목표는 작업자를 지치게 만드는 경우를 많이 봐왔다. 그러므로 구성원들이 스프린트 목표에만 집중할 수 있도록 작은 단위로 쪼개고 업무를 할당하는 것이 매우 중요하다. 앞서 생성한 작업에 스프린트를 지정하여 스프린트별 처리해야 할 작업물의 진척률을 관리할 수 있다.

타임라인 보기를 통해 스프린트 별 기간을 파악할 수 있다. 각 스프린트 별 기한을 최대한 지켜야 다음 스프린트에 지장을 주지 않는다.

스프린트 보드 메뉴

이제 칸반 형태의 스프린트 보드에서 각 담당자에게 할당된 작업 혹은 에픽의 진행 상태를 확인하면서 프로젝트를 관리하면 된다.

정리하자면

프로젝트 생성 -> 작업(일종의 to-do List) 생성 후 담당자 배정 -> 스프린트 설정 후 작업 카드 연결 -> 스프린트 보드로 진행상황 관리

순서로 작업하면 된다. 스프린트를 우선 설정 후 작업 카드를 생성해도 상관없다. 스프린트 별로 기한 내 작업이 완수될 수 있도록 구성원을 독려하고 공통의 목표를 위해 나아갈 수 있도록 북극성 지표를 꾸준히 상기시켜 주자.

지금 바로 업무 효율성을 극대화해 보세요! (노션 바로가기 클릭)

돌아가는 이미지 캐러셀(Carousel)

노사수 — Sat, 20 Jan 2024 00:38:49 +0900

캐러셀이란?

캐러셀의 사전적 정의는 회전목마. UIUX 용어로 사용될 땐 회전목마처럼 반복해서 돌아가는 형태의 이미지를 뜻한다. 캐러셀은 주로 커머스에서 메인 배너 영역에서 쉽게 볼 수 있다. 다른 단어로는 이미지 로테이터 혹은 슬라이더라고도 불린다.

캐러셀은 언제 사용할까?

다양한 랜딩페이지 배너나 이미지를 표현하고자 할 때, 한정된 영역 안에서 유저로 하여금 추가 콘텐츠가 있음을 알려줄 수도 있고, 자동으로 로테이션을 돌려 중요도 순으로 프로모션을 홍보할 수도 있다. 그래서인지 모바일, 태블릿 사이즈에서 더욱 자주 볼 수 있다.

캐러셀 예시

상기 이미지와 같이 슬라이더 형태로 드래그해서 넘기는 경우에는 다음 이미지가 걸쳐 보이도록 표현해야 한다. 그래야 유저로 하여금 행동을 유도할 수 있다. 이미지가 걸쳐있지 않고 영역을 모두 채운다면 유저가 고정된 단일 이미지로 착각할 수 있다.

혹은 상기 이미지처럼 arrow 아이콘과 이미지 하단에 이미지 개수를 표현해도 마찬가지로 다음 이미지가 있음을 유추할 수 있게 한다.

스크롤 중에도 고정되는 Sticky Side Bar

노사수 — Fri, 19 Jan 2024 21:10:10 +0900

오른쪽에 따라다니는 애

기획을 하다 보면 디자이너 혹은 개발자와 소통할 일이 잦다. 기획 화면을 공유하면서 화면 설명을 하다가 갑자기 커뮤니케이션이 막혔다.

"이거, 이거 있잖아요."
"이게 뭔데요?"
"이 오른쪽에 계속 따라다니는 애요."

커뮤니케이션을 할 때 잘 정의된 유비쿼터스 랭귀지, 혹은 UIUX 용어를 서로 간에 잘 숙지하고 있으면 이러한 불필요한 대화를 줄일 수 있다. 문제는 UIUX 관련 용어가 보통 영어 단어 그대로 쓰는 경우가 많아 여전히 외우기도 어렵고 부르기도 어려운 게 현실이다.

유비쿼터스 랭귀지란?

Ubiquitous language(보급어)는 소프트웨어 개발에서 사용되는 특별한 언어로, 모든 관계자 간에 공유되고 이해하기 쉬운 언어를 의미합니다. 이 용어는 주로 도메인 주도 설계(DDD)와 관련이 있습니다. 개발자, 비즈니스 분석가, 고객 등 모든 팀 구성원이 동일한 용어와 의미 체계를 사용하여 의사 소통하면서 프로젝트의 효율성과 이해도를 높일 수 있습니다. Ubiquitous language를 구현하면 소프트웨어 개발 프로세스에서 발생하는 혼란을 최소화하고 일관된 이해를 도모할 수 있습니다.

Sticky Side Bar

이미지에서 알 수 있듯, Sticky Side Bar는 단어 그대로 따라다니는 사이드 바를 지칭한다. 국내에서는 플로팅메뉴, 플로팅배너 등으로 사용하기도 한다. 페이지 콘텐츠가 긴 경우 스크롤을 하며 콘텐츠를 읽는다. 그때 일반 Side Bar의 위치가 고정되어 있어 스크롤 다운 시 페이지에서 사라지게 된다. 하지만 콘텐츠를 읽어 나감과 동시에 메뉴를 표시해야 할 때는 Sticky Side Bar를 이용하여 스크롤이 끝나는 시점까지 사이드바를 유저에게 노출시킬 수 있다.

[EasyRes] 맥북에서 확장 모니터 화면이 안나올 때 해결방법

노사수 — Thu, 18 Jan 2024 11:38:04 +0900

맥북 확장모니터 출력 문제

맥북 프로 13인치를 사용하면서 두 달 넘게 나를 괴롭히던 확장 모니터 출력 문제를 해결한 방법을 소개하고자 한다. 화면이 출력되지 않아 모니터도 바꿔보고, HDMI 연결선과 컨버터까지 이것저것 시도해 봤지만 여전히 확장모니터 출력이 되지 않았다.

구글링을 통해 알게 된 사실은 LG 모니터의 경우 주파수 문제로 인해 외국에서도 나와 비슷한 현상을 겪는 사람들이 많다는 것이다. LG 모니터는 정해진 주파수 내에서만 화면을 송출하는데 초기 설정 시 높은 주파수로 잘못 설정되었던 것이 문제였다.

MacOS 업데이트 후 주사율 설정 문제

여기서 문제는, Ventura OS 13.0.1 버전에서는 디스플레이 설정에서 모니터 주사율(Refresh Rate) 설정이 존재하지 않았던 것이다.

(현재 Sonoma OS 14.2.1 버전에서는 설정 - 디스플레이 - 고급 - 목록으로 해상도 보기 토글 ON 할 경우 해상도 리스트가 표시된다.)

확장모니터 해상도 문제를 해결하기 위해 열심히 구글링 한 결과 EasyRes 라는 앱을 알게 되었다.

EasyRes 소개

EasyRes는 플러그인 처럼 주 모니터와 확장 모니터의 해상도를 변경할 수 있으며 상당히 많은 옵션을 제공한다. 앱 설치 후 실행해보니 나의 확장모니터가 Retina (2X)로 설정되어 있는 것을 확인했다.

바로 Standard (1x) 1920 x 1080 25Hz "1080p" 값으로 변경해 주니 몇 달 동안 나를 괴롭혔던 모니터 문제를 해결할 수 있었다. 역시 문제 해결은 구글링이 최고다.

[PowerMockup] PPT 연동 플러그인 파워목업으로 와이어프레임 제작하기

노사수 — Thu, 18 Jan 2024 00:06:25 +0900

기획자의 무기, 기획툴

디자이너에게 포토샵이나 피그마, 개발자에게 VS Code나 IntelliJ가 있다면 기획자에게는 다양한 와이어프레임 제작 툴이 존재한다. 화면설계서, 와이어프레임, 스토리보드. 뭐라고 부르던 기획문서를 작성하는 것이 기획자의 기본이다.

기획툴 종류는?

기획서 작성은 파워포인트, Figma, Adobe XD, Sketch 등 다양하며 회사마다 사용하는 툴이 다르고 기획자마다의 선호도도 다르다. 툴이 중요하지는 않다. 작업은 어차피 사람이 하는 것이고 기획자가 얼마나 꼼꼼하고 직무 스킬이 높냐에 따라 기획서 퀄리티도 갈린다.

가볍지만 강력한 기획툴 PowerMockup

그중에서 파워포인트에 플러그인 형태로 설치해 사용할 수 있는 PowerMockup이라는 와이어프레임 제작 툴을 소개하고자 한다. 다양한 컴포넌트 라이브러리를 활용하여 손쉽게 와이어프레임을 제작할 수 있다.

현재 내가 사용 중인 Figma는 디자이너 친화적인 업무툴이라고 생각한다. 물론 Figma에도 다양한 플러그인이 존재하고, 커뮤니티에서 다양한 디자인 시스템이나 컴포넌트 라이브러리를 사용할 수 있긴 하지만 지금까지 딱히 유용하게 써본 경험이 없긴 하다.

파워목업은 PC, Moblie Web과 App 기획에 모두 유용하게 쓰일 수 있는 800개 이상의 UI 컴포넌트를 제공한다.

한 번 구매로 평생 소장

대부분의 업무툴이 월 구독형 과금모델인데 비해 와이어프레임은 구매 시 평생 사용할 수 있다. 트라이얼 버전에서는 사용할 수 있는 기능이 매우 한정적이기 때문에 유료 플랜을 구매해서 사용하는 것이 좋다. 파워목업은 블로그나 SNS에 홍보 글을 기재해서 파워목업 홈페이지에 바우처를 신청할 수 있다. 나 또한 예전에 게시물을 작성해서 무료로 다운로드할 수 있었다.

파워목업의 장점

가장 마음에 드는 것은 MS PowerPoint에서 플러그인 형태로 사용할 수 있다는 점.
피그마보다 훨씬 가볍고 수정이 매우 간편하며 회의 시에도 빠른 의사결정을 할 수 있을 것 같다.

기존 제공되는 Shape뿐만 아니라 원하는 요소들을 언제든 검색하여 추가할 수 있다.

기획툴을 써야 하는 이유

기획자와 디자이너의 역할은 확실히 구분되어 있다. 기획자는 정책서를 작성하고 와이어프레임을 lo-fi 형태로 빠르게 구현하는 것이 중요하다. 업무 시간은 한정되어 있고 그 시간을 정책의 구멍을 메우는 것이 와이어프레임을 hi-fi 형태로 이쁘게 작성하는 것보다 중요하다.

또한 lo-fi 형태로 제작 시, 디자이너가 더욱 창의적인 산출물을 만드는데 도움이 된다. 뭔가 완성된 듯 완성되지 않은 형태의 와이어프레임을 전달받으면 디자이너의 역할이 축소되고 정해진 레이아웃 내에서 처리해야 할 것 같은 느낌이 들기 때문이다.

앞서 설명했지만 업무툴이 중요하지 않다. 무엇보다 기획서를 작성하는 사람이 중요하며, 제품은 혼자 만드는 것이 아니기에 각자의 팀에서, 회사에서 가장 효율적으로 업무할 수 있는 툴을 찾는 것이 중요하다.

카드정보 과연 DB에 저장해도 되는가?

노사수 — Wed, 17 Jan 2024 01:27:22 +0900

인공지능 진짜 대단하다. 이런 이미지도 제작 가능.

PG는 꼭 연동해야할까?

기획하고 있는 제품의 도메인 특성상 PG사를 이용하지 않고 승인/매입이 이뤄진다. 보통 PG 결제창을 호출하여 다양한 결제수단을 이용하는 것이 커머스나 플랫폼에서 흔히 사용하는 방식이다. 다만 이 경우 가맹점 수수료가 2~4%까지 부담스러운 수준이다. 상품가가 100만 원이 넘어선다면 수익률이 상당히 악화될 것이다.

앞서 언급했듯 도메인 특성상 PG를 사용하지 않다 보니 Key-in 호출을 통해 결제를 진행한다. 장점은 UI 커스터마이징이 가능하여 톤 앤 매너를 맞춰 결제창을 구현할 수 있으며 별도 팝업창이 뜨지 않아 정보 입력 후 바로 결제가 완료된다.

단점으로는 매 번 결제 시마다 카드정보를 재입력해야 한다는 점이다. 이 부분을 해결하기 위해 유저 카드정보 입력값을 서버에 저장하자는 의견이 나오게 된다.

과연 이 정보 저장해도 될까?

신용카드 결제정보 저장해도 될까?

많은 시간을 들여 서치를 해도, GPT에 물어봐도, 국내 최대 기획 커뮤니티 맥*님의 단톡방에서 질문해도 뚜렷한 답을 구할 수 없었다. 그래서 그 답을 직접 찾기로 했으며 그 과정을 서술하려 한다.

일단 기획자 커뮤니티에 물어봤을 때, 100% 저장하지 말라는 답변이 돌아왔다. 리스크가 너무 크기 때문이다. 도용된 카드정보로 비정상 결제가 일어난 경우 책임이 정보가 유출된 가맹점에 있다.

여신금융업법 17조

여신금융업법 17조에 해당되는 내용이다.

제17조(가맹점에 대한 책임) ① 신용카드업자는 다음 각 호의 어느 하나에 해당하는 거래에 따른 손실을 신용카드가맹점이 부담하도록 할 수 없다. 다만, 신용카드업자가 그 거래에 대한 그 신용카드가맹점의 고의 또는 중대한 과실을 증명하면 그 손실의 전부 또는 일부를 신용카드가맹점이 부담하도록 할 수 있다는 취지의 계약을 신용카드가맹점과 체결한 경우에는 그러하지 아니하다.
1. 잃어버리거나 도난당한 신용카드를 사용한 거래
2. 위조되거나 변조된 신용카드를 사용한 거래
3. 해킹, 전산장애, 내부자정보유출 등 부정한 방법으로 얻은 신용카드등의 정보를 이용하여 신용카드등을 사용한 거래
4. 다른 사람의 명의를 도용하여 발급받은 신용카드등을 사용한 거래
② 제1항 각 호 외의 부분 단서에 따른 계약은 서면 또는 전자문서로 한 경우에만 효력이 있으며, 신용카드가맹점의 중대한 과실은 계약서에 적혀 있는 사항만 해당한다. <개정 2023. 3. 21.>
[전문개정 2009. 2. 6.]

카드정보 암호화해서 저장했다 하더라도 해킹당해서 털리면? 피해액 전액 혹은 일부를 가맹점, 즉 유출당한 회사에서 책임져야 한다. 이렇게 계속 정보를 찾던 중 하나의 기사를 발견하게 되는데..

자기자본 400억원, FDS 도입한 PG사에 카드정보 저장 허용

https://www.etnews.com/20141001000259#:~:text=%EC%B9%B4%EB%93%9C%EC%A0%95%EB%B3%B4%20%EC%A0%80%EC%9E%A5%EC%9D%B4%20%ED%97%88%EC%9A%A9%EB%90%98%EB%8A%94%20PG%EC%82%AC%EB%8A%94%20%EC%9E%90%EA%B8%B0%EC%9E%90%EB%B3%B8,%EA%B3%B5%EC%A0%9C%EC%97%90%20%EA%B0%80%EC%9E%85%ED%95%B4%EC%95%BC%20%ED%95%9C%EB%8B%A4.

자기자본 400억원, FDS 도입한 PG사에 카드정보 저장 허용

자기자본 400억원, 순부채비율이 200% 이하인 전자지급결제대행업체(PG)는 카드정보 저장이 허용된다. 단 부정거래방지시스템(FD...

www.etnews.com

해당 기사와 관련 기사를 찾아보니, 기존에는 카드사만 카드 인증 정보를 저장할 수 있었는데 구매자 편의성 측면에서 적격 PG에 카드정보 저장할 수 있도록 법을 개정한다는 내용이었다.

카드정보 저장이 허용되는 PG사는 자기자본 400억원 이상, 순부채비율 200% 이하(고객 예수금 제외)의 재무적 기준을 충족해야 한다. 또 개인정보 유출이나 전자금융사고 등에 따른 손해배상책임의 이행을 위해 충분한 수준의 보험이나 공제에 가입해야 한다.
출처 : 전자신문

2014년 기사이긴 하지만 기사 내용만 봤을 땐 카드 인증정보 저장에 대한 기준이 엄격 그 잡채인 것을 확인할 수 있다. 모든 지표가 카드정보 저장을 하지 말라고 말하고 있다. 기획을 틀어야 하는 것인가?

카드사 가맹점 이용약관에도 명시

추가로, 신한카드 가맹점 이용약관을 살펴보니

② 가맹점은 카드 유효기한, 검증값(CVC, CVV), PIN 및 PIN 블록, PIN 검증데이터(PVV)등 카드 인증정보를 보관하여서는 아니됩니다. 또한, 가맹점은 카드회원과의 신용판매, 카드사와의 신용판매대금 결제 등을 위해서 반드시 필요한 경우가 아니면 회원의 카드번호를 보유하지 않아야 합니다.
③ 제2항에도 불구하고 결제대행업체가 간편한 카드결제를 목적으로 카드번호, 유효기한 등을 보유하고자 하는 경우에는 카드사가 요구하는 보안에 대한 기준을 충족하는 경우에 한하여 결제대행업체에 간편결제를 신청하고자 하는 자로부터 동의를 받아 카드사와 사전에 협의된 정보의 범위 내에서 수집·보유할 수 있습니다.

기획을 틀어야겠다. 무지하면 몸이 고생이다. 지금은 새벽 한 시 반을 향하고 있다.

결론

정리해 보자면

"카드번호(16자리)" 자체는 암호화 처리 후 DB 저장 가능
단, 카드 인증정보(CVC, 만료기간 등) 법률상 저장 불가
저장 가능 업체는 카드사 혹은 자기자본 400억 이상, 순부채 비율 200% 이하 PG사만 가능 (PCI DSS 인증 등 추가 조치 필요)
카드사의 가맹점 이용약관에도 인증정보 저장 불가 명시, 저장 필요시 카드사 조건에 부합하는 보안 기준 충족 후 카드사와 협의
여신금융업법 17조에 따라 유출된 카드정보로 피해 발생 시 가맹점에서 전액 혹은 일부 피해액 전액 배상의무

너 이정도면 스카이넷일듯

카드정보 저장하지도, 저장하려는 생각조차 하지 말자.

[Figma] 피그마 작업물 히스토리 관리하기

노사수 — Tue, 16 Jan 2024 23:29:12 +0900

피그마 산출물 버전 관리가 가능할까?

피그마는 좋은 툴이다. 디자인 툴로써, 와이어프레임 제작 툴로써 그리고 프로토타이핑 툴로써도 좋은 툴이다. 협업하기에도 좋다. 다만 사용해보지 않은 자에게는 그저 어색한 툴이며, 때문에 변화에 둔감한 사람에겐 겉멋 정도로 불리는 툴이기도 하다.

어떤 용도로 사용하든 간에, 피그마로 작업 시 히스토리 분기 처리를 해야 할 때가 온다. 다양한 방법이 있을 수 있다. 신규파일로 분리하거나, 페이지로 분류하거나, export 하여 PDF 등으로 관리할 수도 있다. 다만 피그마에서 히스토리 관리를 위한 기능을 제공하기 때문에 이 기능을 소개해보고자 한다.

피그마 히스토리 버전 기능 활용

A라는 작업물을 산출한 뒤, 어떤 이유에서든 작업물을 업데이트 해야 하는 상황이 찾아온다. 그럴 땐 히스토리 기능을 이용하여 A 산출물을 히스토리로 저장할 수 있다.

방법은 두 가지다.

1. 좌측 상단 피그마 아이콘 -> File -> Save to version history 클릭

2. 중앙 상단 파일명 우측 애로우 아이콘 클릭 -> Show version history 클릭

클릭하면 우측에 버전 히스토리 영역이 열린다. 빨간색 박스친 + 아이콘 클릭 시 버전 타이틀과 디스크립션을 작성할 수 있는 모달 창이 실행된다.

해당 히스토리를 식별할 수 있도록 적절한 제목과 내용을 기록해준다. 물론 피그마는 이러한 수동 저장 외 자동저장(auto save) 기능도 제공한다.

그 뒤 A 산출물을 B라는 내용으로 업데이트 했다고 치자. 그런데 작업을 하다 보면 이전 버전을 다시 봐야 할 일이 분명히 생긴다. 그럴 때 다시 버전 히스토리 영역을 활성화하여 A 히스토리를 클릭하면 분기처리된 A 히스토리 화면을 표시한다.

이 상태에서 더보기 버튼을 클릭하여 duplicate 기능을 사용해 파일을 복사할 수도 있고, 불러와진 히스토리 화면을 복사하여 업데이트된 화면에 붙여 넣을 수도 있다.

이런 식으로 버전관리를 철저히 하면 롤백도 간편하고, 협업 부서 간 논쟁도 피할 수 있고, 책임소재가 명확해지고, 이전 작업물 일부를 다시 가져올 수도 있고 장점이 넘쳐난다.

버전관리의 중요성

신규 제품을 개발하거나 출시된 제품에 대한 업데이트를 진행할 때, 기획과 디자인 그리고 개발팀의 업무 속도가 항상 같을 순 없다. 그렇다고 개발이 완료될 때까지 기획과 디자인을 멈추고 있을 수만도 없는 일이다. 그럴 땐 배포 범위를 산정하고 히스토리 처리를 한 뒤, 해당 버전을 개발자에게 개발 요청을 하고, 이후 버전의 기능들에 대해 우선적으로 작업할 수도 있다.

또한 히스토리 관리를 하지 않고 하나의 산출물에 덮어쓰면서 작업하다 보면 개발자가 어떤 화면을 보고 개발해야 하는지 알 수 없으며 이전 버전 보고 실수로 개발하거나 아직 구현하지 않아야 할 기능을 구현한다거나 하는 다양한 문제점이 생긴다.

버전관리는 정도가 없다. 팀 구성원 간 가장 편하고 맞는 방법을 찾으면 된다.

기획&디자인 협업툴 Figma 둘러보기

당겨서 새로고침 혹은 Pull to Refresh

노사수 — Tue, 16 Jan 2024 23:06:05 +0900

이름도 생소했던 그 기능

기획을 하다 보면 디자이너, 개발자와 소통할 때 전문용어 사용이 필수불가결하다. 그러던 어느 날 이건 뭐라고 부르지? 도저히 표현할 방법이 내 머릿속에 없었던 하나의 유저 행동이 나를 힘들게 했다. 그 게 바로 Pull to Refresh. 웹의 경우 F5 혹은 브라우저 새로고침 아이콘을 통해 페이지를 새로고침 하는 경우가 흔하지만 앱이나 모바일 웹의 경우 키보드 자판도 없고 새로고침 UI가 별도로 없어 모바일 특유의 새로고침 UX인 당겨서 새로고침, 영어로는 Pull to Refresh이라고 불리는 액션이다.

Pull to Refresh 작동 방식

목업 이미지처럼, 손가락을 이용해 아래로 드래그하여 새로고침을 하는 방식이다. 보통 드래그 후 손가락을 놓으면 튕기는 듯한 인터랙션을 많이 사용하다 보니 Bounce Back 이라고도 표현하는 것 같다. 당긴 액션 이후 스피너를 통해 정보를 불러오고 있음을 나타내주는 것이 좋다.

한국어로 굳이 표현하자면 당겨서 새로고침 정도로 표현하는 것 같다. 어떤 명칭으로 불리는 건 중요하지 않다. 결국 팀원들 간 효율적인 커뮤니케이션을 위해서라도 UI/UX 전문 용어를 최대한 익혀두는 것이 좋겠다.

[회고] 효율적인 회의를 위한 고찰

노사수 — Mon, 15 Jan 2024 22:47:13 +0900

회의를 하면서, 하고 나서 겪었던 다양한 문제점을 돌이켜보고, 효율적인 회의를 위해 어떤 점이 부족했는지 나를, 팀을 돌아보고자 한다.

1. 회의 전 아젠다 공유는 필수

회의는 이해관계자들에게 사전 아젠다를 공유하여 미리 해당 주제에 대해 생각 정리할 시간을 가져야 한다. 그래야 의미 없는 마라톤 회의를 미연에 방지할 수 있다. 우리 조직은 회의 아젠다를 제대로 공유하지 않는다. 물론 급히 회의 소집되는 경우엔 사전 공지가 어렵지만 제품 관련 주요 의사결정이 필요한 경우도 사전 공유 없이 소집되는 경우가 종종 있다.

2. 북극성 지표

회사의, 부서의, 제품의 북극성 지표가 필요하다. 특히 특정 주제에 대해 의견이 대립할 때, 데이터가 충분하지 않다면 주관적 관점에서 의견이 충돌하는 경우가 잦다. 논리대 논리의 싸움이라면 다행이겠지만 각 구성원들이 쌓은 주관적 경험에 의해 티격태격할 때가 많다. 이럴 때 공통의 목표 혹은 북극성 지표가 존재한다면 불필요한 논쟁을 없앨 수 있고 나와 의견이 다른 상대방을 잠재울 수 있는 한방을 먹일 수 있기 때문이다.

3. 이해관계자는 반드시 필참

우리 조직의 회의 방식은 이상한 점이 많다. 1, 2번도 해당되지만 가장 큰 문제이자 내가 이 포스팅을 작성하는 주된 이유이기도 하다. 신규 기능에 대한 회의를 기획자와 개발자 없이 의사결정자와 운영팀만 진행하는가 하면, 개발자 없이 기획자만 기획회의를 진행해 구현 불가한 기능을 기획한 적도 많다. 논리는 이러하다. 회의에 많은 인원을 인볼브 시키면 해당 인원들의 업무시간을 빼앗는다고. 그런데 회의에 참석한 인원이 모든 걸 다 결정한 뒤에도 회의에 초대받지 못한 실무자가 해당 기능에 대해 부정적이거나, 구현이 불가해서 회의가 다시 진행되는 경우도 있고 모든 게 긍정적이더라도 결국 회의에 참여하지 않은 구성원들에게 두 번 세 번 반복해서 설명해줘야 한다. 한 번에 끝내자 제발.

4. 회의록 작성은 필수

많은 사람들이 회의록을 작성하지 않는다. 나서서 작성하는 사람이 없다. 생각해보면 누가 작성해야 하는지 잘 모르겠다. 화면을 공유하지 않은 사람 중에서 서기를 자처한다면 좋을 텐데 그게 잘 안된다. 그러다 보니 회의에서 결정된 내용이 기록되지 않고 나중에 결정을 번복하거나 회의 내용을 기억하기 위해 부단히 애쓰는 경우가 자주 일어난다. 또한 회의에 참여하지 않은 구성원이 회의록만 봐도 내용 파악이 가능하므로 전반적인 팀의 이해도를 맞출 수 있다.

5. 가지치기 금지

1번에서 이어지는 케이스. 주요 아젠다가 없다 보니 몇 개 안건을 처리한 후에는 잡담으로 이어지거나 알맹이 없는 스몰톡으로 이어져 업무 시간을 갉아먹기도 한다. 이건 나부터 반성하려고 한다. 주요 안건에 대해 충분히 논의했다면 빠르게 마무리해서 업무에 복귀하는 것이 필요할 것 같다.

효율적인 회의를 위해서는?

효율적인 회의를 위해 사전 아젠다 공유 및 숙지, 북극성 지표 도입을 통해 빠른 의사결정 돕기, 이해관계자를 참여시켜 불필요한 재설명 방지, 회의록 작성 및 공유, 불필요한 잡담을 금지 등 회의 효율을 높이기 위한 다양한 방법을 구성원 모두가 인지해야 한다.

사이트 구조를 나타내는 Navigation Bar 종류

노사수 — Sun, 14 Jan 2024 22:29:56 +0900

재직 중인 회사에서 위치별 내비게이션에 대해 잘못된 용어를 사용하고 있어 따로 정리해 보았다.

내비게이션 바의 정의

내비게이션 바에 대해 GPT에 물어보니 아래와 같이 대답했다.

내비게이션바는 일반적으로 모바일 앱이나 웹 페이지에서 화면 상단이나 하단에 위치한 바를 의미합니다. 이 바에는 주로 홈 버튼, 뒤로 가기 버튼, 메뉴 버튼 등이 포함되어 있어 사용자가 앱이나 웹 페이지를 쉽게 탐색할 수 있도록 도와줍니다. 여행 서비스 앱을 개발 중이신 분이라면, 여행 관련 기능이나 메뉴에 대한 내비게이션바가 중요할 것입니다. 사용자가 쉽게 여행 정보를 찾고 이동할 수 있도록 디자인하는 것이 좋습니다.

내비게이션 바의 종류

내비게이션 바는 크게 GNB, LNB, SNB, FNB로 나눌 수 있으며 각각 Global Navigation Bar, Local Navigation Bar, Side Navigation Bar, Footer Navigation Bar의 약자이다.

GNB(Global Navigation Bar)

붉은색 박스 친 부분이 GNB 영역이다. GNB는 보통 웹사이트의 헤더 영역 쪽에 위치한다. 카테고리별 구분할 때 많이 사용되며 대분류라고 부르는 경우도 있다.

LNB(Local Navigation Bar)

GNB에 마우스 오버 했을 때 표시되는 영역을 LNB라고 한다. GNB의 2 depth라고 생각하면 된다. GNB영역은 보통 메인 상단 부분에 노출되기 때문에 2 뎁스 메뉴인 LBN를 호버 시 표출 형태로 숨기는 경우가 많다.

SNB(Side Navigation Bar)

SNB 영역. 보통 GNB와 LNB를 같이 쓰거나, GNB 클릭 후 SNB 메뉴가 표시되는 케이스를 흔히 볼 수 있다.

FNB(Footer Navigation Bar)

FNB 영역. Footer 영역에 사이트맵 형태로 제공되는 것이 대부분이다. GNB의 경우 메인 화면에 위치하기 때문에 주요 콘텐츠 노출을 위해 LNB 형태로 서브 메뉴를 숨기는 반면, FNB의 경우 화면이 끝나는 지점에 위치해 있기 때문에 영역을 넓게 써서 펼쳐진 상태로 표현하기 상대적으로 수월하다.

내비게이션 적용 기준

내비게이션 바를 어떻게 운영할지는 제품의 페이지 뎁스가 얼마나 세분화되어 있는지에 따라 결정하면 될 것 같다. 결국 사용자가 원하는 메뉴에 빠르게 접근할 수 있도록 도움을 주는 기능이기 때문에 그 관점에서 고민하면 된다.

[Figma] 피그마 replace 기능

노사수 — Sat, 13 Jan 2024 15:14:34 +0900

피할 수 없는 기획 수정

서비스기획을 하다 보면 내외부 요인에 의해 필터명, 테이블명 등 문구, 버튼명, 타이틀 등의 변경이 발생한다. 물론 변경을 하지 않도록 기획 단계에서 최대한 많은 고민이 들어가야 개발 공수를 최대한 줄일 수 있다. 만약 어쩔 수 없이 수정을 해야 하는 상황이 온다면 수백 개의 화면에서 단어를 찾아 수기로 수정해야 하는 반복 작업이 발생된다. 결국 기획자는 굉장한 노동력을 투여해야 하며 그만큼 시간을 허비하게 된다.

피그마 replace 기능을 통한 빠른 수정

피그마에서는 replace 기능을 통해 쉽게 처리가 가능하다.

command + F (윈도우는 ctrl + F)로 검색하고자 하는 단어를 입력 후, replace 기능을 활용할 수 있다.

replace 옵션을 선택하여 검색할 단어와 교체할 단어를 입력 후 일괄/선택 변경을 해주면 된다.

일괄 replace 처리할 수도 있지만, 일부 화면에서만 변경해야 하는 경우 결과값 하나하나 클릭해 주면 해당 프레임으로 이동되면서 아이체크 후 변경할 수 있다.

이렇게 아이 체크 후 개별 replace 버튼을 변경해주거나 일괄 변경하면 모든 페이지에서 손쉽게 변경 처리가 가능하다.