refactor(resume): 공개 프로필 구조 개선

docs/reports/resume-profile-as-is-to-be-2026-05-22.md

@@ -0,0 +1,123 @@
+# Resume Profile AS-IS / TO-BE 비교 리포트
+
+작성일: 2026-05-22  
+대상 화면: `/resume`
+
+## 비교 기준
+
+| 구분 | 기준 |
+| --- | --- |
+| AS-IS | `origin/master` (`9d11c153`) |
+| TO-BE | `codex/resume-brand-profile` (`7a490ff7`) |
+| 데스크톱 캡처 | 1440 x 1200 |
+| 모바일 캡처 | 390 x 1600 |
+
+이번 비교는 지원용 이력서가 아니라 공개 프로필, 즉 박은우라는 엔지니어를
+설명하고 어필하는 수단으로서의 품질을 기준으로 봤다.
+
+## 요약
+
+TO-BE는 AS-IS보다 개인 브랜딩 메시지가 선명하다. AS-IS는 경력 정보와
+프로젝트가 충분하지만 첫 화면에서 "어떤 사람인가"보다 "무엇을 해왔는가"가
+먼저 읽힌다. TO-BE는 반복을 구조로 옮기는 사람이라는 메시지, 대표 성과
+숫자, 일하는 기준을 앞에 배치해 공개 프로필의 목적에 더 잘 맞는다.
+
+핵심 개선은 세 가지다.
+
+- 상단 메시지가 `Software Engineer`에서 `Backend / Data Platform Engineer`로
+  좁혀졌다.
+- 첫 화면에 대표 성과 4개가 추가되어 기술 신뢰도와 기억 지점이 생겼다.
+- 본문에서 `How I Work`, `Selected Work`, `Technical Experiments`가 추가되어
+  경험 나열보다 문제 해석 방식이 먼저 보인다.
+
+## 데스크톱 비교
+
+| AS-IS | TO-BE |
+| --- | --- |
+| ![AS-IS desktop](./assets/resume-profile-as-is-to-be-2026-05-22/asis-desktop.png) | ![TO-BE desktop](./assets/resume-profile-as-is-to-be-2026-05-22/tobe-desktop.png) |
+
+### 데스크톱 분석
+
+AS-IS는 첫 화면에서 이름, 직무, 검도 기반 서사, 연락처가 안정적으로 보인다.
+다만 첫 화면 하단에 바로 `Profile`, `Skills`, `Experience`가 이어지면서
+일반적인 CV 구조처럼 읽힌다. 개인의 관점보다 경력 정보의 정돈감이 먼저 온다.
+
+TO-BE는 같은 서사를 유지하면서도 첫 화면 안에 대표 성과가 추가된다. 이로
+인해 "반복을 구조로 옮긴다"는 선언이 추상적인 자기소개에 머물지 않고,
+분석 리드타임, 백오피스 응답, 정산 데이터, 지급대행 구축 범위로 이어진다.
+
+데스크톱에서는 좌측 사이드 정보와 우측 핵심 본문이 나란히 보인다. TO-BE의
+우측 상단 `How I Work`는 공개 프로필의 성격을 강화한다. 단순히 사용 기술을
+나열하는 문서가 아니라, 어떤 기준으로 문제를 보는지 설명하는 문서로 읽힌다.
+
+## 모바일 비교
+
+| AS-IS | TO-BE |
+| --- | --- |
+| ![AS-IS mobile](./assets/resume-profile-as-is-to-be-2026-05-22/asis-mobile.png) | ![TO-BE mobile](./assets/resume-profile-as-is-to-be-2026-05-22/tobe-mobile.png) |
+
+### 모바일 분석
+
+AS-IS 모바일은 긴 자기소개 이후 `Contact`, `Profile`, `Skills`가 먼저 나온다.
+핵심 경력과 프로젝트까지 도달하기 전에 메타 정보와 기술 목록을 길게 읽어야
+한다. 지원용 이력서라면 무난하지만, 공개 프로필로서는 초반 설득력이 분산된다.
+
+TO-BE 모바일은 상단에서 대표 성과 4개를 먼저 보여준다. 긴 프로젝트 상세로
+내려가기 전에 독자가 기억할 수 있는 증거가 생긴다. 이후 `Contact`가 나오고,
+본문에서는 `How I Work -> Experience -> Selected Work -> Technical
+Experiments` 순서로 시각적으로 읽힌다.
+
+캡처 기준에서 TO-BE의 주요 섹션 위치는 다음과 같았다.
+
+| 섹션 | 모바일 상단 위치 |
+| --- | ---: |
+| `How I Work` | 1,562px |
+| `Experience` | 2,130px |
+| `Selected Work` | 3,111px |
+| `Technical Experiments` | 8,475px |
+| `Profile` | 10,788px |
+
+즉, 모바일 시각 흐름에서는 프로필/스킬/활동 같은 보조 정보보다 일하는 방식과
+실무 증거가 먼저 노출된다.
+
+## 정보 구조 변화
+
+| 항목 | AS-IS | TO-BE | 효과 |
+| --- | --- | --- | --- |
+| 직무 정의 | `Software Engineer` | `Backend / Data Platform Engineer` | 전문성이 더 좁고 분명하게 읽힘 |
+| 상단 메시지 | 반복 운영 업무를 자동화로 바꿈 | 반복 운영을 데이터 구조와 자동화로 바꾸는 엔지니어 | 행위보다 정체성이 먼저 보임 |
+| 상단 증거 | 없음 | 대표 성과 4개 | 선언과 실적이 같은 화면에서 연결됨 |
+| 스킬 | 언어/프레임워크/DB/클라우드 나열 | Backend/Data Platform/Cloud & Automation | 기술을 사용 맥락과 연결함 |
+| 활동 | `Activities`에 일괄 배치 | `Writing & Mentoring`, `Background`로 분리 | 글쓰기/멘토링이 정체성의 일부로 승격됨 |
+| 프로젝트 섹션 | `Projects` | `Selected Work` | 경험 나열보다 선별된 작업으로 읽힘 |
+| 개인 프로젝트 | `Personal Projects` | `Technical Experiments` | 토이 프로젝트보다 설계 검증으로 읽힘 |
+
+## 품질 판단
+
+TO-BE는 공개 프로필 목적에 더 적합하다. 특히 다음 지점이 강하다.
+
+- 검도 서사를 제거하지 않고, 필요한 반복과 위험한 반복의 대비로 재해석했다.
+- 숫자 성과를 상단에 둬 기술적 신뢰도를 빠르게 확보한다.
+- `How I Work`가 추가되어 경험 목록 이전에 판단 기준을 보여준다.
+- `Writing & Mentoring`을 분리해 글과 멘토링 활동을 부가 정보가 아닌
+  커뮤니케이션 역량의 증거로 만든다.
+
+## 남은 리스크
+
+TO-BE도 개선 여지는 있다.
+
+1. 모바일 시각 흐름은 개선됐지만 DOM의 원천 순서는 아직 `aside`가 본문보다
+   먼저다. 스크린 리더나 문서 구조를 더 엄격히 보려면 DOM 자체를
+   `main content -> aside` 순서로 바꾸고 데스크톱에서만 CSS grid로 좌측에
+   배치하는 후속 개선이 가능하다.
+2. 페이지 길이가 길어졌다. 공개 프로필로는 감당 가능한 수준이지만, 향후
+   프로젝트가 더 늘어나면 상단 요약 앵커나 섹션 접기 전략을 검토할 수 있다.
+3. `기반`, `방향` 계열 표현은 줄었지만 일부 남아 있다. 프로젝트별 결과
+   문장은 앞으로 운영 지표나 검증 범위가 더 생길 때 계속 구체화하는 편이 좋다.
+
+## 결론
+
+현재 TO-BE 방향은 유지하는 것이 좋다. AS-IS가 정돈된 이력서라면, TO-BE는
+"반복을 데이터 구조와 자동화로 옮기는 엔지니어"라는 메시지가 더 빠르게 남는
+공개 프로필이다. 이번 변경은 지원용 최적화가 아니라 자기 어필용 프로필이라는
+목적에 맞게 정보 우선순위와 표현 방식을 재정렬한 개선으로 판단한다.

