Changuk Woo
Web developer expanding into SAR · a full-stack engineer who treats AI as a thinking partner while widening the role boundary and building systems alongside it.
Summary
I run frontend + backend + infra/CI-CD end-to-end as one full-stack engineer, absorbing the SAR / satellite domain I first met at Lumir as a role expansion and applying it back. All code work runs on an AI-native pattern; the human nodes are UI planning, code-connection review, and e2e testing.
At work I run three workstreams in parallel: the LumirX SAR-pipeline (SDPE) DAG UI, GitLab CI/CD build-out and interface-detail design; the Sentinel SAR search/analysis NestJS backend (sar-data-retrieval) + its sister InSAR processing repo (lumir-linux-snap, 5-tool stack); and a four-domain internal back office (Lumir-ERP — CMS · resource scheduling · LRIM · interview management) full-stack.
On the side I run him (home-inventory-manager) 100% AI-native; the full-stack e2e test pattern validated there is now being back-transferred into the company frontend. I also run Brain Trinity, a meta wiki system (Karpathy LLM Wiki + Claude Code + skill system) that compiled this very resume and portfolio.
- •100% AI-native — AI writes the code; the human is the planning, design, and review node. I aim for the system-designer mode where multiple workstreams run in parallel.
- •Domain adaptability — I enter out-of-role areas like SAR, InSAR, MintPy, and SNAPHU with AI as a thinking partner and produce results. I expect the same mechanism to work for embedded and robotics.
- •Full-stack + full cycle — I've owned full cycles spanning planning · frontend · backend · infra · testing · CI/CD. Concrete examples include solo full-stack CMS delivery and standing up GitLab CI/CD from zero.
If you're looking for
Are you launching into a new industry that demands fast domain absorption?
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?
Experience
Lumir
Dec 2023 – present (2 yrs 5 mos)A 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 + the CLAUDE.md 4-layer backend design (written by me, back-transferring the him pattern).
- ▸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.
- ▸The 4-layer + CQRS + Korean-method-name pattern validated in him is back-transferred into the sar-search-and-analyzer backend design — the second instance of the stage-5 side-project authority bypass.
※ 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). The sar-search-and-analyzer backend (apps/api · worker · crawler) is still at the CLAUDE.md design-document stage; actual implementation is the next phase.
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 — naturally extending into embedded, hardware, and robotics.
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.
- →Currently extending into embedded systems
- →Expecting a natural extension into hardware and robotics
- →Plan to grow Brain Trinity into a complete personal system (voice + journal + meeting notes + PDFs unified)