이민기

이민기
복잡해진 코드베이스를 구조부터 다시 설계해 제품과 팀의 개발 속도를 함께 높이는 4년차 프론트엔드 개발자입니다.
사용자의 흐름과 개발 생산성을 함께 개선하는 코드를 지향합니다.
우측 하단 'Contact' 버튼을 통해 편하게 연락 가능합니다.

Introduce

저는 사용자의 흐름과 개발 생산성을 함께 개선하는 프론트엔드 개발자입니다.
실제 회사 프로젝트에서 FSD(Feature-Sliced Design), Clean Architecture 등 구조적 설계 방식을 적용하며, 확장성과 유지보수성을 고려한 코드 구조와 일관된 코드 품질을 중요하게 생각해 왔습니다.
AI를 활용한 개발이 보편화될수록 빠른 개발 속도는 단순한 코드 생산량이 아니라, 문제를 정확히 이해하고 복잡도를 낮추며 신뢰할 수 있게 구현하는 과정에서 나온다고 생각합니다.
React/Next.js 기반 프론트엔드를 중심으로 Node.js 백엔드와 Golang 기반 블록체인 네트워크까지 경험하며, 제품을 더 넓은 관점에서 이해하고 팀과 프로젝트에 실질적인 가치를 더하는 개발자로 성장하고자 합니다.

Work Experience

ThakiCloud Korea

2025.12 ~ 현재10개월
AI PlatformFrontend Engineer

데이터 주권을 지키는 엔터프라이즈 AI 인프라 개발

AI 도구로 빠르게 구축된 MVP 코드베이스를 프로덕션 제품으로 전환하며, AI 모델 학습·추론과 GPU·클러스터 자원, 데이터셋, 모델 레지스트리를 관리하는 통합 콘솔을 개발2025.12
Frontend Engineer
TypeScript
React
Rspack
Turborepo
Biome
TailwindCSS
ReactQuery
Zustand
ReactHookForm
Zod
i18next
Playwright
Vitest
  • Feature-Sliced Design 기반 점진적 마이그레이션
    • 합류 시점의 코드베이스는 AI 도구로 빠르게 만든 MVP였고, 도메인 간 책임 경계가 없고 중복·미사용 코드가 쌓여 변경 하나가 어디까지 영향을 주는지 예측하기 어려웠습니다. 프론트엔드 2인 팀에서 FSD 기반 계층 구조로의 전환을 제안했고, 기능 개발을 멈출 수 없어 전면 재작성 대신 기능 단위로 점진 마이그레이션하는 방식을 택했습니다. PR 기준 10만 줄 이상의 레거시 코드를 제거했고, bundle analyzer 기준 앱 번들은 37MB에서 32MB로 15%, gzip은 12.1MB에서 10.1MB로 17% 줄었습니다.
  • Module Federation 호스트 편입과 실행 환경 추상화
    • 단독 실행만 하던 제품을 다른 팀이 운영하는 React 기반 Module Federation 호스트에 Remote App으로 편입했습니다. 단독 실행은 TanStack Router로 라우팅하고 인증 토큰·테마·언어를 직접 초기화하지만, 호스트 안에서는 호스트가 제공하는 라우팅 함수와 인증·테마·언어 설정을 받아 써야 했습니다. 이 차이를 mount/unmount 진입점 뒤의 공통 인터페이스로 묶어 비즈니스 로직이 어느 환경에서 실행되는지 모르게 했습니다. 번들러는 Vite에 federation 플러그인을 붙이는 방법도 있었지만, 빌드 결과물 포맷과 shared 의존성 해석, 런타임 로딩 방식이 호스트의 Rspack과 미묘하게 달라 Rspack으로 전환해 호환 리스크를 없앴고, 캐시 없는 빌드 기준 22.3초에서 5.6초로 75% 줄었습니다.
  • 초기 로드 성능 개선
    • 콘솔 초기 로드가 Chrome DevTools Network 탭 기준 1.2초였고, 원인은 29MB 단일 벤더 번들과 다국어 리소스를 첫 로드에 전부 받는 구조였습니다. 벤더 번들을 도메인 라우트 단위로 분리해 진입한 화면에 필요한 묶음만 받도록 바꾸고 i18n 리소스도 필요한 시점에 받도록 지연 로딩했으며, 사용하지 않는 라이브러리 제거·트리 쉐이킹·프리로드를 함께 적용했습니다. 콘솔 전체 초기 로드가 0.45초로 약 62% 줄었습니다.
  • AI 생성 코드의 계층 규칙 위반을 커밋 단계에서 차단
    • FSD로 구조를 정리한 뒤에도 AI 도구로 생성한 코드가 계층 방향을 거스르는 역방향 의존이나 팀 컨벤션을 어기는 일이 반복됐습니다. 계층 규칙은 dependency-cruiser, 정적 분석은 Biome, 테스트는 Vitest로 검사하도록 구성해 커밋 훅과 CI 양쪽에 걸었습니다. 레포 자체에 설정돼 있어 누가 커밋하든 같은 기준을 통과해야 하고, 규칙을 어긴 코드는 리뷰에 도달하기 전에 커밋 단계에서 막힙니다.
  • Turborepo와 Vitest 동시성 중첩으로 인한 테스트 불안정 해결
    • 의존성 업데이트 후 테스트 코드는 그대로인데 전체 실행에서만 간헐적으로 실패하고 CPU 점유율이 치솟았습니다. 12코어 환경에서 Turborepo가 기본값으로 워크스페이스 10개를 동시에 돌리고 각 Vitest가 코어 수 빼기 1인 11개 워커를 띄워 워커 110개가 CPU를 경쟁하는 것이 원인이었고, 로드 에버리지가 64.41까지 올라갔습니다. Turborepo 동시성을 코어의 50%로 제한하고 Vitest 워커를 인스턴스당 2개로 줄였으며, cgroup 쿼터를 읽어 컨테이너의 실제 가용 CPU를 반영하게 했습니다. 전체 테스트 시간이 70초에서 26초로 줄고 로드 에버리지는 7.35로 내려갔습니다.