resume/model/resume-data.ts

@@ -5,47 +5,84 @@ import type {
   Education,
   Activity,
   Certification,
+  ResumeHighlight,
+  WorkingPrinciple,
 } from '@/resume/model/types';
 
 export const personalInfo: PersonalInfo = {
   name: '박은우',
   birthDate: '1996.07.20',
-  position: 'Software Engineer',
-  // keywords: 'BE, DE, Platform',
+  position: 'Backend / Data Platform Engineer',
   email: 'une@kakao.com',
   phone: '+82 01029139706',
   github: 'https://github.com/dev-wooyeon',
   blog: 'https://ark-log.vercel.app',
   skillGroups: [
     {
-      category: '언어',
-      skills: ['Java'],
+      category: 'Backend',
+      skills: ['Java', 'Spring Boot', 'Spring Batch', 'JPA', 'QueryDSL'],
+      description:
+        '결제·정산·송금 도메인의 거래 상태, 정산 기준, 운영 백오피스 구현',
     },
     {
-      category: '프레임워크',
-      skills: ['Spring Boot', 'Spring Batch', 'JPA'],
+      category: 'Data Platform',
+      skills: ['MySQL', 'ClickHouse', 'Kafka', 'Flink', 'Athena'],
+      description:
+        'CDC 기반 분석 파이프라인, 대용량 정산 배치, 실시간 집계 실험',
     },
     {
-      category: '데이터베이스',
-      skills: ['MySQL', 'ClickHouse'],
-    },
-    {
-      category: '데이터 파이프라인',
-      skills: ['Kafka', 'Flink', 'Athena'],
-    },
-    {
-      category: '클라우드',
-      skills: ['AWS', 'AWS DMS', 'AWS Glue'],
-    },
-    {
-      category: '자동화',
-      skills: ['MCP/Codex'],
+      category: 'Cloud & Automation',
+      skills: ['AWS', 'AWS DMS', 'AWS Glue', 'Grafana', 'MCP/Codex'],
+      description:
+        '반복 장애 확인 절차와 운영 분석 흐름을 리포트와 자동화로 전환',
     },
   ],
   introduction:
-    '백엔드 엔지니어로 일하며 서비스의 완성도는 기능 수보다 데이터가 얼마나 정확하게 쌓이고, 일관된 기준으로 흐르며, 여러 팀이 믿고 사용할 수 있는 구조를 갖추는지에 달려 있다는 점을 체감했습니다. 결제·정산·IoT 도메인에서 데이터 기준을 명확히 하고 운영 가능한 구조로 바꾸는 일에 강한 몰입과 성과를 냈습니다.',
+    '서비스의 완성도는 기능 수만으로 결정되지 않는다고 봅니다. 데이터가 정확히 쌓이고, 일관된 기준으로 흐르며, 여러 팀이 믿고 사용할 수 있어야 합니다. 저는 결제·정산·IoT 도메인에서 그런 구조를 만드는 일에 몰입해 왔습니다.',
 };
 
