권동하

Software Engineer

ansqhrl3037@gmail.comgithub.com/ssyy3034velog.io/@ansqhrl3037/posts

About

JavaScript/TypeScript와 React를 주력으로 사용하며, 기본기가 탄탄한 개발자를 지향합니다. OS(Pintos) 구현 프로젝트를 통해 문제를 해결했던 끈기를 바탕으로 컴퓨터의 동작 원리를 깊이 있게 학습했고, 이 경험을 바탕으로 브라우저 렌더링 최적화나 효율적인 상태 관리 방법을 고민하고 있습니다. 단순히 기능만 구현하는 것이 아니라, 성능과 유지보수성까지 고려한 '좋은 코드'를 작성하기 위해 노력합니다. 배운 내용을 체계적으로 정리하고 공유합니다. 복잡한 개념도 남에게 설명할 수 있을 만큼 확실하게 이해하고 넘어가며, 학습한 내용은 기술 블로그와 개인 노트(Obsidian)에 꾸준히 기록해 왔습니다. 이러한 습관 덕분에 새로운 기술도 빠르게 익혀 실무에 적용할 수 있으며, 동료들과 지식을 나누며 함께 성장할 준비가 되어 있습니다. 좋은 서비스는 개발자 혼자가 아닌, 팀 전체의 소통 속에서 만들어진다고 믿습니다. 3년간 서비스직 현장 리더로 일하며, 바쁜 시기에도 팀원 간의 의견을 조율하고 돌발 상황을 해결해 본 경험이 있습니다. 개발 현장에서도 기획자, 디자이너, 백엔드 개발자와 적극적으로 소통하며, 사용자에게 더 나은 경험을 전달하려 합니다.

다양한 분야에 대한 호기심을 바탕으로 사용자의 맥락을 이해하려 노력하며, AI를 활용해 견고한 결과물을 가장 효율적으로 만들어내기 위해 매일 스스로를 점검합니다.

Core Expertise

ReactTypeScriptZustandTanStack QueryTiptapViteJavaSpring BootCDocker

Key Projects

StoLink

— 웹소설 작가용 에디터 프론트엔드

2025.12 - 2026.01

Frontend Developer · 5인 팀 (FE 전담)· github.com/stolink/stolink_frontend

D3.js 그래프 Canvas 전환(INP 16배 개선) 및 AI 에이전트 기반 개발 워크플로우 자동화. Vite 번들 최적화로 초기 로딩 60% 단축.

1048 → 64ms드래그 응답 (INP)CLI & Agent워크플로우 자동화450 → 190KB초기 번들 (gzip)

React · TypeScript · Canvas API · AI Agent · Zustand · TanStack Query

Pintos Kernel

— 커널 프로그래밍 및 운영체제 실습

2025.11 - 2025.12

System Engineer · KAIST Jungle 4인 팀

Priority Donation, Demand Paging 구현. GDB로 SW-HW 상태 불일치(Widowed Frame) 버그를 추적하여 해결.

4개 모듈Threads, Userprog, VM, FSGDB 디버깅Page Fault 무한루프 해결

C · Assembly · OS Internals · QEMU

Aidiary

— AI 기반 육아 기록 플랫폼

2025.03 - 2025.06

Full-stack Developer · 3인 팀· github.com/ssyy3034/aidiary-main

Spring Boot + Python Flask 마이크로서비스 구조로 AI 연산 분리. Zustand로 전역 상태 관리, Docker Compose로 전체 서비스 구성.

3개 서비스Spring, Flask, React6개 컨테이너Docker Compose 구성

React · Zustand · Spring Boot · Python · Docker

Technical Expertise

Core competencies and practical applications

Frontend

React

useRef로 에디터 인스턴스 재생성 방지, useMemo로 불필요한 트리 연산 제거 등 리렌더링 최적화 경험이 있습니다.

TypeScript

인터페이스를 활용해 데이터 구조를 명확히 정의하고, 컴파일 단계에서 잠재적인 오류를 예방했습니다.

