<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Portfolio on jyukki's Blog</title><link>https://jyukki.com/tags/portfolio/</link><description>Recent content in Portfolio on jyukki's Blog</description><generator>Hugo -- 0.147.0</generator><language>ko-kr</language><lastBuildDate>Mon, 22 Jun 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://jyukki.com/tags/portfolio/index.xml" rel="self" type="application/rss+xml"/><item><title>Projects</title><link>https://jyukki.com/projects/</link><pubDate>Tue, 19 Mar 2024 00:00:00 +0000</pubDate><guid>https://jyukki.com/projects/</guid><description>진행 중인 프로젝트와 관련 포스트를 구현 맥락, 읽기 순서, 운영 관점으로 탐색하는 프로젝트 허브</description><content:encoded><![CDATA[<h1 id="진행-중인-프로젝트">진행 중인 프로젝트</h1>
<p>현재 진행 중인 프로젝트들과 각 프로젝트와 관련된 포스트를 확인할 수 있습니다.<br>
각 프로젝트는 학습 과정과 개발 경험을 기록하고 공유하기 위한 목적으로 진행되고 있습니다.</p>
<p>이 페이지는 단순 포트폴리오 목록보다 <strong>프로젝트별로 무엇을 만들었고, 어떤 문제를 겪었고, 어떤 글부터 읽으면 흐름이 잡히는지</strong>를 안내하는 허브입니다. 같은 기술 스택이라도 실제 프로젝트 안에서는 설계 의도, 운영 제약, 테스트 방식, 장애 가능성이 함께 움직입니다. 그래서 프로젝트를 볼 때는 기능 목록만 훑기보다, &ldquo;처음에는 어떤 가정으로 시작했고, 구현 중 어떤 제약이 드러났으며, 다음 글에서 그 제약을 어떻게 줄였는가&quot;를 따라가는 편이 더 좋습니다.</p>
<h2 id="빠른-선택-가이드">빠른 선택 가이드</h2>
<h3 id="데이터베이스-프록시와-운영-안전성을-보고-싶다면">데이터베이스 프록시와 운영 안전성을 보고 싶다면</h3>
<p><a href="/projects/pgmux/">pgmux</a>부터 보는 것을 추천합니다. PostgreSQL wire protocol, 커넥션 풀링, 읽기/쓰기 라우팅, 캐시 무효화, TLS, circuit breaker, SQL redaction, OpenTelemetry 같은 주제가 한 프로젝트 안에서 이어집니다. 처음에는 &ldquo;PostgreSQL 프록시를 직접 만들 수 있을까&quot;라는 학습 목표에 가깝지만, 글이 진행될수록 운영자가 실제로 확인해야 하는 지표, 위험 쿼리 차단, 설정 리로드, 릴리스 전 QA 같은 주제로 넓어집니다.</p>
<p>읽기 순서는 아래 흐름이 좋습니다.</p>
<ol>
<li><a href="/posts/2026-03-11-pgmux-1-pg-wire-protocol/">PG Wire Protocol 이해</a>로 프록시의 입구를 잡습니다.</li>
<li><a href="/posts/2026-03-11-pgmux-2-connection-pooling/">커넥션 풀링</a>과 <a href="/posts/2026-03-11-pgmux-3-rw-routing/">R/W 라우팅</a>에서 기본 동작을 봅니다.</li>
<li><a href="/posts/2026-03-11-pgmux-4-query-caching/">쿼리 캐싱</a> 이후에는 캐시 무효화와 일관성 문제가 왜 어려운지 확인합니다.</li>
<li>QA 글들은 단순 버그 수정 기록이 아니라, 프록시처럼 상태가 많은 시스템에서 어떤 실패 모드를 먼저 의심해야 하는지 보여주는 릴리스 게이트 예시로 읽으면 좋습니다.</li>
</ol>
<h3 id="메시지-큐와-멀티-테넌트-설계를-보고-싶다면">메시지 큐와 멀티 테넌트 설계를 보고 싶다면</h3>
<p><a href="/projects/simple-queue-service/">Simple Queue Service</a>는 메시지 큐를 직접 구현하면서 &ldquo;간단한 큐&quot;가 운영 가능한 서비스로 바뀌려면 무엇이 추가되어야 하는지를 따라가기 좋습니다. FIFO/Standard 큐, 지연 메시지, visibility timeout, DLQ, 스토리지 계층화 같은 기능은 각각 독립 기능처럼 보이지만, 실제로는 메시지를 잃지 않고, 중복 처리를 줄이고, 테넌트별 영향을 격리하기 위한 하나의 흐름입니다.</p>
<p>처음 읽는다면 <a href="/posts/sqs-01-architecture/">1편: 간단한 메시지 큐에서 멀티 테넌트 시스템까지</a>를 먼저 읽고, <a href="/posts/sqs-02-admin-dashboard/">2편 Admin 페이지 구현</a>으로 이어가면 좋습니다. API만 만들었을 때는 보이지 않던 문제가 운영 화면을 만들면서 드러납니다. 큐 목록, 메시지 수, tenant context, 실패 메시지 상태를 눈으로 확인할 수 있어야 설계가 맞는지 검증할 수 있기 때문입니다.</p>
<h3 id="블로그-자체의-정보-구조를-보고-싶다면">블로그 자체의 정보 구조를 보고 싶다면</h3>
<p><a href="/projects/study-blog/">Study Blog</a>는 이 사이트 자체를 개선해 온 기록입니다. Hugo, PaperMod, 검색, SEO, 구조화 데이터, 글 목록, 학습 허브, 프로젝트 허브 같은 요소가 어떻게 연결되는지 볼 수 있습니다. 특히 글이 많아질수록 중요한 것은 &ldquo;글을 더 많이 쓰는 것&quot;만이 아니라, 독자가 원하는 글을 빨리 찾고 다음 글로 자연스럽게 이동할 수 있는 구조를 만드는 일입니다.</p>
<h2 id="프로젝트-글을-읽을-때-확인하면-좋은-질문">프로젝트 글을 읽을 때 확인하면 좋은 질문</h2>
<p>프로젝트 글은 완성된 정답보다 의사결정 과정을 남기는 쪽에 가깝습니다. 읽을 때 아래 질문을 같이 들고 보면 각 글의 목적이 더 선명해집니다.</p>
<ul>
<li>처음 구현은 어떤 단순한 가정에서 출발했는가?</li>
<li>기능이 늘어나면서 데이터 모델, 상태 관리, 권한, 관측성 중 무엇이 먼저 흔들렸는가?</li>
<li>테스트나 QA에서 발견된 문제는 정상 경로가 아니라 어떤 경계 조건에서 터졌는가?</li>
<li>운영자가 실제로 확인해야 하는 지표, 로그, 관리자 화면, 롤백 방법은 무엇인가?</li>
<li>다음 글로 넘어가면서 설계가 더 단단해졌는가, 아니면 임시 우회가 늘어났는가?</li>
</ul>
<h2 id="프로젝트별-핵심-관점">프로젝트별 핵심 관점</h2>
<table>
  <thead>
      <tr>
          <th>프로젝트</th>
          <th>핵심 주제</th>
          <th>먼저 볼 지점</th>
          <th>이어 읽을 관점</th>
      </tr>
  </thead>
  <tbody>
      <tr>
          <td><a href="/projects/pgmux/">pgmux</a></td>
          <td>PostgreSQL 프록시, 풀링, 라우팅, 캐시, 운영 안전성</td>
          <td>wire protocol과 커넥션 풀링</td>
          <td>QA, 관측성, SQL redaction, 무중단 설정</td>
      </tr>
      <tr>
          <td><a href="/projects/simple-queue-service/">Simple Queue Service</a></td>
          <td>메시지 큐, 멀티 테넌트, visibility timeout, DLQ</td>
          <td>큐 기본 모델과 tenant key 설계</td>
          <td>Admin 화면, 스토리지 계층화, 운영 검증</td>
      </tr>
      <tr>
          <td><a href="/projects/study-blog/">Study Blog</a></td>
          <td>Hugo 블로그, 콘텐츠 구조, 검색, SEO</td>
          <td>학습 허브와 프로젝트 허브</td>
          <td>내부 링크, front matter, 읽기 동선</td>
      </tr>
  </tbody>
</table>
<h2 id="운영-관점-체크리스트">운영 관점 체크리스트</h2>
<p>프로젝트를 구현하거나 글로 정리할 때는 아래 기준을 계속 확인하려고 합니다.</p>
<ul>
<li>기능 설명만 있고 실패 시나리오가 빠져 있지 않은가?</li>
<li>코드 예시가 실제 의사결정 기준과 연결되는가?</li>
<li>프로젝트 글과 학습 글이 서로 이어져 있는가?</li>
<li>&ldquo;왜 이렇게 만들었는지&quot;와 &ldquo;다시 한다면 무엇을 바꿀지&quot;가 남아 있는가?</li>
<li>사용자가 다음에 읽을 글이나 확인할 저장소로 자연스럽게 이동할 수 있는가?</li>
</ul>
<p>이 허브도 앞으로 프로젝트가 늘어날수록 계속 업데이트할 예정입니다. 새 프로젝트가 추가되면 단순 카드만 늘리는 대신, 어떤 독자가 왜 읽어야 하는지, 기존 학습 글과 어떤 주제로 연결되는지, 프로젝트가 보여주는 설계 trade-off가 무엇인지 함께 보강하는 방향으로 운영합니다.</p>
]]></content:encoded></item></channel></rss>