블로그 모아보기 - 인프런

인프런 워밍업 클럽 3기 PM 1주차 발자국

강의 요약PM의 역할과 고유 전문성PM의 직무는 상품을 기획하고 개발자, 디자이너와 소통하는 직무을 통해 만드는 사람이 아닌 성공시키는 전문가한 번에 완성되는 것은 없고 기민하게 반응하여 발전해 나가야한다.문제를 제대로 정의하고 해결하기문제를 다각도로 보는 것이 중요하다.충분한 시간을 가지고 본질을 분명하게 이해하고 분명하게 해결하자.인사이트PM 직무는 단순히 상품을 이해하는 것이 아니라 상품에 대한 기본적인 이해, 관련된 시장, 갖고 있는 자원을 모두 이해해야하는 직무이다.회고PM으로 직무를 전환하고 싶어서 듣게 되었는데 후기에 PM 직무가 아니더라도 듣는 것이 좋다는 것에 어떤 의미가 있는지 느끼게 되었다.단순히 상품을 관리하는 것이 아니라 책임감이 엄청난 분야임이 느껴졌다.초반 내용만으로도 인사이트를 얻을 수 있었어서 앞으로 이걸 어떻게 적용하고 실천해야할지 고민이 되었다.

1

[인프런 워밍업 클럽 스터디 3기] PM 워밍업클럽 1주차 회고

1주차 학습 회고: PM으로서 문제 정의와 해결의 중요성이번 1주차 강의를 통해 PM의 핵심 역할을 다시금 정리할 수 있는 기회가 되었습니다. PM은 고객과 비즈니스의 가치를 균형 있게 만들어가는 역할이며, 이를 위해 Valuable(가치 있는), Usable(사용 가능한), Feasible(개발 가능한), Viable(사업적으로 지속 가능한) 제품을 만들어야 한다는 것이 다시 한번 강조되었습니다.특히 문제 정의의 중요성을 깊이 실감했습니다. PM은 단순히 문제를 해결하는 것이 아니라, 해결할 가치가 있는 문제를 찾는 것이 핵심 역할입니다. 이 과정에서 "문제 공간을 2차원으로 시각화하고 Deep Dive하는 방법"과 "Feature Work와 Growth Work를 구분하여 접근하는 방식"이 인상적이었습니다. 기존에도 문제를 정의하려고 노력했지만, 실제로 이를 구조화하는 데 어려움이 있었는데, 이번 강의를 통해 좀 더 명확한 기준을 가질 수 있을 것 같습니다.또한, "모든 고객의 문제가 비즈니스로 연결되지는 않는다"는 점이 다시금 와닿았습니다. 문제를 정의하고 나면, 본능적으로 해결책을 고민하게 되는데, 정작 이 문제가 해결할 가치가 있는지에 대한 검증을 소홀히 할 때가 많습니다. 앞으로는 데이터 기반으로 문제를 분석하고, 해결책을 검증하며 이터레이션을 반복하는 과정을 더 의식적으로 적용해야겠다고 다짐했습니다. 강의를 들으면서 가장 와닿았던 부분은 "학습이 끝이 아니라 실천해야 한다"는 점입니다. 결국 이 내용을 업무와 실제 프로젝트에 적용해보면서 나만의 방법론으로 체득하는 것이 중요합니다. 사이드 프로젝트에서도 이번 강의 내용을 활용해 문제 정의를 더욱 명확히 하고, 분석 툴을 적극적으로 활용해볼 계획입니다. 마지막으로, 학습한 내용을 단순히 듣고 끝내는 것이 아니라, 직접 회고를 작성하면서 다시 한번 정리하는 것이 도움이 되었습니다. 앞으로도 학습한 내용을 적용하고 기록하는 습관을 들여야겠다고 생각합니다.

기획 · PM· PO･워밍업클럽･pm･po･데이터분석가･1주차회고

1

워밍업 클럽 3기 BE 클린코드&테스트 - 1주차 발자국