Zustand

Prop Drilling 문제를 해결하고, 도메인별 스토어를 분리하여 상태 관리 복잡도를 낮춘 경험이 있습니다.

TanStack Query

서버/클라이언트 상태를 분리하고, 낙관적 업데이트 및 자동 롤백 전략으로 사용자에게 즉각적인 피드백을 제공했습니다.

Tiptap

ProseMirror 기반 에디터를 확장하여 커스텀 노드를 개발하고, 에디터 안정화 문제를 해결했습니다.

Vite

manualChunks로 번들을 분리하고 Lazy Loading을 적용하여 초기 로딩 시간을 개선했습니다.

Backend & System

Java

학부 시절 주 언어로 사용했으며, 객체지향 프로그래밍(OOP)의 기본 개념을 이해하고 있습니다.

Spring Boot

Layered Architecture 기반으로 API를 개발하며, 기본적인 트랜잭션 처리와 예외 핸들링을 경험했습니다.

C

Pintos OS 프로젝트에서 스케줄러, 가상 메모리를 구현하며 시스템이 어떻게 동작하는지 이해했습니다.

Docker

Docker Compose로 로컬 개발 환경을 구성하고, 기본적인 컨테이너 명령어를 사용할 수 있습니다.

PostgreSQL

SQL을 사용하여 데이터를 조작하고, 인덱스와 트랜잭션의 기본 개념을 이해하고 있습니다.

Neo4j

노드와 관계 중심의 그래프 DB 개념을 이해하고 있으며, Cypher 쿼리를 통해 데이터를 조회하고 가시화해 본 경험이 있습니다.

관심 분야

Next.js

App Router 기반으로 포트폴리오를 구축하며 SSR/RSC 개념을 학습하고 있습니다.

Web Performance

Chrome DevTools로 INP, LCP를 측정하며 병목을 찾고 개선하는 방법을 익히고 있습니다.

Project Case Study

StoLink

웹소설 작가용 에디터 프론트엔드

2025.12 - 2026.01Frontend Developer

“SVG→Canvas 마이그레이션으로 INP 16배 개선, 번들 최적화로 초기 로딩 60% 단축”

Overview

5인 개발팀의 웹소설 작가용 플랫폼에서 프론트엔드 전체를 단독 담당했습니다. 노드 30개에서 멈추던 관계도 그래프를 600개 이상 처리 가능하도록 Canvas로 전환하고, Vite 번들 최적화로 초기 로딩을 60% 단축했습니다.

Key Results

1048 → 64ms

드래그 응답 시간

SVG→Canvas 전환으로 DOM 조작 제거, Chrome DevTools Performance 탭에서 측정

450 → 190KB

초기 번들 크기

Vite manualChunks로 Export/Graph 라이브러리 Lazy Loading 적용 (gzip 기준)

인스턴스 유지

에디터 안정화

useRef 패턴으로 부모 리렌더링에도 Tiptap 인스턴스 유지, 커서 튐 현상 해결

O(n log n) → O(1)

트리 변환 최적화

useMemo + 참조 동등성으로 데이터 변경 시에만 트리 재구성

100%

표준 준수

자동화된 워크플로우 도입으로 온보딩 비용 제거 및 코드 품질 표준화

Technical Deep Dive

1. SVG → Canvas 마이그레이션

INP 1,048ms → 64ms

ChallengeD3.js 기반 캐릭터 관계도에서 노드가 30개를 넘어서자 줌/팬 조작 시 FPS가 10 미만으로 하락했습니다. Chrome DevTools 프로파일링 결과, 매 프레임마다 수백 개 DOM 요소의 Style Recalculation에 935ms가 소요되고 있었습니다.

Solution

SVG(DOM) 기반 렌더링을 Canvas API(react-force-graph-2d)로 전면 전환했습니다. 단일 Canvas 레이어에서 일괄 드로잉하여 브라우저의 스타일 재계산 부하를 완전히 제거했습니다.

