+ {activity.title} +
++ {activity.organization} +
++ {activity.period} +
+-
+ {activity.description.map((description, index) => (
+
- + {description} + + ))} +
diff --git a/docs/reports/assets/resume-profile-as-is-to-be-2026-05-22/asis-desktop.png b/docs/reports/assets/resume-profile-as-is-to-be-2026-05-22/asis-desktop.png new file mode 100644 index 0000000..bc3faab Binary files /dev/null and b/docs/reports/assets/resume-profile-as-is-to-be-2026-05-22/asis-desktop.png differ diff --git a/docs/reports/assets/resume-profile-as-is-to-be-2026-05-22/asis-mobile.png b/docs/reports/assets/resume-profile-as-is-to-be-2026-05-22/asis-mobile.png new file mode 100644 index 0000000..02a9696 Binary files /dev/null and b/docs/reports/assets/resume-profile-as-is-to-be-2026-05-22/asis-mobile.png differ diff --git a/docs/reports/assets/resume-profile-as-is-to-be-2026-05-22/tobe-desktop.png b/docs/reports/assets/resume-profile-as-is-to-be-2026-05-22/tobe-desktop.png new file mode 100644 index 0000000..14252d6 Binary files /dev/null and b/docs/reports/assets/resume-profile-as-is-to-be-2026-05-22/tobe-desktop.png differ diff --git a/docs/reports/assets/resume-profile-as-is-to-be-2026-05-22/tobe-mobile.png b/docs/reports/assets/resume-profile-as-is-to-be-2026-05-22/tobe-mobile.png new file mode 100644 index 0000000..598ecc4 Binary files /dev/null and b/docs/reports/assets/resume-profile-as-is-to-be-2026-05-22/tobe-mobile.png differ diff --git a/docs/reports/resume-profile-as-is-to-be-2026-05-22.md b/docs/reports/resume-profile-as-is-to-be-2026-05-22.md new file mode 100644 index 0000000..65fbe1a --- /dev/null +++ b/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는 첫 화면에서 이름, 직무, 검도 기반 서사, 연락처가 안정적으로 보인다. +다만 첫 화면 하단에 바로 `Profile`, `Skills`, `Experience`가 이어지면서 +일반적인 CV 구조처럼 읽힌다. 개인의 관점보다 경력 정보의 정돈감이 먼저 온다. + +TO-BE는 같은 서사를 유지하면서도 첫 화면 안에 대표 성과가 추가된다. 이로 +인해 "반복을 구조로 옮긴다"는 선언이 추상적인 자기소개에 머물지 않고, +분석 리드타임, 백오피스 응답, 정산 데이터, 지급대행 구축 범위로 이어진다. + +데스크톱에서는 좌측 사이드 정보와 우측 핵심 본문이 나란히 보인다. TO-BE의 +우측 상단 `How I Work`는 공개 프로필의 성격을 강화한다. 단순히 사용 기술을 +나열하는 문서가 아니라, 어떤 기준으로 문제를 보는지 설명하는 문서로 읽힌다. + +## 모바일 비교 + +| AS-IS | TO-BE | +| --- | --- | +|  |  | + +### 모바일 분석 + +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는 +"반복을 데이터 구조와 자동화로 옮기는 엔지니어"라는 메시지가 더 빠르게 남는 +공개 프로필이다. 이번 변경은 지원용 최적화가 아니라 자기 어필용 프로필이라는 +목적에 맞게 정보 우선순위와 표현 방식을 재정렬한 개선으로 판단한다. diff --git a/resume/model/resume-data.ts b/resume/model/resume-data.ts index 2d80827..2e90f55 100644 --- a/resume/model/resume-data.ts +++ b/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 서빙 구조까지 검증 범위에 포함했습니다.', ], }, { diff --git a/resume/model/types.ts b/resume/model/types.ts index 028a312..a5ead75 100644 --- a/resume/model/types.ts +++ b/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 { diff --git a/resume/ui/pages/ResumePage.tsx b/resume/ui/pages/ResumePage.tsx index f542dbf..7260476 100644 --- a/resume/ui/pages/ResumePage.tsx +++ b/resume/ui/pages/ResumePage.tsx @@ -8,21 +8,26 @@ import { experiences, personalInfo, personalProjects, + resumeHighlights, + workingPrinciples, } from '@/resume/model/resume-data'; import { orderExperienceStages } from '@/resume/model/order-experience-stages'; +import type { Activity } from '@/resume/model/types'; export const metadata: Metadata = { title: 'CV', description: `${personalInfo.name}의 CV`, }; -const heroStatement = '반복되는 운영 업무를 데이터 구조와 자동화로 바꿉니다'; +const heroStatement = '반복되는 운영을 데이터 구조와 자동화로 바꾸는 엔지니어'; -const heroSummary = - '해동검도 4단과 세계대회 본선을 준비하며 같은 동작을 수백, 수천 번 반복했습니다. 필요한 반복의 가치는 알지만, 개발자가 된 뒤 사람이 매번 확인하고 옮기는 반복이 장애와 비용으로 이어지는 장면은 그냥 넘기기 어려웠습니다. 백엔드 엔지니어로 일하며 서비스의 완성도는 기능 수보다 데이터가 얼마나 정확하게 쌓이고, 일관된 기준으로 흐르며, 여러 팀이 믿고 사용할 수 있는 구조를 갖추는지에 달려 있다는 점을 체감했습니다.'; +const heroSummary = [ + '해동검도 4단과 세계대회 본선을 준비하며 같은 동작을 수백, 수천 번 반복했습니다. 그 경험 덕분에 필요한 반복의 가치는 압니다.', + '하지만 개발자가 된 뒤에는 사람이 매번 확인하고 옮기는 반복이 장애와 비용으로 바뀌는 장면을 자주 봤습니다. 저는 그런 반복을 데이터 구조와 자동화 안으로 옮기는 일에 끌립니다.', +]; const motivationStatement = - '그래서 제 관심은 API를 하나 더 만드는 일보다, 귀찮고 위험한 반복을 데이터 흐름과 자동화 안으로 옮겨 운영 가능한 구조로 바꾸는 데 있습니다.'; + 'API를 하나 더 만드는 일보다 데이터 기준, 처리 흐름, 운영 방식을 정리해 팀이 믿고 쓰는 구조를 만드는 데 관심이 있습니다.'; function calculateCareerYears(): number { const careerStart = new Date(2019, 11, 1); @@ -156,6 +161,42 @@ function renderProjectLinks( ); } +function renderActivityList(activityItems: Activity[]): ReactNode { + return ( +
+ {activity.title} +
++ {activity.organization} +
++ {activity.period} +
+- {heroSummary} -
++ {paragraph} +
+ ))} +{motivationStatement}
+ ++ {highlight.value} +
++ {highlight.description} +
+