OpusM

2022.07 ~ 2025.083년 2개월
기술연구소Research Engineer

엔터프라이즈 블록체인 솔루션 개발 및 연구

LedgerMaster 3.0 MetaVisual

LedgerMaster 3.0 Admin 사용자를 위한 블록체인 대시보드를 요구사항 정의와 구조 설계부터 구현까지 개발2024.07 ~ 2024.11
Frontend Developer
TypeScript
Next.Js
ReactHookForm
TailwindCSS
Turborepo
StoryBook
Jest
TestingLibrary
ReactQuery
Yarn
Jira
Bitbucket
  • 블록체인 도메인 정의 및 화면 흐름 제안
    • 기획자가 블록체인을 처음 다루는 프로젝트라, 초기 기획안에는 밸리데이터를 마이너로 쓰는 식으로 체인의 실제 합의 방식과 맞지 않는 용어가 들어 있었습니다. 블록·트랜잭션·스마트 컨트랙트의 데이터 구조와 관계를 회의에서 설명하며 정리하고, 화면에 노출할 용어 체계와 정보 위계, 탐색 흐름을 제안했습니다. 그 결과 화면의 용어와 탐색 구조를 체인의 실제 개념에 맞췄습니다.
  • Feature-Sliced Design과 Atomic Design을 나눠 적용한 아키텍처 설계
    • PASS SIGN에서 쓴 Atomic Design Pattern은 UI를 구조화하기에는 좋았지만, 인증·블록·트랜잭션·컨트랙트처럼 도메인 엔티티가 여러 개인 제품에서 비즈니스 로직과 도메인 로직을 어디에 둘지 정해주지 못했습니다. 신규 프로젝트를 처음부터 설계하면서 비즈니스 로직·엔티티·위젯을 기능 단위로 나누는 Feature-Sliced Design을 도입해 도메인 간 의존을 끊고, 순수 UI 컴포넌트에는 Atomic Design을 그대로 써서 두 패턴이 맡는 영역을 분리했습니다.
  • Monorepo 기반 디자인 시스템 및 공통 패키지 구축
    • 솔루션 문서 애플리케이션과 어드민 프론트엔드 두 앱이 같은 UI를 써야 했습니다. Turborepo 기반 모노레포로 앱과 공유 패키지를 분리해, 디자인 시스템을 독립 패키지로 떼어내 Storybook으로 문서화하고 TypeScript·ESLint·TailwindCSS 설정도 공용 패키지로 뽑아 두 앱이 같은 규칙과 UI를 쓰게 했습니다. 공용 컴포넌트 패키지에는 Jest와 Testing Library로 테스트를 붙였고 커버리지 리포트 기준 80% 이상이었습니다.

LedgerMaster 3.0