Single Layer Rendering: 개별 DOM 노드 대신 Canvas 컨텍스트에서 Batch Drawing
Image Caching (useImageCache): 캐릭터 이미지를 텍스처로 메모리에 캐싱하여 드로잉 성능 최적화
Color-based Hit Detection: Canvas에서 클릭 이벤트 감지를 위한 O(1) 히트맵 구현 - 각 노드를 고유 색상으로 칠한 히든 캔버스에서 픽셀 색상으로 노드 ID 역추적

2. 번들 최적화로 초기 로딩 60% 개선

초기 JS 450KB → 187KB

Challenge프로덕션 빌드 후 Lighthouse 측정 시, 사용하지 않는 Export 라이브러리(docx 714KB, jspdf 341KB, epub-gen)가 초기 번들에 포함되어 로딩 지연 발생. 초기 JS 크기가 450KB(gzip)에 달했습니다.

Solution

Vite의 manualChunks 설정으로 라이브러리를 용도별로 분리하고 Lazy Loading을 적용했습니다.

vendor-export (714KB): docx, jspdf, epub-gen → Export 페이지에서만 로드
vendor-graph (61KB): D3, react-force-graph → 관계도 페이지에서만 로드
vendor-editor-extensions (33KB): Tiptap 확장 → 에디터 페이지에서만 로드
캐시 효율성: 세분화된 청크로 코드 수정 시 변경된 청크만 재다운로드 (40% → 85%)

3. Tiptap 에디터 인스턴스 안정화

인스턴스 재생성 0회, 커서 튐 완전 제거

ChallengeTiptap(ProseMirror) 에디터에서 부모 컴포넌트가 리렌더링될 때마다 onUpdate 콜백이 새로 생성되어 에디터 인스턴스가 파괴/재생성되었습니다. 이로 인해 타이핑 도중 커서 위치가 초기화되고, 입력이 씹히는 치명적인 UX 문제가 발생했습니다.

Solution

Stable Callback Ref 패턴을 적용하여 에디터의 의존성(Dependencies)과 콜백의 최신성(Freshness)을 분리했습니다. 함수 자체가 아닌 함수의 참조(ref)를 구독하게 하여 리렌더링 사이클을 끊었습니다.

Before: useEditor({ onUpdate }, [onUpdate]) → 콜백 변경 시 에디터 전체 재생성
After: onUpdateRef = useRef(callback) → ref.current만 갱신, 에디터는 최초 1회만 생성
useEffect로 ref.current를 동기화하여 항상 최신 로직에 접근 가능

4. 트리 변환 메모이제이션

연산 비용 제거 (O(n log n) → O(1)), 반응성 극대화

Challenge문서 트리 사이드바에서 노드 클릭/호버마다 Flat Array → Nested Tree 변환 함수(buildTree)가 매번 실행되었습니다. Map 생성 O(n) + 관계 연결 O(n) + 정렬 O(n log n) 과정으로, 문서 수백 개일 때 단순 클릭에도 15~20ms 연산이 발생하여 UI 반응성이 저하되었습니다.

Solution

useMemo와 참조 동등성(Referential Equality)을 활용하여 데이터가 실제로 변경되었을 때만 트리 변환을 수행하도록 최적화했습니다.

Before: 렌더링마다 buildTree(documents) 실행 → 매번 15~20ms 소요
After: useMemo(() => buildTree(documents), [documents]) → 참조 변경 시에만 재연산
불변성(Immutability) 원칙 덕분에 내용이 같으면 참조도 같음이 보장됨

5. AI 에이전트 워크플로우 자동화

개인 도구로 시작하여 4팀 중 3팀(15/20명)으로 확산, 기수 전체 생산성 견인

Challenge5인 팀 개발 중 Git 숙련도 격차로 인한 브랜치 충돌, 이슈 트래킹 누락, 구두 합의된 컨벤션 미준수 등 협업 비효율이 발생했습니다.

Solution