+export const resumeHighlights: ResumeHighlight[] = [
+  {
+    label: '분석 리드타임',
+    value: '1~2시간 -> 즉시 조회',
+    description: '운영 DB 직접 조회와 수동 검증을 CDC 기반 분석 계층으로 전환',
+  },
+  {
+    label: '백오피스 응답',
+    value: '15,000ms -> 2,000ms',
+    description:
+      '병목 쿼리, N+1, 페이지네이션을 정리해 반복 조회 대기 시간 축소',
+  },
+  {
+    label: '정산 데이터',
+    value: '400만 건+',
+    description: '반기별 사업자 구간 변경과 과거 거래 소급 정산 흐름을 자동화',
+  },
+  {
+    label: '지급대행 구축',
+    value: '30개+ 테이블 / 19개 API',
+    description: '거래·정산·송금 책임을 분리하고 초기 고객사 연동 흐름을 검증',
+  },
+];
+
+export const workingPrinciples: WorkingPrinciple[] = [
+  {
+    title: '반복은 없애기 전에 분류합니다',
+    description:
+      '필요한 반복과 사람이 반복하면 위험한 절차를 구분한 뒤, 장애와 비용으로 이어지는 반복을 시스템 안으로 옮깁니다.',
+  },
+  {
+    title: '기능보다 먼저 데이터 흐름을 봅니다',
+    description:
+      'API나 화면 단위로 문제를 닫기보다 데이터가 어디서 생기고, 어떤 기준으로 이동하며, 누가 믿고 쓰는지부터 확인합니다.',
+  },
+  {
+    title: '운영자가 믿을 수 있는 기준으로 닫습니다',
+    description:
+      '구현이 끝났다는 말보다 운영자가 다시 확인하지 않아도 되는 상태, 장애 신호를 빠르게 구분할 수 있는 상태를 더 중요하게 봅니다.',
+  },
+];
+
 export const experiences: Experience[] = [
   {
     company: '모노리스',
@@ -89,7 +126,7 @@ export const experiences: Experience[] = [
             key: 'result',
             label: '성과',
             detail: [
-              '분석 리드타임을 1~2시간에서 즉시 조회 가능한 수준으로 단축하고, 월 평균 4회 이상 발생하던 수동 추출·검증 작업을 사실상 제거했습니다. 분석가가 개발자 개입 없이 필요한 데이터를 직접 확인할 수 있는 기반을 마련했습니다.',
+              '분석 리드타임을 1~2시간에서 즉시 조회 가능한 수준으로 단축했습니다. 반복 분석 요청을 Athena 조회 계층으로 옮겨, 개발자가 운영 DB에서 매번 추출하지 않아도 되는 구조로 바꿨습니다.',
             ],
           },
         ],
@@ -138,7 +175,7 @@ export const experiences: Experience[] = [
             key: 'result',
             label: '성과',
             detail: [
-              '변경 범위를 도메인 단위로 예측할 수 있게 만들고 신규 파크 대응을 설정 중심으로 확장할 수 있는 기반을 마련했습니다. 서비스 중단 없이 구조 개선을 이어갈 수 있는 방향을 만들었습니다.',
+              '변경 범위를 도메인 단위로 예측할 수 있게 정리했습니다. 신규 파크 대응은 설정 중심으로 확장할 수 있게 만들고, 기존 시스템은 중단 없이 점진적으로 전환하는 방향을 잡았습니다.',
             ],
           },
         ],
