+
+
+ + {activity.title} +
++ {activity.organization} +
++ {activity.period} +
+-
+ {activity.description.map((description, index) => (
+
- + {description} + + ))} +
밈 → 관심 → 음원 탐색 → 음악의 발견 → 재청취 → 입덕이라는 건강한 순환 고리를 만들어냈다. 2024년에 이미 웰메이드로 만들어 두었던 음악 자산이 있었기에, 2년이 지난 2026년에 마침내 차트를 뚫고 역주행을 성공시킬 수 있었던 것이다.
+
+## 운이 전부도 아니고, 노력만으로 되는 것도 아니다
+
+리센느 사례를 보며 흥미로웠던 부분은 노력과 운의 관계였다.
+
+리센느는 분명히 자신들이 할 수 있는 부분을 우직하게 해왔다.
+
+* 좋은 음악 준비
+* 흔들리지 않는 무대 연습
+* 팀 색깔 구축
+* 꾸준한 활동
+
+이것은 진인사(盡人事)다.
+
+반면,
+
+* 어떤 영상이 바이럴될지
+* 언제 대중의 관심이 쏠릴지
+* 어떤 계기로 사람들이 유입될지
+
+이런 것들은 누구도 예측할 수 없다. 이것은 대천명(待天命)에 가깝다.
+
+결국 성공은 노력과 운 중 하나를 선택하는 문제가 아니라, 두 가지가 만나는 임계점에서 발생하는 것 같다. 2024~2025년의 긴 터널은 묵묵히 씨앗을 뿌려두는 '진인사'의 시간이었고, 2026년은 비로소 '대천명'의 바람이 불어와 그 씨앗을 꽃피운 순간이라고 볼 수 있다.
+
+## 개발자 커리어도 비슷하지 않을까
+
+생각해보니 개발자로서의 성장도 크게 다르지 않다. 내가 통제할 수 있는 것들이 있다.
+
+* 좋은 설계를 끊임없이 고민하기
+* 프로젝트 경험을 깊이 있게 쌓기
+* 새로운 기술과 본질을 공부하기
+* 문제 해결 과정을 기록하기
+* 생각을 글로 정리하기
+
+반면 내가 통제할 수 없는 것들도 많다.
+
+* 어떤 회사가 언제 채용을 열지
+* 어떤 사람이 내 글과 프로젝트를 발견할지
+* 어떤 우연한 기회가 찾아올지
+* 어떤 기술 트렌드가 급부상할지
+
+생각보다 많은 부분이 후자에 속한다. 그렇다면 내가 집중해야 할 영역은 명확해진다. 결과를 걱정하는 것이 아니라, 내가 통제 가능한 부분을 계속해서 쌓아가는 것이다.
+
+## 한계를 깨부수는 능동적인 준비: Love Attack
+
+단순히 기회가 오기를 수동적으로 기다리는 것만이 '준비'는 아니다. 리센느의 대표곡인 〈Love Attack〉의 후렴구 가사를 듣다 보면, 진인사대천명이라는 단어가 품은 진짜 역동성이 느껴진다.
+
+> "아주 눈이 부신 너를 숨김없이 보여줘
+> 한 번도 빛난 적 없었던 미지의 향으로 온 세상을 물들여"
+
+이 가사처럼, 준비란 내면에 숨겨진 가장 눈부신 가능성을 찾아내어 숨김없이 보여줄 수 있도록 갈고닦는 과정이다. 아직 한 번도 빛나지 못했을지라도, 나만의 '미지의 향'으로 세상을 물들이겠다는 의지다.
+
+이직을 준비하며 내 한계에 부딪히는 순간이 올 때마다 이 가사를 곱씹게 된다. '과연 내가 더 성장할 수 있을까?', '내 실력으로 가고 싶은 회사에 갈 수 있을까?' 하는 의구심이 조급함으로 바뀔 때, 내가 할 일은 멈추는 것이 아니라 내 한계의 벽을 한 단계 깨부수는 노력을 더하는 것이다. 한계를 넘어서는 준비가 되어 있을 때, 비로소 대천명(待天命)의 기회가 왔을 때 나를 완전히 보여줄 수 있기 때문이다.
+
+## 그래서 당분간은 이 과정을 반복하려고 한다
+
+요즘 이직을 준비하면서 마음이 흔들리고 조급해질 때가 자주 있었다.
+
+“언제 좋은 기회가 올까?”
+“언제 원하는 회사에 합격할까?”
+
+하지만 리센느 사례를 보며 생각이 조금 바뀌었다. 내가 할 수 있는 것은 불확실한 결과를 미리 걱정하는 것이 아니다.
+
+오히려,
+
+* 가고 싶은 기업의 도메인과 기술을 꾸준히 분석하고
+* 내가 왜 그곳에서 함께하고 싶은지 생각을 정리하고
+* 기술과 협업에 대한 철학을 글로 남기고
+* 내 경험과 역량을 명확히 언어화하는 연습을 하는 것
+
+이런 과정 자체가 본질이다. 결국 누군가가 나를 발견하는 순간이 찾아온다면, 그때 나의 한계를 깨부수고 준비한 '눈이 부신' 모습을 보여줄 수 있어야 하기 때문이다.
+
+## 마무리
+
+기회는 통제할 수 없지만, 준비는 통제할 수 있다.
+
+그래서 당장 눈앞에 결과가 보이지 않더라도, 내가 해야 할 일들을 묵묵히 쌓아가려고 한다. 언제 기회가 올지는 모르지만, 적어도 그 기회가 찾아왔을 때 머뭇거리지 않고 나를 세상에 내보일 수 있는 사람이 되고 싶다.
+
+어쩌면 진인사대천명이라는 말은 단순한 위로의 문장이 아니라, 나 자신을 한 번도 빛난 적 없던 미지의 향으로 피워내기 위해 매일 한계를 깨부수는 가장 지독하고도 현실적인 태도일지 모른다.
diff --git "a/posts/\352\261\260\354\240\234-\354\225\274\355\230\270\353\241\234\353\266\200\355\204\260-\353\260\260\354\232\264-\353\246\254\354\204\274\353\212\220-\354\227\255\354\243\274\355\226\211\354\235\230-\354\247\204\354\247\234-\353\263\270\354\247\210/meta.json" "b/posts/\352\261\260\354\240\234-\354\225\274\355\230\270\353\241\234\353\266\200\355\204\260-\353\260\260\354\232\264-\353\246\254\354\204\274\353\212\220-\354\227\255\354\243\274\355\226\211\354\235\230-\354\247\204\354\247\234-\353\263\270\354\247\210/meta.json"
new file mode 100644
index 0000000..85973b4
--- /dev/null
+++ "b/posts/\352\261\260\354\240\234-\354\225\274\355\230\270\353\241\234\353\266\200\355\204\260-\353\260\260\354\232\264-\353\246\254\354\204\274\353\212\220-\354\227\255\354\243\274\355\226\211\354\235\230-\354\247\204\354\247\234-\353\263\270\354\247\210/meta.json"
@@ -0,0 +1,23 @@
+{
+ "title": "‘거제 야호’로부터 배운 리센느 역주행의 진짜 본질",
+ "slug": "rescene-reverse-run-and-effort",
+ "description": "최근 걸그룹 리센느의 역주행 사례를 통해 노력과 운의 관계, 그리고 한계를 깨부수기 위한 준비에 대해 고민해 봅니다.",
+ "date": "2026-06-12",
+ "category": "Life",
+ "image": "/images/posts/거제-야호로부터-배운-리센느-역주행의-진짜-본질/yaho.jpg",
+ "tags": [
+ "Career",
+ "Life",
+ "Thoughts"
+ ],
+ "featured": false,
+ "visibility": "public",
+ "qualityReview": {
+ "philosophy": 4.5,
+ "design": 4,
+ "implementation": 4,
+ "brandFit": 4,
+ "notes": "리센느 역주행과 Love Attack 가사 기반의 깨달음 작성",
+ "reviewedAt": "2026-06-12"
+ }
+}
diff --git "a/posts/\353\270\224\353\241\234\352\267\270-\354\213\234\354\212\244\355\205\234-\352\265\254\354\266\225\352\270\260/index.mdx" "b/posts/\353\270\224\353\241\234\352\267\270-\354\213\234\354\212\244\355\205\234-\352\265\254\354\266\225\352\270\260/index.mdx"
index 3e42517..d879d23 100644
--- "a/posts/\353\270\224\353\241\234\352\267\270-\354\213\234\354\212\244\355\205\234-\352\265\254\354\266\225\352\270\260/index.mdx"
+++ "b/posts/\353\270\224\353\241\234\352\267\270-\354\213\234\354\212\244\355\205\234-\352\265\254\354\266\225\352\270\260/index.mdx"
@@ -17,10 +17,10 @@ AI 활용 방식까지 한 흐름으로 정리한다.
프로젝트를 시작하며 큰 영감을 받은 곳이 있다.
-**[zerolog.vercel.app](https://zerolog.vercel.app)**
+[zerolog.vercel.app](https://zerolog.vercel.app)
미니멀하면서도 완성도 높은 디자인, 깔끔한 타이포그래피, 그리고 세심한 인터랙션.
-단순히 "이쁘다"를 넘어 **"어떻게 구현했을까?"** 를 고민하게 만드는 블로그였다.
+단순히 "이쁘다"를 넘어 "어떻게 구현했을까?" 를 고민하게 만드는 블로그였다.
실제로 DevTools를 열어 구조를 뜯어보고, 애니메이션 타이밍을 트레이싱하며 많은 것을 배웠다.
특히 다음 부분에서 큰 영향을 받았다.
@@ -31,7 +31,7 @@ AI 활용 방식까지 한 흐름으로 정리한다.
- **JetBrains Mono 폰트** → 기술 블로그에 어울리는 코드 친화적 폰트
좋은 디자인을 보고 배우는 건 부끄러운 일이 아니라고 생각했다.
-오히려 **"왜 이렇게 만들었을까?"** 를 고민하며 스스로 구현해보는 과정이 가장 좋은 학습이었다.
+오히려 "왜 이렇게 만들었을까?" 를 고민하며 스스로 구현해보는 과정이 가장 좋은 학습이었다.
---
@@ -740,17 +740,17 @@ AI는 **페어 프로그래밍 파트너**다.
### 8.1 설계 원칙
-**"완벽한 디자인 시스템보다 일관성 있는 구현이 중요하다."**
+"완벽한 디자인 시스템보다 일관성 있는 구현이 중요하다."
초반에 완벽한 디자인 시스템을 만들려 했지만, 실제 구현 과정에서 일관성이 깨졌다.
Phase별 리팩토링을 통해 일관성을 확보하는 것이 더 효과적이었다.
-**"Server Component 기본, Client Component 최소화."**
+"Server Component 기본, Client Component 최소화."
모든 컴포넌트를 'use client'로 만들면 편하지만,
Server Component를 최대한 활용하면 번들 사이즈와 성능에서 큰 이점을 얻을 수 있다.
-**"추상화는 중복이 3번 이상 발생할 때."**
+"추상화는 중복이 3번 이상 발생할 때."
PageLayout 컴포넌트를 초반에 만들지 않고,
2개 페이지에서 중복이 명확해진 시점에 추상화했다.
@@ -758,25 +758,25 @@ PageLayout 컴포넌트를 초반에 만들지 않고,
### 8.2 기술 선택
-**"최신 기술은 생산성을 위해, 안정성도 함께 고려."**
+"최신 기술은 생산성을 위해, 안정성도 함께 고려."
- Next.js 16: App Router의 안정성 확보
- Tailwind v4: 빌드 속도 개선 체감
- MDX: React 통합으로 확장성 극대화
-**"번들 사이즈는 항상 모니터링."**
+"번들 사이즈는 항상 모니터링."
Three.js 같은 무거운 라이브러리는 코드 스플리팅 필수.
`next/dynamic`과 `'use client'`를 조합하여 초기 로딩에 영향 없도록 관리.
### 8.3 최적화
-**"측정하지 않으면 최적화할 수 없다."**
+"측정하지 않으면 최적화할 수 없다."
Lighthouse, Bundle Analyzer를 통해 정량적 지표를 확보했다.
추측이 아닌 데이터 기반 최적화다.
-**"점진적 개선이 급진적 리팩토링보다 안전하다."**
+"점진적 개선이 급진적 리팩토링보다 안전하다."
Phase 1~5로 나눠 단계별로 개선했다.
각 Phase마다 빌드 검증 → 커밋 → 다음 단계.
diff --git "a/posts/\355\206\240\354\212\244\354\246\235\352\266\214-\354\247\201\353\254\264\353\251\264\354\240\221-\355\232\214\352\263\240/index.mdx" "b/posts/\355\206\240\354\212\244\354\246\235\352\266\214-\354\247\201\353\254\264\353\251\264\354\240\221-\355\232\214\352\263\240/index.mdx"
new file mode 100644
index 0000000..9fa3f7f
--- /dev/null
+++ "b/posts/\355\206\240\354\212\244\354\246\235\352\266\214-\354\247\201\353\254\264\353\251\264\354\240\221-\355\232\214\352\263\240/index.mdx"
@@ -0,0 +1,80 @@
+## 개요
+
+면접관들과의 따뜻한 마지막 인사와 함께 구글 미트(Google Meet) 화면이 꺼진 바로 그 순간, 복잡한 생각들이 뇌리를 스쳤다.
+
+*"아, 어렵다. 특정 질문이 계속 밟히네. 잘 대답한 게 맞나? 왜 머릿속으로 아는 개념인데 입 밖으로는 잘 안 나왔을까..."*
+
+그리고 며칠 뒤, 아쉽게도 '1차 면접 탈락'이라는 성적표를 마주했다. 쓰라린 결과였지만, 면접장에서 느꼈던 본능적인 직감과 스스로에 대한 아쉬움이 정확한 결과로 돌아왔기에 오히려 고개가 끄덕여졌다.
+
+이번 글은 토스증권 데이터 엔지니어 직무면접을 치르며 겪은 날것의 기록이자, 실패를 마주하고 작성한 뼈아픈 성찰의 일지다. 총 2시간 동안 1부와 2부로 밀도 있게 나누어 진행된 1차 면접에서, 현업 엔지니어와 나누었던 치열한 기술 논쟁의 즐거움과 '일하는 방식'이라는 추상적인 질문 앞에서 느꼈던 한계, 그리고 이를 극복하기 위한 나의 다짐을 솔직하게 기록해 본다.
+
+> ⚠️ **안내**: 본 회고는 면접 시 서명한 비밀유지서약서(NDA)를 철저히 준수하기 위해 구체적인 질문 시나리오, 사내 프로젝트 정보, 고유 기술 스택에 관한 세부 사항은 모두 배제하거나 범용적인 엔지니어링 개념으로 추상화 및 비식별화하여 작성되었습니다.
+
+---
+
+## ⚡️ 1부: 도파민이 터졌던 기술 논쟁
+
+면접의 시작을 알린 1부는 현업 데이터 엔지니어분과의 아주 밀도 높은 기술 논쟁으로 채워졌다. 사전에 공유된 나의 이력을 기반으로 꼬리에 꼬리를 무는 질문들이 이어졌고, 대규모 배치 파이프라인에서 발생할 수 있는 일반적인 예외 상황과 복구 설계 쟁점으로 토론이 확장되었다.
+
+이때는 정말 시간 가는 줄 모르고 몰입해서 대화했다. 예상치 못한 장애나 분산 환경에서의 데이터 정합성 이슈를 해결하기 위해,
+- 어떤 아키텍처적 리스크와 트레이드오프(Trade-off)가 존재하는지,
+- 시스템 자원과 실시간성 사이에서 무엇을 얻고 무엇을 타협할지,
+- 멱등성(Idempotency)과 무장애 처리를 위해 어떤 범용적 접근이 가장 현실적일지
+
+머리를 맞대고 치열하게 고민했다. 일방적인 평가를 받는 자리가 아니라, **두 명의 엔지니어가 칠판을 채워가며 실질적인 기술적 해결책을 찾아가는 티키타카**였다. 하드스킬의 "왜(Why)"와 "어떻게(How)"를 논증하며 도파민이 터졌던 이 1부의 경험은, 데이터 엔지니어로서 진정한 기술적 성장을 꿈꾸는 내 선택에 더 큰 확신을 주었다.
+
+---
+
+## 🚨 2부: 뼈아픈 성찰, "평소 일을 어떻게 하시나요?"
+
+이어진 2부에서는 직무 적합성과 협업 성향을 확인하기 위한 소프트 스킬 및 메타 관점의 대화들이 오갔다. 그리고 뜻하지 않은 추상적 질문에서 나의 브레이크가 걸렸다.
+
+> *"이전 직무에서 데이터 엔지니어 영역으로 방향을 정한 본질적인 차이점은 무엇인가요?"*
+> *"평소에 일을 어떤 방식으로 진행하시나요?"*
+
+기술적인 딥다이브에서는 거침없이 논리를 펼치던 뇌가, 일하는 방식이라는 고차원적이고 추상적인 개념 앞에서 순간 정지했다. 긴장한 뇌를 다잡고 입 밖으로 내뱉었던 나의 대답 프로세스는 다음과 같았다.
+
+1. 운영상 반복되는 비효율을 잠재적 시스템 리스크로 먼저 포착한다.
+2. 유관 부서 및 이해관계자들과 논의하여 해당 작업의 시급성과 필요성을 검토한다.
+3. 설계와 구현을 완료한 후, 지속적으로 피드백을 수집하며 제품을 성장시킨다.
+
+단계적 구조는 나름대로 논리적이었으나, 면접관이 던진 질문의 본질(실질적인 소통 경험과 의사결정의 무게감)을 관통하지 못했다는 아쉬움이 짙게 남았다. 차분히 돌이켜 보니 뇌가 당황하며 두 가지 허점을 보였다.
+
+### 1. 당위성의 함정과 구체적 에피소드의 결여
+"어떻게 일하나요?"라는 질문에 '일반적으로 이렇게 일하는 것이 옳다'는 방법론적 프로세스만 나열했다. 면접관이 진짜 보고 싶었던 것은 교과서적 프로세스가 아니라, 내가 직접 이해관계자를 찾아가 정량적 니즈를 파악하고 조율했던 '단 하나의 생생하고 구체적인 사례'였다. 실체가 없는 추상적 답변은 설득력을 얻기 어려웠다.
+
+### 2. 인지 과부하로 인한 비언어적 흔들림
+예상 밖의 메타 질문에 답의 갈피를 잡으려다 보니 나도 모르게 말이 빨라졌고, 목소리 톤과 전달력의 흔들림이 고스란히 묻어났다. 아무리 좋은 내용이라도 불안함에 실려 나가면 설득력이 깎일 수밖에 없다.
+
+---
+
+## ⚖️ "일하기 좋은 엔지니어"와 "일하기 좋은 동료"
+
+면접을 복기하며 스스로 내린 가장 뼈아픈 한 줄은 이것이었다.
+
+> "나는 기술적 토론을 나누기 좋아하는 엔지니어는 맞지만, 비즈니스 임팩트를 위해 조율하고 소통하는 매력적인 '동료(사람)'로 보였는가?"
+
+토스증권은 극도의 기술력만큼이나, 비즈니스 임팩트를 내기 위해 주도적으로 문제를 찾아 조율하고 소통하는 협업의 온도를 중시한다고 생각한다. 내가 내린 아키텍처적 결정들이 순수한 기술적 재미를 넘어, 실제 비즈니스 관점의 어떤 요구사항을 충족하기 위한 의사결정이었는지를 **소통의 구체성**으로 명확히 설명해 냈어야 했다.
+
+스스로에 대한 이 날카로운 메타인지는 이번 면접의 당락을 떠나, 진정한 엔지니어로 거듭나기 위한 성장의 밑거름이 되었다.
+
+---
+
+## 🎯 향후 성장을 위한 액션 플랜
+
+10년 뒤, 도메인에 종속되지 않고 시스템 아키텍처와 분산 플랫폼을 이끄는 **데이터 전문 기술 리더**가 되기 위해 오늘 배운 교훈을 바탕으로 구체적인 액션 플랜을 수립한다.
+
+1. **소프트스킬의 아키텍처화 (C-A-T-I)**
+ 내가 일하는 방식과 의사결정 경험을 규격화하여 저장한다. `Context(맥락) - Action(구체적 행동) - Trade-off(조율 과정) - Impact(임팩트)` 포맷으로 내 프로젝트 사례들을 정리해 두고, 추상적 질문을 받으면 프로세스가 아닌 **이 포맷을 적용한 단 하나의 핵심 사례**를 즉시 꺼내 답변할 것이다.
+2. **당황할 때 확보하는 3초의 템포**
+ 추상적이고 열린 질문을 받더라도 즉각 입을 열지 않고, 3초간 숨을 고르며 생각을 정돈한 뒤 차분한 호흡으로 3인칭 시점에서 답변을 시작하는 연습을 하겠다.
+
+---
+
+## 마무리하며
+
+마지막 질문 시간에 로그플랫폼팀의 최신 행보와 A/B테스팅 플랫폼 Tuba에 대한 리서치를 드러냈을 때, 면접관분들이 환하게 웃어주셨던 모습이 여전히 선명하다. 2시간 동안의 치열했던 1차 면접은 비록 '탈락'이라는 쓰라린 결과를 남겼지만, 역설적이게도 나에게 그 어떤 합격 수기보다 값진 **내 커리어의 선명한 나침반**을 선물해 주었다.
+
+내가 무엇이 부족한지 명확히 인지했고, 이를 극복할 구체적인 설계도까지 쥐었으니 이번 실패는 성장의 아주 완벽한 이정표가 될 것이다.
+
+각성은 끝났으니, 이제 다시 코드를 짜고 데이터를 흐르게 할 시간이다. 더 단단해진 동료이자 엔지니어로 다음 도약을 준비한다. 🚀
diff --git "a/posts/\355\206\240\354\212\244\354\246\235\352\266\214-\354\247\201\353\254\264\353\251\264\354\240\221-\355\232\214\352\263\240/meta.json" "b/posts/\355\206\240\354\212\244\354\246\235\352\266\214-\354\247\201\353\254\264\353\251\264\354\240\221-\355\232\214\352\263\240/meta.json"
new file mode 100644
index 0000000..f856d28
--- /dev/null
+++ "b/posts/\355\206\240\354\212\244\354\246\235\352\266\214-\354\247\201\353\254\264\353\251\264\354\240\221-\355\232\214\352\263\240/meta.json"
@@ -0,0 +1,17 @@
+{
+ "title": "토스증권 데이터 엔지니어 직무면접 회고",
+ "slug": "toss-securities-de-interview-retrospective",
+ "description": "토스증권 1차 직무면접 탈락이라는 성적표를 마주하고 작성한 뼈아픈 성찰의 기록입니다. 치열했던 기술 토론의 즐거움과 '일하는 방식'에 대한 메타인지적 고찰을 솔직하게 나눕니다.",
+ "date": "2026-05-29",
+ "category": "Life",
+ "tags": [
+ "Retrospective",
+ "회고",
+ "Data Engineering",
+ "Toss Securities",
+ "Interview",
+ "Work"
+ ],
+ "featured": false,
+ "visibility": "public"
+}
diff --git "a/public/images/posts/\352\261\260\354\240\234-\354\225\274\355\230\270\353\241\234\353\266\200\355\204\260-\353\260\260\354\232\264-\353\246\254\354\204\274\353\212\220-\354\227\255\354\243\274\355\226\211\354\235\230-\354\247\204\354\247\234-\353\263\270\354\247\210/yaho.jpg" "b/public/images/posts/\352\261\260\354\240\234-\354\225\274\355\230\270\353\241\234\353\266\200\355\204\260-\353\260\260\354\232\264-\353\246\254\354\204\274\353\212\220-\354\227\255\354\243\274\355\226\211\354\235\230-\354\247\204\354\247\234-\353\263\270\354\247\210/yaho.jpg"
new file mode 100644
index 0000000..504e112
Binary files /dev/null and "b/public/images/posts/\352\261\260\354\240\234-\354\225\274\355\230\270\353\241\234\353\266\200\355\204\260-\353\260\260\354\232\264-\353\246\254\354\204\274\353\212\220-\354\227\255\354\243\274\355\226\211\354\235\230-\354\247\204\354\247\234-\353\263\270\354\247\210/yaho.jpg" differ
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} +
+