이슈 생성부터 PR까지의 수명주기를 자동화하는 'Smart-Commit' CLI와, 작업 크기에 따라 최적의 프롬프트를 주입하는 'Supervisor Agent' 시스템을 구축했습니다.

Smart-Commit: Staging된 변경사항을 분석하여 Conventional Commits 메시지 및 이슈 연결 자동화
Supervisor Agent: 작업 명세를 분석하여 Stylist/Architect 등 전문 에이전트에게 최소한의 Context만 동적 주입
Quality Gates: 'Design Compliance'를 포함한 3단계 자동 감사를 통해 코드와 디자인 품질 집중 검증

Project Case Study

Pintos Kernel

커널 프로그래밍 및 운영체제 실습

2025.11 - 2025.12System Engineer

“8-depth Priority Donation, Widowed Frame 디버깅, Demand Paging 기반 메모리 관리”

Overview

하드웨어 위에서 직접 동작하는 교육용 운영체제의 핵심 모듈을 구현했습니다. 우선순위 역전 해결, 무한 Page Fault 디버깅, 가상 메모리 관리 등 저수준 시스템 문제를 해결하며 CS 기초 역량을 확보했습니다.

Key Results

4개 모듈

OS 핵심 기능 구현

Threads, User Programs, Virtual Memory, File System

GDB 디버깅

Widowed Frame 해결

SW-HW 상태 불일치로 인한 무한 Page Fault를 GDB로 추적하여 수정

Technical Deep Dive

1. Priority Donation: 8-depth 중첩 락 체인 해결

donate-nest/chain 테스트 통과

Challenge높은 우선순위(H) 스레드가 낮은 우선순위(L) 스레드가 점유한 락을 기다릴 때, 중간 우선순위(M) 스레드가 L을 선점해버리면 H가 무한정 대기하는 우선순위 역전이 발생했습니다.

Solution

Priority Donation 메커니즘을 설계하고 구현했습니다. 락 대기 시 보유자에게 우선순위를 기부하고, 중첩된 락 대기 상황까지 재귀적으로 전파합니다.

Donation: 락 대기 시 보유자에게 자신의 높은 우선순위를 일시적으로 기부
Chain Handling: Nested Donation까지 재귀적으로 전파 (depth limit: 8)
Revert: 락 해제 시 기부받은 우선순위 반납 및 본래 우선순위로 복귀

2. Widowed Frame 디버깅: 무한 Page Fault 해결

mmap-* 테스트 전체 통과

Challengemmap된 메모리 접근 시 Page Fault가 무한 반복되며 프로세스가 exit(-1)로 강제 종료되었습니다. page->frame은 존재하지만 실제 PML4 매핑은 없는 '고아 프레임' 상태였습니다.

Solution

vm_do_claim_page에서 프레임 존재 여부만 확인하던 로직에 PML4 매핑 검증을 추가했습니다. 고아 상태 감지 시 pml4_set_page로 매핑을 복구합니다.

Before: page->frame != NULL이면 true 반환 → PML4 매핑 누락 시 무한 루프
After: pml4_get_page로 하드웨어 매핑 검증 → 누락 시 pml4_set_page로 복구
GDB로 Page Fault Handler 진입점 추적하여 원인 특정

3. Demand Paging: 가상 공간 확장 및 지연 로딩

한정된 물리 메모리 극복 및 가상 공간 활용

Challenge프로세스 실행 시 모든 세그먼트를 메모리에 올리면 물리 메모리가 금방 부족해지는 문제가 있었습니다.

Solution

Page Fault가 발생했을 때만 해당 페이지를 로드하는 Demand Paging을 구현했습니다.

Supplemental Page Table (SPT): 페이지 메타데이터(디스크 위치, 쓰기 가능 여부) 관리
Page Fault Handler: 디스크에서 데이터를 읽어 물리 프레임에 매핑 후 재시작
Stack Growth: rsp 레지스터 감시하여 스택 영역 접근 시 자동 페이지 할당

Project Case Study

Aidiary