@@ -180,7 +217,7 @@ export const experiences: Experience[] = [
             key: 'result',
             label: '성과',
             detail: [
-              '우선 대응이 필요한 오류를 더 빠르게 식별할 수 있게 만들고, 로깅 레벨 관리와 잠재 오류 탐지의 기반을 함께 마련했습니다.',
+              '반복 확인하던 로그, TraceId, API 경로, 코드 링크를 하나의 리포트로 묶어 대응 우선순위 판단에 필요한 정보를 줄였습니다.',
             ],
           },
         ],
@@ -237,7 +274,7 @@ export const experiences: Experience[] = [
             key: 'result',
             label: '성과',
             detail: [
-              '기능 확장과 서비스 성장에 대응할 수 있는 도메인 단위 변경 통제 구조를 확보했습니다. 고객사 초기 연동 단계부터 장애 없이 안정적으로 서비스가 운영됐고, 팀의 일관된 개발 기준을 수립했습니다.',
+              '기능 확장과 서비스 성장에 대응할 수 있는 도메인 단위 변경 통제 구조를 확보했습니다. 초기 고객사 연동 구간에서 핵심 거래·정산 흐름이 중단 없이 운영되도록 검증 범위와 변경 통제를 관리했습니다.',
             ],
           },
         ],
@@ -444,8 +481,8 @@ export const personalProjects: PersonalProject[] = [
         key: 'result',
         label: '성과',
         detail: [
-          '계층을 많이 나누는 구조보다 현재 목표와 제약에 맞는 최소 구조가 더 좋은 설계일 수 있음을 검증했습니다.',
-          '단순 기능 구현을 넘어 스트리밍 정확성, 성능 엔지니어링, 운영 안정성, 관측성을 함께 다루는 데이터 엔지니어링 프로젝트로 발전시켰습니다.',
+          '초기 다중 싱크 구조의 오버헤드를 확인한 뒤 ClickHouse 원본 테이블과 Materialized View 중심으로 단순화했습니다.',
+          '기능 구현 이후 checkpoint/restart, 지연 이벤트, DLQ, ClickHouse 서빙 구조까지 검증 범위에 포함했습니다.',
         ],
       },
       {

resume/model/types.ts

@@ -58,6 +58,18 @@ export interface PersonalInfo {
 export interface SkillGroup {
   category: string;
   skills: string[];
+  description?: string;
+}
+
+export interface ResumeHighlight {
+  label: string;
+  value: string;
+  description: string;
+}
+
+export interface WorkingPrinciple {
+  title: string;
+  description: string;
 }
 
 export interface Education {