Changuk Woo
A full-stack engineer on a geospatial-engineering M.S. foundation (crustal deformation · GNSS), who measures and validates ground displacement with satellite InSAR and builds the systems on top of it. I pair research-domain understanding with production engineering in one person.
Summary
I studied Civil Engineering (B.S.) and Geospatial Information Engineering (M.S., thesis: a crustal-deformation model for southeastern Korea, GNSS-based) at Sungkyunkwan University. So the 'ground / crustal displacement' that satellite InSAR measures is my own research topic; the SAR processing tools and pipelines I picked up after joining, with AI as a thinking partner. In parallel I own the full stack — planning, frontend, backend, infra/CI-CD — working AI-native: AI writes the code while I focus on the human-owned nodes (planning, review, e2e tests that guarantee behavior).
At work I run three quite different workstreams in parallel: (1) the LumirX SAR processing pipeline (SDPE) — I built the DAG UI operators use to compose and run processing stages, stood up GitLab CI/CD from scratch, and did the detailed design of the interfaces between stages; (2) the Sentinel SAR search/analysis backend (sar-data-retrieval, NestJS) plus a separate repo that handles the actual InSAR analysis (lumir-linux-snap, a 5-tool stack); and (3) a four-domain internal back office (Lumir-ERP — CMS · resource scheduling · hiring · interview management), full-stack.
My side projects aren't just hobbies — they loop back into work both ways. I built 'him' (home-inventory-manager) 100% AI-native and validated a full-stack e2e testing pattern there; that pattern is now being adopted, in reverse, to strengthen the company frontend. I also run 'Brain Trinity', a personal knowledge system where AI compiles a wiki — and this very resume and portfolio are outputs of that system.
- •100% AI-native — AI writes the code; the human is the node that owns planning, design, and review. I aim for a 'system-designer' mode where one person keeps several workstreams running at once.
- •Research-domain understanding + adaptability — ground/crustal displacement is my master's field (crustal deformation · GNSS), so I can judge the methodology; the new processing tools (SAR, InSAR, MintPy, SNAPHU) I learned with AI as a thinking partner to produce real results.
- •Full-stack · owns the whole cycle — I've taken full cycles end to end: planning · frontend · backend · infra · testing · CI/CD. For example, I delivered a CMS solo full-stack and stood up GitLab CI/CD from scratch.
- •Systems & infra operation — I run the InSAR processing platform split across multiple servers (processing · DB · PSI nodes), and set up RAID5+NFS storage, Uptime-Kuma fleet monitoring, and systemd-based auto-eviction myself. I own incidents and performance too — recovered a PostgreSQL killed by a full disk, cut a response payload from 81 MB to 1.1 MB. Next: Kubernetes (CKA).
If you're looking for
Need an infra engineer who operates servers, storage, and CI/CD — and owns incidents and performance end to end?
Do you need someone who can analyze observational / experimental data and build the systems on top of it?
Do you need a full-stack engineer who treats AI as a collaborator, not just a tool?
Looking for someone who owns one full cycle — code, planning, infra, and testing?
Education
M.S., Geospatial Information Engineering
Feb 2023Thesis: "A crustal-deformation model for southeastern Korea" (GNSS-based) — the very phenomenon satellite InSAR measures.
B.S., Civil Engineering
Feb 2021Experience
Lumir
Nov 2023 – presentA full-stack role running the Sentinel-1 SAR pipeline and the internal back office in parallel. My primary role is web development; the SAR domain is a role expansion absorbed after joining.
Lumir SAR Data Platform (3-layer integration)
There was no integrated service that handled Sentinel and LumirX data from search → storage → analysis → request as one cycle. I'm solo-bundling all three layers — storage (NAS + CDSE), InSAR analysis (SNAP · ISCE2 · MintPy), and the user-facing frontend.
- ▸Storage layer (sar-data-retrieval) — solo NestJS monorepo + CDSE external API integration + NAS PoC (SMB2 vs direct FS) + SLC domain modeling + DDD 5-layer test separation.
- ▸Analysis layer (lumir-linux-snap) — 5-tool stack (SNAP 12 + SNAPHU + MintPy + StaMPS PSI + ISCE2) + multi-Claude-Code agent worktrees (agents 1–4 in parallel) + stack extended from 1.12 yr to 2.30 yr + AI-native automation of program reports v1–v4.
- ▸Frontend layer (sar-search-and-analyzer) — Next.js + Plan/Current environment split + map-based AOI polygons + catalog search + InSAR-request UI (frontend-only — the backend is the separate sar-data-retrieval repo).
- ▸Anti-over-engineering as the working principle, AI as a thinking partner for every tool-evaluation decision, 100% AI-native.
- ▸Introducing ISCE2 unlocked the processing speed needed to bring weather- and season-independent surface-displacement data as a service within reach.
- ▸Verified Mt. Sirubong absolute subsidence of −17.30 mm/yr against GNSS (SUWN), detected 5,143,119 PSI scatterers, applied 5 m DEM terrain correction.
- ▸The core asset: a single person owns the full-stack flow that turns a user's location pick into either an instant cached result or a freshly-processed one.
※ Some patterns in each layer came from elsewhere — the Plan/Current split (team lead) and parts of the SAR domain knowledge (AI as a thinking partner).
SDPE — SAR processing pipeline orchestration
We needed a system that lets operators safely configure, run, trace, and recover the LumirX L0–L3 SAR pipeline. I was dropped into the SAR processing domain blank-slate.
- ▸On top of an inherited NestJS 5-subsystem monorepo, designed and built the DAG-pipeline planning UI (no Figma — the UI code plus Playwright e2e is the planning document).
- ▸Built the GitLab CI/CD pipeline from zero — server install, custom mail notifications, runner setup.
- ▸Detailed design for interfaces/csc-8 (csc-7/9 to follow).
- ▸Fed the 80–100-page ICD/SAD docx directly into AI and ran a tight loop of small 'does this break the rule?' reviews — a consistency mechanism.
- ▸Wired up an auto-redeploy hook for the ops console (Next.js) that fires on work completion.
- ▸Despite a blank-slate role expansion, produced detailed design and implementation on top of my senior's base design.
- ▸Settled the architecture into a shape where, once the planning is done, a new satellite (Sentinel) or algorithm (Snappy) costs near-zero time to add.
※ pgmq, the apps structure, natives/csc, and the ICD/SAD were the senior's inherited design. I owned the DAG UI, CI/CD, csc-8 detail, and applying the ICD/SAD learning mechanism.
Lumir-ERP — 4-domain internal back office
We needed full-stack delivery across four internal back-office domains (resource scheduling · CMS · LRIM hiring · LRIM interview management); the user pool spanned every employee plus external applicants.
- ▸Resource scheduling / calendar / schedule-status — all frontend functionality.
- ▸CMS — solo full-stack (planning · backend · tests). Frontend tests are currently being improved.
- ▸LRIM hiring (apps/lrim) — all frontend functionality.
- ▸LRIM interview management (apps/lrim-interview-management) — applicants pick and submit interview slots. All frontend.
- ▸Applied the Plan (mock) / Current (real API) environment split + domain-Context pattern consistently across all four workstreams.
- ▸A 4-domain back office running in production for every employee, recruiters, interviewers, evaluators, and external applicants.
- ▸The asset isn't 'four projects' — it's adapting to four domains simultaneously and the solo full-cycle CMS experience.
※ The Plan/Current split and domain-context patterns like WikiContext are the team lead's frontend architecture. I applied them consistently across the four workstreams.
Side Projects
him (home-inventory-manager)
Real household-inventory pain points (where did it go · expirations · stock · re-order alerts) plus a personal motive — prove I can solo every layer: UI planning, frontend, backend, infra.
- ▸NestJS + CQRS + TypeORM + PostgreSQL + a separate frontend + Docker Compose + S3 + Terraform IaC + backup metrics piped to Grafana.
- ▸Lifted work-validated architecture patterns directly — the starting point of bidirectional transfer.
- ▸100% AI-native — AI writes code; the human nodes are only UI planning, code-connection review, and the e2e test suite.
- ▸Building self-hosted infra to achieve DB-level user isolation.
- ▸13+ wiki assets fed back (the 2-stage design process, 5-layer testing, 31 consistency-gap repairs, automated backup metrics).
- ▸Back-transfer to work: the him UI + current e2e test pattern is being adopted to strengthen the company frontend — shifting from manual click-through verification to automated tests.
- ▸100%-AI-native insight: when humans write code, review is sporadic; AI-native + human review is frequent and periodic → more stable, more refined. It applies not just to entities but to frontend, infra, planning, and UI alike.
Brain Trinity — AI-collaboration wiki compile system
To keep the biological brain on the important work, 'important but doesn't need to live in working memory' content has to live in an external system. Plain note apps are searchable but don't synthesize, link, or re-use.
- ▸Karpathy LLM Wiki pattern, 3 layers (immutable raw/ + AI-compiled wiki/ + derived Output/).
- ▸Claude Code as the only collaborator — no other AI tools.
- ▸Skill system — ingest / lint / query defined.
- ▸Frontmatter schema + auto-updating index/log + Obsidian graph + auto-syncing MEMORY.
- ▸100% AI-written — the user's input is just the prompt chat.
- ▸56+ wiki pages and counting; every ingest triggers automatic cross-linking, raw-frontmatter sync, and index/log updates.
- ▸This portfolio, the resume, the self-diagnosis, and the 6 project briefs are all Brain Trinity compile outputs — the system itself is the living evidence of stage-4 automatic operation.
- ▸Given a new domain, structured information + an AI-native foundation can solve almost anything.
Tech Stack
About
Brain Trinity is the meta system that produced this portfolio and the project briefs. I can demo it live in an interview.
- →Plan to grow Brain Trinity into a complete personal system (voice + journal + meeting notes + PDFs unified)