AI 기반 육아 기록 플랫폼

2025.03 - 2025.06Full-stack Developer

“Spring Boot + Python Flask 마이크로서비스, Docker Compose로 6개 컨테이너 구성”

Overview

AI 기반 육아 기록 플랫폼의 전체 스택을 담당했습니다. 프론트엔드에서는 Zustand + Custom Hooks로 상태를 관리하고, 백엔드에서는 Spring Boot와 Python Flask를 분리하여 AI 연산과 비즈니스 로직을 분리했습니다.

Key Results

3개 서비스

마이크로서비스 구성

Spring Boot + Python Flask + React 독립적인 서비스로 분리

6개 컨테이너

Docker Compose

FE, BE, AI, DB, Prometheus, Grafana 전체 인프라 구성

Zustand

상태 관리

Custom Hooks 패턴으로 전역 상태 관리 및 비즈니스 로직 분리

Technical Deep Dive

1. 프론트엔드 상태 관리 구조화

Prop Drilling 제거

Challenge다수의 useState와 prop drilling으로 인해 상태 흐름을 파악하기 어려웠습니다. 같은 데이터를 여러 컴포넌트에서 중복 관리하고 있었습니다.

Solution

Zustand 스토어 기반으로 전역 상태를 일원화하고, Custom Hooks로 비즈니스 로직을 View에서 분리했습니다.

Zustand 스토어로 전역 상태 중앙 관리
useCharacter.ts 등 도메인별 Custom Hooks로 로직 분리
Single Source of Truth 원칙 적용

2. Hybrid AI Architecture

AI 연산 분리로 메인 서버 블로킹 방지

ChallengeAI 이미지 생성(DALL-E 3)은 30초 이상 소요되는 작업입니다. 이를 메인 서버에서 처리하면 다른 요청이 블로킹됩니다.

Solution

적재적소 원칙으로 서비스를 분리했습니다. Spring Boot는 비즈니스 로직과 인증, Python Flask는 AI/ML 라이브러리 활용에 집중합니다.

Spring Boot: 비즈니스 로직, 트랜잭션, 보안/인증
Python Flask: face-cli, OpenAI API 등 AI 연산
RestTemplate: 서비스 간 HTTP 통신

3. AI Pipeline 구축

얼굴 특징 기반 프롬프트 자동 생성

Challenge부모 사진으로 아이 얼굴을 예측하려면 단순 API 호출이 아닌 전처리 과정이 필요했습니다.

Solution

face-cli로 얼굴 특징점을 추출하고, 이를 자연어 프롬프트로 변환하여 DALL-E 3에 전달하는 파이프라인을 구축했습니다.

Input: 부모 사진 업로드
Preprocessing: face-cli로 얼굴 특징점 추출
Prompt Engineering: 특징 → 자연어 프롬프트 변환
Generation: DALL-E 3 API 호출

AI Native Software Engineer

I'm |, a
Software Engineer||

Frontend Developer

Problem Solver

배운 내용을 체계적으로 정리하고 공유합니다. 복잡한 개념도 남에게 설명할 수 있을 만큼 확실하게 이해하고 넘어가며, 학습한 내용은 기술 블로그와 개인 노트(Obsidian)에 꾸준히 기록해 왔습니다. 이러한 습관 덕분에 새로운 기술도 빠르게 익혀 실무에 적용할 수 있으며, 동료들과 지식을 나누며 함께 성장할 준비가 되어 있습니다.

Team Player

좋은 서비스는 개발자 혼자가 아닌, 팀 전체의 소통 속에서 만들어진다고 믿습니다. 3년간 서비스직 현장 리더로 일하며, 바쁜 시기에도 팀원 간의 의견을 조율하고 돌발 상황을 해결해 본 경험이 있습니다. 개발 현장에서도 기획자, 디자이너, 백엔드 개발자와 적극적으로 소통하며, 사용자에게 더 나은 경험을 전달하려 합니다.

프로젝트 둘러보기 이력서 보기 GitHub

👤