블록체인 솔루션 LedgerMaster 3.0의 Admin Server를 도메인 설계부터 API 구현까지 개발2023.06 ~ 2024.11
Backend Developer
TypeScript
Express
MongoDB
Mongoose
Docker
Web3.Js
Solc
Joi
JsonWebTokens
EthereumJs
Quorum
Axios
Jira
Bitbucket
Nats.io
Jest
  • 보안 토큰 관리 도메인의 서비스 구조 설계
    • 블록체인 기반 보안 토큰을 관리하는 시스템으로, 사용자·컨트랙트·트랜잭션 도메인이 MongoDB·NATS·블록체인 등 서로 다른 외부 시스템에 동시에 얽히는 구조였습니다.
    외부 연동 코드가 비즈니스 로직에 섞이지 않도록 api·application·domain·infrastructure 계층을 분리하고 의존성 주입과 인터페이스 추상화를 적용했습니다. 저장 형태와 도메인 개념이 함께 바뀌지 않도록 DB Entity와 Domain Entity를 분리해, MSA 환경에서 NATS로 수신되는 컨트랙트·트랜잭션 이벤트를 도메인 규칙에 맞게 변환해 저장하도록 했습니다.
  • RESTful API와 검증 미들웨어 설계
    • Express와 TypeScript 기반으로 인증·사용자·컨트랙트·트랜잭션·파일 5개 도메인 20여 개의 REST API를 설계·구현했습니다. 요청 검증 로직이 컨트롤러에 흩어지지 않도록 Joi 기반 검증 미들웨어를 도메인별로 구성하고, JWT 인증·인가와 일관된 에러 응답 포맷을 적용했습니다.
  • 스마트 컨트랙트 컴파일·배포·실행 파이프라인 구현
    • 어드민에서 스마트 컨트랙트를 직접 다룰 수 있도록 solc 기반 컴파일 파이프라인을 구현했습니다. OpenZeppelin 등 외부 라이브러리의 import 경로를 해석하는 콜백을 직접 구성하고, 컴파일 산출물인 ABI·bytecode를 저장해 재사용할 수 있게 했습니다. 배포·실행·조회를 각각 독립된 유스케이스로 분리하고, 컴파일 오류는 API 에러 포맷으로 변환해 프론트엔드에서 실패 원인을 그대로 확인할 수 있도록 했습니다.
  • 도메인 로직 테스트와 운영 기반 정비
    • 데이터베이스나 외부 시스템 상태에 의존하면 도메인 로직 검증이 불안정해질 수 있다고 보고, Jest와 Mock 객체로 사용자 등록·인증 등 주요 로직을 인프라와 분리해 독립적으로 검증했습니다. 운영 중 서버 상태를 확인할 수 있도록 Prometheus 메트릭 수집을 연동하고, 빌드 단계에서 API 문서를 자동 생성해 프론트엔드와의 연동 기준을 코드와 일치시켰습니다. 블록체인 어댑터 서비스와 어드민 서비스가 함께 쓰는 코드는 npm·Nexus 사설 저장소로 패키지화해 두 서비스가 같은 버전을 쓰도록 했습니다.

SKT PASS SIGN

SKT PASS 앱 내 전자계약 웹앱의 프론트엔드를 초기 구축부터 담당2022.07 ~ 2024.07
Frontend Developer
TypeScript
React
Axios
ReactQuery
ReactHookForm
StoryBook
Redux
StyledComponents
MUI
Jest
TestingLibrary
Jira
Bitbucket
  • PASS 앱 웹뷰와 브라우저 실행 환경 대응
    • 서비스는 PASS 앱 웹뷰 안에서만 동작하지만 개발과 QA는 네이티브 브릿지가 없는 일반 브라우저에서 진행해야 했고, 앱 안에서도 Android는 Chrome WebView, iOS는 WebKit으로 엔진이 달랐습니다. 실행 환경을 런타임에 판별하는 훅을 두고, SKT 네이티브 팀이 정한 브릿지 스펙에 맞춰 계약서 다운로드·로딩 표시·뒤로가기·웹뷰 종료처럼 앱이 제어해야 하는 동작은 브릿지로 위임하고 브라우저에서는 웹 표준 방식으로 분기했습니다. 그 결과 하나의 코드베이스로 앱 안에서 서비스하면서 브라우저에서 개발·QA를 돌릴 수 있었습니다.
  • 컴포넌트 구조 정리 및 테스트 기반 품질 확보
    • 촉박한 일정에 맞춰 화면부터 구현하다 보니 컴포넌트가 혼재되어 변경 비용이 커지고, 디자인과 구현물 간 피드백도 늦어졌습니다. 공통 UI를 Atomic Design Pattern으로 계층화하고 Storybook에 59개 컴포넌트 스토리를 구성해, 배포된 Storybook 주소에서 디자이너가 구현물을 직접 확인할 수 있게 했습니다. 주요 화면 16개에는 Jest와 React Testing Library로 렌더링 테스트를 작성했고, Jest 커버리지 리포트 기준 95% 이상이었습니다.
  • 해시 기반 전자계약 증명 모델 제안 및 설계
    • 계약이 완료된 뒤 PDF가 서명 당시 문서와 같다는 것과 각 서명이 어떤 상태의 문서에 대한 것인지를 증명할 방법이 필요했습니다. 사내 회의에서 원본 문서와 완성 계약서의 해시를 각각 보관하고, 서명자마다 서명 시점의 문서 해시와 서명 이미지 해시를 함께 기록하는 구조를 제안했고 그 방식으로 진행했습니다. 서명 순서에 따라 계약 상태를 검증할 수 있고, 화면에서는 식별정보를 직접 비교하지 않고 해시로 대조해 본인의 서명 영역을 판별하도록 구현했습니다.

