📚 이번주엔 뭘 배웠지?
[수업과정]
이번 주는 백엔드 개발자로서 핵심이 되는 인메모리 DB(REDIS),
MSA/애자일/폭포수 모델과 같은 SW 공학 개념, 그리고
Git/GitHub 실무 사용법을 폭넓게 배웠다.
📌 Redis & In-memory DB
- 메모리 기반 DB의 특징과 저장 방식 (메모리 vs 스토리지)
- Redis 설치 (도커 기반) 및 CLI 사용법
- Redis 자료구조 String, List, Set, ZSet, Hash
로그인/좋아요/캐싱/재고관리 등 실전 활용 사례 - TTL, incr/decr, pub/sub, streams 등 개념
- Redis 사용 시 주의점:
대용량 저장 불가
Redis만 저장소로 쓰면 위험(유실 가능성)
📌 SW 공학 & 개발 방법론
- 폭포수 모델: 기획 → 분석 → 설계 → 구현 → 테스트 → 유지보수
- 애자일 & 스프린트, MVP 개념
- MSA 구조와 서비스 간 동기/비동기 통신
- Kafka 같은 메시지 브로커의 역할
- Scale-out / Scale-up 개념
- 컨테이너, Docker, 쿠버네티스의 필요성
📌 Git/GitHub 실무
- 로컬/원격 저장소 개념, Git clone → add → commit → push 흐름
- Staging Area 역할
- main / feature 브랜치 구조
- 토큰 인증 방식
- .gitignore, reset, branch, log, checkout
- 다른 사람 repo를 내 repo로 가져오는 2가지 방식
- Git 충돌 해결과 commit ID의 의미
👊 어떤 문제점이 있었지?
[수업과정]
-
Redis 자료구조가 많아서 차이점과 활용처를 정확히 구분하는 데 혼동이 있었다.
(특히 String vs Hash, List vs ZSet) -
폭포수/애자일/MSA가 머리로는 이해되는데
실제 회사에서 어떻게 쓰는지 감이 부족하다.
[프로젝트]
1) 설계 초기에 요구사항이 계속 바뀌었다.
"곡은 장르 하나만 가진다?" → "여러 장르 가능"
"유저 재생 기록 테이블에 뭘 넣어야 하지?"
“차트는 어떻게 구성해야 하지?” 등
요구사항이 잡히지 않은 상태에서 설계를 시작해서 계속 수정이 필요했다.
2) 프로시저 작성 시 예외 케이스 처리 미흡
display_order가 NULL일 때 max+1 처리
곡 재생 시간 계산할 때 기본 유효성 검사 누락
last_insert_id 문제 등
로직은 큰 틀에서 맞았지만, 세부 조건 처리가 부족해 오류를 여러 번 마주했다.
🙏 무엇을 깨달았고, 어떤 생각이 들었지?
[수업과정]
-
redis를 쓰는 거는 "그냥 빠르다니까 쓰는 거겠지?” 정도로 생각했는데
왜 “메모리 기반 데이터 저장소가 왜 필요한지” 이해되었다.
디스크 I/O 없고 해시 테이블 기반 구조, 싱글 스레드 기반 처리,
복잡한 쿼리 없이 key-value로 접근 등
-> 이런 이유들을 알게 되니까 RDBMS와 역할이 완전히 다르다는 게 명확해졌다. -
프로젝트를 통해 설계했던 음악 스트리밍 서비스에서도 Redis가 어디에 쓰일지 자연스럽게 그려졌다.
-> 로그인 세션 관리 , 최근 재생곡 캐시, 곡 재생수 실시간 카운트, 특정 아티스트 인기곡 순위 캐싱, 인기 차트 캐싱 등 -
Git을 정말 잘 알아야 될거같다..
브랜치 전략·PR·Merge·충돌 해결 능력도 개발자의 실력일 것이다.
[프로젝트]
-
내팀은 주제를 음악 스트리밍 서비스를 제공하는 플랫폼을 선택하여 설계를 시작 했다.
-
이 플랫폼은 '재생순위에 의한 차트제공'과 '추천 기반의 차트제공' 이 가장 큰 특징이자 핵심이란 것을 프로젝트를 진행하면서 느꼈다. 서비스가 어떤 목적이고 반드시 지켜야할 점들을 알아야 내가 다른 무언갈 개발을 하더라도 핵심을 잃지 않겠다란 생각이 들었다.
-
기획–설계–실행 단계가 아직 매끄럽지 않다는 걸 느꼈다.
-> 기획 단계가 정말 중요했다. 이때 팀원들과 의견 조율을 많이 하며 기능설계 등을 했어야 했다. 주제 정하는데만 시간을 헛되이 쓰고, 기획단계에서 짧은 시간을 투자하여 혼자 설계하고 이해하는데 애를 좀 먹었다. -
차트 데이터를 어떻게 저장해야 유지보수가 쉬울까?
-> DB 설계는 맞고 틀림이 아니라, 유지보수성과 요구사항을 만족하는 선택의 문제일 수도 있겠다란 생각이 들었다. -
혼자 설계하면 보이는 것만 보였다.
“아 이게 빠졌네?”
“이 테이블이 있어야 유스케이스가 작동하네?”
전혀 다른 관점이 보인다.
팀 프로젝트에서 팀원들의 의견 리뷰가 정말 중요했다.
(물론 아예 안한 사람도 있어서 더욱 느꼈다. 잘 도와준 팀원에게는 고마웠다.)
😄 결과적으로, 현재 나의 상태는?
[수업과정]
-
Redis 사용법과 자료구조는 어느 정도 손에 익었지만,
실제 서비스 상황에서 어떤 구조를 선택해야 할지 감각은 아직 부족하다. -
MSA/애자일 같은 개념은 이해는 됐지만 경험이 쌓여야 명확해질 것 같다.
-
Git은 훨씬 익숙해졌지만 협업할때 조심하게 되는건 나뿐만은 아니겠지?
벌써 프로젝트할 때 Readme 파일을 한번 날려먹었다. (강제로 푸쉬함) -
전체적으로 배운 양이 많아 머릿속이 꽉 찬 느낌이다.
[프로젝트]
- DB 구조에 대한 이해도는 확실히 올라갔고,
- SQL 문법도 익숙해지고 있다.
👨🚀 앞으로 어떻게 하는게 좋을까?
[수업과정]
🔹 Git 브랜치 전략 연습
feature → main PR 보내는 흐름에 대한 이해가 누군가에게 확신에 찰 정도로 설명할 수 있게 복습을 해야겠다.
[프로젝트]
학교에서 했었던 프로젝트가 기억이 났다.
앞으로 프로젝트 진행시 모든 단계에서 참여자들의 참여의지를 꼭 확인하고 진행해야 될거 같다.
