AWS에서 자주 쓰는 주요 서비스 정리
·
용어 설명회
AWS를 사용하는 팀/회사의 경우라면 회의나 업무 시간에 AWS 관련 서비스 용어를 자주 접하게 된다. 기획 직군에 종사할 경우, 개발자들의 대화에서 어떤 주제로 이야기 하고 있는지 파악하기 위해서는 관련 용어를 미리 알아두면 좋을 것 같다.AWS 주요 서비스 목록 1. 서버 / 실행EC2: 가상 서버. 직접 서버를 띄워서 웹앱, API, 배치 작업 등을 운영할 때 많이 씀Lightsail: 간편형 서버. EC2보다 단순해서 개인 프로젝트나 소규모 서비스에 적합Lambda: 서버 없이 코드만 실행하는 서버리스. 간단한 API, 자동화, 이벤트 처리용 2. 저장소 / 데이터S3: 파일 저장소. 이미지, 첨부파일, 백업, 정적 파일 보관용RDS: 관리형 관계형 DB. MySQL, PostgreSQL 같은 D..
[추천도서] 프로덕트 오너: 책을 통해 얻을 수 있는 값진 간접 경험
·
기획자의 양식
기획자로 여러 회사에서 다양한 제품팀을 만나보지 못한 것이 혹시나 독이될까 우려수러워 다양한 커뮤니티에서 정보도 얻고 여러 책을 읽으며 간접 경험을 쌓으려고 노력했다. 서비스를 기획하다 보면 자주 드는 생각이 있다.“이 기능이 정말 필요한가?”“지금 이게 우선순위가 맞나?”“우리는 왜 이걸 만들고 있지?” 김성한 저자의 『프로덕트 오너』는 이런 질문에 대해 다시 생각하게 해준 책이었다. 이 책을 읽으며 가장 크게 느낀 건, 프로덕트 오너는 단순히 할 일을 정리하는 사람이 아니라는 점이다.무엇을 만들지보다, 왜 만들어야 하는지를 계속 붙들고 있는 사람에 더 가깝다. 특히 인상 깊었던 부분은 우선순위에 대한 관점이었다.실무에서는 모든 요청이 다 중요해 보이지만, 결국 중요한 건 많이 하는 것이 아니라 제품 ..
[추천도서] 린 스타트업: 서비스기획자, PM이 읽어야할 필독서
·
기획자의 양식
기획자로 일하다 보면 열심히 기능을 정의하고, 화면을 설계하고, 우선순위를 정했는데도 막상 출시 후 반응은 기대와 다를 때가 있다.우리는 정말 고객이 원하는 것을 만들고 있었을까?린 스타트업은 이 질문에 대해 꽤 현실적인 답을 주는 책이었다.특히 기획자 입장에서 이 책이 좋았던 이유는, 제품을 처음부터 완벽하게 설계하는 방식보다 빠르게 가설을 세우고, 검증하고, 수정하는 방식을 더 중요하게 보기 때문이다. 기획자는 “무엇을 만들지”보다 “무엇을 먼저 검증할지”를 배운다기획자는 흔히 요구사항을 정리하고 기능을 설계하는 사람으로 보인다. 하지만 실제로는 그보다 더 앞단에서 고민해야 할 일이 많다.이 문제가 진짜 문제인지고객이 이 기능을 실제로 원하는지지금 이 기능이 최우선인지얼마나 작게 만들어도 검증이 가..
TPS(Transaction per Second)란?
·
용어 설명회
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는 직원이 얼마나 빠르냐가 아니라, 동시에 얼마나 많이 ..
스코프 크리프(Scope Creep)란?
·
용어 설명회
📌 스코프 크리프란?스코프 크리프(Scope Creep)는 프로젝트 진행 중, 처음 정의한 업무 범위(Scope)가 명확한 승인 없이 계속 확장되는 현상을 의미한다. 쉽게 말하면,“애초에 하기로 한 범위 밖의 일이 계속 추가되는 상황”대부분 일정 지연, 비용 증가, 품질 저하, 팀 번아웃을 일으킨다.✅ 스코프 크리프가 왜 생길까? (원인)요구사항 정의가 불명확함이해관계자 요구/의견이 중간에 바뀜PM의 조율/필터링 부족의사결정 기록 부족 → 말로만 합의고객/상사의 추가 요청 무분별 수용팀 간 목표/방향 정렬 실패✅ 어떤 문제가 생길까?일정 지연개발비/운영비 증가품질 저하설계/테스트 리소스 부족팀 피로감 증가책임 소재 불분명제품 방향성 흐려짐✅ 어떻게 예방할 수 있을까?1) 초기 Scope 명확화In-Sc..
[AI 독학하기] 3. 바이브 코딩(Vive Coding)
·
용어 설명회
개발자가 아니라면 코딩은 어렵고 먼 이야기처럼 느껴지곤 한다. 하지만 최근에는 생성형 AI의 발전으로, 누구나 코드를 직접 쓰지 않고도 개발을 시작할 수 있는 시대가 열렸다. 그 중심에 있는 개념이 바로 바이브 코딩(Vive Coding)이다. 바이브 코딩, 정확히 어떤 개념일까?바이브 코딩(Vibe Coding)은 공식 용어나 특정 브랜드명이 아니다.GPT 같은 대형 언어모델을 활용해 자연어로 프로그램을 짜고 수정하고 완성해나가는 새로운 방식의 코딩 접근법을 뜻한다.즉, 프로그래머처럼 문법을 일일이 외우기보다는,“AI야, 이런 기능을 만들어줘”라고 말하고,그 결과로 코드를 받아보며 피드백을 주고받는 흐름이다.예를 들어,“사용자 로그인 화면을 만들고 싶어”→ GPT가 HTML과 JavaScript 코드..
[회고] 기능조직과 목적조직 경험담
·
회고
기능조직 vs 목적조직조직을 어떻게 짜느냐에 따라 협업 방식, 속도, 책임 구조가 완전히 달라진다. 그중 가장 대표적인 두 가지 방식이 기능조직과 목적조직이다. 지난 번 성능우선주의와 고객우선주의 모두를 경험한 경험기를 작성했는데, 역시 운이 좋게도 동일한 제품을 기능조직에서, 목적조직에서 각각 기획해볼 수 있는 값진 경험을 했다. 우선 각각의 장단점과 실제 기업 사례를 통해 비교해고자 한다.기능조직: 역할 중심 구조기능조직은 기획팀, 개발팀, 사업개발팀, 마케팅팀처럼 기능별로 조직을 나누는 방식이다.전문성을 키우고 일관된 프로세스를 유지하기에 적합하다.장점비슷한 일을 하는 사람끼리 모여 효율성 높음역할과 책임이 명확함전문성 강화 및 교육 시스템 구축 용이단점부서 간 소통과 협업이 어려움전체 목표보다 부..
[AI 독학하기] 2. 머신러닝(Machine Learning)과 딥러닝(Deep Learning)
·
용어 설명회
머신러닝과 딥러닝으로 자연어 처리하는 방법전처리도 했고, 벡터화도 완료했다면 이제는 기계가 문장을 보고 뭔가 “판단”하거나 “생성”하는 단계그 중심에 머신러닝(Machine Learning)과 딥러닝(Deep Learning)이 있음머신러닝 vs 딥러닝 차이항목머신러닝딥러닝특징규칙 기반 + 수작업 특징 추출스스로 특징을 학습예시 모델Naive Bayes, SVMRNN, LSTM, Transformer장점빠르고 단순복잡한 문맥까지 처리 가능단점복잡한 문장에 약함학습 시간이 오래 걸리고 데이터 많이 필요 주요 모델 소개Naive Bayes문장 안에 있는 단어들의 확률로 긍정/부정을 판단예: “맛있다” 80%, “최고” 60% → 긍정일 확률이 높음SVM (Support Vector Machine)단어들의 벡..