Opstra

회사 블록체인 솔루션을 검증할 자체 네트워크의 필요성을 제안하고, Cosmos SDK 커스텀 체인과 CometBFT 합의 네트워크를 구축2025.03 ~ 2025.04
Blockchain Engineer
Go
CosmosSDK
CometBFT
ubuntu
  • 커스텀 블록체인 테스트넷 구축 및 모니터링
    • 자체 네트워크 구성을 검증하기 위해 Cosmos SDK v0.50.1 기반으로 체인을 구성하고 chain-id·denom·스테이킹 파라미터를 목적에 맞게 조정한 뒤, 사내 PC 기반 Ubuntu Linux 환경에서 밸리데이터 노드 4대와 RPC 노드 2대를 연결한 P2P 테스트넷 인프라를 구축했습니다. 또한 PingPub 대시보드를 연결해 테스트 네트워크의 노드 상태를 실시간으로 확인할 수 있도록 했습니다.
  • 노드 빌드 및 설치 자동화
    • 다양한 OS 환경에서 노드를 일관되게 실행할 수 있도록 Makefile 기반 바이너리 빌드와 Shell 스크립트 기반 설치 자동화를 구성했습니다. 이를 통해 반복적인 노드 설치 과정을 표준화했습니다.

Opus DID Wallet

DID 기반 블록체인 지갑 연구 및 프로토타입 개발 참여2023.02 ~ 2023.06
Researcher
Docker
JavaScript
HyperLedger
  • DID 프로세스 시나리오 연구 및 설계
    • 기존 카드 태깅 방식은 인증 수단이 분실되거나 양도되면 본인 여부를 확인할 수 없다는 한계가 있었습니다.
    이를 신원 증명 문제로 보고, 회사가 Issuer로서 QR 코드를 통해 Holder인 직원에게 Verifiable Credential을 발급하고, 직원이 Verifier인 출퇴근 시스템에 Verifiable Presentation을 제출해 증명하는 출퇴근 인증 프로세스를 설계했습니다. 인증 정보를 중앙 시스템이 아니라 사용자가 보유하는 구조로 두어, 개인정보를 최소한으로 제출하면서 본인을 증명할 수 있도록 했습니다.
  • Hyperledger 기반 DID 인프라 연구 및 프로토타입 개발
    • 설계한 인증 프로세스가 실제로 동작하는지 확인하기 위해 Hyperledger VON·Aries Cloud Agent·Indy Tails Server로 테스트 환경을 구성하는 작업에 참여했습니다. VC 발급과 VP 검증 흐름을 개념 증명으로 검증해, 데이터 주권을 사용자에게 두는 신원 인증 구조가 기술적으로 성립한다는 것을 확인했습니다.

Other Experience

OpenSource

