🚀
Projects
진행 중인 프로젝트
현재 진행 중인 프로젝트들과 각 프로젝트와 관련된 포스트를 확인할 수 있습니다.
각 프로젝트는 학습 과정과 개발 경험을 기록하고 공유하기 위한 목적으로 진행되고 있습니다.
이 페이지는 단순 포트폴리오 목록보다 프로젝트별로 무엇을 만들었고, 어떤 문제를 겪었고, 어떤 글부터 읽으면 흐름이 잡히는지를 안내하는 허브입니다. 같은 기술 스택이라도 실제 프로젝트 안에서는 설계 의도, 운영 제약, 테스트 방식, 장애 가능성이 함께 움직입니다. 그래서 프로젝트를 볼 때는 기능 목록만 훑기보다, “처음에는 어떤 가정으로 시작했고, 구현 중 어떤 제약이 드러났으며, 다음 글에서 그 제약을 어떻게 줄였는가"를 따라가는 편이 더 좋습니다.
빠른 선택 가이드
데이터베이스 프록시와 운영 안전성을 보고 싶다면
pgmux부터 보는 것을 추천합니다. PostgreSQL wire protocol, 커넥션 풀링, 읽기/쓰기 라우팅, 캐시 무효화, TLS, circuit breaker, SQL redaction, OpenTelemetry 같은 주제가 한 프로젝트 안에서 이어집니다. 처음에는 “PostgreSQL 프록시를 직접 만들 수 있을까"라는 학습 목표에 가깝지만, 글이 진행될수록 운영자가 실제로 확인해야 하는 지표, 위험 쿼리 차단, 설정 리로드, 릴리스 전 QA 같은 주제로 넓어집니다.
읽기 순서는 아래 흐름이 좋습니다.
- PG Wire Protocol 이해로 프록시의 입구를 잡습니다.
- 커넥션 풀링과 R/W 라우팅에서 기본 동작을 봅니다.
- 쿼리 캐싱 이후에는 캐시 무효화와 일관성 문제가 왜 어려운지 확인합니다.
- QA 글들은 단순 버그 수정 기록이 아니라, 프록시처럼 상태가 많은 시스템에서 어떤 실패 모드를 먼저 의심해야 하는지 보여주는 릴리스 게이트 예시로 읽으면 좋습니다.
메시지 큐와 멀티 테넌트 설계를 보고 싶다면
Simple Queue Service는 메시지 큐를 직접 구현하면서 “간단한 큐"가 운영 가능한 서비스로 바뀌려면 무엇이 추가되어야 하는지를 따라가기 좋습니다. FIFO/Standard 큐, 지연 메시지, visibility timeout, DLQ, 스토리지 계층화 같은 기능은 각각 독립 기능처럼 보이지만, 실제로는 메시지를 잃지 않고, 중복 처리를 줄이고, 테넌트별 영향을 격리하기 위한 하나의 흐름입니다.
처음 읽는다면 1편: 간단한 메시지 큐에서 멀티 테넌트 시스템까지를 먼저 읽고, 2편 Admin 페이지 구현으로 이어가면 좋습니다. API만 만들었을 때는 보이지 않던 문제가 운영 화면을 만들면서 드러납니다. 큐 목록, 메시지 수, tenant context, 실패 메시지 상태를 눈으로 확인할 수 있어야 설계가 맞는지 검증할 수 있기 때문입니다.
블로그 자체의 정보 구조를 보고 싶다면
Study Blog는 이 사이트 자체를 개선해 온 기록입니다. Hugo, PaperMod, 검색, SEO, 구조화 데이터, 글 목록, 학습 허브, 프로젝트 허브 같은 요소가 어떻게 연결되는지 볼 수 있습니다. 특히 글이 많아질수록 중요한 것은 “글을 더 많이 쓰는 것"만이 아니라, 독자가 원하는 글을 빨리 찾고 다음 글로 자연스럽게 이동할 수 있는 구조를 만드는 일입니다.
프로젝트 글을 읽을 때 확인하면 좋은 질문
프로젝트 글은 완성된 정답보다 의사결정 과정을 남기는 쪽에 가깝습니다. 읽을 때 아래 질문을 같이 들고 보면 각 글의 목적이 더 선명해집니다.
- 처음 구현은 어떤 단순한 가정에서 출발했는가?
- 기능이 늘어나면서 데이터 모델, 상태 관리, 권한, 관측성 중 무엇이 먼저 흔들렸는가?
- 테스트나 QA에서 발견된 문제는 정상 경로가 아니라 어떤 경계 조건에서 터졌는가?
- 운영자가 실제로 확인해야 하는 지표, 로그, 관리자 화면, 롤백 방법은 무엇인가?
- 다음 글로 넘어가면서 설계가 더 단단해졌는가, 아니면 임시 우회가 늘어났는가?
프로젝트별 핵심 관점
| 프로젝트 | 핵심 주제 | 먼저 볼 지점 | 이어 읽을 관점 |
|---|
| pgmux | PostgreSQL 프록시, 풀링, 라우팅, 캐시, 운영 안전성 | wire protocol과 커넥션 풀링 | QA, 관측성, SQL redaction, 무중단 설정 |
| Simple Queue Service | 메시지 큐, 멀티 테넌트, visibility timeout, DLQ | 큐 기본 모델과 tenant key 설계 | Admin 화면, 스토리지 계층화, 운영 검증 |
| Study Blog | Hugo 블로그, 콘텐츠 구조, 검색, SEO | 학습 허브와 프로젝트 허브 | 내부 링크, front matter, 읽기 동선 |
운영 관점 체크리스트
프로젝트를 구현하거나 글로 정리할 때는 아래 기준을 계속 확인하려고 합니다.
- 기능 설명만 있고 실패 시나리오가 빠져 있지 않은가?
- 코드 예시가 실제 의사결정 기준과 연결되는가?
- 프로젝트 글과 학습 글이 서로 이어져 있는가?
- “왜 이렇게 만들었는지"와 “다시 한다면 무엇을 바꿀지"가 남아 있는가?
- 사용자가 다음에 읽을 글이나 확인할 저장소로 자연스럽게 이동할 수 있는가?
이 허브도 앞으로 프로젝트가 늘어날수록 계속 업데이트할 예정입니다. 새 프로젝트가 추가되면 단순 카드만 늘리는 대신, 어떤 독자가 왜 읽어야 하는지, 기존 학습 글과 어떤 주제로 연결되는지, 프로젝트가 보여주는 설계 trade-off가 무엇인지 함께 보강하는 방향으로 운영합니다.