<feed xmlns="http://www.w3.org/2005/Atom"> <id>https://vryez11.github.io/</id><title>d이지원b</title><subtitle>Vryez11의 개발 블로그입니다.</subtitle> <updated>2026-07-19T15:21:06+09:00</updated> <author> <name>vryez11</name> <uri>https://vryez11.github.io/</uri> </author><link rel="self" type="application/atom+xml" href="https://vryez11.github.io/feed.xml"/><link rel="alternate" type="text/html" hreflang="ko" href="https://vryez11.github.io/"/> <generator uri="https://jekyllrb.com/" version="4.4.1">Jekyll</generator> <rights> © 2026 vryez11 </rights> <icon>/assets/img/favicons/favicon.ico</icon> <logo>/assets/img/favicons/favicon-96x96.png</logo> <entry><title>오픈 소스 Tolgee 분석기_1</title><link href="https://vryez11.github.io/posts/%EC%98%A4%ED%94%88-%EC%86%8C%EC%8A%A4-Tolgee_1/" rel="alternate" type="text/html" title="오픈 소스 Tolgee 분석기_1" /><published>2026-07-19T13:32:00+09:00</published> <updated>2026-07-19T15:20:40+09:00</updated> <id>https://vryez11.github.io/posts/%EC%98%A4%ED%94%88-%EC%86%8C%EC%8A%A4-Tolgee_1/</id> <content type="text/html" src="https://vryez11.github.io/posts/%EC%98%A4%ED%94%88-%EC%86%8C%EC%8A%A4-Tolgee_1/" /> <author> <name>vryez11</name> </author> <category term="오픈소스" /> <category term="Tolgee" /> <summary>오픈 소스 Tolgee 분석기 1 일차 오픈 소스 분석을 하게 된 이유? 프로젝트를 진행하면서, 직접 코딩을 하고 이를 AI에게 리뷰 받는 방식에서 얘가 제대로 리뷰를 해주고 있나? 라는 생각이 들기 시작했다. 하지만, 내 기본기는 생각보다 좋지 못했고 코드 리뷰를 멘토님에게 매일 부탁드릴 수 없는 상황에서 그러면 잘 짜여진 best practice를 공부해볼까?라는 생각에서 오픈 소스 분석기(해체기)를 시작하게 됐다. 처음 프로젝트를 봤을 때, 너무 큰 프로젝트 볼륨에 어떻게 시작할지 막막했지만 API 요청 하나를 기준으로 수직적으로 공부해보는 방식으로 해체해야 겠다고 생각했다. 글 작성 기준은 API 하나 수직 해체가 끝날 때마다 작성할 예정이며, 주당 2회 작성을 목표로 ...</summary> </entry> <entry><title>Redis 실습 장애 대응 1</title><link href="https://vryez11.github.io/posts/Redis-%EC%8B%A4%EC%8A%B5-%EC%9E%A5%EC%95%A0-%EB%8C%80%EC%9D%91-1/" rel="alternate" type="text/html" title="Redis 실습 장애 대응 1" /><published>2026-07-13T22:00:00+09:00</published> <updated>2026-07-13T22:38:25+09:00</updated> <id>https://vryez11.github.io/posts/Redis-%EC%8B%A4%EC%8A%B5-%EC%9E%A5%EC%95%A0-%EB%8C%80%EC%9D%91-1/</id> <content type="text/html" src="https://vryez11.github.io/posts/Redis-%EC%8B%A4%EC%8A%B5-%EC%9E%A5%EC%95%A0-%EB%8C%80%EC%9D%91-1/" /> <author> <name>vryez11</name> </author> <category term="소마" /> <category term="Redis 장애 실습" /> <summary>증상 응답이 쌓일 수록 응답시간이 느려지는 증상 확인 요구사항 파악 Redis에서 point:* 키의 랜덤 100개를 받아서 렌더링한다. 클라이언트 쪽 렌더링 문제인가? 서버 쪽 응답 문제인가? 확인을 위해 개발자 도구로 확인했을 때, → 클라이언트는 요청을 보내는데, 서버 응답이 pending되어 늦어지는 것을 확인 이 후 서버 쪽 app.py 코드를 확인해봐야 겠다고 생각했다. 가설 결국, GET /points 로 불러올 때 문제였기 때문에, 코드를 자세히 보기로 판단 @app.get("/points") def get_points(): start = time.time() keys = r.keys("points:*") duration_...</summary> </entry> <entry><title>미니 SNS 스파클링 백엔드 2주차</title><link href="https://vryez11.github.io/posts/%EB%AF%B8%EB%8B%88-SNS-%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8-2%EC%A3%BC%EC%B0%A8/" rel="alternate" type="text/html" title="미니 SNS 스파클링 백엔드 2주차" /><published>2026-07-13T16:00:00+09:00</published> <updated>2026-07-13T19:39:35+09:00</updated> <id>https://vryez11.github.io/posts/%EB%AF%B8%EB%8B%88-SNS-%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8-2%EC%A3%BC%EC%B0%A8/</id> <content type="text/html" src="https://vryez11.github.io/posts/%EB%AF%B8%EB%8B%88-SNS-%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8-2%EC%A3%BC%EC%B0%A8/" /> <author> <name>vryez11</name> </author> <category term="프로젝트" /> <category term="스파클링" /> <summary>스파클링 2주차 회고 2주차에 한 것 핵심 유스케이스 작성 (목표) 사용자는 게시글 작성 후 등록을 통해 게시글 확이니 가능하다. 사용자는 댓글 작성과 댓글 좋아요가 가능하다. 사용자는 검색을 통해 게시글, 사용자 검색이 가능하다. 사용자는 게시글 작성 시 해시태그 작성이 가능하다. 사용자는 게시글 작성자와 1:1 채팅이 가능하다. API 목록표 초안 작성 API를 나눈 기준 : API가 어떤 자원을 이용하는지를 기준으로 (테이블) 기능 API를 나눔. 인증 여부 판단 기준 : 서박 요청자를 식별해야만 올바른 응답을 만들 수 있는 가...</summary> </entry> <entry><title>미니 SNS 스파클링 백엔드 1주차</title><link href="https://vryez11.github.io/posts/%EB%AF%B8%EB%8B%88-SNS-%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8-1%EC%A3%BC%EC%B0%A8/" rel="alternate" type="text/html" title="미니 SNS 스파클링 백엔드 1주차" /><published>2026-07-04T00:38:00+09:00</published> <updated>2026-07-13T16:15:30+09:00</updated> <id>https://vryez11.github.io/posts/%EB%AF%B8%EB%8B%88-SNS-%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8-1%EC%A3%BC%EC%B0%A8/</id> <content type="text/html" src="https://vryez11.github.io/posts/%EB%AF%B8%EB%8B%88-SNS-%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8-1%EC%A3%BC%EC%B0%A8/" /> <author> <name>vryez11</name> </author> <category term="프로젝트" /> <category term="스파클링" /> <summary>미니 SNS 프로젝트, 스파클링을 시작하며 1. 간단한 소개 Sparkling ✨ 은 소셜 네트워크 서비스(SNS)의 핵심 기능만 담은 미니 백엔드 프로젝트입니다. 거창한 서비스를 만들려는 게 아닙니다. 회원가입부터 게시글, 댓글, 좋아요까지 SNS의 뼈대가 되는 기능을 직접 설계하고 구현하면서, “왜 이렇게 만드는가”를 매주 기록으로 남기는 것이 목표입니다. 기술 스택은 다음과 같습니다. 구분 기술 Language Java 21 Framework Spring Boot 4.1.0 Security Spring Security, JW...</summary> </entry> <entry><title>트위치 시스템 디자인 300만 동시시청 파해치기</title><link href="https://vryez11.github.io/posts/%ED%8A%B8%EC%9C%84%EC%B9%98-%EC%8B%9C%EC%8A%A4%ED%85%9C-%EB%94%94%EC%9E%90%EC%9D%B8-%EC%99%84%EC%A0%84%EC%A0%95%EB%B3%B5-300%EB%A7%8C-%EB%8F%99%EC%8B%9C%EC%8B%9C%EC%B2%AD-%EB%B9%84%EB%B2%95-%EA%B3%B5%EA%B0%9C-%ED%8C%8C%ED%95%B4%EC%B9%98%EA%B8%B0/" rel="alternate" type="text/html" title="트위치 시스템 디자인 300만 동시시청 파해치기" /><published>2026-06-23T21:46:00+09:00</published> <updated>2026-06-24T00:54:39+09:00</updated> <id>https://vryez11.github.io/posts/%ED%8A%B8%EC%9C%84%EC%B9%98-%EC%8B%9C%EC%8A%A4%ED%85%9C-%EB%94%94%EC%9E%90%EC%9D%B8-%EC%99%84%EC%A0%84%EC%A0%95%EB%B3%B5-300%EB%A7%8C-%EB%8F%99%EC%8B%9C%EC%8B%9C%EC%B2%AD-%EB%B9%84%EB%B2%95-%EA%B3%B5%EA%B0%9C-%ED%8C%8C%ED%95%B4%EC%B9%98%EA%B8%B0/</id> <content type="text/html" src="https://vryez11.github.io/posts/%ED%8A%B8%EC%9C%84%EC%B9%98-%EC%8B%9C%EC%8A%A4%ED%85%9C-%EB%94%94%EC%9E%90%EC%9D%B8-%EC%99%84%EC%A0%84%EC%A0%95%EB%B3%B5-300%EB%A7%8C-%EB%8F%99%EC%8B%9C%EC%8B%9C%EC%B2%AD-%EB%B9%84%EB%B2%95-%EA%B3%B5%EA%B0%9C-%ED%8C%8C%ED%95%B4%EC%B9%98%EA%B8%B0/" /> <author> <name>vryez11</name> </author> <category term="기술 아티클" /> <category term="트위치" /> <summary>트위치 시스템 디자인 완전정복 | 300만 동시시청 비법 공개! 를 보고 참고한 아티클: 트위치 시스템 디자인 완전정복 1. 라이브 스트리밍은 어떻게 하는 거지? 전체 흐름을 먼저 정리하면 이렇다. replication 과정은 내가 아는 그 데이터 정합성? 데이터를 안전하게 유지하기 위해서 필요한 것인가? 여러 storage에 저장하는 것. 맞다. replication은 같은 미디어 데이터를 여러 storage에 복사해 두는 것이고, 목적은 안정성(가용성, 내구성)이다. 특정 storage(혹은 데이터 센터)가 죽더라도 다른 복사본에서 계속 데이터를 내보낼 수 있어야 라이브 방송이 끊기지 않는다. “한 곳에만 두면 그 한 곳이 죽었을 때 방송 자체가 멈춘다”는 단일...</summary> </entry> </feed>