2025.09.25 IBC 트랜잭션 모니터링을 개발하던 중, 비정상적인 packet timeout height를 가진 트랜잭션을 발견하고 ibc-go의 타임아웃 검증 로직을 분석했습니다. RevisionNumber 설정에 따라 패킷 타임아웃이 사실상 우회될 수 있는 문제를 확인했고, v8.x.x 환경에서 Docker 기반 PoC와 CLI 재현 절차를 구성해 이슈로 제보하고, 이후 제출한 수정 PR이 머지되었습니다.
Go
Docker
  • 개선 필요성
    • SendPacket(), Timeout.Elapsed(), heightElapsed(), Height.Compare() 흐름을 코드 레벨에서 추적했습니다. RevisionNumber가 RevisionHeight보다 우선 비교되는 구조가 체인 업그레이드를 고려한 합리적인 설계임을 이해하는 동시에, 비정상적으로 높은 RevisionNumber가 설정되면 타임아웃 판정이 사실상 미래 시점으로 밀릴 수 있는 원인을 확인했습니다.
  • 재현 및 해결 방향 제안
    • simapp 2개와 Hermes relayer를 Docker Compose로 구성해 v8.x.x 환경에서 문제를 재현하고, 여러 체인의 ibc-go 사용 버전을 확인해 프로덕션 영향 가능성을 검토했습니다. 이후 ibc-go V2에서는 timeout height 대신 timestamp 중심으로 전환되는 방향을 확인하고, V1 환경을 위한 SendPacket()의 RevisionNumber 사전 검증과 heightElapsed() 로직 개선안을 코드와 함께 제안했습니다.
  • 수정 PR 구현 및 머지
    • 제안한 방향을 직접 구현해 수정 PR을 제출했습니다. 패킷이 체인 상태에 기록되기 전 SendPacket()에서 타임아웃 높이의 RevisionNumber가 상대 클라이언트의 현재 리비전을 넘어서면 거부하도록 하고, 검사는 리비전을 쓰는 Tendermint와 localhost 클라이언트로 한정해 다른 클라이언트 타입의 기존 동작이 바뀌지 않도록 했습니다.
    상태 머신에 영향을 주는 변경이라 클라이언트 타입별 테스트를 추가했고, 메인테이너 리뷰를 거쳐 머지되었습니다.
2023.07.23 회사 DID 연구 및 PoC에서 revocation registry 동작을 검증하려 Indy Tails Server 데모를 실행하던 중 발견한 Docker 빌드 실패의 원인을 찾아 수정 PR로 기여했습니다.
Docker
Python
Hyperledger Indy
  • 개선 필요성
    • VC/VP 검증 흐름을 실험하기 위한 Indy Tails Server 데모 환경을 구성하던 중 Docker 컨테이너의 pip 설치 단계에서 indy_vdr 설치 오류가 발생하는 것을 확인했습니다. requirements 파일과 패키지 버전을 비교하며 원인을 좁히고, 특정 dev 버전에서 정상적으로 빌드되는 조건을 확인했습니다.
  • 해결 및 기여
    • 재현 가능한 해결 방법으로 indy_vdr 버전 명시를 제안하는 PR을 작성했습니다. 해당 변경은 프로젝트에 반영되어 Docker 데모 환경에서 동일한 설치 오류가 발생하지 않도록 개선되었습니다.

Hackathons

2025.12
Lead Engineer
Sui Foundation과 Walrus Foundation이 주최한 Walrus Haulout Hackathon 2025에서, 이력서를 암호화한 채로 AI 프리뷰만 공개하고 열람은 구직자 승인으로 여는 채용 매칭 플랫폼 'Tusk'로 Best Technical Implementation을 수상했습니다.
5인 팀에서 시스템 아키텍처와 시나리오 플로우 설계, 프론트엔드 개발·배포, 문서 작업을 맡았고, 지인 한 명과 함께 팀을 이끌었습니다.
Sui
Move
Seal
Walrus
TypeScript
Next.js
  • 프라이버시 중심 채용 플로우 설계
    • 구직자 이력서가 과하게 공개되고 채용 담당자는 제한된 정보로 탐색해야 하는 문제를 잡고, 등록 → 검색 → 열람 권한 요청 → 승인·거절 → 열람의 5단계 플로우를 설계했습니다. 이력서 저장은 Walrus, 접근 제어는 Sui 객체와 Seal로 분리해 신뢰 범위를 최소화했습니다. 채용 담당자 KYC와 섹션별·기간별 세밀한 권한은 해커톤 범위에서 제외하고 이력서 단위 승인만 구현했습니다.
  • 프론트엔드 구현과 배포
    • Next.js와 TypeScript로 프로젝트를 세팅하고, Sui 네트워크와 Slush Wallet 연결을 위한 Provider와 상태 관리 구조를 설계했습니다. 랜딩 페이지 개발과 배포를 맡았고, QA에서 나온 이슈를 고치고 README와 아키텍처 다이어그램을 작성했습니다.

Activities

Blockchain Valley

2025.09 ~ 2026.06고려대학교 기반 블록체인 학회 블록체인 밸리 8기 코어팀으로 활동했습니다.
  • Cosmos 기반 인터체인 아키텍처 및 앱체인 구조 연구
    • Cosmos SDK와 IBC 프로토콜을 기준으로, 특정 도메인에 특화된 App Chain이 어떻게 설계되고 다른 체인과 연결되는지를 구조 단위로 정리했습니다.
  • 합의 알고리즘과 기존 취약점 사례 분석
    • CometBFT와 Tendermint의 합의 구조를 코드 단위로 따라가며, 과거 보고된 합의 과정의 주요 취약점이 어느 지점에서 발생했는지 분석했습니다.