📖 강의 요약 2⃣ 추상우리가 클린 코드를 추구하는 이유"가독성"혼자만 사용한다면 아마 필요 없는 이야기 일수도 있을 것이다 하지만 개발자는 협업이 중요하다고 들었다.나만 코드를 읽는 것이 아니라 협업을 하는 사람들끼리 컨벤션도 중요하지만 그 전에 가독성 있는 코드를 짜면 원활한 작업을 할수 있을 것이라고 생각한다. 추후 발생하는 비용들도 줄어들 것이다.이번 섹션에서 강조하는 것은 제목처럼 추상인 것 같다.추상을 알아보자"추상"중요한 정보는 가려내어 남기고 덜 중요한 정보는 생략하여 버린다.미션에서 제출한 내가 이해한 추상과 구체를 위와 같이 예시를 들수 있을 것 같다.[추상] 인프런 워밍업 클럽 3기 BE 클린코드 & 테스트를 수료 한다. [구체] 2 개 강의(Readable Code: 읽기 좋은 코드를 작성하는 사고법&Practical Testing: 실용적인 테스트 가이드 )를 100 % 수강한다. 주 1회(총 4회) 발자국 작성을 한다. OT를 포함한 총 3회 온라인 라이브를 출석한다 미션 6개 중 5개 이상 기한 내 제출 완료한다.추상화의 가장 대표적인 행위는 이름 짓기,메서드 선언, 동등한 추상화 레벨, 매직 넘버,매직 스트링 제거 등 이 있다.위 주제에서 공통적으로 이름을 잘 짓는 것이 기반이 되는 것 같다. ex) 변수이름, 메서드 이름, 상수 이름 3⃣ 논리, 사고의 흐름이번 섹션에서 한마디로 정리하자면 빼고 생각하자 였다. (로직이 복잡하면 그 내가 먼저 생각 할 수 있는 상황부터 먼저 거르고 생각하기)추가적으로 부정어, 예외처리, null,optional에 대해 한번 더 생각해보고 작성해보기 4⃣ 객체 지향 패러다임이번 섹션은 좀 반성을 좀 하였다. 특히 강의 중 getter 사용 에 대한 이야기 였는데 무조건 getter를 사용하면 객체안에 정보를 가져올수 있잖아라고 생각하는 나에게 생각을 많이하게 되었다.핵심 : 관심사를 분리, 높은 응집도, 낮은 결합도, getter를 사용하기 전에 객체의 메시지를 보내서 그 값을 사용할수 있는 지 부터 생각하는 능력 기르기 SOLID 원칙✅SRP : 하나의 클래스는 단 한 가지 변경 이유(= 책임) 만을 가져야 한다.✅OCP: 확장에는 열려 있고, 수정에는 닫혀 있어야 한다.✅LSP: 자식 클래스는 부모클래스의 책임을 준수하며, 부모 클래스의 행동을 변경하지 않아야 한다.✅ISP : 클라이언트는 자신이 사용하지 않는 인터페이스에 의존하면 안된다.✅DIP : 상위 수준의 모듈은 하위 수준의 모듈에 의존해서는 안된다. 5⃣ 객체 지향 적용하기이번 섹션은 내가 잘 이해를 잘못한 것 같아 다시 보아야 할 것 같다. 지금은 일기 정도로 작성 하지만 이해하여 꼭 적어보자강의를 듣고 옛날에 내가 작성한 코드(전체 코드 x)가 생각 났다.public enum ReservationStatus { PENDING("PENDING") { @Override public boolean canChangeTo(ReservationStatus status) { switch (status) { case APPROVED, CANCELED, EXPIRED -> { return true; } } return false; } }, APPROVED("APPROVED") { @Override public boolean canChangeTo(ReservationStatus status) { return status.equals(APPROVED); } }, CANCELED("CANCELED") { @Override public boolean canChangeTo(ReservationStatus status) { return status.equals(CANCELED); } }, EXPIRED("EXPIRED") { @Override public boolean canChangeTo(ReservationStatus status) { return status.equals(EXPIRED); } };지금 보니 메서드 명도 바꿀 필요가 있고 switch 사용으로 유지보수 어려움, if-else 사용 등 고쳐야할 부분이 많은 것 같다.목표 : 강의를 어느 정도 이해하여 코드를 바꿔보기 💡 미션 코드와 설명을 보고, [섹션 3. 논리 의 사고 흐름]에서 이야기 하는 내용을 중심으로 읽기좋은 코드로 리팩토링 해보기 블로그: https://zunmin4030.tistory.com/56 먼저 사이즈가 0이면 어떤 행위를 하고 0보다 크면 어떤 행위 0보다 작으면 어떤 행위를 한다라는 접근으로 코드를 이해 하는 것 부터 시작하였다. 거기에 대한 궁금증을 가지고 섹션별 내가 적용할 수 있는 부분을 생각해보았다. 이름짓기 , 부정 연산자 제거, Early return을 생각하여 과제를 해결하다보니 처음 코드를 말로 정리했을 때 생긴 궁금증을 해소 할수 있었다. 💬 회고 👍 잘한 점배운 것을 하나씩 적용해 보며 과제를 수행 해 나갔다.😮‍💨 아쉬웠거나 보완하고 싶은 점섹션 5에 대한 이해를 하지 못해 한번 더 공부 해야겠다. 📎출처Readable Code: 읽기 좋은 코드를 작성하는 사고법https://www.inflearn.com/course/readable-code-%EC%9D%BD%EA%B8%B0%EC%A2%8B%EC%9D%80%EC%BD%94%EB%93%9C-%EC%9E%91%EC%84%B1%EC%82%AC%EA%B3%A0%EB%B2%95/dashboard

백엔드･인프런･워밍업클럽･backend･3기

1

[인프런 워밍업 클럽 3기 - CS] - 1주차 발자국 (운영체제) - 1

💻 운영체제 들어가기📌 개요개인용 컴퓨터: Windows / MacOS대형 컴퓨터, 서버: Unix / Linux스마트폰, 테블릿: Android / IOS스마트워치, 냉장고, 세탁기: Embeded OS ❓컴퓨터는 운영체제가 있어야 동작하는가?✅ 없어도 동작은 가능하지만 처음 설계를 제외한 다른 기능 추가가 불가(유연성 X) - 전화기(통화만 가능) / 스마트폰(업데이트 및 설치) 운영체제가 하는 일1⃣ 프로세스 관리 (CPU)→ 여러 프로그램을 동시에 실행하고, CPU 자원을 효율적으로 배분2⃣ 메모리 관리 (메모리)→ 실행 중인 프로그램이 필요한 메모리를 할당하고 관리3⃣ 하드웨어 관리 (하드웨어)→ 키보드, 마우스, 프린터 등 장치를 제어하고 하드디스크 특정 영역의 데이터 저장관리4⃣ 파일 시스템 관리 (파일)→ 하드디스크의 효율적인 파일 저장과 관리 📌 역사🗓 1940년대- 미국 펜실베니아 대학교에서 미국 탄도 계산을 위해 30톤 무게의 전자 디지털 계산기 발명- 종이에 수기로 작성하여 테스트 진행 후, 수동으로 스위치와 배선을 연결하여 프로그래밍- 펀치 카드를 이용한 입출력은 속도가 느리며 진공관의 유지 보수 비용도 크다.- 하드웨어의 비용이 비싸기에, CPU의 효율적인 활용이 중요해진다. 🗓 1950년대- 아주 작은 크기의 직접회로 개발.- 컴퓨터가 삽입된 펀치카드를 직접 읽어 계산하고 프린터로 출력.- 기존 과정 (오버헤드 과다 발생)1. 프로그래머가 오퍼레이터에게 펀치카드 전달.2. 펀치카드를 컴퓨터에 삽입 후, 결과 도출.3. 오퍼레이터가 결과를 프로그래머에게 전달.- 싱글 스트림 배치 시스템 (Single-stream Batch Processing Systems)1. 오퍼레이터에게 여러개의 펀치카드를 전달.2. 컴퓨터는 다수의 펀치카드를 한 번에 하나씩 읽어가며 결과를 도출- 입출력 관리자(I/O Device Controller) 를 개발하여 입출력 중에도 CPU 계산 가능- 입출력이 끝나면 CPU에게 인터럽트 신호를 주고, CPU는 신호를 받아 처리- 출력은 CPU와 입출력 관리자 분리가 가능하지만, 입력은 작업이 완료되어야지만 처리가 가능하여 어쩔 수 없이 CPU의 대기가 필요해짐. 🗓 1960년대- 시분할 시스템(Time Sharing System)- CPU 시간을 여러 개의 프로그램에 분배하여 동시에 실행되는 것 같은 효과 제공- 하나의 컴퓨터에 다수의 터미널을 연결시켜, 여러 사용자의 작업이 가능해짐.- 벨 연구소에서 유닉스(UNIX) 운영체제 개발- 멀티 프로그래밍: 여러 개의 프로그램 동시 실행 가능- 다중 사용자: 여러 사용자가 한 대의 컴퓨터를 공유하여 사용- 트리구조 파일 시스템: 루트("/")를 기준으로 파일과 디렉터리가 계층형 구조로 정리- 보안 및 접근 권한: 파일, 디렉터리에 대한 권한('r', 'w', 'x') 설정 가능- 높은 이식성: 다양한 하드웨어에 쉽게 적용 가능- 쉡 기반 CLI 제공: GUI가 아닌 CLI를 통해 운영- 여러 프로그래밍 간 메모리 영역을 침범하는 문제 발생 🗓 1970 ~ 1980년대- 개인용 컴퓨터의 등장(애플 맥킨토시, MS DOS)- GUI(Graphic User Interface)의 등장 🗓 1990 년대- GUI 환경의 개인용 컴퓨터의 보급으로 다양한 응용 프로그램 등장- Excel, Word - Winow 운영체제의 대중화- UNIX를 기반으로 한 오픈소스 LINUX 운영체제의 등장➡ CPU의 효율성과 오버헤드의 감소를 위한 고민이 끊임없이 이루어짐. 📌 구조1. 사용자는 인터페이스를 통해 커널에 접근- GUI: 그래픽으로 커널과 상호작용으로 일반 사용자도 접근 가능- CLI: 텍스트 형태의 명령어로 커널과 상호작용 2. 어플리케이션을 시스템 콜을 통해 커널 접근어플리케이션이 직접 커널에 접근하여 하드 디스크에 파일을 저장할 경우, 중요한 데이터의 손실이 발생할 수 있다. 이를 방지하기 위해 시스템 콜을 이용하여 운영체제를 통해 하드디스크의 빈 공간에 데이터를 저장한다. 3. 커널이 하드웨어에 접근드라이버를 통해 커널은 하드웨어에 접근할 수 있다. 커널이 모든 하드웨어에 대한 드라이버를 저장할 수는 없으니, 하드웨어의 제조사에서 드라이버를 만들어 제공하고 커널이 이를 설치하면 접근 가능하다. 📌 컴퓨터 하드웨어와 구조기존에는 하드웨어로 프로그램을 만들었기에, 프로그램의 수정마다 배선와 스위치를 수동으로 변경해야 한다. ✅ 폰 노이만 구조 (Von Neumann Architecture)1. 프로그램 내장 방식- 프로그램과 데이터가 같은 메모리에 저장- 실행한 명령어를 CPU가 메모리에서 읽어와 수행2. 순차적 명령 실행- CPU는 한 번에 하나의 명령어를 순차적으로 실행3. 메모리, CPU, 입출력 장치로 구성- CPU(Central Pocessing Unit)1. 산술논리 연산장치: 실제로 데이터 연산을 담당2. 제어장치: 모든 장치들의 동작을 제어하고 지시3. 레지스터: CPU내에 계산을 위해 임시적으로 저장하는 공간- Memory1. RAM: 랜덤으로 데이터를 읽어도 속도는 일정, 휘발성2. ROM: 전력이 끊겨도 데이터 저장이 되지만 수정 불가 (BIOS)- 입출력 장치: 사용자와 컴퓨터 간 데이터 입/출력 관리 📌 컴퓨터 부팅 과정1. 컴퓨터의 전원을 누름2. ROM에 저장된 BIOS 실행1. CPU, RAM, 하드웨어에 이상 여부를 확인2. 이상이 없다면 하드디스크에 저장된 마스터 부트 레코드를 메모리로 올림3. 운영체제 동작3. 모니터에 운영체제의 동작을 실행 ✅ 마스터 부트 레코드(Master Boot Record, MBR)하드디스크, SSD, USB등 저장장치에서 부팅과 파티션 정보를 관리하는 0번 섹터1. 부트 로더(bootloader) 저장 - BIOS가 MBR을 읽고 부트 로더를 실행하여 운영체제로 부팅2. 파티션 정보 저장- 디스크의 파티션 구조를 관리 (최대 4개의 파티션)3. 디스크 식별- 디스크의 고유한 식별 정보를 포함 📌 인터럽트✅ 폴링(Polling)CPU가 지속적으로 장치나 하드웨어의 상태를 확인하여 필요한 작업을 처리하는 방식.- CPU의 비효율적인 자원 소모- 다수의 장치를 관리할 수록 CPU는 주기적으로 다수의 장치를 확인해야 하므로 다른 중요한 작업의 처리 속도가 느려질 수 있다.- 상태 확인 주기와 타이밍- 처리가 완료되어도 다음 폴링 주기까지 기다려야 하며 사용자 응답 또한 지연된다. ✅ 인터럽트(Interupt)프로세서가 현재 실행 중인 작업을 중단하고, 중요한 작업이나 이벤트를 즉시 처리- 하드웨어 인터럽트 - 시스템 외부의 하드웨어 장치에서 발생한 이벤트에 반응- 소프트웨어 인터럽트 - 소프트웨어, 프로그램에 의해 발생

시스템 · 운영체제･운영체제･감자･워밍업클럽3기

1

[인프런 워밍업 클럽 스터디 3기] PM 워밍업클럽 1주차 발자국

PM은 뭘 하는 사람인지 알게되었다. 그저 일정 관리하고 서비스를 기획하는 작업자의 롤과는 다르다.고객의 모든 문제를 해결할 필요는 없다그것이 실제 문제인가 의심해야하고해결할 가치가 있는 문제인지 고민하자팀에 문제의 맥락 커뮤니케이션을 하자데일리 미팅

기획 · PM· PO･인프런워밍업･발자국･PM･PO･기획자

1

인프런워밍업클럽3기 PM/PO 발자국 1주차

PM은 '기능 출시'가 목표로 하는 사람이라기 보다는 성과 전반을 책임지는 사람이다. - 여기서 'Product Management'로 검색해서 학습을 하는 것이 사랑받는 프로덕트를 만드는 데 도움이 된다는 것이 인상적이었다.강의를 들으면서 위에서 말한 정의 외에도 PM/PO 직군에서 요구하는 '사업 성과' 라는 것이 무엇인지, 그리고 어떻게 내면 되는 것인지 이해를 할 수 있었다. 약간 고민이라면, '기능'을 어느정도 설계해야 고객이 원하는 것을 생각할 수 있을 텐데 인터렉션을 정의하는 데 어느정도 시간을 할애하면 좋을지에 대해 궁금증이 생겼다. 아직 프로덕트를 보는 시야가 나에겐 부족한 것 같다. 강의에서 알려주는 방식이 직군과 상관없이 좋은 질문을 던지는 방법 인 것 같아, 유용하게 써먹어야지, 생각하였다. 이 강의를 듣기 전에 데이터 분석 공부도 시작하였는데 데이터 분석 과정에서 동일한 질문을 던져도 좋을 것 같다.

1

워밍업 클럽 스터디 3기(PM) 1주차 발자국

강의명: 시작하는 PM/PO들에게 알려주고 싶은, 프로덕트의 모든 것코치: 김민우링크: https://www.inflearn.com/course/%EC%8B%9C%EC%9E%91%ED%95%98%EB%8A%94-pmpo-%EB%AA%A8%EB%93%A0%EA%B2%83/dashboard1주차 강의 포인트PM의 역할은 제품으로써 고객 가치와 사업적 가치를 만들어 내는 것여기서 제품이 '성공적인 프로덕트'이기 위해서는 4가지 조건이 필요함.ValuableUsableFeasibleViablePM은 주로 Valuable과 Viable을 담당하는 역할임PM은 고객, 데이터, 비즈니스, 산업에 대한 심층적인 지식을 가지고 있어야 함.결국 중요한 것은 PMF(Product/Market Fit)을 찾는 것!문제를 잘 정의해야 해결 할 수 있다.문제를 잘 정의 했다면 이제는 해결책을 만들 차례, 좋은 해결책을 내기 위해서는 다음 두 가지가 필요좋은 아이디어이터레이션(Iteration): 만들고, 테스트하고, 학습하기를 반복하여 제품을 발전시키는 것하지만 모든 고객 문제들이 비즈니스로 연결되지는 않는다는 것을 명심해야 함.우리는 Problem Worth Solving, 즉 해결할 가치가 있는 문제를 찾아서 해결해야 함. 1주차 회고스타트업을 창업하면서 항상 중요하다고 인식을 해온 개념이었지만, 과연 내가 실천하고 있었을까 돌아보는 시간이 되었다. 특히 문제 정의 부분과 나의 문제 assumption이 해결할 가치가 문제가 맞는지를 판단하는데에 막연함이 있었는데, 코치님께서 알려주신 해당 상황에서의 판단 기준은 앞으로 나의 업무에 있어 큰 도움이 될 것 같은 기준들이었다. 강의를 들으면서도 결국 중요한 것은 내가 직접 실천하여 나의 것으로 만드는 과정이라는 생각이 들었다. 업무를 할 때에 있어 의식적으로 생각의 방향을 잘 정립하여 수행해보고자 한다.

기획 · PM· PO

1

[인프런 워밍업 클럽 스터디 3기] 프로덕트 디자인 1주차 발자국

📖 1주차 - 학습 내용 정리1. 피그마 배리어블과 디자인 토큰 개념 정리피그마 배리어블과 디자인 토큰의 개념 다시 한번 정리하기 Semantic이 중요하게 필요한 이유 Mode로 구분 가능하고, 로컬 베리어블 관리가 필요하기 때문2. 배리어블과 파운데이션 세팅하기색상, 타이포그래피, 간격, 선, 그림자, 그리드 등 베리어블 직접 등록해보기다양한 효과(Effect) 알아보기, Drop Shadow외에도 다른 효과들도 사용해보기높낮이(Elevation)는 UI 요소 간의 계층 구조를 시각적으로 명확하게 나타내고, 베리어블로 정리하면 유용그리드 종류 Fixed Grid(centered), Fluid Grid(stretch), Hybrid Grid 살펴보기.디바이스별 반응형 디자인 기준점(viewport) 정리해보고, Min width와 Max width를 지정해주기.3. 유용한 피그마 플러그인들 적용해보기 💡 1주차 - 회고 및 느낀 점 😆 좋았던 점강의를 듣고 직접 실습하면서 배리어블 개념, 용어, 피그마 플러그인등을 정리할 수 있었던 점이 좋았다.UI3에 맞춰서 업데이트 된 강의를 들을 수 있는게 너무 좋았다. 이전에 강의 들을 당시 예전 UI와 다른점이 많아서 이해하기 어려운 부분들도 있었는데, 이번에 다시 정리하면서 들으니 너무 좋았고, 좀더 체계적으로 추가 업데이트 된 내용을 배울 수 있어서 좋았다.😅 아쉬웠던 점스터디 첫 주였는데 계획했던 것처럼 매일 강의를 듣지는 못했고, 정해진 시간에 아직 루틴화 되지 못한 점, 강의 따라가기에 바빠서 스타일가이드 문서화 정리까지는 제대로 못했던 점이 아쉽다.😍 앞으로 바라는 점다음 주부터는 정해진 시간에 조금씩이라도 매일 공부하고, 문서화 하는 부분도 염두해두면서 작업해보자 💪

UX/UI･인프런_워밍업_클럽･디자인시스템･Figma･UX/UI

1

[인프런워밍업클럽3기] PM/PO 발자국 1주차

PM/PO 1주차 회고 -PM이 어떤 생각을 가지고 프로젝트를 진행해야 하는지 알 수 있었다-출시에만 초점이 맞춰지게 업무를 해온 상황에서 답답함을 느꼈는데, 내가 놓치고 있는게 무엇인지를 알게 되었다.-어떠한 새로운 기능들이 출시할 때 유저들에게 새로운 기능을 알리고 잘 사용할 수 설계하는것과 제품 사용을 습관화 하도록 만드는것 또한 연결되는 것을 깨닫게 되었다.-기획할 때 시간에 쫓겨 급하게 진행하고, 충분한 탐색을 하지 않은 상태에서 기획을 넘겼던 프로젝트들이 생각났다.-느긋해지자, 조급하면 시야가 좁아진다.

PM/PO･발자국

1

CQRS와 조회 전용 저장소, 그리고 카테고리-상품 관계 고민기

도메인 주도 설계를 배우면서 겪은 고민최근 도메인 주도 개발(DDD)에 관한 책을 읽으면서 여러 가지 설계에 대한 깊은 고민을 하게 되었다. 특히 관심을 끈 부분은 CQRS(Command Query Responsibility Segregation) 개념이었다. 이 글에서는 공부한 CQRS 개념과 함께, 카테고리와 상품 사이의 관계를 어떻게 효율적으로 설계할 수 있는지 정리해 보려고 한다. 쓰기 모델과 조회 모델을 분리한 이유일반적인 웹 애플리케이션은 데이터베이스 하나에서 읽기 쓰기를 모두 처리한다. 이렇게 구현해도 초반에는 큰 문제없이 잘 동작하지만, 서비스가 성장하면서 읽기(조회) 트래픽이 급증하면 다음과 같은 문제가 발생할 수 있다.읽기 요청 증가로 인한 데이터베이스 성능 저하복잡한 검색 및 필터링으로 인한 성능 한계이를 해결하기 위한 방법 중 하나가 CQRS 이다. CQRS의 핵심 개념쓰기(명령)와 읽기(쿼리)의 책임을 분리쓰기 작업은 RDB에 반영하고, 읽기는 ElasticSearch나 Redis 같은 빠른 저장소를 활용CQRS 흐름쓰기 발생: 데이터를 RDB에 저장이벤트 또는 동기화: Kafka 등을 통해 조회 전용 저장소(ElasticSearch)에 데이터 동기화조회 요청 처리: 조회 전용 저장소에서 빠르게 검색/조회이를 통해 조회 성능 향상과 시스템 부하 분산을 얻을 수 있다. 하지만 이벤트 동기화 과정에서 구현 복잡도가 늘어나고, 실시간성이 필요한 경우 동기화 지연이 단점으로 작용할 수 있다.간단 예시: CQRS 적용 시나리오 상품 생성 시:상품 정보를 RDB에 저장이벤트를 발생 (예: "상품 생성됨")이벤트 소비자가 ElasticSearch에 해당 상품 정보를 인덱싱사용자 조회 시:ElasticSearch에서 상품 목록 검색 -> 빠른 검색 결과 반환카테고리와 상품 관계 설계카테고리와 상품 간의 설계는 애플리케이션 성능, 특히 페이징 처리와 깊은 관련이 있다.데이터 조회와 성능에 큰 영향을 미치는 두 가지 대표적인 설계 방식을 자세히 살펴보자. N-1 관계 (상품 -> 카테고리 참조)N-1 관계는 상품(Product)이 특정 카테고리(Category)를 직접 참조하는 방식이다. 일반적으로 상품이 반드시 하나의 카테고리에만 속할 때 이 방식을 사용한다.@Entity public class Product { @Id private Long id; @ManyToOne @JoinColumn(name = "category_id") private Category category; }장점특정 카테고리에 속한 상품을 효율적으로 페이징 가능하다.category_id컬럼에 DB 인덱스를 설정하면 빠른 조회가 가능하다.단점카테고리에서 직접적으로 상품 목록에 접근하는 것이 어렵다.N+1 문제가 발생할 가능성이 높다.이 문제는 JPA의 Fetch Join이나 EntityGraph 같은 기법으로 해결할 수는 있으나 본 글의 내용과는 관련성이 떨어지기 때문에 자세히 다루진 않도록 하겠다. M-N 관계 (상품 <-> 카테고리 ID로 연결)M-N 방식은 하나의 상품이 여러 개의 카테고리에 속할 때 사용하는 구조로, 중간 테이블을 사용하여 다대다 관계를 처리한다. 특히 ID기반으로 연관관계를 표현하여 직접적인 엔티티 참조를 피하는 방식이다.@Entity public class Product { @Id private Long id; @ElementCollection @CollectionTable(name = "product_category", joinColumns = @JoinColumn(name = "product_id")) @Column(name = "category_id") private Set<Long> categoryIds; }장점엔티티 간 직접적인 양방향 참조 없이 ID로만 관계를 맺어 결합도를 낮춘다.데이터가 많은 때도 페이징 및 필터링을 DB에서 효과적으로 처리할 수 있다.단점특정 카테고리에 속한 상품을 조회하려면 추가적인 쿼리가 필요하다.카테고리와 상품 정보를 함께 조회할 경우 성능 저하가 발생할 수 있다. 어떤 방식을 선택해야 할까?관계를 설계할 때는 애플리케이션의 사용 패턴과 비즈니스 요구사항을 깊게 고민해야 한다. 각각의 관계 방식은 다음과 같은 상황에 효과적이다.N-1 방식상품이 주로 하나의 카테고리에 속하는 경우상품 중심으로 자주 조회하는 기능이 필요할 때조회 성능 및 빠른 페이징이 중요한 경우M-N 방식하나의 상품이 여러 카테고리에 동시에 속할 수 있는 경우다양한 조건으로 필터링하거나 복잡한 조회가 필요한 경우많은 데이터를 효율적으로 처리해야 할 경우 글을 마무리하며이 글을 작성하면서 설계 방식 하나를 선택하는 일이 얼마나 중요한 고민인지 새삼 느끼게 되었다.이론적으로는 두 방식 모두 장단점이 있기 때문에 어느 하나가 더 우월하다 말할 수는 없겠지만, 결국 실제 서비스에서 어떤 방식이 더 효율적일지는 요구사항을 고려하여 더 효율적인 선택을 하는건 개발자의 몫인 것 같다.앞으로도 단순히 이론에 그치지 않고 실무에서 끊임없이 고민하며 상황에 맞는 좋은 설계 방식을 찾아가야겠다는 생각이 들었으며 끝으로 이 글의 내용과 비슷한 고민을 하고 있는 사람들에게 조금이나마 도움이 되었기를 바란다.

백엔드･CQRS･ManyToOne･ManyToMany･조회전용저장소

1

[현대자동차그룹] 개발자 컨퍼런스 'Pleos 25' 참가자 모집 (~3/27)

개발자들을 위한 새로운 무대, Pleos 25지난 4년간 개발자들과 모빌리티 생태계를 만들어온 HMG developer conference가현대자동차그룹의 통합 소프트웨어 브랜드 'Pleos'와 함께 완전히 새로워진 모습으로 찾아왔습니다.🧐Pleos가 무엇인가요?Pleos는 HMG의 소프트웨어 역량을 하나로 모은 그룹사 통합 소프트웨어 브랜드입니다.📍Pleos 25는 어떻게 진행되나요? 이번 행사 현장에 오시면 SDV, AI, 자율주행 등 다양한 주제의 트랙 세션을 들으실 수 있고, 차량용 앱 개발 및 SDK 활용 실습을 할 수 있는 핸즈온 세션에 참여하실 수 있습니다!관심있는 개발자 분들 모두 참가하실 수 있으니 많은 관심 부탁드리며 현대자동차그룹 전문가들과 함께 개발 경험과 지식을 나누어 성장하는 기회가 되셨으면 좋겠습니다.다가오는 3월 28일, 코엑스에서 열릴 'Pleos 25'에서 만나요!▪일시 : 2025년 3월 28일 (금) 오전 10:00▪장소 : 코엑스 오디토리움 & 전시홀 D▪참가 대상 : 차량용 앱 생태계에 관심있는 개발자 및 비즈니스 파트너▪행사 구성- Track : SDV, AI, 자율주행 등 다양한 분야의 개발자들이 전하는 생생한 개발 경험과 인사이트를 공유합니다.- Exhibition : 차량 데이터를 활용한 현대자동차그룹과 파트너사들의 다양한 협업 사례와 모빌리티 최신 기술 및 솔루션을 만날 수 있습니다.- Hands-on : 차량용 앱 개발 및 SDK 활용 방법에 대해 직접 체험해 볼 수 있습니다.- 채용 상담 : 현대자동차그룹에서 제공하는 다양한 분야의 채용 상담도 준비되어 있습니다.▪사전 등록 기간 : 2월 24일 (월) ~ 3월 27일 (목)▪신청 방법 : 홈페이지 내 '참가 신청하기'를 통해 사전 등록▪홈페이지 : https://pleos.ai/pleos25▪참가비 : 무료👉문의Pleos 25 운영 사무국 pleos.help@hyundai.com

모빌리티･개발자･컨퍼런스･강연･행사･자동차･모빌리티･IT･정보

1

[K-DEVCON] 고투런 2기 멘티 모집!

[유료] K-DEVCON 고투런(Go-to-Learn) 2기 모집고투런이란?고투런(Go To Learn)이란 기술적 성장을 원하는 신입, 주니어 개발자들을 위한 멘토링 트랙은 최소 4주, 최대 8주간 미들급 이상의 개발자들이 멘토가 되어 직접 멘토링 주제 기획부터 멘티 선발, 학습까지의 과정을 진행하는 멘토 리딩 트랙입니다. 1⃣ 멘티 모집 대상, 모집 기간, 참가비📌 모집 대상: 기술적 성장이 필요한 신입 ~ 주니어 개발자 (전/현직 개발자분들을 대상으로 합니다) 📅 모집 기간: 2월 15일 ~ 2월 28일 23:59까지 📢 선발 발표: 3월 5일 💰 참가비: 50,000 2⃣ 지원 절차📌 지원서 제출 -> 멘토님의 지원서 검토 (또는 인터뷰) -> 합류 결과 안내 📝 지원 링크: https://forms.gle/c4sFfYFxpwgRVPRw93⃣ 멘토링 주제✅ 확장성, 회복탄력성, 고가용성을 보장하는 애플리케이션 설계 / 온오프라인 / 김정우 멘토님✅ 프로젝트로 배우는 안드로이드 프로그래밍 A to Z / 온오프라인 / 서준수 멘토님 ✅ 객체지향 101 - 객체지향을 쓰게된 이유 / 오프라인 / 이현재 멘토님✅ 20년차 AI 엔지니어에게 배우는 AI 에이전트의 모든 것 / 온오프라인 / 정유선 멘토님4⃣ 멘토링 세션에서 얻을 수 있는 것🚀 멘티가 얻을 수 있는 혜택:🔹 사수가 없거나 도움을 받기 어려운 상황이라면 검증된 멘토와 함께 빠르게 성장할 수 있다.🔹 기술적 성장을 목표로 하는 트랙이기 때문에, 본인의 실무 역량 향상에 도움을 받을 수 있다.🔹 4 ~ 8주간의 깊이 있는 멘토링을 통해서 기술 성장 이상의 깊이있는 성장 경험을 할 수 있어 향후 커리어 빌딩에도 도움을 받을 수 있다.자세한 내용은 Go To Learn 노션을 참고해주세요.https://bluepicture08.notion.site/K-DEVCON-Go-To-Learn-2-16becf714ca380f58b78edac54401608📩 문의: [이메일 or Slack DM]info@k-devcon.com 지금 바로 지원하고 성장할 기회를 잡으세요! 🚀K-DEVCON이 궁금하다면? 홈페이지 / Slack 대화방 / 링크드인 / 인스타그램

커리어 · 자기계발 기타･K-DEVCON･스터디･멘토링

1

[Gen AI 인사이트] HeyGen, AI로 가상의 캐릭터를 만들다!

AI 기술의 발전으로 이제 원하는 캐릭터를 만들고, 자연스러운 목소리까지 입힐 수 있어요.오늘 소개할 HeyGen은 가상의 인물과 음성을 생성하는 혁신적인 AI 기술입니다.HeyGen은 AI 기술을 활용해 가상의 인물과 음성을 생성하는 플랫폼이에요.실제 사람처럼 말하고 움직이는 AI 캐릭터를 쉽게 만들 수 있죠!특히 영상 제작을 위한 캐릭터가 필요할 때, 빠르고 효율적인 솔루션을 제공합니다.1. AI 기반 아바타 생성사용자가 원하는 외모의 캐릭터를 AI가 만들어 줘요.기본 제공 아바타를 선택하거나, 직접 제작할 수도 있어요.2. 자연스러운 음성 합성한국어를 포함해 다양한 언어로 자연스럽게 말할 수 있어요.별도의 성우 녹음 없이 원하는 대사를 입력하면 음성이 생성됩니다.3. 입모양 싱크 기술대사에 맞춰 입모양까지 자동으로 조정되어 더욱 자연스러운 영상이 완성돼요.1단계: 캐릭터 선택: 기본 제공 아바타를 선택하거나 직접 만들 수 있어요.2단계: 스크립트 입력: 원하는 대사를 입력하면 AI가 음성을 생성해 줍니다.3단계: 입모양 & 표정 조정: 말하는 방식에 맞춰 입모양과 표정을 자연스럽게 수정할 수 있어요.4단계: 영상 제작 & 활용: 완성된 영상은 SNS, 교육 콘텐츠, 마케팅 영상 등 다양한 분야에서 활용할 수 있습니다!기존 영상 제작촬영 및 편집 시간이 오래 걸림성우 녹음이 필요해 비용이 높음 수정이 어려움HeyGen 활용AI가 자동으로 생성하여 제작 시간이 단축됨별도의 성우 없이도 음성을 합성할 수 있어 비용 절감간단한 수정만으로도 빠르게 콘텐츠를 업데이트할 수 있음HeyGen은 다양한 곳에서 활용할 수 있어요! 마케팅 영상 – 기업 홍보 및 광고 콘텐츠 제작교육 콘텐츠 – 온라인 강의 및 튜토리얼 영상 제작가상 인플루언서 – 유튜브 및 SNS 콘텐츠 제작엔터테인먼트 – 애니메이션, 게임 캐릭터 활용자연스러운 AI 음성 합성 : 실제 사람처럼 말하는 AI 음성 제공빠르고 간편한 영상 제작 : 복잡한 편집 과정 없이 영상 완성다국어 지원 : 다양한 언어로 콘텐츠 제작 가능맞춤형 캐릭터 생성 : 원하는 외모와 목소리를 가진 AI 캐릭터 제작 가능1. 기업 홍보 영상 제작 – 브랜드 광고 및 마케팅 콘텐츠2. 온라인 강의 및 튜토리얼 – 교육 콘텐츠 제작3. 유튜브 및 SNS 콘텐츠 – 가상 캐릭터를 활용한 콘텐츠 제작4. 가상 캐릭터 기반 광고 – 디지털 마케팅에 활용HeyGen을 활용하면 빠르고 간편하게 고품질 영상 제작이 가능합니다.촬영이나 성우 비용 없이 비용 효율적인 콘텐츠 제작이 가능해요.마케팅, 교육, SNS 등 다양한 분야에서 활용할 수 있는 강력한 도구이니 꼭 사용해보세요!마소캠퍼스와 함께 AI를 활용해 업무 혁신을 이뤄보세요!효율적이고 스마트한 일의 방식을 통해 성장할 수 있도록 도와드릴게요. 📌관련 강의<미드저니 비법 클래스, 현직 AI 디자인 전문가의 이미지 프롬프트 엔지니어링 핵심 정리>기초 사용 방법부터 실제 디자인 프로젝트 실습을 통한 실무 적용까지 한 번에!

AI · ChatGPT 활용･HeyGen･AI영상제작･가상캐릭터･마케팅영상･가상인플루언서･디지털혁신･AI기술･SNS콘텐츠･브랜딩･광고제작

1

[K-DEVCON 서울 2월 밋업] 2월엔 DevBloom

안녕하세요, K-DEVCON 서울입니다.2월 밋업의 테마는 입춘, 봄의 시작과 설레임을 담은 “DevBloom”입니다.“Dev(개발)“의 “Bloom(꽃이 피다)“의 의미를 담은 이번 DevBloom 행사는 최신 IT 개발 지식뿐만 아니라, IT 업계 종사자들에게 실질적으로 도움이 될 다양한 주제를 함께 다룹니다. 디자인, 부동산 상식 등 다채로운 인사이트를 제공하며, 폭넓은 시각과 실질적인 정보를 얻을 수 있는 기회를 제공합니다.이번 데브콘 2월 서울 행사에 많은 참여와 관심 부탁드립니다. 🥳📌 행사 안내- 테마 : 2월엔 DevBloom- 일시 : 2025년 2월 15일(토) 13:00~18:00 (5hr)- 장소 : 서울특별시 종로구 중학동 종로1길 50 [마이크로소프트 코리아] 13층- 신청링크 : 이벤터스 - 2월엔 DevBloom- 주최 : K-DEVCON📢 문의 : info@k-devcon.com- K-DEVCON이 궁금하다면? 홈페이지 / Slack 대화방 / 링크드인 / 페이스북 감사합니다.

커리어 · 자기계발 기타･K-DEVCON･개발･UI/UX･Devops･AI

1

AI 들에게 물어보기 - 노래 가사

"글렌 메데이로스의 nothing's gonna change ..." 오며가며 추천에 떠서 유튜브 복고맨 을 보게 되며 80-90 음악들로 다시 refresh 되는 일들이 있었고, 그 중 몇몇 노래들은 당시 어설프지만 영어를 배우게 해 준 고마운 노래들이어서(?) AI 서비스들에게 가사를 물어 보았다. 여전히 얕은 기량이지만, 문장으로도 예뻤던 기억들도 있다.알아듣고 기뻐하던 가장 오래된 기억의 노래로 Glenn Mediros 의 Nothing's gonna change my love for you 에 대한 이야기들도 있었고, 며칠 전 저녁 먹는 식당에서 들리길래 이것저것 해 보았다. 깔려 있는 앱들이 다 한글 영어 음성 지원이 되고, 말로 해서 꽤 알아 듣는 모양새들이었지만, 이 글을 만들기 위해 데스크탑에서 다시 해 보고 정리. 때마침 저작권 이슈도 언급되기도 해서 ( “AI 추격조에 데이터 개방… 저작권료 차후 계산 파격 필요” [뉴스 투데이] ) 몇 개 해 봄. 이번부터는 네이버와 더불어 클로바x 도 참전... 많이 복잡해 졌는데, 개인적/주관적이지만 오늘의 기준사용자인 내가 '정확한 가사'를 볼 수 있는가 ? 출처는 믿을만 한가 ? 친절한가 ? 질문은 "글렌 메데이로스의 nothing's gonna change my life for you 가사 써 줘"결과는 구글 검색 > Liner > 네이버 = Bing > 클로버x > Perplexity > ChatGPT = Claude > WRTN > Gemini 구글 검색 ( 10 / 10 )Knowledge Panel 에 특화된 쿼리여서 공정성 시비가 있을 수 있음 인정.한 페이지 넘게 가득 할애하는 이전에 못 보던 용기까지.발매 년도 1987. 이것도 정답. 이 노래는 1986년에 녹음되어 1987년에 발매되었다 함. 원곡도 아니니 이정도는 인정.늠름한 출처까지.. Liner ( 8/10 )결과 페이지 포맷팅 감점. 노래 가사가 한 줄씩 한 페이지 너머 이렇게 itemized item 로 보이는 거는 많이 불편함. 맨 위 결과인 블로그 페이지는 찜찜하지만, 벅스가 보이면 인정, 랭킹 아쉬움.네이버 ( 6/10 )링크 클릭하면 되긴 함. 네이버 블로그들 Bing ( 6/10 )링크 클릭하면 되긴 함. 역시 여기도 블로그들 클로바x ( 5.5/10 ) 일단 안 된다고 함. 가끔씩(!) 블로그 링크 보여 줌.Perplexity ( 5/10 ) 못 가르쳐 주겠다면서 뭘 이렇게나 많이..?영어가 많다고 영어로 답을 ?링크들은 전부 unofficial links. ChatGPT ( 4/10 )못 가르쳐 주겠다는데.. 굳이 요약을...? 왜...? Claude ( 4/10 )못 가르쳐 주겠다는데.. 그래도 안내 해 줌.. WRTN ( 3/10 )못 가르쳐 주는데, 그 중 제일 불친절함. 맨 마지막 문장은 심지어 조롱 같음. Gemini ( 2/10 )가사를 틀리게 보여 줌. 그래서 최하위 점수.심지어 아래 출처 링크는 404. 조금은 진지하게... Gemini 는 구글 검색 안 쓰나 ? 총평AI 서비스의 최대 적은 저작권 ?? 정말 ? 저작권이라는 두리뭉실한 이름으로 여러 가지 의미로 쓰이지 싶은데... 구글 검색이 추구하는 방향으로 출처와 credit 을 authorship 형태로 존중하는 방향으로 진행되어야 하지 않을까 ? 각각 서비스들 MOE 등등 할 거면 구글 검색보다는 잘 하자 ?

대학 교육 기타･검색

1

데이터베이스 관련 학습 내용 정리

예전에 공부했었던 데이터베이스 정규화와 관련해서 제 나름대로 정리해본 내용입니다.제1정규형정의: 한 레코드의 각 칼럼들에 담긴 값은 원자값들만 담긴다.맥락이 부분이 정확히 왜 제시되었는지 아직도 적확하게 결론짓지는 못했습니다.하지만 제 나름대로 관련해서 이해한 방식은 "모든 칼럼들의 집합은 슈퍼키이다" 입니다.따라서 제1정규형을 만족한다면 슈퍼키의 존재성을 가정해도 되어서, 다른 정규형들을 설명할 때의 논리적인 기반이 되는 것 같습니다.제3정규형 (수정: 논리적으로 잘못 이해한 부분이 있어 수정하였습니다. 정리 안 했으면 지나칠 뻔 했습니다.)정의: 다음 조건을 만족하면 제3정규형 위반이행적 종속성 A -> B -> C가 발생하는데,A -> B가 일대일 대응이 아니여서 칼럼 C의 값이 중복해서 들어가고,원래 테이블 ABC를 AB와 BC로 분리했을 때 후보키가 바뀌는 일이 일어나지 않는다.C가 후보 키의 일부인 경우 분리를 못하는 경우가 있습니다. (예: AC -> B, B -> C)이 부분을 설명하기 위해 prime attribute이라는 개념을 사용하는 것 같습니다.맥락정리하고 보니 핵심적인 부분이 바로 칼럼 간의 의존관계인 것 같습니다.데이터 모델링을 할 때, 각 칼럼이 어떤 칼럼들에 의존하는지 파악하는 연습을 하기로 생각했습니다.제2정규형정의: 제3정규형 조건에서 B가 후보키의 일부일 때가 제2정규형의 조건이 됩니다.즉, 앞의 A -> B가 일대일 대응이 아닌 경우에서 B의 칼럼들이 A의 칼럼들 중 일부인 경우입니다.사용한 용어들입니다.슈퍼키: 레코드를 유일하게 결정지을 수 있는 칼럼들의 집합후보 키: minimal 슈퍼키. 후보 키 자체는 슈퍼키인데, 후보 키에서 칼럼을 하나라도 제외하면 레코드를 유일하게 결정지을 수 없다.기본 키 (PK): 후보키 중 사람이 DBMS 관리를 위해 고른 것 2024-11-10수정: 인프런 데이터베이스 강의 소개 영상을 보는데 실무에서의 RDBMS 설계는 이론과 괴리가 있다는 사실이 약간 충격이었습니다.최근에 어떤 블로그 글을 보는데 비즈니스 로직이 실제로 블로그에 나오는 식의 명세로 작성되고, 데이터베이스 스키마로 옮겨진다는 것을 확인하였습니다. (그리고 DDD라는 개념이 무엇인지 궁금해졌습니다.)업데이트: 다시 읽어보는데, 엔티티 관계 다이어그램으로 일차적으로 옮겨지고 그 다음 데이터 모델링이 진행되는 것으로 해석하였습니다.수정: 데이터베이스 강의 소개 영상을 보니 실무에서는 기획에서 나온 화면의 데이터를 바탕으로 진행하는 경우가 더 많다는 것을 알았습니다. 간단한 프로젝트를 천천히 진행해보면서 여기의 내용과 유사하게 진행해보아야겠습니다.수정: 천천히 진행해보려 했는데, 간단한 프로젝트의 데이터베이스 스키마의 복잡도가 실제 포트폴리오의 스키마에 미치지 못할 수 있겠다는 생각이 들었습니다. 그 경우를 대비해서 최대한 빠르게 스키마 설계를 해보고 잘 되는지 확인해보아야겠습니다.업데이트: 일단은 다음 방법이 저에게 효과가 있는 것 같습니다. 더 복잡한 테이블 설계에서도 적용 가능한지 확인해보아야겠습니다.비즈니스 로직에 대한 명세를 만든다. (상황에 따라 테이블 설계하면서 동시적으로 진행)제일 개념들이 많이 들어가는 구체적인 명세들을 먼저 고른다.명세들을 잘 표현하는 테이블 구조를 설계한다.제3정규형을 지키도록 데이터 모델링을 한다.

데이터베이스

1

0

인프런 워밍업 스터디 클럽 3기 4주 차 발자국

섹션 7: Mockito로 Stubbing하기Test Double 종류Dummy: 아무 기능도 없는 객체.Fake: 간단한 형태로 실제 기능 수행 가능하지만, 프로덕션에 적합하지 않은 객체.Stub: 미리 준비된 결과를 반환하는 객체로, 상태 검증에 사용.Spy: Stub이면서 호출 기록을 제공하며 일부는 실제 객체처럼 동작 가능.Mock: 특정 행위를 명세하고 동작하도록 설계된 객체로, 행위 검증에 사용.Mockito 주요 어노테이션@Mock: Mock 객체 생성.@Spy: 실제 객체의 메서드를 수행하되 특정 메서드만 Mocking.@InjectMocks: Mock과 Spy 객체를 자동 주입.BDDMockito행동 주도 개발 방식으로 given().willReturn()을 사용하여 테스트 작성.Classicist vs MockistClassicist: 실제 객체를 사용해 자연스럽고 직관적인 테스트. 리팩토링에 유리하지만 상태 검증만으로는 동작 오류를 놓칠 수 있음.Mockist: 모든 협력자를 Mock으로 대체하여 동작을 명확히 검증. 세부 구현에 의존적이라 리팩토링 시 테스트가 깨질 가능성이 있음.섹션 8: 더 나은 테스트 작성법테스트 작성 원칙한 테스트는 한 목적만 가져야 하며, if와 for 사용을 지양.LocalDateTime.now() 같은 제어 불가능한 값은 파라미터로 넘겨 제어.테스트 환경 독립성공유 자원을 사용하지 말고, 테스트 간 독립성을 보장.픽스처(Test Fixture)는 각 테스트가 내부 구현을 몰라도 이해 가능해야 함.Test Fixture 클렌징deleteAll(): 순차적으로 삭제, 성능 저하 우려.deleteAllInBatch(): 단일 SQL DELETE 쿼리로 대량 데이터 삭제 가능.반복 및 동적 테스트@ParameterizedTest: 여러 파라미터 값으로 반복 테스트.예: CsvSource, MethodSource 활용.@DynamicTest: 런타임에 동적으로 테스트 케이스 생성 및 실행.통합 환경 최적화서버 부팅 횟수를 줄이기 위해 통합 테스트 클래스를 상속 구조로 설계.예: @SpringBootTest, @ActiveProfiles("test").Private 메서드와 테스트 전용 코드Private 메서드는 직접 테스트하지 말고, 객체 분리를 통해 public 메서드로 검증.테스트 전용 메서드는 필요하면 작성 가능하나 신중히 접근.추가 내용Spring REST Docs vs SwaggerREST Docs: 신뢰도 높고 프로덕션 비침투적이지만 설정이 복잡함.Swagger: 적용이 쉽고 API 호출 가능하지만 프로덕션 코드에 침투적이고 신뢰도가 낮음. 후기 생각보다 봐야할 강의 양도 많고 이해하기가 어려워서 한 강의당 3번씩 돌려본것 같다. 특히나 하다가 테스트를 시도했는데. 아니 강의에서는 통과하는데 나는 실패했을때 실패지점 찾는데 진짜 애먹었다. 정신나갈뻔한 상황도 많았지만 많이 배울 수 있었다. 그럼에도 아직 어려운 부분이 많았다. 강의 : https://www.inflearn.com/course/readable-code-%EC%9D%BD%EA%B8%B0%EC%A2%8B%EC%9D%80%EC%BD%94%EB%93%9C-%EC%9E%91%EC%84%B1%EC%82%AC%EA%B3%A0%EB%B2%95/dashboard

0

@Mock, @MockBean, @Spy, @SpyBean, @InjectMocks의 차이

1. @Mock, @MockBean, @Spy, @SpyBean, @InjectMocks의 차이 @Mock@Mock은 Mockito에서 제공하는 애노테이션으로, 특정 클래스나 인터페이스의 가짜 객체(Mock)를 생성한다.Spring 컨텍스트와는 무관하며, 순수하게 단위 테스트를 위해 사용된다.테스트 대상 객체가 의존하는 객체를 가짜로 만들어 테스트를 고립시키고자 할 때 활용된다.@MockBean@MockBean은 Spring Boot에서 제공하는 애노테이션으로, Spring 컨텍스트에 등록된 Bean을 Mock 객체로 교체한다.통합 테스트에서 특정 Bean의 실제 동작을 대체해야 할 때 사용된다.주로 서비스 계층의 일부 Bean을 Mock으로 교체해 컨트롤러 테스트를 진행하는 경우에 적합하다.@Spy@Spy는 실제 객체를 기반으로 부분적으로 Mocking을 할 수 있게 해주는 Mockito 애노테이션이다.객체 전체를 Mock으로 만드는 것이 아니라, 특정 메서드만 가짜 동작을 설정할 수 있다. 나머지 메서드는 원래 동작을 그대로 유지한다.실제 객체의 일부 동작만 변경하거나 추적하려는 경우에 적합하다.@SpyBean@SpyBean은 Spring Boot에서 제공하는 애노테이션으로, Spring 컨텍스트에서 관리되는 Bean을 Spy로 교체한다.@Spy와 비슷하지만, Spring 컨텍스트 내에서 관리되는 Bean에 대해 부분적인 Mocking이 가능하다는 점에서 차이가 있다.Spring 환경에서 특정 Bean의 일부 메서드만 가짜로 설정하고 나머지는 원래 동작을 유지하고자 할 때 사용된다.@InjectMocks@InjectMocks는 테스트 대상 클래스에 필요한 의존성을 자동으로 주입해주는 Mockito 애노테이션이다.생성자, 필드, 또는 setter를 통해 Mock이나 Spy 객체를 자동으로 주입한다.테스트 대상 클래스가 여러 의존성을 가지고 있을 때 이를 효율적으로 설정할 수 있다.Mock이나 Spy 객체를 단순히 생성하는 것을 넘어, 이들을 테스트 대상 클래스와 연결해주는 역할을 한다.이 애노테이션들은 각각의 목적과 상황에 맞게 사용되며, 단위 테스트에서는 주로 @Mock과 @InjectMocks가 사용되고, 통합 테스트에서는 @MockBean과 @SpyBean이 적합한 경우가 많다. @Spy는 실제 객체의 일부만 Mocking해야 하는 상황에서 유용하다. 2. 테스트 코드 리팩토링공통 항목(@BeforeEach)테스트 코드에서 중복되는 사용자 및 게시물 생성 로직을 @BeforeEach로 이동하여 공통화할 수 있다. class CommentServiceTest { private User user; private Post post; @BeforeEach void setUp() { // 사용자 생성에 필요한 내용 준비 및 사용자 생성 user = createUser(); // 게시물 생성에 필요한 내용 준비 및 게시물 생성 post = createPost(user); } @DisplayName("사용자가 댓글을 작성할 수 있다.") @Test void writeComment() { // given Comment comment = prepareComment(post, user); // when commentService.writeComment(comment); // then assertThat(commentRepository.findById(comment.getId())).isPresent(); } @DisplayName("사용자가 댓글을 수정할 수 있다.") @Test void updateComment() { // given Comment comment = prepareComment(post, user); commentService.writeComment(comment); String updatedContent = "Updated content"; // when commentService.updateComment(comment.getId(), updatedContent); // then assertThat(commentRepository.findById(comment.getId()).get().getContent()).isEqualTo(updatedContent); } @DisplayName("자신이 작성한 댓글이 아니면 수정할 수 없다.") @Test void cannotUpdateCommentWhenUserIsNotWriter() { // given User anotherUser = createAnotherUser(); Comment comment = prepareComment(post, user); commentService.writeComment(comment); String updatedContent = "Updated content"; // when & then assertThrows(UnauthorizedException.class, () -> commentService.updateCommentAsUser(anotherUser, comment.getId(), updatedContent) ); } private User createUser() { // 사용자 생성 로직 구현 return new User("user1", "password"); } private User createAnotherUser() { // 다른 사용자 생성 로직 구현 return new User("user2", "password"); } private Post createPost(User user) { // 게시물 생성 로직 구현 return new Post("게시물 제목", "게시물 내용", user); } private Comment prepareComment(Post post, User user) { // 댓글 생성 로직 구현 return new Comment("댓글 내용", post, user); } }

0

Layered Architecture 구조의 레이어별 특징과 테스트 작성법

1. 레이어별 특징Presentation Layer외부 세계의 요청을 가장 먼저 받는 레이어로, 사용자나 외부 시스템과의 인터페이스 역할을 한다.클라이언트로부터 전달받은 데이터를 검증하고, 비즈니스 로직을 수행할 수 있도록 Business Layer로 전달한다.주로 요청 파라미터에 대한 최소한의 검증과 API 응답 형식을 처리한다.Business Layer애플리케이션의 핵심 비즈니스 로직이 구현되는 레이어이다.Persistence Layer와 상호작용하며 데이터 처리 및 트랜잭션을 보장한다.비즈니스 규칙에 따라 데이터를 가공하거나 처리하는 역할을 담당한다.Persistence Layer데이터베이스와 직접적으로 상호작용하는 레이어로, 데이터 CRUD(Create, Read, Update, Delete) 작업에만 집중한다.비즈니스 로직이 포함되지 않으며, 순수하게 데이터 접근 및 저장소 관련 작업만 수행한다.2. 테스트 작성법Presentation Layer 테스트목적: 외부 요청에 대한 파라미터 검증과 컨트롤러 동작을 독립적으로 테스트한다.방법:하위 계층(Business Layer, Persistence Layer)은 @MockBean으로 모킹(mocking) 처리하여 독립적인 단위 테스트를 진행한다.Spring MVC 테스트를 활용해 HTTP 요청 및 응답 흐름을 검증한다.예를 들어, 잘못된 파라미터가 전달되었을 때 적절한 에러 메시지가 반환되는지 확인한다.Business Layer 테스트목적: 비즈니스 로직이 의도한 대로 동작하는지 검증하고, Persistence Layer와의 상호작용을 확인한다.방법:단위 테스트를 작성하여 특정 메서드의 동작을 검증한다.Persistence Layer를 실제로 호출하지 않고, Mock 객체를 사용해 독립적으로 테스트할 수도 있다.통합 테스트 시에는 @SpringBootTest와 실제 DB를 활용하여 트랜잭션 롤백 기능으로 데이터를 정리하며 테스트를 진행한다.Persistence Layer 테스트목적: SQL 쿼리가 제대로 동작하는지 검증하고, 데이터베이스와의 CRUD 작업이 정상적으로 수행되는지 확인한다.방법:@DataJpaTest를 활용하여 인메모리 DB(H2 등)를 사용해 빠르게 검증한다.단위 테스트 성격을 가지며, Repository 계층에서 작성한 쿼리 메서드가 의도한 대로 동작하는지 확인한다.테스트용 프로필 설정과 초기 데이터 주입 설정을 활용하면 편리하다.3. 테스트 방법 요약레이어주요 특징테스트 방법Presentation외부 요청 처리 및 파라미터 검증MockBean으로 하위 계층 모킹 처리 후 단위 테스트 진행 (Spring MVC Test 활용)Business비즈니스 로직 구현 및 트랜잭션 보장단위 테스트 또는 통합 테스트 (@SpringBootTest)Persistence데이터 CRUD 작업@DataJpaTest와 인메모리 DB로 SQL 쿼리 및 CRUD 동작 검증이처럼 각 레이어는 역할과 책임이 명확히 분리되어 있으며, 각 레이어에 맞는 적절한 테스트 전략을 적용함으로써 코드 품질과 유지보수성을 높일 수 있습니다. 출처 : https://inf.run/pZXb7

0

인프런 워밍업 스터디 클럽 3기 3주 차 발자국

Layered Architecture 테스트하기 어려운 부분 분리,테스트 하고자 하는 영역에 집중,명시적이고 이해할 수 있는 형태의 문서 작성 가능여러 가지 모듈이 합쳐진 결과를 우리는 예상 할 수 있는가?이를 위한 통.합.테.스.트통합 테스트🔸 여러 모듈이 협력하는 기능을 통합적으로 검증하는 테스트🔸 일반적으로 작은 범위의 단위 테스트만으로는 기능 전체의 신뢰성을 보장할 수 없다.🔸 풍부한 단위 테스트 & 큰 기능 단위를 검증하는 통합 테스트Library vs. Framework내 코드가 주체가 되어서 필요한 기능은 외부에서 끌어다 옴 vs. 이미 갖춰진 동작 환경에서 내 코드가 수동적으로 역할을 하게 됨Spring🔸 Ioc (Inversion of Control)객체의 생명주기를 주관해서. 필요한 객체가 있을때 필요한 객체를 제3자가 만들어서 주입해줌🔸 DI (Dependency Injection)생성자를 주입해서 사용함. 어디서 온 것인지는 알 수 없음(주는 것만 사용)🔸 AOP (Aspect Oriented Programming)비즈니스 흐름과 관계없는 부분을 하나로 모아서 다른 모듈로 분리해서 사용(스프링에서는 프록시 사용해서 구현 함)ORM (Object-Relational Mapping)객체지향에 대한 개념과 관계형 DB 간의 패러다임이 달라서 DB에 넣기에 어려움🔸 객체 지향 패러다임과 관계형 DB 패러다임의 불일치🔸 이전에는 개발자가 객체의 데이터를 한땀한땀 매피하여 DB에 저장 및 조회(CRUD)🔸 ORM 을 사용함으로써 개발자는 단순 작업을 줄이고, 비즈니스 로직에 집중할 수 있다.JPA. (Java Persistence API)🔸 Java 진영의 ORM 기술 표준🔸인터페이스이고, 여러 구현체가 있지만 보통 Hibernate를 많이 사용한다.🔸 반복적인 CRUD SQL 을 생성 및 실행해주고, 여러 부가 기능들을 제공한다.🔸 편리하지만 쿼리를 직접 작성하지 않기 때문에, 어떤 식으로 쿼리가 만들어지고 실행되는지 명확하게 이해하고 있어야 한다.🔸 Spring 진영에서는 JPA를 한번 더 추상화한 Spring Data JPA 제공🔸 QueryDSL 과 조합하여 많이 사용한다. (타입체크, 동적쿼리에 대한 장점. 실무에서는 필수로 사용하지만 강의의 범위를 넘어섬)🔸@Entity 테이블 과 객체를 매핑, @Id , @Column Entity 정의🔸@ManyToOne 두 객체간의 연관관계, @OneToMany, @OneToOne, @ManyToMany(일대다 - 다대일 관계로 풀어서 사용)엔티티 설계Order 와 Product 는 다대다 관계로서. 주문 입장에서 여러 음료수, 음료수 입장에서 여러 주문들이 된다.다대다 관계는. 일대다, 다대일 관계로 풀어서 접근할 것Order — OrderProduct — Product요구사항🔸 키오스크 주문을 위한 상품 후보 리스트 조회하기🔸 상품의 판매 상태 : 판매중, 판매보류, 판매중지→ 판매중, 판매보류인 상태의 상품을 화면에 보여준다🔸 id, 상품 번호, 상품 타입, 판매 상태, 상품 이름, 가격Persistence Layer🔸 Data Access 의 역할(여기에 집중한 레이어)🔸 비즈니스 가공 로직이 포함되어서는 안 된다. Data에 대한 CRUD에만 집중한 레이어Business Layer🔸 비즈니스 로직을 구현하는 역할🔸 Persistence Layer 와의 상호작용(Data를 읽고 쓰는 행위) 을 통해 비즈니스 로직을 전개시킨다.🔸 트랜잭션을 보장해야 한다.(로직을 전개하다 문제가 생기면 롤백해야 하기에, 롤백에 대한 트랜잭션을 보장해 줘야 한다). 작업 단위에 대한 원자성

0

인프런 워밍업 스터디 클럽 3기 2주 차 발자국

코드 다듬기와 리팩토링에 대한 요약1. 코드 다듬기주석의 양면성:주석은 코드로 설명할 수 없는 의사결정 히스토리를 기록하는 데 사용하되, 자주 변하는 정보는 주석으로 작성하지 않는 것이 좋다. 주석이 많다는 것은 비즈니스 로직이 코드에 잘 녹아들지 못했음을 의미할 수 있다.가독성을 위한 메서드와 변수 정렬:메서드는 상태 변경 > 판별 > 조회 순으로 나열하고, 접근 제한자는 public → private 순서를 유지하면 가독성이 향상된다.패키지 구조 설계:패키지는 문맥 정보를 제공해야 하며, 너무 세밀하거나 큰 단위로 나누면 유지보수가 어려워진다. 대규모 변경 시 팀원들과 반드시 협의해야 한다.클린 코드의 현실적 접근:클린 코드는 은탄환이 아니다. 요구사항이 변하지 않는 경우 절차지향적인 코드가 더 적합할 수도 있다. 실무에서는 품질과 빠른 결과물 사이에서 균형을 잡는 것이 중요하다.2. 리팩토링리팩토링의 본질:리팩토링은 단순히 코드를 변경하는 것이 아니라, 응집도를 높이고 결합도를 낮추는 과정이다. 객체 간의 관계와 책임을 점검하며 진행해야 한다.예외 처리와 boolean 반환:기존의 boolean 반환 방식을 예외 처리로 변경하는 것은 상황에 따라 좋을 수도, 오버엔지니어링이 될 수도 있다. 예외 처리는 비용이 크므로 신중히 사용해야 한다.일급 컬렉션 활용:컬렉션을 직접 노출하지 않고 이를 감싸는 클래스를 사용하면 유지보수가 쉬워지고 테스트 가능성이 높아진다.객체에 메시지를 보내라:무분별한 getter 사용 대신 객체에 메시지를 보내는 방식으로 설계하자. 예를 들어, isSamePassTypeWith 메서드를 통해 객체 내부에서 비교하도록 하면 캡슐화가 강화된다.인터페이스 활용:조건별로 다른 동작을 수행해야 할 때 인터페이스를 도입해 if문 사용을 줄이고 유연성을 높일 수 있다.3. 리팩토링 사례✅ 리팩토링 성공 사례중복 제거 및 메서드 추출:중복된 로직을 제거하고 메서드로 분리해 가독성과 재사용성을 높였다.StudyCafePassMachine 의존성 주입:필요한 의존성을 외부에서 주입받도록 하여 내부 구현을 외부에 노출하지 않도록 개선했다.도메인 모델 개선:StudyCafePassType 내 LOCKER_TYPES 상수를 선언해 사물함 관련 로직을 간단하게 처리했다.특정 타입만 처리하는 로직을 enum 내부에서 해결하도록 하여 책임 분리를 명확히 했다.Order 도메인 추출:스터디 카페 좌석 이용권과 사물함 이용권을 합친 Order 도메인을 새로 만들어 FixedPassType 관련 분기문을 간소화했다.❌ 놓친 부분과 개선 방향FileHandler 개선 필요:데이터를 가져오는 로직만 포함되어 있으나, File 관련 로직이 추가되면 클래스가 방대해질 우려가 있다. Provider를 통해 데이터 요구사항 중심으로 설계하는 것이 바람직하다.도메인과 View 로직 분리 부족:StudyCafePassType enum에 입력 관련 필드(command)가 포함되어 있어 도메인 모델과 View 로직이 섞였다. 이는 입력 방식 변경 시 도메인 모델까지 수정해야 하는 문제를 초래한다.4. 최종 결론좋은 코드는 단순히 동작하는 코드가 아니라, 이해하기 쉽고 유지보수 가능한 코드다.완벽한 설계는 없으며, 지속적으로 개선하며 유연한 구조를 만들어가는 것이 중요하다.객체 지향 설계의 핵심은 변경에 유연한 구조를 만드는 것이다.

0

[인프런 워밍업 클럽 스터디 3기] 미션 4

미션프로덕트의 Opportunity Solution Tree 만들기왜 그런 Opportunity들과 Solution들을 도출했는지, 생각의 과정도 함께 적기 대상 프로덕트마켓컬리 Desired Outcome 고객의 재구매율을 높인다지속적인 성장을 위해서는 신규 고객 유입뿐만 아니라 기존 고객이 반복 구매하도록 유도하는 것이 핵심이므로특히 마켓컬리의 주력상품인 신선식품(채소, 과일, 육류, 유제품 등)은 한 번 만족하면 재구매 가능성이 높음소비 주기가 짧아 일정 기간마다 지속적으로 필요하므로신선식품은 품질 차이가 크고, 온라인에서는 직접 보고 고를 수 없기 때문에 한 번 만족한 고객은 같은 곳에서 재구매하려는 경향이 강하므로 Opportunity & SolutionOpportunity : 첫 구매 후 사이트 방문 빈도가 낮다신선식품은 한 번 만족하면 재구매 가능성이 높은데, 고객이 첫 구매 후 방문하지 않는다면 그 경험을 이어나가지 못하는 문제가 생김 -> 재방문을 유도하는 방법들을 고민Solutions :첫 구매 고객에게 맞춤형 추천 상품 제공 구매 후 리뷰 작성 시 할인 쿠폰 지급 첫 구매 후 7일 내 재방문 유도 메시지 발송Opportunity : 장바구니에 담았지만 결제하지 않는 비율이 높다해당 상품에 관심이 있지만 가격이 비싸게 느껴지거나, 구매에 고민이 되어 결제하지 않는 것으로 생각 -> 가격이 변하거나 좋은 리뷰를 보여주어 상품에 매력을 느끼도록 함Solutions :장바구니에 있는 상품 가격 변동 알림 제공 장바구니 보관 기한 연장 & 리마인드 알림 베스트셀러 제품 리뷰 강조하여 신뢰도 향상Opportunity : 특정 고객층의 구매 주기가 길다신선식품이 필요하지만, 매번 주문하는 것이 귀찮은 고객층이 존재 -> 자연스럽게 재구매를 유도하는 방법이 효과적일 것으로 판단Solutions :정기구독 모델 도입 (필수 식료품 자동 배송) 최근 구매한 상품 기반으로 맞춤형 재구매 추천 "이번 주 인기 장바구니" 기능으로 구매 유도

기획 · PM· PO

0

CS 1주차 발자국

운영 체제운영체제 개요컴퓨터는 운영체제가 없어도 동작이 가능예전 전화기는 통화만 되지만 최신 휴대전화는 어플등 다양한 기능이 가능운영체제의 일프로세스 관리메모리 관리하드웨어 관리파일 시스템 관리운영체제의 역사1943 애니악1950초반 직접회로 개발후반 싱글 스트림 배치시스템1960시분할 시스템싱글 스트림 배치 시스템 한계 극복프로그램을 순서대로 실행하는 것이 아닌 메모리에 여러 프로그램을 올려 놓고 시간을 나누어서 빠르게 돌아가며 실행UNIX멀티 프로그래밍다중 사용자파일 시스템1970개인용 컴퓨터의 시대매킨토시, ms-dos 운영체제의 구조커널프로세스와 메모리, 저장 장치를 관리하는 기능사용자는 인터페이스를 통해 접속사용자는 GUI, CLI로 커널 제어어플리케이션과 커널의 인터페이스는 시스템 콜을 사용하드웨어와 커널의 인터페이스는 드라이버를 사용컴퓨터 하드웨어와 구조폰 노이만 구조CPU와 메모리 사이에 버스로 연결.메인보드다른 하드웨어를 연결하는 장치cpu와 메모리가 필수CPU(중앙처리 장치)산술 논리 연산장치, 제어장치, 레지스터의 구조메모리 종류ram전원을 끄면 메모리가 휘발ROM(Read Only Memory)전월을 꺼도 메모리가 보존.바이오스 등 수정되지 않는 데이터를 저장부팅 과정ROM에 저장된 바이오스 실행부트 오더인터럽트cpu는 입출력 작업이 들어오면 입출력 관리자에게 입출력 명령주기적으로 장치들에게 확인→ polling 방식. 효율이 좋지 않음polling방식의 단점을 보완한게 인터럽트입출력 명령을 내리고 입출력 관리자는 입출력이 발생하면 cpu에게 전달cpu는 isr실행시켜 작업 완료.하드웨어 인터럽트소프트웨어 인터럽트 프로그램하드디스크 등과 저장장치에 저장된 명령문의 집합체저장 장치만 사용하는 수동적인 존재프로세스실행중인 프로그램하드디스크에 저장되어 있는 프로그램이 메모리에 올라가있는 상태메모리도 사용하고 운영체제의 cpu 스케줄링 알고르즘도 사용, 출력와 입력도 하는 능동적인 존재프로세스 구조code, data, heap, stack 영역으로 구조code실행하는 코드가 저장data전역 변수와 static(정적) 변수가 저장heap동적으로 메모리를 할당하는데 사용.stack지역 변수와 함수를 호출했을때 필요한 정보들이 저장프로세스가 되는 과정컴파일 과정전처리기 → 컴파일러 → 어셈블러 → 링커(링킹)유니프로그래밍메모리에 오직 하나의 프로세스가 올라와 처리하는 것cpu는 프로세스를 실행하다가 i/o 작업을 만나면 기다렸다가 완료되면 작업을 처리하나의 프로세스를 다 끝내야 다른 프로세스를 실행하는 단점이 존재.멀티 프로그래밍메모리에 여러개의 프로세스를 올려서 실행cpu가 프로세스를 실행하다가 I/O 작업을 만나면 기다리면서 다른 프로세스를 실행cpu 쉬는시간이 줄어들어 효율적여러개의 프로세스를 돌아가면서 짧은시간동안 작업을 진행하여 모든 프로세스를 동시에 실행시키는 것처럼 느끼게 하는 기술→ 멀티태스킹cpu를 한개가 아니라 여러개를 이용→ 멀티 프로세서멀티 프로세서로 작업을 처리하는 방식을 멀티 프로세싱이라 칭함.PCB(Process Control Block)프로세스가 만들어지면 운영체제는 해당 프로세스의 정보를 갖고 있는 PCB를 만들고 저장.PCB들은 연결리스트라는 자료 구조로 저장.프로세스가 종료되면 연결리스트에서 해당 프로세스의 PCB를 제거.연결 리스트의 구조는 유지PCB 구조포인터부모와 자식 프로세스에 대한 포인터와 할당된 자원에 대한 포인터를 저장프로세스 상태현재 프로세스의 5가지 상태를 나타냄생성, 준비, 실행, 대기, 완료프로세스 ID프로세스를 식별하기 위한 숫자프로그램 카운터다음에 실행될 명령어의 주소를 포함하는 프로그램 카운터를 저장레지스터 정보프로세스가 실행될때 사용했던 레지스터 값들을 저장메모리 관련 정보메모리에 있는 위치정보, 경계레지스터 값 등이 저장CPU 스케쥴링 정보스케쥴링에 필요한 우선순위, 최종 실행시간, CPU 점유 시간등이 저장프로세스 상태시분할 시스템을 사용하는 운영체제는 여러개의 프로세스를 돌아가면서 실행cpu가 여러개의 프로세스를 동시에 실행하는 것이 아니라 한 순간에는 하나의 프로세스밖에 처리하지 못함속도가 빨라 사람이 보기엔 동시에 처리로 보임.생성 상태PCB를 생성하고 메모리에 프로그램 적재를 요청한 상태준비 상태CPU를 사용하기 위해 준비하고 있는 상태CPU 스케쥴러에 의해 CPU가 할당됨.대부분의 프로세스 상태실행 상태준비상태에 있는 프로세스가 CPU 스케쥴러에 의해 CPU를 할당받아 실행되는 상태실행상태에 있는 프로세스의 수는 CPU의 갯수만큼부여된 시간만큼만 사용이 가능시간이 완료되면 다시 준비 상태로 변경대기 상태프로세스가 입출력을 요청하면 입출력이 완료될 때까지 기다리는 상태완료 상태프로세스가 종료된 상태데이터를 메모리에서 제거하고 생성된 PCB제거 컨텍스트 스위칭프로세스를 실행하는 중에 다른 프로세스를 실행하기 위해 실행중인 프로세스의 상태를 저장하고 다른 프로세스의 상태값으로 교체하는 작업실행중인 프로세스의 작업 내용을 PCB에 저장하고 실행될 기존 프로세스의 PCB의 내용대로 CPU가 다시 세팅됨. PCB에 변경되는 값들은 프로세스 상태, 프로그램 카운터, 레지스터 정보, 메모리 관련 정보 등컨텍스트 스위칭이 발생하는 이유CPU 점유 시간이 다 된 경우I/O 요청이 있는 경우다른 종류의 인터럽트가 있는 경우프로세스 생성과 종료.exe 파일 실행시 운영체제는 포로그램의 코드영역과 데이터 영역을 메모리에 로드하고 빈스택과 빈 힙을 만들어 공간을 확보프로세스를 관리하기 위한 pcb를 만들어 값을 초기화프로세스 생성과 정은 운영체제가 부팅되고 0번 프로세스가 생성될때 딱 1번만 실행.나머지 모든 프로세스는 새로 생성하지 않고 0번 프로세스를 복사해서 사용복사는 fork()함수를 사용새로 생성하는 것보다 복사하는게 빠르기 때문복사한 프로세스는 자식 프로세스0번 프로세스는 부모 프로세스자식 프로세스는 부모 프로세스의 코드영역, 데이터 영역, 스텍 영역가 pcb 내용을 전부 복사그럼 복사하면 0번 프로세스가 똑같이 실행되는거 아닌가?맞음. 그대로 복사하니 당연한 결과자기가 원하는 코드는 exec() 함수를 이용하여 실행.부모를 복사한 자식 프로세스의 코드와 데이터 영역을 원하는 겂으로 덮어쓰게됨.자식프로세스는 부모 프로세스와 다르게 동작 부모 프로세스와 자식 프로세스는 cpu 스케줄링에 따라 실행되는데 순서는 운영체제 따라 결정.부모 프로세스가 먼저 실행되는 경우pid 값을1 받으면 17번째 줄 함수 실행자식 프로세스의 exit 실행될때까지 대기.자식 프로세스 실행12번 함수 실행 후 13번 함수를 통해 프로세스 종료를 부모 프로세스에게 전달대기하고 있던 부모 프로세서는 자식 프로세스의 종료 신호를 받고 18번 함수 19번 함수를 실행하고 종료만약 부모 프로세스가 자식 프로세스보다 먼저 종료되거나 자식 프로세스가 비정상적인 종료가 되어서 exit신호를 주지 못해 ExitStatus를 읽어오지 못하여 메모리에 계속 살아 있는 상태를 좀비 프로세스라고 함쓰레드운영체제가 작업을 처리하는 단위는 프로세스프로세스를 생성하면 pcb가 생성되고 프로세스 수만큼 pcb, 코드, 데이터, 스택, 힙 영역도 만들어줘야 하기 때문에 너무 무거워짐.그래서 프로세스가 많아질수록 메모리를 많이 차지 하게 됨.⇒ 쓰레드 고안쓰레드는 프로세스 안에 있고 한개 또는 여러개가 존재하게 됨.쓰레드들은 프로세스의 pcb, code, data, heap영역을 공유. 단 stack은 쓰레드마다 하나씩 갖고 있음. 쓰레드들에게 id를 부여하고, 쓰레드를 관리하기 위한 TCB(Thread Control Blcok)이 생성.운영체제 관점에서 쓰레드들도 구분이 가능해짐.브라우저에서 탭을 하나 추가로 생성하면, 프로세스가 생성되는 것이 아니라 쓰레드가 하나 더 생성됨.프로세스와 쓰레드의 장단점안정성프로세스는 서로 독립적이기 때문에 하나의 프로세스가 문제 있어도 다른 프로세스는 영향을 받지 않는다.쓰레드는 하나의 프로세스 안에 존재하기 때문에 프로세스에 문제가 생기면 쓰레드에게도 문제가 생긴다.프로세스 방식이 쓰레드 보다 우수속도와 자원각각의 프로세스는 서로 고유한 자원을 갖고 있음. code, data, heap, stack영역을 전부 따로 두고 있고, 프로세스간 통신을 하려면 IPC를 이용해야 해서 오버헤드가 크고 속도가 느림.쓰레드는 한 프로세스 내에서 stack 영역을 제외한 영역을 공유하므로 오버헤드가 작음. 쓰레드 간의 통신은 데이터를 공유할 수 있으니 쉽지만, 공유되는 공간에서 문제가 생길 수 있음. CPU 스케쥴링 개요운영체제는 모든 프로세스에게 cpu를 할당/해제 하는데 이를 cpu 스케쥴링이라 함.스케줄러(운영체제)의 고려사항어떤 프로세스에게 cpu리소스를 주어야 하는가.cpu를 할당 받은 프로세스가 얼마나 cpu를 사용해야 하는가.시분할 처리 방식으로 여러 프로세스에 짧은 시간동안 돌아가면서 Cpu를 할당.→ 컴퓨터의 성능에 영향을 많이 미침.cpu를 할당받아 처리하는 작업을 CPU Burst. 입출력 작업을 I/O Burst.다중 큐큐먼저 들어온걸 먼저 처리하고, 나중에 들어온걸 나중에 처리하는 구조.프로세스가 실행상태에서 준비 상태로 돌아갈때운영체제는 해당 프로세스의 우선순위를 보고 그에 맞는 준비 큐에 넣음.cpu스케줄러는 준비 상태의 다중큐에 들어있는 프로세스들 중에 적당한 프로세스를 선택해서 실행 상태로 전환.프로세스가 실행상태에서 i/o 요청을 받아 대기상태로 오면i/o 작업 종류에 따라서 분류된 큐에 들어가게 됨.hdd, lan, 키보드 큐큐에 들어가는건 프로세스의 정보를 갖고 있는 PCB가 들어감.프로세스 정보를 담고 있는 PCB는 준비상태의 다중큐에 들어가서 준비되길 기다리며, CPU스케쥴러에 의해 실행 상태로 전환.CPU스케쥴러는 준비상태의 다중큐를 참조하여 어떤 프로세스를 실행시킬지 결정I/O 작업도 종류별로 나누어진 큐에 들어가고 CPU스케쥴러는 이를 참조해 스케쥴링을 진행.스케쥴링 목표리소스 사용률CPU사용률을 높이는것을 또는 I/O 사용률을 높이는것을 목표로 할 수 있음.오버헤드 최소화스케줄링을 하기 위한 계산이 복잡하거나 컨텍스트 스위칭을 자주하면 배보다 배꼽이 커지는 상황이 발생.스케줄러는 이런 오버헤드를 최소화 하는것을 목표공평성모든 프로세스에게 공평하게 CPU가 할당되어야 함.공평의 의미는 시스템에 따라 달라질 수 있음.처리량같은 시간내에 더 많은 처리를 할 수 있는 방법을 목표로 함.대기시간작업을 요청하고 실제 작업이 이뤄지기 전까지 대기하는 시간이 짧은 것을 목표로 함.응답시간대화형 시스템에서 사용자의 요청이 얼마나 빨리 반응하는지가 중요하므로 응답시간이 짧은것을 목표로 함.모든 목표를 최고 수준으로 유지하기는 힘듬.서로 상반된 목표가 있기 때문.처리량을 높이기 위해서는 하나의 프로세스에 cpu를 오래 할당해야함.응답시간을 줄이기 위해서는 여러 프로세스에 cpu를 골고루 할당해야함.→ 처리량과 응답시간의 목표를 같이 달성할 수 없음.→ 사용자가 사용하는 시스템에 따라서 목표를 다르게 설정.스케쥴링 알고리즘FIFO(First In First Out)먼저 들어온 작업이 먼저 나감.스케쥴링 큐에 들어온 순서대로 cpu를 할당하는 방식.먼저 들어온 프로세스가 완전히 끝나야만 다음 프로세스가 실행 됨.장점단순하고 직관적단점한 프로세스가 완전히 끝나야 다음 프로세스가 실행되기 때문에 실행시간이 짧고 늦게 도착한 프로세스가 실행시간이 길고 빨리 도착한 프로세스의 작업을 기다려야 함.또한 I/O작업이 있다면 cpu가 i/o작업이 끝날때까지 기다리기때문에 cpu 사용률이 떨어짐.스케줄링의 성능은 평균 대기 시간으로 평가평균 대기 시간은 프로세스가 여러개 실행될때 이 프로세스가 모두 실행될때까지 대기 시간의 평균.프로세스 1의 burst는 25초, 프로세스2는 5초 프로세스3은 4초.프로세스1이 먼저 도착했으므로 대기시은 0초.프로세스2는 프로세스1이 실행되고 실행 하므로 대기시간은 25초.프로세스 3은 프로세스1과 프로세스2가 실행되고 실행 하므로 대기시간은 30초.평균 대기시간은 18.3초.순서가 바뀌면프로세스3은 바로 시작 되었으므로 대기시간은 0초.프로세스2이 실행되고 프로세스2가 실행. 대기시간은 4초.프로세스1은 프로세스 3,2 실행 시간만큼 기다려서 대기시간은 9초.평균 대기시간은 4.3초.⇒ FIFO 알고리즘은 프로세스의 Burst Time에 따라 성능의 차이가 심하게 나서 현대 운영체제에서는 잘 쓰이지 않고 일괄 처리 시스템에 사용됨.SJF(Shortest Job First)FIFO의 단점을 보완.이론적으로 FIFO보다 성능이 좋음.하지만 문제점 발생어떤 프로세스가 얼마나 실행될 지 예측이 힘듦.BurstTime이 긴 프로세스는 아주 오래동안 실행되지 않을 수 있음.→ 이러한 문제때문에 SJF알고리즘은 사용되지 않음.RR(Round Robin)FIFO알고리즘은 일괄처리 시스템엔 적절하지만 시분할 처리 시스템엔 부적절SJF알고리즘의 단점은 프로세스의 종료 시간을 예측하기 힘듦.FIFO 알고리즘의 단점을 해결한 프로세스에게 일정 시간만큼 cpu를 할당하고, 할당시간이 지나면 강제로 다른 프로세스에게 일정 시간만큼 cpu를 할당.강제로 cpu를 빼앗긴 프로세스는 큐의 마지막으로 이당.프로세스에게 할당하는 일정 시간은 타임 슬라이스 또는 타임 퀀텀이라고 부름.평균 대기시간 측정타임슬라이스: 10sP1의 BursTime은 25초 / P2는 4초 / P3는 10초P1은 큐에 들어오자마 실행. 대기시간은 0초25초중 타임 슬라이스 값인 10초만 실행되고 나머지 시간은 큐의 제일 뒤로 이동.P2(4s) / P3(10s) / P1(15s)p2는 10초동안 기다림. 대기시간은 10초BurstTime인 4초만 실행하고 종료.P3(10s) / P1(15s)p3은 14초동안 기다림. 대기시간은 14초BurstTime인 10초만 실행하고 종료P1(15s)p1은 p2, p3의 실행 시가만큼 기다림. 대기시간은 14초.BurstTime이 타임 슬라이스 값보다 크므로 10초만 실행.남은 작업시간은 큐의 맨 뒤로 생성P1(5s)다시 P1의 남은 작업을 실행. 큐에 생성되자마자 실행 되므로 대기시간은 0초.→ 평균 대기시간은 12.67sRR방식과 FIFO방식의 평균 대기시간이 비슷할 수 있음.평균 대기시간이 비슷하면 RR방식이 비효율적→ 컨텍스트 스위칭이 있기 때문에 컨텍스트 스위칭 시간이 더 추가되기 때문.→ RR 알고리즘의 성능은 타임슬라이스 값에 따라 크게 달라짐.타임 슬라이스가 무제한인 경우 FIFO와 같음.타임 슬라이스가 작은경우에는 컨텍스트 스위칭이 너무 자주 발생함.타임 슬라이스에서 실행되는 프로세스의 처리 양보다 컨텍스트 스위칭을 처리하는 양이커져서 오버헤드가 너무 커지는 상황 발생.최적의 타임슬라이스를 설정하는 방법은 사용자가 느끼기에 여러 프로세스가 버벅 거리지 않고 동시에 실행된다고 느끼면서 오버헤드가 너무 크지 않는 값을 찾아야 함.윈도우는 20ms, Unix는 100msMLFQ(Multi Level Feedback Queue)가장 일반적으로 쓰이는 cpu 스케쥴링 기법탄생 배경RR의 업그레이드 된 알고리즘P1은 I/O 작업 없이 CPU연사만 하는 프로세스, P2는 1초 CPU 연산을 하고 10초 동안 I/O 작업.P1 → Cpu Bound Process // P2 → I/O Bound ProcessCpu Bound Process는 Cpu 사용률과 처리량을 중요하게 여김.I/O Bound Process는 응답 속도를 중요하게 여김타임 슬라이스 값에 따른 효율 분석. (P2가 먼저 시작된다고 가정)타임 슬라이스가 100초인 경우I/O 요청이 발생하고 P1이 100초동안 실행됨. 타임 슬라이스가 1초인 경우I/O요청이 발생하고 P1이 10번 실행되면 P2의 작업이 끝나 인터럽트가 발생되고, P2는 큐에 들어감.P2는 다시 1초 실행 되고 다시 I/O 작업을 기다림.이후 계속 반속 상황 비교CPU는 쉬지 않고 일해서 CPU사용률은 100%I/O 사용률을 보면 P1이 실행되는 동안 P2의 I/O 작업이 완료된 시점부터 기다리는 시간이 발생하기 때문에 10%밖에 되지 않음.타임 슬라이스가 작기 때문에 P2가 첫번째 상황처럼 기다리며 낭비되는 시간이 거의 없음. 90%정도 나오게 됨. CPU 사용률과 I/O 사용률이 좋게 나오는 작은 크기의 타임슬라이스를 선택그리고 CPU Boud Process 타임 슬라이스를 크게 설정.운영체제 입장에서 CPU Boud Process와 I/O Bound Process 구분하는 기준CPU를 실행하는 프로세스가 스스로 CPU를 반납하면 CPU사용량이 적은거니 I/O Bound Process일 가능성이 큼.반대로 CPU를 사용하는 프로세스가 타임 슬라이스 크기를 오버해서 강제로 CPU를 뺏기는 상황이면 CPU Boud Process일 확률이 높음.우선 순위를 가진 큐를 여러가지 준비.우선순위가 높으면 타임 슬라이스가 낮고 우선순위가 낮을 수록 타임 슬라이스 크기가 커짐.타임 슬라이스 크기를 오버해서 강제로 Cpu를 뺏기면 원래있던 순위보다 우선순위가 낮은 큐로 이동.자료구조 자료구조데이터가 어떻게 저장되고 어떻게 사용되는지 나타냄.가장 간단한 자료구조는 변수, 배열알고리즘어떤 문제를 해결하기 위한 확실한 방법자료구조가 바뀌면 알고리즘도 바뀐다시간복잡도특정 알고리즘이 어떤 문제를 해결하는 데 걸리는 시간시간을 측정하는 시간이 아닌 실행시간을 예측반복문이 많아지면 시간이 늘어난다.최선의 경우 - $\varOmega$최악의 경우 배열의 길이만큼 - Big-O평균의 경우 - $\Theta$ 배열기본적으로 제공하는 자료구조일반적인 프로그래밍 언어는 배열을 선언할때 배열의 크기를 선언.운영체제는 메모리에서 해당 크기만큼 연속된 빈공간을 찾아서 값을 할당.할당하지 않은 부분은 의미없는 쓰레기 값을 전달하고, 운영체제는 배열의 시작 주소만 기억.배열의 인덱스 참조는 크기에 상관없이 한번에 찾아와서 O(1)의 성능을 갖는다.하지만, 데이터 삽입, 삭제의 성능은 좋지 않음.배열의 데이터는 메모리에 연속된 공간에 할당하고 있음.배열 크기를 넘어서 할당하게 되면 문제가 발생.배열의 끝에는 다른 데이터가 있을경우 운영체제는 다시 연속적인 크기의 메모리를 찾아서 다시 할당하고. 기존의 데이터를 복사까지 해주어야함.그렇다고 배열의 크기를 처음부터 크게 할당하면 일시적으로 해결된것 처럼 보이지만, 처음부터 공간을 크게 할당하면 배열하나의 메모리양이 커지고, 다 사용하지 않으면 공간의 낭비이다.JS의 배열은 상황에 따라서 연속적, 불연속적으로 메모리를 할당하지만 대부분 불연속적으로 할당.메모리는 내부적으로 연결하여 사용자에게는 연속적처럼 느껴지게함.장점읽기, 쓰기와 같은 참조에는 O(1)의 성능을 가진다단점크기 예측이 힘들기 때문에 메모리 낭비가 발생할 수 있다.데이터 삽입, 삭제가 비효율적이다.연결리스트(Linked List)배열의 단점을 보완.저장하는 데이터들을 메모리에 분산해서 할당하고 데이터들을 서로 연결.Node라는 것을 만들어서 수행Node의 구조데이터를 담는 변수다음 노드를 가리키는 변수연결 리스트는 첫 노드의 주소만 알고 있으면 다른 모든 노드에 접근 할 수 있음.연결이라는 특성 때문에 배열과 다른 장단점을 갖고 있음.장점중간에 데이터를 삽입(삭제)하게 되는 경우 다음 노드의 정보만 바꿔주면 되므로 간단.단점특정 인덱스의 데이터에 바로 접근이 힘듦. 첫번째 노드에서 부터 순서대로 원하는 인덱스까지 이동해야 하므로 데이터 참조는 O(n)의 성능을 가짐.배열과의 비교크기배열은 고정연결리스트는 노드를 만들어 연결해주므로 동적주소배열은 연속적으로 할당연결 리스트는 불연속적인 공간에 할당데이터 참조배열은 메모리 접근이 빠름(O(1)연결리스트는 앞에서부터 해당 노드에 접근해야 하므로 느림(O(n))삽입과 삭제배열은 모든 데이터를 옮겨야해서 O(n)의 성능연결리스트는 삽입하려는 노드까지 계속 노드를 타고가야 하므로 O(n)의 성능 스택(Stack)First In Last Out(FIFO)먼저 들어온 데이터가 마지막에, 가장 늦게 나온 데이터가 제일 앞에 있는 데이터 구조.큐(Queue)First In First Out덱(Deque)덱은 데이터를 tail, head에 삽입과 삭제가 자유로운 자료 구조해시 테이블(Hash Table)해시, 맵, 해시맵, 딕셔너리로 언어마다 다른 이름을 갖고 있음.장점빠른 데이터 읽기삽입, 삭제단점메모리를 많이 차지함.좋은 해시 함수의 구현이 필수정Set데이터 중복을 허용하지 않는 자료 구조해시 테이블을 사용. HashSet이라고 불리기도 함.

운영체제

0

워밍업 클럽 3기 PM/PO_미션4

미션 4여러분이 맡은 프로덕트의 Opportunity Solution Tree를 만들어보세요. (맡고 있는 프로덕트가 없는 경우, 프로덕트를 하나 정해서 해 보세요) 왜 그런 Opportunity들과 Solution들을 도출했는지, 생각의 과정도 함께 적어주세요. Opportunity 및 솔루션 도출 과정블로그를 운영하면서 생각보다 뜻대로 수익 창출이 되지 않아서 어떠한 방법으로 가능할지를 생각해보았습니다.사용자 유입일단 조회수가 계속해서 발생해야한다고 생각했습니다. 사용자가 유입이 되어야 광고 노출을 통한 수익을 기대할 수도 있고, 제휴사를 통한 수익이 발생할 수 있을 거라고 생각했습니다.블로그는 컨텐츠 발행을 통해 사용자가 유입되는 것이기에 어떻게 해야 유입이 될지를 생각해보았을 때,1) 블로그는 서로이웃/이웃을 맺게되면 신규 포스트로 보여지게 됩니다. 이를 이용해서 블로그 조회수를 높힐 수 있을거라고 생각했습니다. 특히 같은 성격의 게시글을 올리는 블로거와의 이웃을 맺음으로써 그 블로거의 포스팅을 통해 어떤 식으로 포스팅 해야할지에 대한 접근 방식도 분석이 가능할 수 있을 거라고 생각했습니다.2) 검색시 보여질 수 있도록 어떤 검색어가 유입이 많이 되는지 분석을 통해 조회수를 높힐 수 있을 거라고 생각했습니다. 또한, 정보성과 후기 콘텐츠의 조회수 차이를 분석하여 어떤 쪽에 집중하여 게시글 포스팅에 대한 방향성도 잡을 수 있을 거라고 생각합니다.2.수익모델 구축조회수를 높혀 포스트내의 광고 노출 수로 수익을 낼 수 있지만 제휴 업체를 통해 체험 또는 제품 제공을 통한 비금전적인 수익 및 제품을 광고함으로써 수익을 얻을 수 있을 거라 생각했습니다. 제휴 업체를 통한 수익을 내는 경우, 협찬글과 일반 게시글의 트래픽을 비교하여 방문객의 관심도에 대한 패턴을 파악하여 협찬되는 제품의 방향을 정하여 협찬 글의 조회수도 높힐 수 있는 방법도 있을 거 같습니다.

0