# Jaeyong Bae — Design Engineer / Product Designer Everything on https://jaeyongbae.com, as text. Generated 2026-10-09. English first, then the Korean pages. Numbers on this site carry their kind: measured, simulation, output (scale), or design value. Anything unverified says so. Failures are kept, not edited out. --- # English ## Profile - Name: Jaeyong Bae - Title: Design Engineer / Product Designer - Design Engineer based in Seoul. I design, build, and ship digital products. - I'm a design engineer based in Seoul. I work from UX and design systems through frontend, data and AI, and I stay with the product after launch to learn from how it actually gets used. - Location: Seoul, Korea · Email: jaeyongbae11@gmail.com · https://jaeyongbae.com - github: https://github.com/exclusiveyon-a11y - linkedin: https://www.linkedin.com/in/jaeyong-bae-1795992b7 ## How the work is made - Design (Figma): Research, information architecture, interaction and design systems. - Build (Claude Code): Frontend and prototypes, written myself, paired with AI. - Ship (Cloudflare): Deployment, the instrumentation that follows it, and running the thing. - Measure (GA4 · Clarity): Behaviour data and validation decide what stays and what goes. ## Experience ### Reevl — Founder & Design Engineer (2026.04–Present) - Designed, built and launched a property-intelligence product solo, covering 45,695 apartment complexes across 255 Korean districts - Built the product end to end across research, information architecture, design system, frontend, data pipelines and operations; launched publicly in Jul 2026 - Published a read-only MCP server for AI tools and removed or constrained forecasts that failed walk-forward validation rather than presenting unsupported precision - Grew the live product past 7,000 monthly active users (GA4 30-day active users, measured 2026-10-09) ### Hongik University — Undergraduate Student Researcher (2026.08–Present) - UX/UI researcher on an industry–academia project designing the teleoperation HMI for an underground-parking patrol robot - Led screen design for the base-layout track: 20 final screens and 30 components on a fixed 1920×1080 control-room display - Defined the information hierarchy around camera awareness, vehicle state, warnings and licence-plate recognition workflows; merged two parallel design tracks into one 220-token system and bound 431 hard-coded colours back to tokens - Worked from literature, industry cases, technical meetings, stakeholder feedback and usability testing; preparing a second validation round using eye-tracking, with partner technical details confidential ### Republic of Korea Air Force — Brand Designer, HQ Media Content Division (2023.10–2025.06) - Designed official social content, event materials and physical goods for a 60,000-person organisation and a YouTube channel with 100M+ cumulative views - Designed F-4 Phantom retirement goods and co-planned "Finding the Phantom," which reached 400K views; the division received the 2024 Air Force group award - Used Midjourney, ElevenLabs and Sora in official production, presenting generated variants side by side so non-design stakeholders could decide on visible evidence ## Education - Hongik University, BA, Visual Communication Design (2021.03–2027.02) - Merz Akademie, Exchange, Visuelle Kommunikation (2025.09–2026.02) - Hyundai High School, (2018.03–2021.02) ## Skills - Design: Product Design, UX Research, Interaction Design, Design Systems, Prototyping - Engineering (AI-assisted): TypeScript, React, Next.js, Tailwind, SwiftUI, Arduino - AI / Data: AI Product Design, AI-assisted Development, n8n, Data Pipelines, GA4 - Visual: Figma, Photoshop, Illustrator, InDesign, After Effects ## Awards - Air Force Honour (division group award), Air Force (2024) ## Activities - HYUNDAI MOTOR GROUP UX Studio Seoul, Research Crew — infotainment usability research (2026.03) ## Languages - Korean – native - English – professional — TOEFL iBT 93 · TOEIC Speaking IH (2024.10) - German – elementary — exchange at Merz Akademie (2026.02) ## Certificates - Google Analytics Certification (GA4) — ID 179338498 (2026.04) ## Global experience - Germany — exchange at Merz Akademie, Stuttgart (2025.09 – 2026.02) - United Kingdom (2010.01 – 2012.12) - Spain (2009.07 – 2010.01) ## Projects ### Reevl — Real Estate Intelligence Platform https://jaeyongbae.com/en/work/reevl/ Period: 2026.04 – Present · Role: Founder & Design Engineer · Team: 1 person live: https://reevl.co.kr · press: https://uibowl.io/website/%EB%A6%AC%EB%B8%94 · github: · figma: A real estate intelligence platform I designed, built, launched, and operate alone. ## Summary ## Overview Reevl is a real estate terminal for Korean apartments. It treats apartment complexes like listed stocks – each with a price chart, a change rate, and a value – so the market state is readable at a glance. I started it in April 2026 and launched it in July 2026. Everything from design to operations is mine. Live: [reevl.co.kr](https://reevl.co.kr) ## Problem Existing services help you find a complex. Reevl lets you compare the state of the market. Someone deciding whether to buy, sell or wait does not need the price of one complex. They need to know where that price sits in the market right now. Whether it is rising or falling, how it compares with the district next door, which way the jeonse ratio and the transaction volume are moving – a decision needs all of that read together. The existing way ended at finding the complex. Search and filters take you to it, and out come the price and the listings. Where that number sits in the market was left for the user to work out. The index, the change rate and the regional ranking lived on other screens and in other services. So the index, the change rate and the regional ranking come before any single price. A complex is not the destination of a search; it is one holding inside a market. This problem statement was my assumption, not the result of user interviews. The validation came after launch: behaviour data and what users pointed out told me which assumptions held and which did not. ## Key decisions Five decisions set the product's direction: what was decided, why, and what came of it.
- **Up is red, down is blue, on every screen** – it follows the convention Korean market users already read by; green never means "up". Direction colours exist only as design-system tokens (up · down). - **One screen, three shells** – the same information appears as a docked panel on desktop, a full screen on phones, and standalone pages for search. That one structure produces 64,817 public pages. - **A missing value is "not applicable", not zero** – Jeju and Ulleung have no motorways, and filling their 1,047 complexes with zero would read as poor transport. Indicators whose sign flipped when the validation window moved were dropped for the same reason. Station access is the baseline, with motorways and airports added on top. - **Advancement rates came out of the school score** – the published rates did not separate anything, and scoring them would have ranked schools. Private-academy density from NEIS took their place. Having the data was not a reason to use it. - **Natural-language search was built without an LLM** – the search bar and the AI canvas share one parser (nlsearch.ts), so "Seocho-gu, near Line 2, under ₩2 billion" becomes a screener condition directly. That avoided the cost, the latency and the uncertainty at once.
## Process ### Research Reevl's research came less from interviews than from **operating data and what users pointed out**. After launch, the signals that arrived every day became the reasons for the next decision. - **366 commits started from a user's remark** – 16% of all commits (output). One-line reports like "the hover effect gets cut off" (its cause changed three times) or "going back drops me on the apartment list" each became a fix. - **Behaviour data** – 89% of visits came from Naver and 79% of devices were mobile (measured in Clarity, as of 2026-09-06). Those two numbers set the priorities: mobile first, Naver search first. - **Eight data sources** – MOLIT transactions, K-apt, the Korea Real Estate Board, KOSIS, the Bank of Korea, V-World, SchoolInfo, and Cheongyak Home: 255 districts, 45,695 apartment complexes and 11 million transactions brought into one screen's language (output). The source data was researched too. Busan's API had been retired, Seoul's open portal had stopped, the national statistics service only offered city-level totals, and just nine agencies published standard data. So some data is refreshed by hand rather than automated – and **the screen says plainly when data is out of date**. ### Design #### Information architecture Three layout shells carry the same screens: a docked panel on desktop, a full-screen view on phones, and standalone routes for search engines. #### Design system The Figma library was rebuilt from production code: the shipped system is the source of truth for the tokens, and how closely it is followed is measured on every build. ### Build More than 2,000 commits – scale, not an achievement (output). Most of them were written with AI (Claude Code), the way I take a design into code myself. #### Build log Selected milestones out of those commits. Each one is a decision that shipped. #### Activity #### Dock identity bug sweep A dock could be opened from more than the table – also from the heatmap, comparison view, search, and deep links. The type-detection logic didn't match all of those paths, causing seven identity bugs. Sweeping for the whole class fixed all seven at once. The code comments showed the same class had already been noted twice.
Next.js, TypeScript, and Tailwind on the front, with TradingView Lightweight Charts for time series. Behind it, a Python data engine. Hosting runs on Cloudflare Workers with D1 and R2, migrated from Vercel on July 25. All 45,000 complex detail pages were being server-rendered on every request, so they were moved to static generation – with the way back left in place. Accessibility work spans 35 commits: ARIA on tooltips, a focus trap for dialogs, sr-only labels, and a version picker for legal documents built on a native select to keep it accessible. Eleven build gates run on every build, including design-system adoption (ds_scan) and a 432 KB first-screen JavaScript budget; failing one blocks the deploy. A rule is added only after an incident. Adding every theoretically bad pattern would pile up warnings, and piled-up warnings get ignored. The same data is also exposed as a public [MCP server](https://github.com/exclusiveyon-a11y/reevl-mcp) so AI tools can query Korean apartment data directly. The MCP server was also listed on the official registry, and the same data was opened through the ChatGPT app directory and the Claude Code plugin marketplace. The channels were later consolidated back down to just the MCP server.
## Results What changed the product most was not a new feature but a release that failed. The numbers below are measured in GA4 and Microsoft Clarity.
The condition bar not attaching to the header and floating mid-page had two causes: opacity and header height. A fixed complex-name column didn't cover the full row, so the column behind it showed through. Rows left ghosting after scrolling past because a blurred child element was missing bar-blur. On narrow screens the complex name disappeared while the badge and range overlapped. A JSX comment written without braces rendered as literal text on screen. The pre-sale type table showed zero rows because of a missing status field and an upcoming-complex filter.
### Scale The data covers eight public sources, 255 districts and 11 million recorded transactions (output). Reevl is featured on [uibowl](https://uibowl.io/website/%EB%A6%AC%EB%B8%94), a Korean UI/UX reference platform. ### Traffic sources Measured in GA4 and Clarity, as of September 6, 2026. The assumption that "Korean real estate search happens on Naver" held up in numbers.
GA4 channels: Organic Search 1,199 · Direct 656 · Organic Social 82 · Unassigned 66 · AI Assistant 42 · Referral 16. The sitemap lists 65,501 URLs. There was also an incident where Google's crawl dropped from 29,514 to 22 requests a day (the cause: detail pages not rendered on the server); after the fix, Google visibility is still recovering. Search Console data showed an average ranking of 2–5, peaking at 1.2 (August 24, 3 clicks). Impressions were 66 and clicks 4 – few pages were indexed, but the ranking itself wasn't low. Growing the sitemap from 41,600 to 65,501 URLs came with a bill: Worker CPU jumped from a usual 2–5M ms to 13.5M ms, and 831 5xx responses appeared. One SEO tool's crawler alone spent 10 million ms of CPU over 9 hours 20 minutes without contributing to any index; robots.txt and a WAF rule stopped it. AI crawlers were slowed down, not blocked. Over 23 hours GPTBot made 34,856 requests (28%) and ClaudeBot 25,161 (21%) – far more than Googlebot's 480 – but a crawl-delay instead of a block kept the chance of being cited by AI. The 42 visits from AI assistants came from that.
## Where a person steps in The operation runs by itself; what needs judgement comes to a person. - **By itself** – transaction refreshes, publishing and error watching run as n8n workflows. Not a window to open every morning, but something that speaks up when it should. - **By hand** – data from unreliable sources is refreshed manually, and the screen carries the **date it is good for**. Saying when something is from beats showing it as if it were current. - **A cap** – outgoing messages are capped at 50 a day. A channel that pings 50 times a day gets muted, and a muted channel is the same as none. ## Reflection ### What held up - **Extracting Figma back from the code.** The values designers see never drifted from the values users get, and how well it is followed is measured on every build: colour 98.5% · type 100% · z-layers 95.2% (measured by ds_scan). - **Mobile first, Naver first.** 89% of visits came from Naver and 79% of devices were mobile (Clarity, as of September 6). The priority set before launch was the right one. - **Deleting numbers that can't be validated.** Complex-level forecast prices beyond two years are gone; what remains on screen is the region level that passed walk-forward validation. A screen that isn't wrong still beats a screen that looks precise. ### What failed - **I assumed a screen that passed review was fine.** August 27 contradicted that. Each of the twelve features was right; the screen they shared was wrong. - **I didn't doubt a good validation score first.** Future information had leaked into the label calculation and doubled the IC. Fixed with FEATURE_LAG=2. Of five model upgrades measured afterwards, four were rejected. - **I trusted the pipeline's green light.** The orchestrator node failed while the workflow still finished as a success. Naver blog publishing had been stopped for six weeks, and 11,891 server errors were reported as zero. Since then what is watched is the **output**, not the success log, across twenty automated operational checks. - **I didn't count the cost of more search visibility.** More public pages meant crawlers, and crawlers meant an infrastructure bill. Now the first question is whether a metric actually matters to the product. ### What I would test next - **A 19.6% quick-back rate.** I still don't know where those sessions break (Clarity, as of September 6). - **Google visibility.** Still recovering, even after the detail-page rendering fix. - **Collaboration.** Built alone, the product shows nothing about whether the same judgement holds in a team. ### Next – ON THE WAY Site visits start only when you arrive, yet the neighbourhoods and roads you pass on the way are already part of the area. Splitting a visit into nine steps showed that half of its 14.3 hours went to travel and sorting notes. So my graduation exhibition, "REEVL: ON THE WAY", turns the drive into exploration: Reevl's transaction and indicator data, redesigned for the car, attaches prices to the places you pass, and asking a question changes the route rather than returning an answer. Before drawing a screen, I checked whether it could ship at all. The review of the AAOS-based Pleos Connect constraints is written up separately in [Reevl: ON THE WAY](/en/work/pleos/). --- ### SAI — An AI colleague that does the work first https://jaeyongbae.com/en/work/sai/ Period: 2026.09 · Role: UX · design system · frontend · Team: 3 people An AI colleague that does the work a meeting needs before anyone asks – it transcribes the room live, reads the context, and researches, compares and calculates, so people can keep talking and pick what to keep. In a team of three I did the UX, the design system and the frontend. ## Summary ## Overview The model proposes. A person accepts. Only then does it become work. SAI listens to the meeting, offers the work it needs before anyone asks, and runs only what someone accepted. Only the result reaches the notes. **It was built by a team of three.** Jaeyong Seong, Jaeyong Bae and Seungbin Oh; I did the UX flow, the design system and the frontend. It was built for the 2026 Wanted AI Championship. Four stages run while the room talks. Speech is transcribed live. The conversation and the shared material are read to work out what is needed now. Web research and arithmetic run, and the answer comes back with its evidence. A follow-up, "and if the budget were 600,000 won?", is linked to the earlier discussion and recalculated. People check an offer at a glance and accept it by hand, without stopping the conversation. They join one meeting from their own laptops and phones in the same room, with a single device listening.
- **Transcription** – Amazon Transcribe, writing down speech as it happens. - **Judgement** – Claude, reading the conversation and the shared material to pick what is needed now. - **Research** – Amazon Nova, searching the web and returning sources with the answer. - **Calculation** – code execution, so numbers are computed rather than guessed by a model. - **Frontend** – Next.js, React, TypeScript, Tailwind CSS; the same meeting room on desktop and mobile.
## Problem - **Looking something up stops the conversation.** Checking one number or comparing two options means someone turns to a screen, and the meeting waits. - **Using an AI means explaining the meeting again.** To ask a chatbot you first summarise what has been said, and writing that summary stops the meeting a second time. ## Key decisions
- **One accent: blue.** Mid-meeting, the screen gets a glance. Kinds and states differ only in grey value, and only what needs pressing now is blue. There is no red. - **Everything happening now, in one island.** Recording state and alerts scattered over the screen pull people out of the conversation. One capsule at the bottom holds the recording state and every alert, and a blocked action shows its reason and a button to fix it.
## Process ### Design system - **Eight principles** – space instead of lines, one blue, AI as light, material waits, say what's unknown, lines only when they carry information, never clip a shadow, official logos as they are. - **Tokens** – primitive → semantic → component. A 4px grid and only two shadows. - **Components** – suggestion cards (offered, working, done, dismissed), three kinds of material card (evidence, calculation, proposal) whose fill shows confidence, the meeting island, a consent gate, QR sharing. - **Live style guide** – `/design-system` inside the app shows the tokens and principles as they run. ### Verification The system was checked by tests, not by eye. - **Tests** – 32 Playwright tests on desktop (1440×900) and mobile; any console error fails a test. axe checks WCAG 2.1 AA. - **Contrast** – colours the check failed (secondary text 4.49, white on the accent 3.88) were fixed to 5.05 and 4.77 (measured). - **Shortcuts while typing Korean** – handled by key code, so they work mid-composition. ### Development Development ran through Codex, from requirements to implementation, tests and code review. ## Results It ran on live models, a real browser and a database. All four stages held together as one flow: transcription, judgement, research and calculation, then the offer. Quotes were compared, a budget change was recalculated from a spoken follow-up, and the chosen items were saved to the notes. ## Where a person steps in - **The AI offers first** – what it heard that might be useful comes out as a card. An offer is only an offer; it never becomes a note by itself. - **Only what is accepted stays** – a card someone takes becomes part of the notes. The meeting is never interrupted, and the decision stays with the room. - **Always with its evidence** – each card carries the utterance it came from, and confidence shows as the card's fill. What it doesn't know, it says it doesn't know. ## Reflection ### What held up - **Nothing reaches the notes before someone accepts it.** The demo ran research and recalculation several times, and the notes still held only what a person had chosen. - **The screen while the AI works is the product.** If people can't see what the model is doing, the wait is just a frozen screen. ### What failed - **I built everything first and cut later.** After the whole thing was built, close to 9,000 lines came out across 90 files (output). Deciding what was essential first would have saved those lines. - **I judged contrast by eye.** Secondary text at 4.49 and white on the accent at 3.88 looked fine on screen. Both were below WCAG AA, and they were only fixed after the check caught them. ### What I would test next - **The two-offer limit.** It is a design value. No one has counted how many offers a real meeting can hold. - **The acceptance rate.** Which offers get accepted and which get ignored is not measured yet. Without that number there is no basis for changing when an offer appears. --- ### Feasix AI — Teleoperation HMI for a patrol robot https://jaeyongbae.com/en/work/feasix-ai/ Period: 2026.06 – Present · Role: UX/UI Designer – screen design · design system · Team: 4 researchers · two design teams in parallel An industry–academia study designing the remote-control screen for an underground-parking patrol robot – 20 screens, 30 components and 220 design tokens in one system. ## Summary The partner's technical details stay private: recognition performance figures, internal names, hardware and network constraints, and schedules. What's here is the structure I designed and why. ## Overview I designed the screen an operator uses to drive a patrol robot through an underground car park. The operator sits in a control room and drives with a gamepad and a PC monitor, watching several camera feeds, driving state, warnings and licence-plate recognition for hours at a time. The screen is a fixed 1920×1080 with a single dark theme for a dark room. The formal study title translates as "Foundational design for improving the remote-driving UX/UI of a Vision AI mobile robot". It runs in two phases: phase one (Jun–Jul 2026) set out the problems and the design criteria; in phase two (Aug–Oct 2026) a base-layout team and a wide-layout team designed in parallel and then merged. I lead screen design for the base-layout track in phase two. There are two dates. I joined the project in June 2026, at the start of phase one; my formal appointment as an Undergraduate Student Researcher at Hongik University began in August 2026. The first date is when I joined the work, the second is when the appointment started. ## Problem Phase one recorded three UX issues. 1. **The camera views had no clear roles or priority.** Front, rear and auxiliary cameras sat at similar weight, so the eye kept travelling between them. 2. **Driving information and warnings had weak visual hierarchy.** Figures watched continuously, like speed and distance, were not separated from warnings that demand attention at once. 3. **Plate-recognition results didn't lead to the next action.** The result is shown, but the next move – reshoot, check by hand – is not. Phase one concluded that the current interface increases the operator's cognitive load and decision burden. That conclusion came from the literature and from screen analysis. It is not a measurement. ## Key decisions
- **The card's title became the plate number, not the status word** – in a plate-recognition panel, the cards were titled "Unregistered" and "Unrecognised" while the number itself was nowhere on screen. The title is now the recognised number, with status demoted to a tag on the right. A failed read says "Plate not recognised". - **The alert log's hierarchy was inverted** – the timestamp was the largest thing and what happened was the smallest. Now: message 16px, detail 12px, time 12px right-aligned, and an absolute time (02:14) became a relative one (3 minutes ago). An operator needs "what happened" before "at what time". - **One way in for each function** – settings lived in both a large window and the right panel; the alert log lived in both a popup and the panel. Settings are now one window, the alert log one popup in the top bar. Two entry points make the user decide which one every time. - **Popovers grow out of the button that opened them** – windows opened below the alert bar, so you couldn't tell which button they came from. A window's top now aligns to the button's top (y=20) and centres on the button, keeping the same icon in its header. Only irreversible actions – reconnecting, handing over control – open a centred modal. - **What survives being collapsed** – three options were compared: a 56px rail, hiding it entirely, and a pill floating over the video. Hiding it entirely wins 96px of video and loses "how many are queued right now". The rail won: collapsed, it still shows whether recognition is on and how many unregistered vehicles are pending.
## Process ### Research - **Narrowed to remote driving** – the macro journey is onboarding → preparing → remote driving and monitoring → ending. The main control tasks and UX issues concentrated in remote driving, so that stretch became the critical journey. It was split into three tasks – driving and situational awareness, plate checks, connectivity and exceptions – each broken into a five-step micro journey, tabulating the activity, the information needed, the operator's judgement, the current problem and the implication. - **Three insights from the journey analysis** – operators spend more attention watching several screens at once than on driving the vehicle. Making the current state clear matters more than presenting the result itself. When connectivity fails, operators check whether the vehicle is safe and still controllable before they look for the cause. - **Three design criteria** – camera hierarchy and expanded driving field of view; grouping information by task purpose; support for unrecognised and emergency situations. Set in phase one from eight prior studies and four industry cases, they became the standard for all of phase two's screen design. - **A quick phase-one usability test** – about ten people, with an RC car, several cameras, OBS Studio and the Figma UI combined. The vehicle was kept out of sight so it had to be driven from the screen alone. Four things were checked: field of view, sense of control over the vehicle, task feedback and emergency handling. - **Development constraints taken before design** – a technical meeting with the developer established what was buildable before screens were drawn, so constraints were inputs rather than obstacles found afterwards. Six items of stakeholder feedback were tracked one by one to completion.
The literature and cases behind each design criterion: - **01 Camera hierarchy and a wider driving view** – Gnatzig (2013), Tener & Lanir (2022), Wolf (2025), and Hyundai–Kia's SVM. Gnatzig proposes presenting driving state through a fused sensor display rather than a single feed. SVM is a production case that merges four cameras into one view with distortion correction, viewpoint transformation and compositing. - **02 Grouping information by task purpose** – Wolf (2025), Kettwich (2021). - **03 Support for unrecognised and emergency situations** – Tener & Lanir (2025), Parasuraman (2017), Fernride. Parasuraman shows network state as a colour band around the video. In Tener & Lanir (2022), 14 expert interviews name the missing sensory feedback of being physically separated from the vehicle as a main difficulty of teleoperation. The four industry cases: Vay (commercial teledriving, where the operator drives on screen and sound alone), Hyundai–Kia SVM, Ottopia (a multi-screen teleoperation console) and Fernride (network bonding and prediction, stopping and calling for help on edge cases).
### Design - **Six areas** – top navigation, status, camera view, driving and control bar, map, plate-recognition panel. - **State by colour only** – on and off differ only in colour; a button's position never changes. - **Three alert levels** – general (toast), urgent (red gradients at the top and bottom edges), and log. - **Fewer states** – the right panel went from eight states to four. The camera layout rearranges itself when reversing, and ultrasonic distance shows in millimetres, turning yellow at 800mm and red at 180mm. Both thresholds are design values. ### Design system Two teams designed in parallel, and their output was merged into one token system. The other team's design language was kept; only its structure was rebuilt into our system. 431 hard-coded colours were bound to tokens.
Tokens are split into primitive 139 · semantic 44 · spacing 15 · radius 6 · text 16; adding amber and blue ramps took primitives from 128 to 139. The semantic layer had been four empty shells, all of them white. It was rebuilt as 44 tokens that reference primitives. The layers exist for the cost of change – change a value in one place and every screen follows. 431 hard-coded colours were bound to tokens. An audit script then reported zero direct primitive references, zero unstyled text and zero clipped text; the 274 items left unbound are listed as deliberate exceptions. Moving everything at once by script caused damage of its own. 11 lost screens and 20 labels were restored and 50 clipped text layers re-measured. Edits to a master sometimes didn't reach the screens: the top bar's eight variants carried instance overrides, so the change had to be applied directly in 32 places. Now overrides are checked before a master is touched. Where a hidden node had dropped out of the tree and could not be edited, the node was deleted and recreated in the master so its id changed and the override broke. All of these numbers are the scale of the output.
## Results Six phase-one concepts became 20 final screens. The final deliverables: 20 screens, 30 components, 220 design tokens. Merging the two teams' parallel work absorbed 431 hard-coded colours into this token system. Both layouts – base and wide, each in light and dark – were handed to the developer on September 2, 2026. The numbers on this page are of two kinds. Sizes and coordinates were measured in the delivered Figma file; counts of screens, components, tokens and colours are the scale of the output. There are no user-outcome figures yet. Cognitive load and error rates have not been measured, so this page does not claim to have reduced cognitive load. Eye-tracking is in progress, and this page will be updated when it produces results. ## Where a person steps in - **What the AI does** – the plate-recognition AI classifies each vehicle as registered, unregistered, uncertain or unrecognised and shows the result on screen. - **What the person does** – the operator makes the final call on what the recognition returned. When recognition fails, the operator drives the robot back to that spot and reshoots. Design criterion 03 (support for unrecognised and emergency situations) put a reshoot control on screen, and connectivity faults and emergencies are flagged immediately with a toast so a person can judge right away. ## Reflection ### What held up - **Development constraints are inputs before design, not obstacles after it.** The technical meeting settled what was buildable before any screen was drawn. - **On a screen under constant watch, coordinates must not depend on state.** For someone pressing buttons by remembered position, the position matters before the information. Across eight state combinations, nothing moves. - **Colour is allocated by frequency × need to act.** Strong colour on common events buries the ones that matter. - **Merging is translation, not copying.** The other team's design language stayed; only the structure moved into our system. - **An exception screen starts with safety, not diagnosis.** The journey analysis showed operators check whether the vehicle is controllable before they look for the cause, so the first line on screen answers that. ### What failed - **I assumed that showing state well would carry the next action with it.** It didn't. The plate panel showed status words and not the plate number. Presenting a result and telling someone what to do next are different jobs. - **I assumed a bulk change was finished once the script ran.** Instance overrides and clipped text appeared in quantity. 11 screens and 20 labels had to be restored and 50 clipped text layers re-measured. Errors made by automation are only caught by automation. - **I assumed more layout combinations would make comparison easier.** The more there were, the harder it became to see what had changed. It came back to changing one thing at a time. ### What I would test next - Cognitive load and error rates. Eye-tracking is in progress; the numbers go on this page when it produces results. - Which layout – base or wide – is actually better to drive with. A second round of user research will answer it. - Whether giving up 36px of video height to keep the alert bar always present was the right trade. Which one operators would choose is still unknown. - Whether the collapsed rail keeps enough. Showing only recognition state and the count of unregistered vehicles has not been tested. --- ### Glide — Motion-sickness relief for autonomous rides https://jaeyongbae.com/en/work/glide/ Period: 2026.04 – 2026.06 · Role: Product · UX · prototyping (solo) · Team: Solo A motion-sickness relief system for autonomous cars that warns riders 2–7 seconds before the car moves so their bodies can brace – with one sickness metric implemented identically on a sensor board, a web console and an iOS app. ## Summary ## Overview Warning first is the whole product. Glide does not soothe the rider after the car sways. It speaks 2–7 seconds before, so the body gets ready first. The warning alone is not enough. Riders in an autonomous car don't look ahead. They watch, work and sit facing each other. For someone not looking at a screen, a screen is not a channel. So the system predicts the motion first, then picks the sense the rider can actually perceive at that moment. Those two steps are the whole structure. The product splits into four layers: L0 route intelligence, L1 cabin control, L2 sensory cues, L3 wearables. L1 needs vehicle-control access, which is the hardest to get organisationally. So the product was split to let L0 and L2, which need no access, stand on their own first. The web console has its own page – [Glide Console](/en/work/glide-saas/) ## Problem - **Cause** – a clash between vision and the vestibular sense. Autonomy adds time not looking ahead, other activities and facing seats. Facing seats measurably increase sickness (MDPI, 2025). - **Scale** – research reports 6–10% of autonomous-vehicle riders regularly experiencing moderate to severe sickness (Sivak & Schoettle), and up to a third of Americans getting car-sick (NIH · Mcity). - **The paradox** – avoid multitasking and the sickness goes away; so does the whole point of autonomy. ## Key decisions
**Silence** – “silence = trust” became a written principle. On steady straight stretches there are zero alerts. A system that always talks gets switched off. **Thirteen steps** – intervention is proportional to severity, from a button that is always present (D0), through a suggestion and acting-then-saying-so, to stopping and setting off again (D12). Every step carries an undo. The recovery protocol is a separate three steps: past a sickness figure of 10 the display dims and the seat reclines (design value, 38°); past 18 the car looks for a safe place to pull over. **Warning distance** – max(40 m, speed × warning time × sensitivity). **The sickness metric (MSDV)** – acceleration is squared and accumulated over time, then turned into a 0–100 Glide Score, with state boundaries at 4 · 10 · 18 (design values). The sensor board, the web console and the iOS app all use that one formula, so what the board measures and what the app shows read in the same language. **Two scores with one name** – the route score is a prediction before the ride; the drive score accumulates during it. Same name, different formula. **Still a proposal** – weighting sickness against time as a cost function, and letting the user pick a point on the slider instead of the system picking an optimum, is a design proposal. It is not implemented.
## Process ### Research - **The metric** – three ways of measuring sickness (MSDV, MISC, FMS) were compared, and **MSDV**, rooted in an international standard (ISO 2631-1), was chosen: a standard metric lets the work speak the same language as everyone else's. - **Competitors** – Apple Vehicle Motion Cues, ClearMotion, Bosch, Toyota and Holoride were compared. The conclusion wasn't "nobody does this" but **"nobody connects it"**: none joins measuring, predicting, warning and explaining in one flow. Prior art here is dense, so none of this is called original technology. - **Validation** – self-reports alone weren't enough. Four axes were tracked together: physical (IMU-based MSDV), physiological (heart rate, head posture), subjective (MISC, FMS) and behavioural (head-down and hand-to-mouth gestures, detected by CV). An effect only counts when all four axes agree. All four are built, but the sample is too small for statistical significance yet. - **Data** – Tmap routes and POIs, OSM/Overpass and Seoul TOPIS are actually wired in. ### Design - **Five principles** – warning is the golden time · silence = trust · speak only at thresholds · a priority order of senses · never blame the rider ("We've got you"). - **Haptics** – a 225 ms on, 100 ms off, 225 ms on pattern, tuned on real rides, with a different strength curve per direction. The vibration flows top to bottom on a curve for one reason: to get the head tilting into the turn. Passive sway becomes an active posture. - **Screens** – five in-car display states, six Dynamic Island states, three widgets and two live activities, and 50+ alert messages (output). - **What the hardware forces on the UX** – an overhead monitor makes riders lift their chin, which can cause sickness rather than relieve it. That screen got the lowest information density of any. ### Prototype Three parts run on one sickness metric. The board measures the real motion, the console watches it and tunes, the app tells the rider. The board and the app are not directly connected; they go through the web. - **Sensor board** – an Arduino with two MPU6050s (one for the car, one for the head) and left/right vibration motors, sampling at 50 Hz and calibrating on 200 samples at start. - **Web console** – the sickness metric on a map, and an experiment tool for replaying scenarios by hand. - **iOS app** – SwiftUI, CoreMotion, AirPods head-motion and haptics. The build passes. It isn't on TestFlight yet: the privacy manifest and permissions are done, and what remains is a paid developer account and signing. The failures are written down too. The board's motion sensors wouldn't show up on the I2C bus, which blocked live measurement, so the iPhone's CoreMotion became the fallback path. Without the board, mock sensor data reproduces the same screens, so the demo runs even in the worst conditions. The sampling rates disagreed as well: GPS updates at 1 Hz, the IMU at 50 Hz. Rather than force them into sync, the roles were split: GPS owns when to warn, the IMU owns how strongly.
**Board** – Arduino, two MPU6050s, a MAX30102 heart-rate sensor, left/right vibration motors. 50 Hz sampling, 200-sample calibration at start. Heart rate is measured on the research board only; the consumer iOS app uses no health data. **In-car display** – Waveshare ESP32-S3-Touch-AMOLED-1.32, a 466×466 overhead monitor, LVGL V8. **Wearable mock-ups** – a parametric model in OpenSCAD, surfaced in Fusion 360, sliced in Bambu Studio. The earpiece drives a vibration motor against the mastoid bone (21×30×3 mm); how open-ear headphones sit on the ear was studied first. The vision band puts two LRAs at the temples under separate control. The ear-hook curve kept breaking until it was rebuilt as a chain of hull() operations. Looking at how a real product is worn would have been faster than modelling from scratch. **iOS** – CMHeadphoneMotionManager reads AirPods head posture, AVAudioEnvironmentNode places the sound in space. TrueDepth video is never stored.
#### Activity ### Research console The warning and the silence had to be tested before the algorithm existed. So the first thing built was an experiment tool where a person sets the timing and the intensity by hand while the rider sees what looks like an automatic system. That console, where sensors, simulation, audio, haptics and vision are tuned on one screen, has its own page – [Glide Console](/en/work/glide-saas/) ## Results The same stretch was driven with Glide on and off, and the accumulated MSDV curves compared. The tool that ran the comparison is the simulation engine in the [research console](/en/work/glide-saas/). All three numbers come from my own simulation, not an in-car controlled trial, and the sample is too small for statistical significance. After finding an unsourced "40% less sickness" figure, every number now carries a tag: measured, simulated, design value or cited. ## Where a person steps in - **By itself** – the sickness figure (MSDV) is measured continuously and spoken before it crosses the line. - **By hand** – intervention is proportional to severity: from a light suggestion, through acting and then saying so, to stopping the car, across thirteen steps. Every step carries an undo. The trade between time and comfort is always the passenger's to make. - **Silence is designed too** – below the threshold it says nothing. A system that always talks gets switched off. ## Reflection ### What held up - **One metric, implemented the same way in three places.** What the board measured, the curve the console drew and the score the app showed all read in the same language. With three formulas, the first argument would have been about which value to trust. - **Putting the warning at the centre.** Detection and mitigation are crowded. Changing the rider's posture through advance warning is the part this product can defend. - **Building the demo for the worst conditions.** When the sensors died, the mock path kept the demo alive. ### What failed - **I trusted the spec over the body.** Warning times of 1.5 / 2 / 3 seconds were fine on paper and late on a real ride. The thing to protect was the experience, not the number. - **I assumed the board and the app would talk directly.** The motion sensors never appeared on the I2C bus. The board still goes through the web. - **I read UX inconsistency as a screen problem.** It was usually an information-architecture problem. Vehicle settings scattered across several screens became one shared component. - **I thought the consumer ride-hailing app could come first.** The direction changed to an SDK for carmakers plus a companion app that works in any car. A consumer app is tied to one region and the SDK isn't, and the operations tool built for experiments was already the screen a customer would use. ### What I would test next - **An in-car controlled trial.** Every effect number here is simulated. The same stretch has to run A/B in a real vehicle. - **Whether the four axes agree.** All four are built. The sample is not there yet. - **The TestFlight release.** What remains is a paid developer account and signing. - **Direct Bluetooth and a personalised model.** Whether warning times should differ per person is still unknown. --- ### Kankan — A subway car crowding mini-app https://jaeyongbae.com/en/work/kankan/ Period: 2026.05 – 2026.09 · Role: Strategy · design · build · operations (solo) · Team: Solo live: https://kankan-eta.vercel.app When every route app shows the fastest way, Kankan shows the car where you can sit. A Toss mini-app I planned, designed, built, got through review and run on my own. ## Summary ## Overview The route is already known. The missing decision is which car to board. Map apps stop at the fastest route, so the car with a seat is picked on instinct every time. It started with my own commute. Kankan is a mini-app that runs inside Toss (Apps in Toss). I planned, designed, built, submitted and operate it on my own, and it passed review and shipped. Live: [kankan-eta.vercel.app](https://kankan-eta.vercel.app) ## Problem The problem fits in one sentence. **Which car do I board to get a seat?** - **Finding a seat is guesswork** – daily riders rely on instinct to decide where to stand. - **Map apps don't look at cars** – Naver and Kakao Maps show the shortest or best route, not crowding by car. - **Who it's for** – commuters and students who want a seat but have no information, and stand again today. ## Key decisions ## Process ### Designing within constraints I mapped the platform, infrastructure and API limits early, and let each one shape a design or build decision. - **Apps in Toss policy** – no pop-up on entry, no pushing users to outside apps, no blocking the back action. The back button was removed in favour of the native gesture. The app passed review once those conditions were met. - **WebView** – built to the Apps in Toss SDK and web framework guide, entirely inside a WebView with no native code. - **Free API limits** – crowding doesn't change much, so it is collected in batches and cached in Supabase, keeping live calls within the 1,000-a-day limit. Running cost stays at zero. ### Design Toss Design System (TDS) components are used as they are, so the app feels native inside Toss.
- **SearchBar** – station search. - **Badge** – crowding, colour-coded. - **CTAButton** – "Recommend a car", the one action. - **NavigationBar** – logo and centred title.
### Data
- **Crowding and alighting ratio by car** – Puzzle API (Geovision SK), in 30-minute steps, lines 1–8. Collected in batches, cached in Supabase and read by hour. - **Quick-transfer car numbers** – Ministry of Land CSV and the Seoul Metro API. Cross-checked, 77 errors fixed, 456 records bundled as static data. - **Maintenance** – a batch script refreshes crowding in Supabase; when station data changes, quick-transfer data is re-checked and replaced. API usage is watched in Vercel logs.
## Results Shipping is the result. It passed review and runs inside Toss. Usage is not measured yet. ## Where a person steps in - **By itself** – public data is cross-checked between two sources and baked into a cache. - **By hand** – the 77 places where the two disagreed were checked and corrected by a person, and where the live API is unreliable, 456 verified records ship as static data so the app never shows a wrong number in real time. ## Reflection ### What held up - **The same data becomes a different service in a different context.** The crowding data already existed; fitted to the moment before boarding, it became something else. - **Choosing not to ship a wrong value.** Verified records won over fresh ones. Coverage stops at lines 1–8, but no wrong car number reaches the screen. - **Removing the cost was a design decision too.** To keep a solo-built service open for long, it had to run at zero. ### What failed - **I assumed two public sources would agree.** They disagreed on 77 records. Trusting one of them would have shipped wrong car numbers. - **I assumed live values were always better.** The live quick-transfer data did not match reality. Being right came before being current. ### What I would test next - **Whether the recommendation was right.** There is no way yet to tell whether people got a seat in the car Kankan suggested. - **Crowding is a 30-minute time-slot figure.** How far it drifts from a given day's reality is unknown. - **More lines** – whether the same data quality exists beyond lines 1–8. Line 9 and the metropolitan express lines (GTX) are next. - **Alerts** – whether a push before departure beats deciding in the seconds before boarding is still unknown. --- ### GLIO — One manuscript, from print PDF to braille https://jaeyongbae.com/en/work/glio-works/ Period: 2026.07 – Present · Role: Solo founder – strategy · design · build · Team: Solo An AI publishing-production tool that turns one manuscript into Korean-typeset print PDF, EPUB3, large print, accessible PDF and braille – with its own Korean typesetting engine, a macOS app and an MCP server, built solo. ## Summary ## Overview One manuscript goes in; print PDF, EPUB3, large print, an accessible PDF and braille come out. It is built in four parts. - **Engine** – Python and FastAPI; HarfBuzz shaping, its own line breaking, Korean typesetting rules as data. - **Studio** – a single-file web UI with no dependencies. - **macOS app** – SwiftUI, calling the engine as a local process instead of over HTTP, so manuscripts and fonts stay on the machine. - **MCP server** – exposes tools to AI clients for analysing artwork, creating specs, preflight, proof rendering, quotes and order requests. It never executes payment; it returns an approval link. Nothing has shipped yet. Accessibility remediation goes out first; typesetting follows. ## Problem Making one book means print typesetting, EPUB, large print and braille each re-interpret the manuscript separately, and proofing repeats each time. Korean typesetting has no standard implementation like Japanese JIS X 4051. Accessible formats are now an obligation: the European Accessibility Act (June 2025) and Korea's Digital Inclusion Act (January 2026) are in force. ## Key decisions
- **People pick a role, not coordinates** – per-paragraph overrides lead to the "one heading in forty looks different" accident. Users choose a block's role only; millimetres and positions are the engine's job. - **When unsure, body text – fail toward the less harmful** – a wrongly structured manuscript makes every format wrong together. Import reads the author's Word styles first, then layout heuristics, and only then, optionally, an LLM. Anything uncertain stays body text.
## Process ### Tested against a real book – the MMCA Guide to Publication The benchmark is a real book made by designers. The National Museum of Modern and Contemporary Art, Korea's *Guide to Publication*, 2nd edition (2020), exists both as its manuscript (docx) and as the printed book, so the same manuscript can be run through GLIO and set beside the real thing. Over 15–16 August, this one book produced 114 result files as the engine was fixed. - **Trim size matched** – the first run came out at 161×256mm; iterations brought it to the real book's 125×220mm. - **Page count differs** – 300 pages in the real book, 263 from GLIO. The same text set tighter; matching the book's leading and margins is the next step. - **Typefaces differ** – the book uses commercial faces (Janson, AG Choijeongho, Akzidenz); GLIO uses OFL faces licensed for servers (EB Garamond, Noto Serif KR).
Five books whose manuscript and printed edition both survive went in, and each ran until the output came close to the printed thing. Between the evening of 14 August and midnight on the 16th, 483 result PDFs piled up. Every run produced three tracks at once: print, spread and reading path. | Publication | Manuscript | Result files (output) | Printed (measured) | GLIO (measured) | First result → last (measured) | |---|---|---|---|---|---| | MMCA Guide to Publication, 1st ed. (2018) | docx | 144 | 300pp | 265pp | 220 → 265pp | | MMCA Guide to Publication, 2nd ed. (2020) | docx | 114 | 300pp | 263pp | 219 → 263pp | | MMCA Collection Description Guide (2023) | docx | 111 | 88pp | 61pp | 36 → 61pp | | This is Hanseongbu (exhibition catalogue) | docx + plate list xlsx | 59 | 176pp | 288pp | 289 → 288pp | | SeMA Collection Description Guide | docx + plate list xlsx | 55 | 52pp | 60pp | 47 → 60pp | A page count that grew is not a failure. The first results were dropping footnotes and plate positions altogether. Across the runs, 87 footnotes, 207 plate markers and the glossary copy found their places, and the pages grew with them. All five are pages taken straight out of the final PDFs GLIO produced. Nothing was edited or redrawn. In *This is Hanseongbu*, Korean, English and Japanese sit on one spread. #### What broke Every manuscript broke the engine somewhere. The order in which they were fixed is the record. - **Korean vanished silently from RTF** – no error, just missing characters. The encoding path was rebuilt. - **A PDF manuscript sent it into an endless load** – it now reads page by page, with a browser regression test attached. - **A whole HWP manuscript became headings** – the outline paragraph style was unreadable, so body text was promoted to chapter titles. - **The first chapter title became the book title** – in the MMCA manuscript, "Part 1: On Art Publishing" was printed on the cover, the half title and the colophon, and the author was Word's "Un-named". The manuscript head is now separated from the body, and what it says beats the file's properties. - **Adding plates killed the grid settings** – full re-typesetting was replaced by partial updates. - **A slow preview broke the loop** – it was made 11× faster (measured) and told to say when it is working. #### Not run yet Three art-magazine manuscripts and the Forbes material were left out. A magazine flows differently from a book: columns change within one page, and pictures wrap the text. The engine cannot place that yet. Every page count above was counted by hand from the printed PDF and from GLIO's output – measured, not estimated. The printed books use commercial typefaces and a designer's page; GLIO uses OFL fonts and its defaults. What was tested is whether the same manuscript yields the same structure, not whether the design matches. The two page counts can't be read as better and worse.
## Results On the accessibility checks, passes went from 5 of 9 PDF/UA items to 7, measured on the same file before and after auto-fix. The two that remain are alt text, which a person writes. Typesetting is 1.76× faster, with none of the same manuscript's 20,413 lines changed. Nothing has shipped. Everything so far was validated on manuscripts I chose myself, not on a customer's book. ## Where a person steps in - **By itself** – one manuscript becomes print PDF, EPUB3, large print, an accessible PDF and braille. Typesetting is checked by rules before any eye sees it. - **By hand** – what rules cannot catch – a picture's description, the reading order of a table, how a name is written – an editor fixes. The tool carries the draft as far as it can and leaves the judgement. ## Reflection ### What held up - **The AI decides; code draws.** After the rewrite that made typesetting 1.76× faster, 0 of the output's 20,413 lines had changed. The test that stops the engine from importing the LLM module is what kept that line. - **Licensing is design too.** No AGPL or GPL libraries, OFL fonts only. A good tool you can't distribute is a tool you can't use. - **Choosing accessibility as the first product.** Pass and fail are written down, so every run pointed at the next thing to fix. Typesetting quality is not judged that way. ### What failed - **I assumed that matching trim size and structure would bring the page close to the real book.** The trim size matched; the page count stayed 300 against 263. Density turned out to be a separate problem. - **I assumed one engine would cover plate-heavy catalogues too.** *This is Hanseongbu* is 176 printed pages against GLIO's 288. A book where text flows and a book where plates hold positions follow different rules. - **I trusted the Word file's properties.** The author came out as "Un-named" and a part title became the book title. Now what the manuscript says beats the file. - **I assumed reading a manuscript's formatting would reveal its structure.** In an HWP manuscript, all the body text was promoted to chapter titles. The rule "when unsure, body text" comes from that run. ### What I would test next - Whether leading and margins can match the real book's density. The same manuscript still sets tighter. - Plate-heavy catalogues, and magazine manuscripts – columns changing within a page, pictures wrapping text. - How far a designer can actually carry the IDML export inside InDesign. - A real customer's book. All five test books were ones I picked. --- ### Commit — Startup grants × an anonymous builder community https://jaeyongbae.com/en/work/commit/ Period: 2026.06 – 2026.07 · Role: Founder – product · design · full-stack · operations · Team: Solo live: https://commit.ai.kr A mobile-first web app that gathers scattered government startup grants into one feed, with an anonymous builder community on top – built and shipped solo in 28 days, leaving the grant amount blank wherever the data could not support it. ## Summary ## Overview Turning public data into product information is half of Commit. The grant API returns raw text with 1,722 different ways of writing an agency's name. A crawler collects it daily, normalises it in seven steps, and the product shows only the cleaned result. On top of that, a grant is treated as **a post written by the agency's account**. The grant list and the community feed share one skeleton, and an agency's page is drawn with the same component as a person's profile. Finding a grant, getting an idea tested anonymously and recording the work continue along one timeline. It's a mobile-first PWA – installed to the home screen, it opens like a native app. Live: [commit.ai.kr](https://commit.ai.kr) ## Problem Even finding grants is hard. - **Scattered sources** – 1,722 different ways of writing agency names in the production database. - **Messy originals** – duplicated agency names, broken "?" characters, and prefixes like "(re-posted)(extended)". - **No amounts** – the grant API has no funding amount; it lives only in a separate programme API. - **Wrong order** – the collected list arrives by posting date. The only hard deadline a grant has is its closing date. - **Nothing after finding** – half-formed ideas are hard to post in a real-name community. ## Key decisions ## Process ### Research K-Startup, Bizinfo, contest sites, startup media, Disquiet, Indie Hackers and Product Hunt, and Notion went into one comparison table. The conclusion wasn't "nobody does this" but **"nobody connects it"**: there are places that collect grants, places that write startup news and places to share building in public – none that links the three. Looking at the data itself mattered too: the founding-period and age fields often listed "every possible range", so tagging them as-is put every tag on every grant. ### Design "Toss's information hierarchy + Threads' timeline." Blue means action, green means alive, and no arbitrary values. - **Tokens** – a 7-step type scale (11 / 12 / 13 / 15 / 17 / 20 / 24), buttons at 36 / 44 / 48, radii 8 / 12 / 16 / full, 15 colour tokens × light and dark, one typeface (Pretendard) at −0.02em. All design values. - **Action colour and link colour split** – after changing the accent blue, blue links inside body text became hard to read, so the button colour and the in-text link colour were separated. - **Three responsive layouts** – under 768px / 768px+ / 1280px+, with a 640px centre column and a 360px right rail. Mobile tap targets grew from 36px to 44px. The six shared primitives were extracted after the screens were built. 27 scattered alert() calls became one toast(), and a single global skeleton became 15 route-specific ones. A design system made first is a guess; made after, it's an observation. ### Build
A Python crawler collects grants daily and cleans them in seven steps. Titles pass five regex stages: strip the duplicated agency name, drop broken encoding, unwrap the leading bracket cluster, normalise whitespace, group editions of the same grant. The same rules were applied retroactively to past data. Notifications are deduplicated by a unique key, every run writes a heartbeat, and an alert fires if nothing has been collected for 36 hours. It runs on GitHub Actions at no extra cost. Only the multi-page backfill runs on a personal Mac through launchd – if the Mac is off, that job doesn't run.
Supabase (PostgreSQL): 24 tables and 12 views and RPCs. Search is built in three layers: typo-tolerant trigram search → pgvector semantic search (with the built-in gte-small embedding model) → autocomplete and personal weighting. Above that sit similar grants by embedding distance, past editions by title series, and similar agencies by the centroid of an agency's grant embeddings. Three cards on the grant page were cluttered, so they became one. If an RPC fails, client-side results take over. The limits are written down too: there are no LLM calls – grant summaries and eligibility checks are rule-based. With a paid external API, cost alone would have kept search out of the product.
The commit_logs table carries a CHECK constraint: a row can't be inserted unless at least one of figma_url, github_commit_hash, image_url or link_url is set. is_verified is a GENERATED column – true automatically once a Figma or GitHub link exists. The rule that proof has to come from doing, not saying, is enforced at the database level.
Agency logos follow the same rule as amounts. A favicon service returned blank icons as "success", so automatic collection wasn't trusted: 116 hand-checked logos, 210 matched by domain, and 17 saved as files where hotlinking was blocked. Prefix matching covers subsidiary bodies. It still falls far short of all 1,722 name variants.
In 28 days, 938 files changed (+27,927 / −6,233 lines); the code is 118 files and 10,536 lines with 47 components – all output counts. Thirteen mistakes were logged: a feed limit that showed only four days of posts, dates off between UTC and Korean time, an ad script loaded only as a preload so ownership verification failed, and a white logo SVG that vanished in the light theme until it became an inline currentColor component.
## Results The product is finished. Whether it's right is still unknown. What didn't work gets stated as plainly as what did. - **14 signups (measured)** – 5 official bot accounts, 9 individuals. Most of the 9 are the founder or people they know. - **33 posts by people vs. 407 bot news posts (measured)** – most of what fills the timeline is bot-posted news. That's the result of deciding to fill an empty feed with startup news. - **₩0 in revenue (measured).** Monthly infrastructure cost is ₩0 too. - **CSP is still Report-Only** – it doesn't block violations, and with no collection endpoint it doesn't even observe them. The hypothesis – that joining grant discovery with building in public reduces drop-off – is still untested. Whether the three-layer search beats plain text search is also unmeasured; there aren't enough users to compare. ## Where a person steps in - **By itself** – a Python crawler gathers grants daily, normalises them in seven steps and records a heartbeat on every run. It says so when nothing has arrived for 36 hours. Posting and reporting carry per-action rate limits. - **By hand** – on money, accuracy beat coverage. Where the rules are not sure, the figure stays empty and the reader is sent to the original (22.1%). Auto-hidden posts are deleted or restored by a person, and the admin tool re-checks permission on every server action, not once at page entry. - **Never handed over** – no model is called at runtime. Amounts and summaries are rule-based. Removing the place where it can be wrong costs less than correcting wrong answers. ## Reflection ### What held up - **Leaving an unknown number blank.** Amount coverage stopped at 22.1%. In exchange, every amount on screen matches the original. In turning public data into product information, the expensive mistake is a wrong value, not a missing one. - **When an external dependency dies, the screen should live.** Search, logos and amount matching all had their failure states designed first. - **Building the design system afterwards.** Extracted after the screens existed, it was an observation rather than a guess. - **Data never collected can't leak.** Choosing anonymity lowered the regulatory cost too, and a delete-account button was on the pre-launch checklist. ### What failed - **I assumed row-level security also controlled columns.** It controls which rows; which columns is a job for grants. Every member's email could have gone through that gap. - **I assumed building the community first would bring people.** People arriving from search wanted grants, so community features came out and grants moved to the centre. - **I assumed a "success" response meant a usable result.** The favicon service returned blank icons as success. After that, logos were checked by hand. - **I read inconsistent UX as a screen problem.** Most of it was an information-structure problem: it only resolved once ownership sat in one place. ### What I would test next - **The integration hypothesis.** Whether one timeline for finding and recording reduces drop-off can first be seen somewhere between 10 and 100 users. - **Whether the search is worth it.** The three-layer search needs an A/B against plain text search. There's no sample for it yet. - **How to raise amount coverage.** Going past 22.1% means adding sources beyond the single one, K-Startup. - **Abuse handling.** Rate limits, auto-hiding and blocking exist but have never met real traffic. - **The debt** – zero tests, a remote database that migrations alone can't reproduce, and a CSP stuck in Report-Only. --- ### FLATTEN — Scattered graduation shows, in one index https://jaeyongbae.com/en/work/flatten/ Period: 2026.08 – Present · Role: Strategy · design · build · Team: Quotely An index for browsing Korean universities' design graduation shows across schools – the first step toward a record that links person, project, programme, institution and year. ## Summary ## Overview This is a content product whose data model and operating structure were designed from the start. Graduation shows come first: they are public, happen every year, have fixed dates and venues, and students want them seen. The screens are a development build on sample data. It isn't publicly deployed yet, the dates aren't real shows, and there are no user numbers or outcomes. ## Problem University project records scatter across school sites, show sites that last a year, Instagram, Behance and PDFs – and on the way, **who made what, in which programme, where and when** is lost. Collecting links doesn't bring that relation back. Recovering it needs a structure that stores the relation in the first place. ## Key decisions
**Designed for zero added cost.** An unvalidated product mustn't close because of its bills. Events are batched and rolled up nightly so the dashboard never scans raw events, and no paid products are used. ₩0 is a design value; the operating figure arrives after launch. **A zoomable poster wall.** Hundreds of shows should be scannable at once without getting slow. It draws at most 900 tiles (a design value) and drops detail as you zoom out, loading images only up close.
## Process ### Data - **Source** – the 2023 department list from the national university information portal, 52,214 rows. - **Design department master** – 786 departments at 217 institutions, pulled out of those 52,214 rows. A department's name alone doesn't say whether it's a design department, so it was checked institution by institution. Ninety departments are prioritised for the first wave (a design value). - **Structure** – 20 tables, built to link people, projects, programmes, institutions and years. An edition hangs off a programme, a programme off a department, a department off an institution. ### Build - **The operations tool came first** – the admin queue was built before the public screens. Collected candidates publish only after a person checks date, venue and cancellation. - **The metadata card is the default form** – designed in type alone so it stands without a poster. A cleared poster sits on top of it. - **Cost was held down structurally** – events are batched and rolled up nightly, and the dashboard reads only the rollup tables. ## Reflection It hasn't launched. Nothing has been validated by use. What follows is what held while building, and what is still open. ### What held up - **Deciding the relations before the screens.** School pages, department pages and year listings became cross-sections of one model rather than separate screens, so widening into works and people won't need a new schema. - **Separating programme from edition.** Linking years is the product's only structural advantage, so that split is the product's reason to exist. - **Making the admin tool the first product.** The judgement that human verification time is the ceiling on coverage still holds. ### What failed - **I planned to use posters as the index's default image.** A poster is someone's work, and rights couldn't be cleared at scale, so the neutral metadata card was rebuilt as the default form. - **I assumed one public dataset would produce the master list.** Department names alone didn't isolate design departments; 217 institutions were checked separately and the first wave narrowed to 90. - **No judgement has been contradicted by use yet.** Everything that changed so far changed during building. ### What I would test next - **Whether the key measure moves** – the share of sessions viewing two or more different schools. The first season's measured value decides whether this continues. - **The real processing time of the admin tool** – how many minutes a person spends verifying and posting one show is unmeasured, and that number is the ceiling on coverage. - **Whether a card without a poster gets clicked** – it's unknown whether the neutral metadata card holds attention on its own. - **The next axis** – whether to widen from graduation shows to works, people, capstones and collaborations depends on the first season's validation. --- ### Gatherly — Samsung Electronics DA industry–academia project https://jaeyongbae.com/en/work/gatherly/ Period: 2026.03 – 2026.06 · Role: Data visualisation · code prototype · UX writing · Team: Team project An industry–academia project with Samsung Electronics' home appliance division. It holds the partner's material, so the work is not published here. Material is available on request. ## Summary ## Overview An industry–academia project with Samsung Electronics' home appliance division (DA). It ran from March to June 2026. It was a team project, and what the team did and what I did are not the same. - **The team** – field research, personas, Figma screens, the final presentation. - **Me** – data visualisation design, the code prototype, the UX writing system. ## Process ### Research The team ran the research together. Only the methods are listed. - **Written interviews with 7 real users** – people who use the product itself. Mar 25–30, 2026. - **In-person interviews across 3 households** – households of three, four and five, visited, each member interviewed separately. Mar 27–29, 2026. - **Diary study with 3 people** – a woman and a man in their twenties, a woman in her forties. Mar 25–28, 2026. - **One expert interview with store observation** – interviewing a sales specialist in a retail store and watching where people look at a screen first. - **Desk research** – trend mapping and a comparison of competing products. ### Prototype I built the comparison tool before choosing a screen, so the evidence wouldn't be assembled after the fact. - **13 visualisation renderers** – the same dataset drawn 13 ways and compared side by side. Six were shortlisted and one became the default. All of it is output from code I wrote. - **The criteria came first** – readable in a glance, magnitude legible without thinking, several values held at once, uncertainty expressible. - **Uncertainty moved into visual properties** – probability as colour temperature, confidence as the stability of an edge. The goal was to stop an uncertain value from looking certain. - **UX writing** – 28 strings rewritten one by one, branched by probability band into roughly 60 variants, with one rule throughout: don't use a confident voice for an uncertain value. The prototype runs on scenario data. There is no trained prediction model. Every number on screen is an example value for designing the screen, and no measured prediction accuracy exists. **What remains private** – the project holds the partner's material, so this page does not publish: the figures and typeface names from Samsung's internal design guidelines, internal screens and screenshots, details of unreleased product, and the partner's internal numbers and judgements. Material is available on request. Write to [jaeyongbae11@gmail.com](mailto:jaeyongbae11@gmail.com). --- ### Distance of Thinking — Flying through a language model's probability field https://jaeyongbae.com/en/work/distance-of-thinking/ Period: 2026.05 – 2026.06 · Role: Concept · interaction · build (solo) · Team: Solo An interactive installation where visitors fly through a language model's real next-token probability field, and the path they fly becomes the model's answer. ## Summary ## Overview Visitors pilot a ship through a tunnel of probabilities the model actually computed, and each word they pass is committed to the answer. A local model replaces a cloud API, so the piece runs in the gallery without internet. All screens and the recording below were made in exhibition mode, from probabilities that local Ollama Llama 3 actually produced. Steering was done with the mouse (in place of the tilt sensor) and temperature with the wheel (in place of the dial). ## Problem The piece treats AI not as a thinking being but as **a system that keeps calculating the probability of the next token**. The condition was to use the values the model really computed rather than drawing probability as a metaphor. Hallucination is **modelled here as convergence on low probability.** That is how the piece works, not a claim about why hallucination happens in real language models. What the piece shows stops at: keep choosing the unlikely branch and watch the sentence come apart. ## Key decisions ## Process ### How it works 1. **Tokens** – the visitor's sentence is split with the real Llama 3 tokenizer. 2. **Meaning space** – each token's 4,096-dimension embedding is projected into 3D, and tokens that land close are joined by lines. 3. **Next-token candidates** – the model is asked for one token at a time, returning its top six candidates and their probabilities. The likeliest sits straight ahead; less likely ones form the outer rings of a tunnel. 4. **Steering** – a tilt sensor (MPU6050) picks a branch and a rotary dial sets temperature, which widens the field on screen and is sent to the model itself. 5. **The sentence coming apart** – straying into unlikely branches raises an instability value and produces misspelled "ghost" words. That is a rule the piece sets, not an output of the model. ### Built for the gallery - **Exhibition mode** – operator UI hides, and after 75 seconds without input an attract loop takes over. - **Warm-up** – a button preloads the models before visitors arrive; if generation fails, a local fallback keeps the visuals running. - **Network** – Web Serial needs a secure page, so instead of a cloud deploy it runs on one HTTPS address on a private network. ## Reflection ### What held up - **It persuades only if what it shows is true.** Choosing real values over imitated ones made the concept and the build say the same thing. - **Choosing a local model.** It gives real probabilities and runs offline in the gallery. A cloud API would have lost both. - **Throwing one input away.** Removing the shake kept the controls aligned with what the piece claims. ### What failed - **I assumed one model could carry both languages.** The model that writes Korean well looped on English, so the model is now picked by language. - **I assumed shaking the sensor was good interaction.** It was fun, but it put the cause in the visitor's hand, which is the opposite of the point. - **I assumed a sensor-driven piece could be deployed to the cloud.** Web Serial requires a secure context, so the whole setup moved to one HTTPS address on a private network. ### What I would test next - **Whether visitors read "probability" at all.** No visit data was collected in the gallery, so there's no measure of whether the piece communicates the idea. - **The physical sculpture wasn't made,** and the Arduino controller was never tested on real hardware. Every flight so far used the mouse as a stand-in. - **Long-run stability** – whether the local model and the serial link hold up over hours of continuous running is untested. --- ### NUN — A seat that meets you at eye level https://jaeyongbae.com/en/work/nun/ Period: 2026.03 – 2026.07 · Role: Concept · UX design · Team: Kia DEX industry–academia A seat that levels the eyes of the people on it – no motors, just the sitter's weight folding an origami structure, carried from a park bench to an autonomous cabin. {/* NUN – Kia DEX industry–academia. The numbers below count outputs; there is no user testing yet. */} ## Summary ## Overview It began with a shared-mobility interior project run with Kia DEX. The goal was to remove three tensions the cabin imposes on people – relational, spatial, bodily. Whether the eye-level axis could actually be built was the question left open. NUN is what came from following that question to the end. It runs from concept to a test of feasibility. Verification stops at simulation and folded paper. No physical mock-up was made and no user testing was run. ## Problem At level 4 and above the role of "driver" disappears, and in shared mobility riding with strangers is the default rather than the exception. Three tensions are then imposed on the rider. - **Relational tension** – eye levels that don't match. - **Spatial tension** – no choice of what to look at. - **Bodily tension** – a body that doesn't fit the space. Who you ride with, your body and your reason for travelling are all decided again on every trip. A fixed interior gives all of them the same state. ## Key decisions ## Process ### Research - **Desk research from papers** – height difference creating hierarchy; adaptive seating raising flexibility while lowering privacy; prospect–refuge theory. Citations stay at author and year. No figures were copied across: the paper behind the enclosure range has no confirmed author or title, so its numbers are not on this page. - **Structural research** – six origami patterns (Kresling, Yoshimura, Miura tube, bellows, waterbomb, Resch) compared on vertical travel, load and manufacturability. Kresling stayed a core candidate: compression couples to twist, and it is bistable.
Three papers were used. A Sarrus self-locking linkage (Kim et al., Science Robotics 2018) combines one-degree-of-freedom linear motion with locking at an orthogonal folding singularity. Dual-morphing origami (Kim et al., Science Robotics 2019) unfolds and then inflates in a quasi-sequential transformation, which is the basis for a wrapping motion. Variable stiffness (Park et al., IEEE RA-L 2023) changes stiffness through facet buckling. One design principle came out of it: one scalar input plus local geometric programming gives distributed, sequential motion with no actuators. Instead of a motor per part, the structure itself carries the signal and the force.
Load bearing · fit to the concept · wrapping · flatness at rest · the choreography of deployment · ease of fabrication · scalability to production · safety while deploying. All eight sat in one table, and the frame-plus-tension-membrane hybrid won. No single concept won on every criterion.
### Design - **Three layers of interface** – choose a state in the app before boarding; adjust with three sliders and three presets in the cabin; then let posture and pressure sensors plus the city's context (entering a tunnel, a riverside stretch, traffic) propose a transition the rider accepts or declines. - **Six scenarios** – mismatched eye levels, a body that doesn't fit, a conversation that matters, a picnic in the city, a space of one's own, shelter on a rainy day. - **Each scenario got its measures before anything else** – subjective (a comfort scale, hierarchy-perception items, intent to ride again), behavioural (number of transitions, acceptance rate, time held), physiological (GSR, HR, HRV). Nothing was measured. The design of the measurement is what exists. ### Development The goal here was to make the digital variables and the physical mechanism point at the same thing. A preset is data, not hardware, and data grows with a software update.
The three axes are software variables: `eyeLevel.offset` (continuous) and `eyeLevel.matchMode` (auto|manual|off); `view.aperture` (0–100) and `view.mode`; `enclosure.ratio` and `enclosure.curl`. The cabin's state is a three-dimensional vector, `{eyeLevel, viewAperture, enclosure}`. All three axes are continuous, so the state space is infinite. Three points in it are meaningful enough to name as presets (intended tension, prospect, refuge). A preset is data, not hardware, so adding one is just a software update.
L0 structure (origami skeleton and locking, hardware), L1 actuation (the weight-driven mechanism, hardware), L2 control (turning the three axes' targets into a trajectory and safety limits, software), L3 experience (presets, scenes and auto-suggestion rules, software, over the air), L4 service (subscriptions, personalisation and partner content, software). The line where hardware ends and software begins was drawn first. `POST /cabin/state` sends target values for the three axes. `POST /cabin/preset` calls up a preset. `GET /cabin/capability` returns which axes and ranges a given vehicle supports. When `POST /cabin/suggest` makes a proposal, the rider's acceptance or refusal is logged as a `cabin.suggestion.accepted` or `.rejected` event, which becomes training data. It is a sketch, not a running server.
### Prototype - **17 physics simulators (output)**, in four strands – a weight-driven seesaw group of 3 (rigid link, rolling rocker, parallelogram), a pure-origami group of 5 (folded apex seesaw, Kresling twist, accordion, back-to-back wave, ground-supported), a pneumatic group of 6, and a mechanism-study group of 3 (lever, accordion, Sarrus linear motion). - **Design → verify → make** – rigid panel chain simulation (PBD), a modified GPU origami simulator, a Python fold-pattern generator, SVG crease-pattern export. - **New ideas were stacked as new files rather than overwriting the old ones** – a discarded concept stays as evidence, because the decision history has to be traceable. ## Results The results are outputs and a validation design. There is no user outcome. - **Level of verification** – simulation and folded paper. No physical mock-up was built and no user testing was run. - **The limit found** – at extreme weight ratios, weight alone cannot level the eyes fully. - **What was not measured** – comfort, perceived hierarchy, released tension. The measures are designed; there are no values. ## Reflection ### What held up - **A good answer came from re-reading a constraint, not adding a feature.** Taking the motor out made the seat's problem look different: the two people who need to meet at eye level are already pressing the structure with different weights. - **Defining the three axes as software variables.** Once a preset became data rather than hardware, adding an experience became an update. - **Proposing instead of acting.** A space that rearranges itself is one more imposition, and the record of acceptance and refusal is material for personalisation. ### What failed - **I assumed better control was the answer.** Motors and tendons did give precise control. But in public, shared settings, power and maintenance break before precision does. - **I assumed weight-driven levelling would work for any pair of bodies.** At extreme weight ratios it doesn't. Pretending to have solved something unsolved throws off everything designed after it. - **I assumed a paper's figure could be used directly as a design parameter.** One of the references has no confirmed author or title, so its number was taken off this page. ### What I would test next - **User validation** – nothing was measured about whether meeting at eye level actually reduces perceived hierarchy. The designed measures need their first run. - **Physical limits** – repeated-use durability, noise and vibration, temperature, crash safety. Getting past simulation needs a build. - **The working range of weight-driven levelling** – how far the weight ratio can go before it fails, measured on a real seat. 0W is a number to confirm on a build too. - **Cost and regulation** – going into a shared vehicle interior means passing production cost and safety regulation. --- ### KTX Passenger Information Display — Before boarding, on the move, after arrival https://jaeyongbae.com/en/work/ktx/ Period: Spring 2026 · Role: Concept · UX design (solo) · Team: Solo live: https://www.behance.net/gallery/245415477/Redesigning-the-KTX-Passenger-Information-Display The screens in a KTX carriage, restructured around the passenger's journey rather than the system's functions. ## Summary The KTX passenger information display adds no information. It reorders it by the moment each piece is needed: before boarding, on the move, after arrival. ## Overview The starting point was a semester abroad in Germany, riding Deutsche Bahn every day. A KTX carriage has to deliver several things in a short time. The existing display was organised by function. Next station, arrival time, transfers, facilities and notices all carried the same weight, so finding the one that mattered took a search. I chose not to add screens. More information costs more looking. The work was deciding what gets read first at each moment. ## The work - **Split by the journey** – before boarding, on the move, after arrival. Each moment keeps only what it needs, and the rest is removed. - **Next station · arrival · which door** – the hierarchy is fixed to those three. Next station and arrival time are sized to read from down the carriage; everything else steps back. At the moment a door opens, only which side stays large. - **A four-language station naming system** – station names follow one rule across Korean, English, Japanese and Chinese (4 languages · output). Body text puts Korean and English in a single layout system, so the two never compete for position. - **Components** – top bar, station list, progress, notice banner and facilities, all under one set of rules (5 components · output). ## Reflection - **Ordering, not adding.** The screen count did not grow. Most of the work was deciding what comes first. - **The trade-off** – making one thing large at a given moment pushes the others later. Transfers and facilities moved to the arrival phase. - **Not validated** – there is no evidence that usability improved. Viewing distance and lighting in a real carriage were never tested, and neither was the design with passengers. So no improvement figure is claimed. --- ### HarikomiMaker — A Mac app that re-seats pages so they can be folded and stitched https://jaeyongbae.com/en/work/harikomi-maker/ Period: 2025.12 · Role: Concept · design · build (solo) · Team: Solo A macOS app that imposes a PDF for saddle stitching, draws the crop and fold marks and exports a print-ready file. It never scales the original – if it doesn't fit, it says so. ## Summary ## Overview In saddle stitching, page 1 and the last page are printed on the same sheet. One macOS app builds that arrangement. This is the prehistory of GLIO: moving a repeated editorial judgement into software started here – [GLIO](/en/work/glio-works/). ## Problem The page count must be a multiple of four, and for the order to come out right after folding, every sheet's front and back needs its own arrangement. I redid that arithmetic for every booklet. By hand it goes wrong, and it goes wrong where you only see it after printing. The app does it instead. ## Key decisions ## Results Sheets exported by the app itself: the original page on the left, and the imposed sheets that fold into order. 757 lines of Swift across 7 files, with zero dependencies (output). There are no usage numbers. I am the only user. ## Reflection - **A tool should be able to refuse.** Stopping and saying why is kinder, in print, than silently making it fit. - **The trade-off** – a refusal hands the work back to the person. Even a small overflow stops the app. Correct format beat fast output. - **Still to do** – a bug that closes the PDF context after the first sheet on longer documents, 4-up layouts, bleed handling. It has never been tested in anyone else's workflow. --- ### Synthetic Vision Fund — An exhibited website about the interfaces that manufacture trust https://jaeyongbae.com/en/work/synthetic-vision-fund/ Period: 2025.11 – 2026.01 · Role: Concept · design · build (solo) · Team: Solo A fictional AI investment platform. By mimicking the familiar motions – reading an article, pressing invest, checking out, receiving a confirmation – it shows how interfaces and terminology manufacture belief. Fictional, and made for an exhibition. This is not a financial service and no money moves. ## Summary ## Overview Synthetic Vision Fund is a fictional AI investment platform. It copies the language, interfaces and flows of contemporary startup and venture capital culture. Reading an article, pressing invest, checking out, receiving a confirmation: every motion is reproduced. The result feels like taking part in a legitimate financial system. It was built and exhibited at Merz Akademie, Stuttgart. ## Problem The target is not AI as a technology. It is how interfaces, terminology and design convention manufacture trust. A familiar order reads as evidence on its own. ## Key decisions ## Reflection ### What held up - **Reproducing instead of explaining.** No critique is written inside the piece. Only someone who walked the procedure sees their own belief. - **Convention, not spectacle, builds trust.** A familiar order and familiar words did most of the persuading. ### What failed - **I assumed brand polish would do the persuading.** It didn't. The order of the checkout steps worked harder than the logo or the generative graphics. - **I underrated the cost of recording nothing.** There is no material at all on how far visitors went. ### What I would test next - **The deliberate 1.5-second delay (design value)** – whether it reads as a signal of legitimacy or just as a slow site. I can't tell the two apart. - **Where doubt begins** – at which checkout a visitor notices something is wrong. - **A record of the exhibition** – since nothing is stored, next time a person has to keep the observation notes. --- ### Glide Console — The web console that watches the sickness metric https://jaeyongbae.com/en/work/glide-saas/ Period: 2026.05 – 2026.06 · Role: Product · UX · Frontend (solo) · Team: Solo Glide's sickness metric, put on a map: a Glide Score for all 25 Seoul districts, the rides running right now and the events as they land – one screen, also used to replay scenarios Wizard-of-Oz style. The research tool for [Glide](/en/work/glide/), built to test the UX before the algorithm existed. ## Summary ## Overview - **Experiment control** – a person picks when to intervene, through which channel, and how strongly. The rider's screen looks exactly like an automatic system. - **District scores** – a weighted average for the whole city, 0–100, higher is safer, with all 25 districts sorted into safe, watch, rough and severe. - **Risk top five** – the lowest-scoring districts, in order. This is the screen you route around. - **Active rides** – current rides split across live, simulation, game and idle. - **Event log** – hard braking, sharp turns, recovery actions and route comparisons, timestamped and tied to a participant code so a session can be replayed later. ## Problem - **Waiting for the algorithm was not an option** – warning times, the threshold for silence and the switch between senses all depend on what a person feels. Those answers were needed before any code could make the call. Having a person reproduce the intervention by hand (Wizard of Oz) tested the UX ahead of the algorithm. - **Why one screen** – validating the sickness model meant sensors, simulation, audio, haptics and vision (camera) being tuned in step. Across five separate tools, one ride cannot be reproduced under the same conditions twice. - **Now** – it started as a research tool. After the pivot, the console became a product asset for B2B customers. ## Key decisions
**Sensors** – with no hardware attached, mock IMU readings take over automatically. The same screen runs without the board. **Simulation** – a drive runs on a canvas, turns are detected from the change in bearing, and warning cues are generated from them. The same stretch can run with Glide on and off for comparison. **Audio** – a 100 Hz sync signal, boosted past a lateral-acceleration threshold, with the Arduino motors firing at the same time. **Vision** – a webcam reads head posture and hand-to-mouth gestures and escalates the recovery step by one. The video is never stored.
## Process ### The map Six layers stack on the map: a sickness heatmap, district polygons, live road speeds, incidents, traffic signals and crosswalks, fed by TOPIS traffic, Tmap roads and OSM/Overpass. ### Data One Supabase project holds seven tables: participants, sessions, events, the sickness time series, haptic firings, vehicle positions and district scores. Every session carries a mode – live, simulation, game or idle – so real drives and simulated ones replay through the same screen. Without the sensor board, faked readings drive the same view. ## Results - **The flagship numbers came from here** – this console's simulation engine (`simDriveEngine.ts`) ran the same stretch with Glide on and off and compared the accumulated MSDV curves. The sickness-metric figure in [Glide](/en/work/glide/)'s results (−77% · simulation) is that comparison. No in-car controlled trial was run. - **Four axes on one screen** – physical (IMU-based MSDV), physiological (heart rate, head posture), subjective (MISC, FMS) and behavioural (gestures read by camera). An effect only counts when all four agree. All four are built, but the sample is too small for statistical significance. - **Deployed** – running on Vercel production. The film on this page was shot after the three fixes below. ## Reflection ### What held up - **Building the tool before the algorithm.** Whether the warning and the silence worked was answered before any code decided it. And the operations screen built for experiments became the product asset a customer would use. - **Making the screen run without the board.** When the hardware dropped out, neither the study nor the demo stopped. - **Keeping the schema in the repo.** After the database disappeared, it went straight back up on a new project. ### What failed - **I thought shipping was the end.** Four months later the screen was empty. Three things had gone wrong at once. - **The database was gone.** A free-tier project that had sat idle was deleted – not unreachable, the hostname itself no longer resolved. - **The map provider changed its terms.** The keyless tiles started arriving stamped "API KEY REQUIRED". Swapped for a provider that needs no key. - **One condition was inverted.** The district panel had always read zero, not because of the data but because of `if (!cancelled || !data) return;` – it bailed out even on a good response. - **I suspected the data before the code.** The cause was one line. Shipping is not the end of a service. When somebody else's free tier or terms change, a working screen goes quietly blank. ### What I would test next - **A larger sample across the four axes.** The axes exist; the participants do not. - **A direct link between the board and the app.** It goes through the web today; direct Bluetooth is untouched. - **Where else this still leans on somebody else's free tier.** --- ### Reevl: ON THE WAY — Pleos feasibility https://jaeyongbae.com/en/work/pleos/ Period: 2026.09 · Role: Feasibility review · screen design (solo) · Team: Solo A study of whether Reevl could ship on Hyundai's Pleos. The constraint came first, and the scope narrowed instead of the screen. The ON THE WAY branch of Reevl. Main project: [Reevl](/en/work/reevl/) ## Summary I looked at whether Reevl could move into a car. The answer was "not as it is." I found the platform constraint first, then narrowed the situation instead of shrinking the screen. The three screens were designed; they have not been built. ## Overview A personal study of Hyundai's Pleos Connect infotainment, done in September 2026. I had hands-on time with the platform in an actual car as part of Hyundai Motor Group UX Studio Seoul's research crew. ## Problem Reevl is a property terminal for the web and the phone. A car would be the eighth surface, and one more assumption breaks here: that a screen means you are allowed to show something on it. ## Key decisions ## Process Feasibility rested on what Reevl already has. Showing nearby complexes from the car's position works with existing assets: 45,000 complex coordinates and a per-district nearby shard of 67KB, so no extra server is needed. Three screens were settled: the viewing mode (parked – three cards for the complexes nearby, with pins on the map), one complex (the headline price large, four cells for jeonse ratio, the one-year AI forecast, transit and school district, plus an AI briefing), and the driving notice. The format is 1920×720 for a 12.3-inch display, in Reevl's dark tokens. All three stopped at the design. Checking the constraint was the point of the study; nothing was built. ## Results --- ### Close to Miracles — Editing the cockpit voice recording of the Hudson River landing https://jaeyongbae.com/en/work/hudson/ Period: 2025.12 – 2026.01 · Role: Editing · typography (solo) · Team: Solo The cockpit voice recorder transcript of US Airways Flight 1549 (2009), set as a 32-page booklet and a 614×861mm poster. Timecodes become folios; channels become columns. ## Summary ## Overview On 15 January 2009, US Airways Flight 1549 lost both engines to a bird strike shortly after take-off and landed on the Hudson River. All 150 passengers and 5 crew got out. The source text is the cockpit voice recorder transcript published by the US National Transportation Safety Board. The sentences stayed as they were; the structure was rebuilt. ## The work - **The timecode is the folio** – from 15:00:32 to 15:30:44, each page is numbered by the moment it holds. Turning a page is time passing. - **The channel is the column** – inside the cockpit (HOT, CAM), radio traffic (RDO, INTR), automatic warnings (GPWS) and cabin announcements (PA) each get their own column, so who spoke to whom is visible before it is read. - **One typeface family** – IBM Plex Mono for the transcript, IBM Plex Sans for titles and notes. Every utterance is set at the same width, so silence and overlapping speech become space. - **The same data as a book and as a poster** – the entire transcript also sits on a single 614×861mm sheet. The book is read in sequence; the poster is seen whole. ## Reflection - **Editing is interpretation.** Without changing a sentence, what becomes a column and what becomes a folio decides how it is understood. - **The trade-off** – the poster shows everything at once but is hard to read in order. The book is the opposite. That is why the same data exists as both. - **Left undone** – a few working markers from the poster's automated typesetting are still in the file; a reprint starts by clearing those. --- ### Hi, High! — Republic of Korea Air Force onboarding kit https://jaeyongbae.com/en/work/airforce-onboarding/ Period: Autumn 2024 · Role: Solo live: https://www.behance.net/gallery/245410791/-Hi-High-On-Boarding-Kit · press: https://kookbang.dema.mil.kr/newsWeb/20231228/1/ATCE_CTGR_0010050000/view.do Hi, High! is an onboarding kit built around cheering new Air Force recruits on toward higher places. The aim was to move away from the usual image of a military institution, create one consistent brand experience, and strengthen members' sense of identity. {/* 2021–2024 visual work, from the printed portfolio "Records & Memories" (기록과 기억). */} ## Summary In-house design work from 21 months at the Air Force HQ Media Content Division (Oct 2023 – Jun 2025). Hi, High! is an onboarding kit for people entering the Air Force. I designed it in autumn 2024 and stayed with it through the bulk order and delivery. The other project from the same posting is [Thank You, Our Dokkaebi](/en/work/airforce-dokkaebi/). ## Overview The posting was the Media Content Division of Air Force Headquarters, the division that makes official communications for an organisation of about 60,000 people. Its YouTube channel, "Republic of Korea Air Force", passed 100 million cumulative views in December 2023 – [Kookbang Ilbo, 27 Dec 2023](https://kookbang.dema.mil.kr/newsWeb/20231228/1/ATCE_CTGR_0010050000/view.do). Its live-fire TAURUS footage has 15.1 million views and "Les Militaribles" 6.62 million. Goods and printed matter had to speak in the same voice. The channel, not the usual image of a military institution, set the standard for the kit. ## The work I did not stamp a logo on stock items. I went to Namdaemun market and to Monami's headquarters to check each material's feel and how it held up in real use. The planner, notebooks, memo cube and bag were designed to work together and on their own. When distribution conditions changed and the full package was about to be cancelled, I switched to distributing single items. Because each piece already had its own use, nothing had to be redesigned. I did not deliver it alone. The bulk order went through suppliers and the distribution through other departments. ## Reflection The design file was not the end. Material, order quantity and distribution route decided half of the result. --- ### Thank You, Our Dokkaebi — Republic of Korea Air Force F-4 retirement goods https://jaeyongbae.com/en/work/airforce-dokkaebi/ Period: Spring 2024 · Role: Solo press: https://www.aeroflap.com.br/en/south-korea-makes-special-flight-to-say-goodbye-to-f-4-phantom/ The F-4 Phantom served 55 years guarding Korean airspace before retiring with honours. The goods made to mark it were given out at the media day, the retirement ceremony and other events – in a friendly, childlike style so every generation could remember it together. {/* 2021–2024 visual work, from the printed portfolio "Records & Memories" (기록과 기억). */} ## Summary In-house design work from 21 months at the Air Force HQ Media Content Division (Oct 2023 – Jun 2025). On the F-4 Phantom retirement task force I designed the commemorative goods and co-planned the retirement content. The other project from the same posting is [Hi, High!](/en/work/airforce-onboarding/). ## Overview The task force was run by the Ministry of National Defense, and I owned the goods. They were the official gift at the media day and the retirement ceremony. Some 220 F-4s had guarded Korean airspace since the mid-1960s. The aircraft closed 55 years of service with a farewell flight in May 2024: four Phantoms and two KF-21 Boramae, South Korea's next fighter, flying three hours over the Gyeonggi, Jeolla and Gyeongsang provinces. The official ceremony followed on 7 June. The flight was reported abroad as well – [Aeroflap, 13 May 2024](https://www.aeroflap.com.br/en/south-korea-makes-special-flight-to-say-goodbye-to-f-4-phantom/). ## The work I redrew the dokkaebi, the Phantom's symbol, rather than the aircraft. A friendly, Korean-painting treatment, so that every generation at the ceremony recognised the same thing. The same drawing ran across the media-day and ceremony goods. "Finding the Phantom", the YouTube content I co-planned, reached 400,000 views – three times the earlier series. For that work the media content division received the Air Force's 2024 "People Who Made the Air Force Shine" group award – a division award, not an individual one. ## Reflection The people approving the work were not designers. So I made the evidence visible. Dozens of AI-generated variants, laid side by side, turned a question of taste into a question of choice. --- ### Comma Project — Redefining rest https://jaeyongbae.com/en/work/comma-project/ Period: Summer 2023 · Role: Team of 3 · web design 100% mine (character illustration excluded) “Stop Doing, notice Being.” The project names the everyday habit of living as if chased by something “Doing” and invites people to pause it. The goal was time spent clearing the mind and focusing only on oneself – Being – which we defined as rest in its essential form. We brought neglected corners of the campus back as places to rest, and made a website that guides people to them. {/* 2021–2024 visual work, from the printed portfolio "Records & Memories" (기록과 기억). */} ## Summary A school brief taken into a real space and a working website. Summer 2023, in a team of three; the web design was mine, the character illustration was not. We brought neglected corners of the campus back as places to rest and built the site that guides people to them. ## Overview We named the habit of living as if chased by something "Doing", and the time spent clearing the mind and attending only to yourself "Being". Being was the rest we designed for. The brief could have ended as a proposal. Instead we cleared the spaces, set our own operating principles and ran them. ## The work The site splits into Our Zone, Map and Archive: introduce the space, help people find it, keep a record. A character graphic on the windows gave the space and the site the same face. A teammate drew the character. ## Reflection Web design that stops at a mock-up and a site that actually runs are different jobs. I checked what could be built first, then redrew the screens. --- ### Focus On Them — Editorial and graphics against prejudice about blindness https://jaeyongbae.com/en/work/focus-on-them/ Period: Winter 2022 · Role: Solo Focus On Them sets out to undo public prejudice and misunderstanding about blind and low-vision people, and to build an attitude of understanding toward the field. {/* 2021–2024 visual work, from the printed portfolio "Records & Memories" (기록과 기억). */} ## Summary Focus On Them is an editorial and graphic project that sets out to undo prejudice and misunderstanding about blind and low-vision people. Made solo, winter 2022. The graphics were built and photographed by hand rather than composited on screen. ## The work A book, a key-visual poster and two graphics, the graphics built on kaleidoscope and light motifs. For the key visual I staged the scene physically and shot it instead of compositing it in Photoshop. ## Reflection Changing the process changed the result. The texture of something made by hand and photographed did not come back from compositing. --- ### Experimental Typography — A typography essay, visual poems and a visual novel https://jaeyongbae.com/en/work/experimental-typography/ Period: Autumn 2022 · Role: Solo · coursework A typography essay, visual poems and a visual novel made as coursework – held together by one tone and manner, and shown in sequence. {/* 2021–2024 visual work, from the printed portfolio "Records & Memories" (기록과 기억). */} ## Summary A typography essay, visual poems and a visual novel, made solo as coursework in autumn 2022. All three run on the same editorial rules. ## The work The rules came first: one format, one grid, one typeface pairing, one hierarchy between heading and body, applied identically across the three pieces. The experiments only break those rules. A spread-by-spread plan controlled the order. It fixed which spread changes size, letterspacing or the direction of a line. ## Reflection Experimenting was not abandoning the rules. A broken arrangement only reads when the basic hierarchy under it holds. --- ### Intellectual Capital — A book redesign https://jaeyongbae.com/en/work/intellectual-capital/ Period: Summer 2022 · Role: Solo · cover and selected spreads Intellectual Capital is Muneaki Masuda's book on his philosophy of business. I redesigned it in a manner and language that fit the ideas running through it – creating customer value, proposing a lifestyle, and the design that makes a proposal convincing. {/* 2021–2024 visual work, from the printed portfolio "Records & Memories" (기록과 기억). */} ## Summary A redesign of Muneaki Masuda's Intellectual Capital. Solo, summer 2022, covering the cover and selected spreads. My first real study in micro-typography. ## The work I read the existing edition element by element first, to work out what the original designer intended. Then I reset the body typeface and size, letterspacing, leading and the position of each chapter opener. The book argues for creating customer value and proposing a lifestyle, so the cover and the spreads had to make that argument in type. ## Reflection A redesign is not a change of taste. I could change only as much of the book as I had read correctly. --- ### The Unseen — Visualising instinct https://jaeyongbae.com/en/work/the-unseen/ Period: Spring 2022 · Role: Solo Two posters in a series that connect vertically. Starting from the root of the Korean word for instinct – “to prick and provoke a reaction” – they visualise how instinct works in the human body. {/* 2021–2024 visual work, from the printed portfolio "Records & Memories" (기록과 기억). */} ## Summary Two posters that reduce instinct to a single visual rule. Solo, spring 2022. The rule comes straight from the root of the Korean word for instinct: to prick and provoke a reaction. ## The work One rule only: a force that pricks, and a body that answers. The two posters stack vertically so the force reads as passing from the upper sheet to the lower one, and the pair reads as one series. ## Reflection Drawing something invisible meant cutting the idea down to one rule. I checked whether the rule persuaded before checking whether the sheet looked good. --- ### Contact; Again — 24th K-Arts Film Department graduation festival https://jaeyongbae.com/en/work/kart-film-festival/ Period: Winter 2021 · Role: Team (volunteer) · programme book 100% mine Design for the graduation film festival that the K-Arts film department holds every year. The trailer read the festival's pandemic-era slogan, “Contact; Again”, through fishing – so the design carried the same idea, with fishing and fish as its motifs. {/* 2021–2024 visual work, from the printed portfolio "Records & Memories" (기록과 기억). */} ## Summary My earliest real distribution and collaboration. Winter 2021, with the K-Arts graduation committee, for the 24th K-Arts Film Department graduation festival. The 64-page programme book was mine. ## Overview The slogan "Contact; Again" came out of the pandemic. The trailer read it through fishing, so the design carried the same idea with fishing and fish as its motifs. This was not coursework but an actual festival. I made the programme book and the venue banners, and the book was handed out to the audience at the screenings. ## The work 64 pages, 169×231mm – film introductions, the schedule and interviews. The printed book, turned page by page. ## Reflection The content of the book was fixed by other teams, so talking across teams mattered more than talking inside the design team. I started without knowing what editorial design was, and ended with printed matter handed out to the public. --- ## Experiments ### Design judgment https://jaeyongbae.com/en/experiments/ai-design-critique/ Six decisions from shipped work where something looked fine and failed in use – what the evidence was, what changed, and what it cost. ## The question A screen can look fine and still be wrong in use. So what tells you it is wrong? The question came back on every project. These six are the evidence that contradicted me, and what I changed because of it. The numbers are the ones on each project's own page. ## 01 – Twelve reviewed features fell over on one screen On 27 August 2026 I shipped twelve features to [Reevl](/en/work/reevl/) in a day. Each had passed review. Within hours bounce went from 24% to 62% and time on site from 226 seconds to 40. Clarity recorded 36 rage clicks – the only day in the observation window with any (measured, GA4 and Clarity). I watched the session replays. The features were not the problem; the screen was. Controls that looked interactive and were not. A filter that reset the view. Density added without a reading order. Six causes, found and fixed. Rage clicks 0 by 29 August, dead clicks 98 → 18. Bounce 29% and dwell 115 seconds by 1 September (measured). - **What it contradicted** – that a screen which passes review is fine. Each of the twelve features was right; the result of putting them on one screen was wrong. - **What changed** – a review answers "does this look good?". So I ship with the instrument that can contradict me switched on. ## 02 – Numbers I could not stand behind, removed Reevl's one-year outlook ranked complexes with an information coefficient of 0.19, positive in 93% of quarters. Beyond two years, the per-complex IC was 0.01. A number that cannot be right. A figure printed in won reads as certainty whatever the caption says. So long-range forecasts show no amount at all. They are given only at the regional level, which held under walk-forward validation (IC 0.16). The validation score fooled me once too. Future information leaked into the label calculation and doubled the IC. Fixed with FEATURE_LAG=2. Of five model upgrades, four were rejected once measured. - **What it contradicted** – that a good validation score can be trusted as it stands. - **What changed** – precision is a visual claim. Where the data cannot carry it, the screen does not make it. ## 03 – An amount I don't know stays blank [Commit](/en/work/commit/) collects grant notices whose API carries no funding amount; the amount lives in a separate business-information API. So an amount shows only where the match is certain: 2,595 of 11,757 notices, 22.1% (output). Filling the gap with a model raises coverage and lowers trust. One wrong amount costs more trust than several right ones return. Where the rules are unsure the figure stays empty and the reader is sent to the original. There are no runtime LLM calls at all; summaries and eligibility checks are rule-based. The same judgment applied to logos. A favicon service returned blank icons as "success", so only 116 hand-checked agency logos are used. - **What it contradicted** – that a success response from automation means the output is right. - **What changed** – a default value is an assertion. If I don't know, the field stays empty. ## 04 – Red is up, blue is down, everywhere Green-for-up is the international habit. Korean market readers read red as rising, so red is correct here. A convention is information, not decoration. Left to whoever builds the next screen, it eventually breaks. So direction colours exist only as design tokens (up · down), and green never means rising anywhere in the product. The tokens were extracted back out of the code into the Figma library: 140 variables, 28 styles, 23 components (v1.0, 2026-09-17, output). Adoption is measured on every build – colour 98.5%, type 100%, z-layers 95.2% (measured by ds_scan). - **What it contradicted** – that consistency holds if you try hard to hold it. - **What changed** – the rule now lives where it cannot be broken. ## 05 – Two colours that looked fine and failed In [SAI](/en/work/sai/), secondary text measured 4.49:1 and white on the accent 3.88:1. Both were below WCAG AA, and both looked fine to me. They became 5.05 and 4.77 (measured). So the eye was replaced by a check: 32 Playwright tests on desktop (1440×900) and mobile, any console error fails the run, axe checks WCAG 2.1 AA (output). - **What it contradicted** – that looking acceptable on a good screen means passing. - **What changed** – where a measurement exists, it decides. The eye is a second opinion. ## 06 – Function-centred to moment-centred The [KTX in-carriage displays](/en/work/ktx/) were organised by function. Next station, arrival time, transfers, facilities and notices all carried the same weight, so a passenger had to search each time. I ranked the content by the moment it belongs to: before boarding, on the move, after arrival. The next station, arrival time and service state are sized to read from across the carriage; everything else steps back. When the doors open, only the side they open on is large. Korean and English share one layout system, and station names follow one rule across four scripts. Nothing was added. Only the order was decided. - **Not verified** – viewing distance and lighting in a real carriage, and testing with passengers. There is no number saying this is easier to use. ## Judging what a model produces I pair-program with a model daily and operate products whose content is partly generated. The same questions apply. - **The system decides, not the generation.** When generated screens stepped outside Reevl's tokens, I changed the tokens, not the screen. - **Don't put a model where it can be wrong.** Commit calls no model at runtime. Not creating the place where it can be wrong was cheaper than correcting wrong answers. - **Generated proposals carry their evidence.** Every SAI suggestion card carries the utterance it came from, and nothing becomes a note until a person accepts it. - **Check the artefact, not the log.** A pipeline of mine reported success for six weeks while blog publishing had stopped, and a broken monitoring filter counted 11,891 server errors as zero. Monitoring now watches what was published. ## The four questions 1. **What is this screen for?** Name the one thing someone came to do, then check whether it is the easiest thing to do. 2. **What is largest?** Size, weight and position are all claims about importance. If everything is the same size, the design has no opinion. 3. **Is colour carrying meaning?** Up and down, normal and delayed – or decoration. 4. **What can be measured?** Contrast, focus order, rage clicks, dwell time, information coefficient. Taste ends where a measurement begins. ## What I can't show yet All six came from products I built. Reevl and Commit are solo; on SAI I owned UX, the design system and the frontend in a team of three. Whether the same judgment holds on someone else's screen, I have no evidence for yet. --- ### Vision-based interfaces https://jaeyongbae.com/en/experiments/vision-interface/ Input from the body rather than the click – what a head tilt, a gaze and a hand can each carry, tested inside real work. ## The question Can the body be the input? And if it can, how much of it should be read – and what should not be read at all? The question came back on three projects: a moving car, a patrol control room, an exhibition floor. In all three the hands are busy or the screen is far away. So a head tilt, a gaze and a hand each took the place of a pointer, and each was pushed until it stopped working. ## Evidence - **A head tilt – [Glide](/en/work/glide/)** – AirPods head-motion sensors and CoreMotion read the passenger's head posture, and a haptic arrives 2–7 seconds before the car sways (design value). On a curve the vibration flows top to bottom, so the rider tilts their head into the turn. The body is read, and the body is what gets spoken to. - **A gaze – [Feasix AI](/en/work/feasix-ai/)** – on the patrol-robot console, gaze is not an input device. It is evidence about the design. The eye-tracking round has not been run yet, and cognitive load and error rates are not measured. So this page does not claim reduced cognitive load. - **A hand – [Distance of Thinking](/en/work/distance-of-thinking/)** – the handle a visitor holds is the control: a tilt sensor (MPU6050) picks a branch of the probability field and a rotary dial sets temperature. No camera, which is why a dark gallery could be the design assumption. The Arduino controller was never tested on real hardware, though: the published recording and screens were steered with a mouse and a scroll wheel. - **The input I dropped – Distance of Thinking** – shaking the sensor to trigger hallucination was removed. It would leave the cause of the hallucination in the visitor's hand, and hallucination had to be the result of an unlikely choice. Taking the body as input did not mean turning every movement into input. ## What holds **Body data has a price.** Glide dropped health-data access and stores no face video. The sickness metric is integrated on the phone with no cloud. Accuracy was the cost. Data never sent is also data never regulated. The lost accuracy is better recovered from vehicle-built-in sensors at production stage. **Gaze works as evidence, not only as input.** Make people press with their eyes and a misread becomes a misclick. On a control-room screen, gaze is safer as the thing that judges the design. **A sensor is sometimes better than a camera.** Use a camera where one tilt reading would do and lighting, privacy and computation come with it. Of Glide's four validation axes, the behavioural one detects head-down and hand-to-mouth gestures with CV – but that axis is for validation, not product input. All four are built; the sample is too small for statistical significance. **The more of the body you read, the more you must explain.** When the system moves first, people ask why. That is why Glide always says what it noticed, and says nothing below the threshold. ## Not verified yet - **Eye tracking** – the Feasix AI round is planned, with no results. - **Real-vehicle test** – Glide's effect figures are all simulation. Whether reading head posture and warning early actually reduces sickness needs a controlled run on the same stretch. - **The controller** – Distance of Thinking's hardware steering still needs a real hardware test. --- ### MPU6050 motion study https://jaeyongbae.com/en/experiments/mpu6050-motion/ Measuring motion sickness as a number with one accelerometer, then turning that number into a buzz the body reads before the eyes do. Glide's hardware came out of this. ## The question Can discomfort be turned into a number? And when the board that produces the number dies, what happens to the product? [Glide](/en/work/glide/)'s hardware came out of this. One Arduino board, asked how much sickness this ride is causing right now, and then asked to tap the wrist before the number crosses the line. The measurement and the buzz pattern set here became the product's hardware. So did the failures. ## Why measure first Motion sickness gets discussed as "uncomfortable", which means no one can check a claim that it improved. A way to measure had to come first. MSDV was chosen after comparing three ways of measuring sickness (MSDV, MISC, FMS). It is rooted in an international standard, ISO 2631-1, so the work can speak the same units as everyone else's. Measuring changes nothing on its own. The number has to reach the body. ## How - **Two sensors** – one MPU6050 on the chassis, one on the head. Sickness comes not from how the car moves but from the difference between the two. - **50 Hz, calibrated on 200 samples** – 200 samples at rest set the baseline, gravity is subtracted, and MSDV is integrated at 50 Hz (design value). - **The buzz** – 225 ms on, 100 ms off, 225 ms on, chosen on real rides. One long buzz startles; two short ones don't read as a warning. - **Left and right** – the motors are split, so a difference in strength says which way the lean is coming from before it arrives. ## What worked and what did not **Worked.** After the resting calibration, even a shake by hand showed in the MSDV curve, and the buzz could be sent about two seconds before the threshold. Those two seconds are where Glide's 2–7 second warning began (design value). **Failed.** The board's two MPU6050s would not appear on the I2C bus together. Days of chasing address conflicts and wiring never got both read at once, and live measurement stopped there. **The sampling rates disagreed too.** GPS updates at 1 Hz, the IMU at 50 Hz. Rather than force them into sync, the roles were split: GPS owns when to warn, the IMU owns how strongly. **So there is a second path.** The same formula was rebuilt on the iPhone with CoreMotion, and mock sensor data reproduces the same screens with no board at all. On the day the sensors died, that path kept the demo alive. ## The rules that stayed **Choose the unit first.** A standard metric can be implemented the same way in several places. In Glide the sensor board, the web console and the iOS app all use one MSDV formula, so what the board measures and what the app shows read in the same language. **Build the demo for the worst conditions.** Without a fallback, one piece of hardware decides the presentation. **A failed wire becomes product structure.** The I2C failure is why the board and the app still do not talk directly; they go through the web. These figures come from a desk and a few short rides, with no control group. The −77% on the Glide page is a simulation result. --- ### Generative UI https://jaeyongbae.com/en/experiments/generative-ui/ When a model assembles the screen at runtime, what to hand it and what to keep. ## The question When a model builds the screen at runtime, what does it get to decide and what does the system keep? Three projects settled it into one sentence. **Content from the model. Form from the system.** ## Why the line is needed Let a model build the whole screen and consistency and trust go first. Fix everything in advance and there is no reason to use a model at all. The usable answer sits between, and the three projects put the line in three different places. ## Evidence - **The model proposes, a person decides – [SAI](/en/work/sai/)** – the suggestion card is a fixed component with four states (offered, working, done, dismissed). Only what is inside it is generated. Only what a person accepts becomes a note, and suggestions never mix into the note itself. At most two wait for an answer at once (design value). - **No evidence, no generation on screen – SAI** – a suggestion without a source utterance or material is not shown. AI output carries a blue glow and an "AI-generated" badge, which is also how Korea's AI Basic Act disclosure duty is met. Confidence shows as the fill of the card, and what it doesn't know it says it doesn't know. New material queues behind a banner instead of replacing the card being read. - **No runtime model call at all – [Commit](/en/work/commit/)** – grant summaries and eligibility checks are rule-based. There are no runtime LLM calls, for two reasons: cost and hallucination. Amounts, dates and eligibility come from normalised data, and where the rules are unsure the figure stays empty. 2,595 of 11,757 notices carry an amount, 22.1% (output). - **A fixed form receives the model's probabilities – [Distance of Thinking](/en/work/distance-of-thinking/)** – the six next-token candidates the model actually produced, and their probabilities, are built as a space. Generated text does not make the screen; a fixed form receives the model's computation. No colour is used: meaning comes from density, opacity, size and movement. ## What holds **Form has to stay put for what someone learned to keep working.** If the component changes every time, the user learns it every time. **Generated output without evidence is not something to accept.** People decide to press once they can see what it came from. **Runtime generation is a cost.** Whatever could be computed in advance was. In Commit, not calling a model at all was the right answer: not creating the place where it can be wrong was cheaper than correcting wrong answers. ## Not verified yet - **Acceptance rate** – which SAI suggestions get accepted and which get ignored is not measured. Without that number there is no basis for changing when a suggestion appears. - **The two-suggestion limit** – a design value. Nobody counted how many are right in a real meeting. - **The limit of rules** – of the amounts Commit's rules left blank, it is not clear how many are genuinely unknowable and how many would be recovered by writing more rules. --- ### Three.js interaction https://jaeyongbae.com/en/experiments/threejs-interaction/ Using three dimensions in a browser as something to read rather than something to look at – tested inside an installation that flies through a probability field. ## The question Does the third dimension build the information structure, or the background? If it doesn't build the structure, it isn't used. ## Why this question Most 3D on the web is decoration that reacts to scrolling. The page gets heavier and there is no more to read. Three dimensions are justified only when they do what two cannot: a space where distance is similarity and travel is selection. ## Evidence - **Coordinates that mean something – [Distance of Thinking](/en/work/distance-of-thinking/)** – Three.js builds a language model's next-token probability field as a space. Each token's 4,096-dimension embedding is projected into three, and nearby tokens are joined by lines. At each step the top six candidates sit in probability order and form a tunnel: the likeliest ahead, the unlikely ones on the outer ring. Whatever token the visitor passes through is fixed as the answer. A prototype built in four days and 22 commits (output). - **Where two dimensions were enough – [Synthetic Vision Fund](/en/work/synthetic-vision-fund/)** – generated p5.js imagery used as the face of the product rather than wallpaper behind it. The same question, answered without a third dimension: here what built belief was the procedure, not a space. - **This site** – no 3D at all. Reading a project needs no coordinates, so there is no three.js dependency. ## What holds **Three dimensions win only when coordinates mean something.** In the probability field, nearer is more plausible. That one rule removed the need to explain the screen. **Travel has to be selection.** If what is shown and what happens are different things, 3D is a picture. So sampling is intervened in directly, and the flight path becomes the answer. Fly straight and it follows the likeliest path. **If it is decoration, leave it out.** That is why this site has no 3D. Where reading needs no coordinates, it only adds weight. ## Not verified yet - **Hardware steering** – the tilt-sensor branch selection is built, but the Arduino controller was never tested on real hardware. The published recording was steered with a mouse and a scroll wheel. - **Long runs** – exhibition mode falls back to an attract loop after 75 seconds without input. Stability over a long exhibition was not checked. - **Deployment** – Web Serial needs a secure page, so the piece ran on one HTTPS address on a private network. There is no way yet to attach the same steering in an ordinary deployment. --- # 한국어 ## 소개 - Name: 배재용 - Title: Design Engineer / Product Designer - 서울에서 일하는 디자인 엔지니어. 디지털 제품을 디자인하고, 만들고, 출시까지. - 서울에서 일하는 디자인 엔지니어다. UX와 디자인 시스템에서 시작해 프론트엔드, 데이터, AI까지 직접 다룬다. 제품을 출시한 뒤에는 사용 데이터와 실패 사례를 다음 설계의 근거로 쓴다. - Location: 서울 · Email: jaeyongbae11@gmail.com · https://jaeyongbae.com - github: https://github.com/exclusiveyon-a11y - linkedin: https://www.linkedin.com/in/jaeyong-bae-1795992b7 ## 일하는 방식 - Design (Figma): 리서치부터 정보 구조, 인터랙션, 디자인 시스템까지 맡는다. - Build (Claude Code): 프론트엔드와 프로토타입을 직접 만든다. AI와 짝을 이뤄 작업한다. - Ship (Cloudflare): 배포하고, 무엇을 볼지 정해 계측을 심고, 직접 운영한다. - Measure (GA4 · Clarity): 행동 데이터와 검증 결과로 무엇을 남기고 무엇을 뺄지 정한다. ## 경력 ### Reevl — 창업자 · 디자인 엔지니어 (2026.04–현재) - 부동산 인텔리전스 제품을 1인으로 설계·개발·출시 – 255개 시군구 45,695단지 - 리서치 · 정보 구조 · 디자인 시스템 · 프론트엔드 · 데이터 파이프라인 · 운영까지 전 과정 담당, 2026년 7월 공개 출시 - AI 도구용 read-only MCP 서버 공개, 워크포워드 검증을 통과하지 못한 예측은 범위를 좁히거나 화면에서 제거 - 월간 활성 사용자 7,000명+ 규모로 라이브 제품 운영 (GA4 30일 활성 사용자 · 2026-10-09 기준) ### 홍익대학교 — 학부연구생 (UX/UI) (2026.08–현재) - 산학 프로젝트에서 지하주차장 순찰로봇 원격 조종 HMI의 UX/UI 리서치를 맡음 - 기본형 트랙 화면 설계 주도 – 1920×1080 고정 관제 화면에 최종안 20장 · 컴포넌트 30종 - 카메라 인지 · 차량 상태 · 경고 · 번호판 인식 흐름을 축으로 정보 위계 정의, 두 디자인 트랙을 220개 토큰 체계로 통합하고 하드코딩 색상 431개를 토큰으로 되돌림 - 선행연구 · 산업사례 · 기술 회의 · 이해관계자 피드백 · 사용성 평가를 근거로 설계, 아이트래킹 2차 검증 준비 중 (파트너사 기술 세부는 비공개) ### 대한민국 공군 — 공군본부 미디어콘텐츠과 · 브랜드 디자이너 (2023.10–2025.06) - 6만 명 규모 조직의 인하우스 디자이너 – 공식 SNS 콘텐츠 · 행사 물품 · 인쇄물 기획·제작, 누적 1억 뷰 채널 - F-4 팬텀 퇴역 굿즈 설계, 함께 기획한 「팬텀을 찾아서」 40만 뷰 – 2024 '공군을 빛낸 인물' 부서 단위 단체상 - Midjourney · ElevenLabs · Sora를 공식 제작에 사용, 생성 시안을 나란히 놓아 비전문가도 근거를 보고 고르게 함 ## 학력 - 홍익대학교, 시각디자인학과 학사 (2021.03–2027.02) - Merz Akademie, 교환학생, Visuelle Kommunikation (2025.09–2026.02) - 현대고등학교, (2018.03–2021.02) ## 기술 - Design: Product Design, UX Research, Interaction Design, Design Systems, Prototyping - Engineering (AI 활용): TypeScript, React, Next.js, Tailwind, SwiftUI, Arduino - AI / Data: AI Product Design, AI-assisted Development, n8n, Data Pipelines, GA4 - Visual: Figma, Photoshop, Illustrator, InDesign, After Effects ## 수상 - 공군을 빛낸 인물 (부서 단위 단체상), 공군 (2024) ## Activities - 현대자동차그룹 UX 스튜디오 서울, 리서치 크루 — 인포테인먼트 사용성 조사 (2026.03) ## Languages - 한국어 – 모국어 - 영어 – 업무 가능 — TOEFL iBT 93 · TOEIC Speaking IH (2024.10) - 독일어 – 기초 — Merz Akademie 교환학생 (2026.02) ## Certificates - Google Analytics 인증 (GA4) — 자격번호 179338498 (2026.04) ## Global experience - 독일 — Merz Akademie 교환학생 (슈투트가르트) (2025.09 – 2026.02) - 영국 (2010.01 – 2012.12) - 스페인 (2009.07 – 2010.01) ## 프로젝트 ### Reevl — 부동산 인텔리전스 플랫폼 https://jaeyongbae.com/ko/work/reevl/ 기간: 2026.04 – 현재 · 역할: 창업자 · 디자인 엔지니어 · 팀: 1인 live: https://reevl.co.kr · press: https://uibowl.io/website/%EB%A6%AC%EB%B8%94 · github: · figma: 1인으로 디자인하고, 개발하고, 출시해 운영 중인 부동산 인텔리전스 플랫폼. ## 요약 ## 개요 Reevl은 한국 아파트를 위한 부동산 터미널이다. 아파트 단지를 상장 종목처럼 다룬다. 가격 차트, 등락률, 단지가치를 붙여 시장 상태를 한눈에 읽게 한다. 2026년 4월에 시작해 2026년 7월에 출시했다. 설계부터 운영까지 혼자 맡고 있다. 라이브: [reevl.co.kr](https://reevl.co.kr) ## 문제 기존 서비스는 단지를 찾게 해준다. Reevl은 시장의 상태를 비교하게 한다. 집을 살지, 팔지, 기다릴지 정하려는 사람에게 필요한 것은 단지 하나의 가격이 아니다. 그 가격이 지금 시장의 어디쯤인지다. 오르는 중인지 내리는 중인지, 옆 지역과 비교해 어떤지, 전세가율과 거래량이 어느 방향인지가 같이 읽혀야 판단이 된다. 기존 방식은 단지를 찾는 데서 끝났다. 검색과 필터로 단지에 도달하면 가격과 매물이 나온다. 그 숫자가 시장의 어디쯤인지는 사용자가 머릿속에서 맞춰야 했다. 지수, 등락, 지역 순위는 다른 화면과 다른 서비스에 흩어져 있었다. 그래서 가격 하나보다 지수, 등락, 지역 순위를 먼저 보이게 했다. 단지는 검색의 목적지가 아니라 시장 안의 한 종목으로 놓았다. 이 문제 정의는 사용자 인터뷰가 아니라 내가 세운 가정이다. 검증은 출시 뒤에 왔다. 어느 가정이 맞고 어느 가정이 틀렸는지는 행동 데이터와 사용자의 지적이 알려줬다. ## 핵심 결정 제품의 방향을 정한 결정 다섯 개다. 무엇을 정했고, 왜 그랬고, 무엇이 나왔는지 적었다.
- **모든 화면에서 상승은 빨강, 하락은 파랑** – 한국 시장 사용자에게 익숙한 관습을 그대로 따랐다. 초록은 상승의 뜻으로 쓰지 않는다. 등락 색은 디자인 시스템 토큰(up · down)으로만 쓴다. - **한 화면, 세 가지 껍데기** – 같은 정보를 PC에서는 도크 패널로, 폰에서는 전체 화면으로, 검색 유입에는 독립 페이지로 보여준다. 같은 구조에서 공개 페이지 64,817개가 나왔다. - **없는 값은 0이 아니라 '해당 없음'으로 비운다** – 고속도로가 없는 제주 · 울릉의 1,047개 단지를 0으로 채우면 교통이 나쁜 곳으로 읽힌다. 검증 구간을 옮기자 부호가 뒤집힌 지표도 같은 이유로 뺐다. 역세권을 기준선에 두고 고속도로와 공항을 더했다. - **학군 점수에서 진학률을 뺐다** – 학교알리미 진학률은 변별력이 없었고, 점수에 넣으면 학교를 서열화하는 신호가 됐다. 대신 NEIS 학원가 밀집도를 썼다. 데이터가 있다고 다 쓰지 않았다. - **자연어 검색은 LLM 없이 만들었다** – 검색창과 AI 캔버스가 파서 하나(nlsearch.ts)를 공유한다. "서초구 2호선 역세권 20억 이하"가 그대로 스크리너 조건이 된다. 비용과 지연과 불확실성을 한 번에 피했다.
## 과정 ### 리서치 리서치는 인터뷰가 아니라 **운영 데이터와 사용자의 지적**에서 나왔다. 출시 후 매일 들어오는 신호가 다음 결정의 근거였다. - **사용자 지적에서 시작된 커밋 366건** – 전체의 16%다(산출물). 한 문장짜리 지적이 그대로 수정으로 이어졌다. "호버 효과가 잘려요"(원인이 세 번 바뀐 문제), "뒤로 가면 아파트 목록으로 돌아가 버려요" 같은 말이다. - **행동 데이터** – 유입의 89%가 네이버, 기기의 79%가 모바일이었다(Clarity 실측, 2026년 9월 6일 기준). 이 두 숫자가 우선순위를 정했다. 모바일 먼저, 네이버 검색 먼저. - **데이터 출처 8곳** – 국토부 실거래, K-apt, 한국부동산원, KOSIS, 한국은행, V-World, 학교알리미, 청약홈. 255개 시군구, 전국 아파트 45,695단지, 누적 실거래 1,100만 건을 한 화면의 언어로 맞췄다(산출물). 일부 데이터는 자동화 대신 손으로 갱신하고, **데이터가 오래됐다는 사실을 화면에 그대로 알린다**. 원천 데이터 자체가 조사 대상이었기 때문이다. 부산의 API는 폐기됐다. 서울 정보몽땅은 중단됐다. 통계누리는 시도별 집계뿐이다. 표준데이터는 제공 기관이 9곳뿐이다. ### 디자인 #### 정보 구조 같은 화면이 세 가지 껍데기로 나온다. PC는 도크 패널, 폰은 전체 화면, 검색 유입은 독립 라우트다. #### 디자인 시스템 Figma 라이브러리를 실제 코드에서 역으로 뽑아 다시 만들었다. 토큰의 원본은 배포된 제품이고, 얼마나 지켜지는지는 매 빌드마다 측정한다. ### 개발 커밋은 2,000개가 넘는다. 성과가 아니라 규모다(산출물). 그 대부분을 AI(Claude Code)와 함께 남겼다. 디자인한 화면을 직접 코드로 옮겼다. #### 빌드 로그 커밋에서 고른 마일스톤이다. 하나하나가 실제로 배포된 결정이다. #### 활동 #### 도크 버그 전수조사 도크를 여는 경로는 표만이 아니라 히트맵 · 비교 · 검색 · 딥링크에도 있었다. 유형 판정 로직이 이 경로와 어긋나 정체성 버그 7건이 났다. 같은 종류를 한 번에 훑어 7건을 함께 고쳤다. 코드 주석에는 같은 계열이 이미 두 번 적혀 있었다.
프론트는 Next.js · TypeScript · Tailwind, 시계열 차트는 TradingView Lightweight Charts. 뒤에는 Python 데이터 엔진. 호스팅은 Cloudflare Workers와 D1 · R2다. 7월 25일 Vercel에서 옮겼다. 단지 상세 4.5만 장이 요청마다 서버에서 렌더되고 있어 정적 생성으로 바꿨고, 되돌릴 경로는 남겨 뒀다. 접근성 작업은 커밋 35건이다. 툴팁 ARIA, 다이얼로그 포커스 트랩, sr-only 라벨을 넣었고, 법적 문서의 판본 선택기는 네이티브 select 위에 얹어 접근성을 지켰다. 빌드 게이트는 11종이다. 디자인 시스템 채택률(ds_scan)과 첫 화면 JS 예산 432KB가 여기 들어 있다. 하나라도 실패하면 배포되지 않는다. 규칙은 실제로 사고가 난 것만 넣는다. 이론상 나쁜 패턴까지 넣으면 경고가 쌓이고, 쌓인 경고는 곧 무시당한다. 같은 데이터를 공개 [MCP 서버](https://github.com/exclusiveyon-a11y/reevl-mcp)로도 열었다. AI 도구가 한국 아파트 데이터를 직접 조회한다. MCP 서버는 공식 레지스트리에도 올랐다. ChatGPT 앱 디렉터리와 Claude Code 플러그인 마켓플레이스에도 열었다. 이후 채널을 MCP 하나로 정리했다.
## 결과 제품을 가장 크게 바꾼 것은 새 기능이 아니라 실패한 배포였다. 아래 숫자는 GA4와 Microsoft Clarity 실측이다.
조건 줄이 헤더에 붙지 않고 중간에 떠 있던 원인은 투명도와 헤더 높이 두 가지였다. 고정된 단지명 칸이 행을 다 덮지 못해 뒤 열이 비쳐 보였다. 지나간 행에 잔상이 남은 이유는 블러를 가진 자식 요소에 bar-blur가 빠져서였다. 좁은 화면에서는 단지명이 사라지고 배지와 범위가 겹쳤다. JSX 주석을 중괄호 없이 넣어 주석이 그대로 글자로 렌더되고 있었다. 청약 유형 표는 상태값 누락과 예정단지 필터 때문에 행이 0개로 나왔다.
### 규모 데이터 범위는 공공 출처 8곳, 255개 시군구, 누적 실거래 1,100만 건이다(산출물). 리블은 국내 UI/UX 레퍼런스 플랫폼 [유아이볼](https://uibowl.io/website/%EB%A6%AC%EB%B8%94)에 소개됐다. ### 유입 경로 "국내 부동산 검색은 네이버가 시장"이라는 가정이 숫자로 확인됐다. GA4와 Clarity 실측, 2026년 9월 6일 기준이다.
GA4 채널: Organic Search 1,199 · Direct 656 · Organic Social 82 · Unassigned 66 · AI Assistant 42 · Referral 16. 사이트맵에는 URL 65,501개가 올라가 있다. 구글 크롤이 하루 29,514건에서 22건으로 급감한 사고가 있었다. 원인은 상세 페이지의 서버 렌더링이었다. 고친 뒤에도 구글 노출은 아직 회복 중이다. Search Console 실측으로는 평균 순위가 2~5위권을 유지했고 최고 1.2위(8월 24일, 클릭 3건)를 기록했다. 노출 66회에 클릭 4회로 수가 적었다. 색인된 페이지가 적을 뿐 순위 자체는 낮지 않았다. 사이트맵을 41,600개에서 65,501개로 키운 뒤 청구서가 따라왔다. Worker CPU가 평소 2~5M ms에서 13.5M ms로 뛰었고, 5xx 831건이 났다. SEO 도구의 크롤러 하나는 9시간 20분 동안 CPU 1,000만 ms를 썼다. 검색엔진이 아니어서 색인에는 기여하지 않았다. robots.txt와 WAF로 막았다. AI 크롤러는 막지 않고 속도만 늦췄다. 23시간 측정에서 GPTBot 34,856건(28%), ClaudeBot 25,161건(21%)이 찍혔다. 같은 시간 Googlebot은 480건이었다. 차단 대신 crawl-delay를 걸어 AI가 인용할 길은 남겼다. AI 어시스턴트 유입 42건이 그 결과다.
## 사람이 개입하는 지점 운영은 자동으로 돈다. 판단이 필요한 자리만 사람에게 온다. - **자동** – 실거래가 갱신, 발행, 오류 감시를 n8n 워크플로우로 돌린다. 매일 열어 보는 창이 아니라 문제가 있을 때만 알리는 구조다. - **사람** – 출처가 불안정한 데이터는 자동화 대신 손으로 갱신한다. 화면에는 **데이터 기준일**을 함께 적는다. 틀린 값을 자동으로 보여 주기보다 언제 값인지 밝히는 편이 낫다. - **상한** – 발송 총량을 하루 50건으로 묶었다. 알림이 하루 50번 울리면 그 채널은 음소거된다. 음소거된 채널은 0건과 같다. ## 회고 ### 맞았던 것 - **Figma를 코드에서 역추출한 결정** – 디자이너가 보는 값과 사용자가 받는 값이 어긋나지 않았다. 지켜지는 정도를 매 빌드마다 측정한다. 색 98.5% · 타이포 100% · z층 95.2%(ds_scan 실측). - **모바일 먼저, 네이버 먼저** – 유입 89%가 네이버, 기기 79%가 모바일이었다(Clarity 실측, 9월 6일 기준). 출시 전에 세운 우선순위가 그대로 맞았다. - **검증되지 않는 숫자를 지우는 판단** – 2년 이상의 단지 단위 예측 금액을 뺐다. 화면에 남은 것은 워크포워드 검증을 통과한 지역 단위뿐이다. 정확해 보이는 화면보다 틀리지 않는 화면이 낫다고 지금도 본다. ### 틀렸던 것 - **리뷰를 통과한 화면은 괜찮다고 봤다.** 8월 27일이 그 가정을 반박했다. 기능 12종은 각각 맞았고, 한 화면에 함께 놓인 결과가 틀렸다. - **좋아 보이는 검증 성적을 먼저 의심하지 않았다.** 라벨 계산에 미래 정보가 새어 들어가 IC가 두 배로 부풀어 있었다. FEATURE_LAG=2로 고쳤다. 모델 업그레이드 5종도 실측 뒤 4종을 기각했다. - **파이프라인의 초록불을 믿었다.** 오케스트레이터 노드가 실패해도 워크플로는 성공으로 끝나고 있었다. 네이버 블로그 발행이 6주 멈춰 있었고, 서버 에러 11,891건이 0건으로 보고됐다. 그 뒤로 성공 로그가 아니라 **결과물**을 감시한다. 운영 점검 20가지를 자동화했다. - **검색 노출을 늘리는 비용을 계산하지 않았다.** 공개 페이지를 늘리자 크롤러가 인프라 청구서를 만들었다. 지표가 제품에 실제로 중요한지 먼저 묻게 됐다. ### 다음에 확인할 것 - **QuickbackClick 19.6%** – 들어왔다 바로 돌아가는 세션이 어디서 끊기는지 아직 모른다(Clarity 실측, 9월 6일 기준). - **구글 노출** – 상세 페이지 렌더링을 고친 뒤에도 아직 회복 중이다. - **협업** – 혼자 만든 제품이라 팀에서도 같은 판단이 통하는지 보여줄 재료가 없다. ### 다음 – ON THE WAY 가는 길을 탐색으로 바꾸는 졸업 전시 「REEVL: ON THE WAY」를 기획하고 있다. 임장은 목적지에 도착해야 시작됐다. 하지만 가는 길에 지나치는 동네와 도로도 이미 그 지역이다. 임장을 9단계로 나눠 재 보니 14.3시간 중 절반이 이동과 정리에 쓰였다. 리블의 실거래와 지표 데이터를 차량 맥락에 맞게 다시 설계한다. 지나가는 장소에 시세가 붙고, 물으면 답 대신 경로가 바뀐다. 화면을 그리기 전에 올릴 수 있는지를 먼저 확인했다. AAOS 기반 Pleos Connect의 제약을 검토한 기록은 [리블: ON THE WAY](/ko/work/pleos/)에 따로 정리했다. --- ### SAI — 먼저 돕는 AI 회의 동료 https://jaeyongbae.com/ko/work/sai/ 기간: 2026.09 · 역할: UX · 디자인 시스템 · 프론트엔드 · 팀: 3인 회의 중 필요한 일을 먼저 해오는 AI 동료. 대화를 실시간으로 받아쓰고 맥락을 읽어 조사·비교·계산을 해 두면, 사람은 결과를 보고 담을 것만 고른다. 3인 팀에서 UX와 디자인 시스템, 프론트엔드를 맡았다. ## 요약 ## 개요 모델이 제안하고, 사람이 수락한다. 그때부터 일이 된다. 사이는 회의를 듣다가 필요한 일을 먼저 제안하고, 수락된 제안만 실행한다. 노트에는 실행된 결과만 남는다. **3인 팀으로 만들었다.** 성재용, 배재용, 오승빈 셋이 붙었고 내 몫은 UX 흐름과 디자인 시스템, 프론트엔드였다. 2026 원티드 AI 챔피언십 출품작이다. 흐름은 네 단계다. 발언을 실시간으로 받아쓰고, 대화와 공유 자료를 읽어 지금 필요한 일을 판단하고, 웹 조사와 수치 계산을 하고, 결과를 근거와 함께 제안한다. "예산을 60만 원으로 바꾸면?" 같은 후속 발언은 앞선 논의에 연결해 다시 계산한다. 사람은 대화를 멈추지 않은 채 눈으로 확인하고 손으로 수락한다. 참가자는 같은 방에서 각자의 노트북과 휴대폰으로 한 회의방에 들어오고, 마이크는 한 기기만 켠다.
- **받아쓰기** – Amazon Transcribe. 발언을 실시간으로 문자로 바꾼다. - **판단** – Claude. 대화와 공유 자료를 읽고 지금 필요한 일을 고른다. - **조사** – Amazon Nova. 웹에서 자료를 찾아 출처와 함께 돌려준다. - **계산** – 코드 실행. 수치는 모델이 암산하지 않고 코드가 계산한다. - **프론트엔드** – Next.js, React, TypeScript, Tailwind CSS. 회의방은 데스크톱과 모바일에서 같은 화면을 쓴다.
## 문제 - **자료를 찾느라 대화가 끊긴다** – 회의 중에 숫자 하나를 확인하거나 대안을 비교하려면 누군가 화면을 보고, 그동안 대화는 멈춘다. - **AI를 쓰려면 맥락을 다시 설명해야 한다** – 챗봇에 물으려면 지금까지의 논의를 요약해 넣어야 한다. 그 요약을 쓰는 동안 회의는 또 멈춘다. ## 핵심 결정
- **강조색은 파랑 하나** – 회의 중에는 화면을 흘끗 본다. 종류와 상태는 회색의 명도로만 나누고, 지금 눌러야 할 것만 파랑으로 뒀다. 빨강은 쓰지 않는다. - **지금 일어나는 일은 아래 섬 하나에** – 녹음 상태와 알림이 화면 곳곳에 흩어지면 대화를 놓친다. 하단의 캡슐 하나가 녹음 상태와 모든 알림을 담는다. 막힌 동작은 이유와 해결 버튼을 함께 보여준다.
## 과정 ### 디자인 시스템 - **원칙 8가지** – 선 대신 여백, 파랑 하나, AI는 빛, 자료는 사용자를 기다림, 모르는 건 모른다고, 선은 정보가 있을 때만, 그림자는 자르지 않음, 공식 로고는 그대로. - **토큰** – primitive → semantic → 컴포넌트의 3단 구조다. 4px 그리드를 쓰고, 그림자는 두 종류만 둔다. - **컴포넌트** – 제안 카드(제안 · 진행 · 완료 · 닫힘), 근거 · 계산 · 제안 세 종류의 자료 카드, 회의 섬, 동의 게이트, QR 공유. 자료 카드는 채움의 강도로 확신도를 표시한다. - **라이브 스타일 가이드** – 앱 안의 `/design-system`에서 토큰과 원칙을 그대로 본다. ### 검증 눈으로 보지 않고 검사로 확인했다. - **테스트** – Playwright 테스트 32개를 데스크톱(1440×900)과 모바일에서 실행한다. 콘솔 오류가 하나라도 나면 실패로 본다. axe로 WCAG 2.1 AA를 검사한다. - **대비** – 검사에서 기준 미달로 걸린 색을 고쳤다. 보조 글자는 4.49에서 5.05로, 강조색 위 흰 글자는 3.88에서 4.77로 올렸다(실측). - **한글 입력 중 단축키** – 키 코드 기준으로 처리했다. 한글을 입력하는 중에도 단축키가 동작한다. ### 개발 요구사항 분석부터 구현, 테스트, 코드 리뷰까지 Codex와 함께 했다. ## 결과 실제 모델과 브라우저, DB를 연결한 상태로 돌렸다. 받아쓰기에서 판단, 조사와 계산, 제안까지 네 단계가 한 흐름으로 이어졌다. 견적 비교, 예산이 바뀔 때의 재계산, 고른 항목의 저장까지 확인했다. ## 사람이 개입하는 지점 - **AI가 먼저 제안** – 들은 내용 중 쓸 만한 것을 카드로 꺼낸다. 제안은 제안일 뿐, 자동으로 노트가 되지 않는다. - **사람이 수락한 것만 남음** – 누군가 받아들인 카드만 회의 노트로 들어간다. 회의를 끊지 않으면서도 결정권은 사람에게 둔다. - **근거를 함께** – 어떤 발화에서 나왔는지가 카드에 붙는다. 확신도는 카드 채움의 강도로 보인다. 모르는 건 모른다고 말한다. ## 회고 ### 맞았던 것 - **수락 전에는 아무것도 노트에 남기지 않는다.** 시연에서 조사와 재계산을 여러 번 돌렸지만 노트에는 사람이 고른 항목만 남았다. - **AI가 일하는 동안의 화면이 제품이다.** 모델이 무엇을 하는지 보이지 않으면 기다리는 동안의 화면이 그냥 멈춘 것으로 읽힌다. ### 틀렸던 것 - **먼저 다 만들고 나중에 줄였다.** 전체를 한 번 만든 뒤 90개 파일에서 9,000줄 가까이 덜어냈다(산출물). 필수 기능부터 정했다면 그 9,000줄을 쓸 일이 없었다. - **대비를 내 눈으로 판단했다.** 보조 글자 4.49와 강조색 위 흰 글자 3.88은 화면에서 멀쩡해 보였다. 둘 다 WCAG AA 미달이었고, 검사가 잡아낸 뒤에 고쳤다. ### 다음에 확인할 것 - **제안 2개 제한.** 설계값이다. 실제 회의에서 몇 개가 적당한지 세어 보지 않았다. - **수락률.** 어떤 제안이 수락되고 어떤 제안이 무시되는지 아직 측정하지 않았다. 이 숫자가 없으면 제안 시점을 고칠 근거도 없다. --- ### Feasix AI — 원격 조종 로봇 관제 HMI https://jaeyongbae.com/ko/work/feasix-ai/ 기간: 2026.06 – 진행 중 · 역할: UX/UI Designer – 화면 설계 · 디자인 시스템 · 팀: 연구원 4명 · 설계 2팀 병행 지하주차장 순찰 로봇을 원격으로 모는 관제사의 화면을, 화면 20장 · 컴포넌트 30종 · 토큰 220개의 시스템으로 설계한 산학 연구. ## 요약 파트너 제품의 기술 정보는 공개하지 않는다. 인식 성능 수치, 내부 명칭, 하드웨어와 통신 제약, 개발 일정이 여기 해당한다. 이 페이지에는 내가 설계한 구조와 판단만 적었다. ## 개요 지하주차장을 도는 순찰 로봇을 원격으로 조종하는 관제사의 화면을 설계했다. 관제사는 관제실에 앉아 게임패드와 PC 모니터로 로봇을 몬다. 여러 대의 카메라 영상, 주행 상태, 경고, 번호판 인식 결과를 오랜 시간 동시에 지켜본다. 화면은 1920×1080 고정 해상도, 어두운 관제실을 위한 다크 단일 테마로 설계했다. 정식 연구명은 「Vision AI 기반 이동형 로봇 원격 조종 UX/UI 개선을 위한 기초 설계」다. 연구는 두 단계로 나눴다. 1차(2026.06–07)에서 문제와 설계 기준을 세웠고, 2차(2026.08–10)에서 기본형과 와이드형 두 팀이 병행 설계한 뒤 하나로 통합했다. 나는 2차의 기본형 트랙 화면 설계를 맡았다. 날짜는 두 개다. 프로젝트에는 2026년 6월 1차 연구부터 참여했고, 홍익대학교 학부연구생(Undergraduate Student Researcher)으로 정식 임용된 것은 2026년 8월이다. 앞은 참여 시점, 뒤는 임용 시점이다. ## 문제 1차 연구에서 정리한 UX 이슈는 세 가지였다. 1. **카메라 화면의 역할과 우선순위가 불명확하다.** 전·후방과 보조 카메라가 비슷한 비중으로 놓여 화면 사이 시선 이동이 반복된다. 2. **주행 정보와 경고의 시각적 위계가 약하다.** 속도와 거리처럼 계속 확인하는 정보와 즉시 확인해야 하는 경고가 구분되지 않는다. 3. **번호판 인식 결과와 그다음 행동이 이어지지 않는다.** 결과는 표시되지만 재촬영이나 수동 확인 같은 다음 동작은 안내되지 않는다. 1차 연구의 결론은 "현재 인터페이스가 조종자의 인지 부하와 의사결정 부담을 키운다"였다. 문헌과 화면 분석에서 나온 결론이고, 측정값은 아니다. ## 핵심 결정
- **패널의 제목은 상태 단어가 아니라 번호로 바꿨다** – 번호판 인식 패널인데 카드 제목이 「미등록」「미인식」이었고 정작 번호가 화면에 없었다. 제목을 인식된 번호로 두고 상태는 오른쪽 꼬리표로 내렸다. 실패한 건은 「번호 인식 실패」로 명시했다. - **알림 기록의 위계를 뒤집었다** – 시각이 가장 크고, 무슨 일이 있었는지가 가장 작게 적혀 있었다. 메시지 16px, 부연 12px, 시각 12px 우측 정렬로 바꿨다. 절대 시각(02:14)은 상대 시각(3분 전)으로 바꿨다. 조종자는 '몇 시'보다 '무슨 일이'를 먼저 알아야 한다. - **같은 기능의 진입점을 하나로 합쳤다** – 설정이 큰 창과 우측 패널 두 곳에, 알림 기록도 팝업과 패널 두 곳에 있었다. 설정은 큰 창 하나, 알림 기록은 상단바 팝업 하나로 통일했다. 진입점이 둘이면 사용자가 매번 어느 쪽인지 판단해야 한다. - **팝오버는 누른 버튼 자리에서 자란다** – 창이 알림 줄 아래에 떠서 어느 버튼에서 나왔는지 알 수 없었다. 창의 상단을 버튼 상단(y=20)에 맞추고 버튼 중심에 가로 정렬했다. 창 머리에 같은 아이콘을 남겨 출처를 잇는다. 되돌릴 수 없는 동작(재연결, 제어권 전환)만 중앙 모달로 띄운다. - **접어도 남길 것을 정했다** – 레일(56px) · 완전 숨김 · 영상 위에 떠 있는 알약 세 안을 비교했다. 완전 숨김은 영상 96px을 더 얻는 대신 '지금 몇 건 밀렸나'를 잃는다. 레일을 택했다. 접어도 인식 켜짐 여부와 미등록 건수는 남긴다.
## 과정 ### 리서치 - **원격 주행으로 좁혔다** – 거시 여정은 온보딩 → 운행 준비 → 원격 주행 및 모니터링 → 운행 종료 네 단계다. 주요 조종 업무와 UX 이슈가 원격 주행에 몰려 있어 이 구간을 핵심 분석 구간(Critical Journey)으로 정했다. 원격 주행은 다시 주행·상황 인지 / 번호판 확인 / 통신·예외 처리 세 업무로 나눴다. 업무마다 미시 여정 5단계로 쪼개 주요 활동, 필요 정보, 사용자 판단, 현재 문제, 시사점을 표로 정리했다. - **여정 분석의 인사이트 3개** – 조종자는 차량을 조작하는 일보다 여러 화면을 동시에 확인하는 데 더 많은 집중을 쓴다. 결과를 보여주기보다 현재 상태를 분명히 이해시키는 편이 중요하다. 통신 이상에서는 장애의 원인보다 '지금 차량이 안전한가, 제어가 가능한가'를 먼저 확인한다. - **설계 기준 3개** – 카메라 위계 및 주행 시야 확대, 업무 목적에 따른 정보 그룹화, 미인식 및 비상상황 대응 지원. 선행 연구 8편과 산업 사례 4건을 근거로 1차 연구에서 세웠고, 2차 화면 설계 전체의 기준이 됐다. - **1차 약식 사용성 테스트** – 10명 내외가 참여했다. RC카와 다중 카메라, OBS Studio, Figma UI를 결합한 환경에서 확인했다. 차량을 직접 보지 못하는 상태를 만들어 화면만으로 조종하게 했다. 확인한 것은 시야, 차량 통제력, 임무 피드백, 비상 대처 네 가지다. - **개발 제약을 설계 전에 받았다** – 개발사와 기술 회의를 열어 설계 방향의 구현 가능 여부를 먼저 확인했다. 제약을 설계가 끝난 뒤의 장애물이 아니라 설계 전의 입력으로 받았다. 이해관계자 피드백 6건은 하나씩 추적해 반영했다.
설계 기준마다 근거로 삼은 문헌과 사례는 다음과 같다. - **01 카메라 위계 및 주행 시야 확대** – Gnatzig(2013), Tener & Lanir(2022), Wolf(2025), 그리고 현대·기아의 SVM. Gnatzig은 단일 영상 대신 센서 융합 디스플레이로 주행 상태를 통합해 보여주라고 제안한다. SVM은 왜곡 보정과 시점 변환, 영상 합성으로 카메라 네 대를 하나의 통합 뷰로 합친 양산 사례다. - **02 업무 목적에 따른 정보 그룹화** – Wolf(2025), Kettwich(2021). - **03 미인식 및 비상상황 대응 지원** – Tener & Lanir(2025), Parasuraman(2017), Fernride. Parasuraman은 네트워크 연결 상태를 영상 주변의 색상 띠로 표시하는 방식을 제시한다. Tener & Lanir(2022)의 전문가 인터뷰 14건에서는 차량에서 물리적으로 떨어져 감각 피드백이 사라지는 점이 원격 조종의 주요 난점으로 꼽혔다. 산업 사례 4건은 Vay(조종자가 차에 타지 않고 화면과 음향만으로 주행하는 상용 원격운전), 현대·기아 SVM, Ottopia(다중 화면 기반 원격조종 콘솔), Fernride(네트워크 본딩과 예측, 엣지 케이스에서 정지 후 호출)다.
### 디자인 - **정보 구조 6영역** – 상단 내비게이션, 상태, 카메라 뷰, 주행·제어 바, 지도, 번호판 인식 패널. - **상태는 색으로만** – 켜짐과 꺼짐은 색으로만 구분하고 버튼 위치는 바꾸지 않는다. - **알림 3단계** – 일반(토스트), 긴급(화면 위아래의 붉은 그라데이션), 기록. - **상태 수를 줄였다** – 오른쪽 패널의 상태를 8가지에서 4가지로 줄였다. 후진할 때는 카메라 배치가 자동으로 바뀐다. 초음파 거리는 mm로 표시한다. 800mm에서 노랑, 180mm에서 빨강으로 바뀐다. 두 임계값은 설계값이다. ### 디자인 시스템 두 팀이 병행 설계한 결과를 하나의 토큰 체계로 통합했다. 다른 팀의 디자인 언어는 유지하고 구조만 우리 시스템으로 다시 짰다. 하드코딩된 색 431개를 토큰에 연결했다.
토큰은 Primitive 139 · Semantic 44 · Spacing 15 · Radius 6 · Text 16으로 나눴다. 필요한 색 램프(Amber, Blue)를 더하며 Primitive는 128개에서 139개가 됐다. Semantic 계층은 원래 값이 전부 흰색인 껍데기 4개였다. 이 계층을 44개 토큰으로 채워 Primitive를 참조하게 다시 설계했다. 토큰을 층으로 나누는 이유는 변경 비용이다. 값을 한 곳에서 바꾸면 모든 화면이 따라온다. 하드코딩된 색 431개를 토큰에 연결했고, 전수 감사 스크립트로 Primitive 직접 참조 0건, 스타일 미적용 텍스트 0건, 잘린 텍스트 0건을 확인했다. 남은 미연결 274건은 의도된 예외로 목록을 남겼다. 스크립트로 한 번에 옮기자 부작용이 대량으로 생겼다. 사라진 화면 11장과 라벨 20개를 복구하고, 잘린 텍스트 50개를 다시 쟀다. 마스터를 고쳐도 화면에 반영되지 않는 일도 있었다. 상단바 8변형에 인스턴스 override가 걸려 있었고, 32곳에 직접 적용해 풀었다. 그 뒤로는 마스터를 고치기 전에 override가 있는지 먼저 확인한다. 숨긴 노드가 트리에서 사라져 수정할 수 없는 건도 있었다. 마스터에서 그 노드를 지우고 다시 만들어 id를 바꿔 override를 끊었다. 위 숫자는 모두 산출물의 규모다.
## 결과 1차 시안 6종이 2차 최종안 20장이 됐다. 최종 산출물은 화면 20장 · 컴포넌트 30종 · 디자인 토큰 220개다. 두 팀이 병행 설계하며 만든 하드코딩 색상 431개를 이 토큰 체계로 흡수했다. 기본형과 와이드형 두 안을 각각 라이트·다크 버전으로 2026년 9월 2일 개발사에 전달했다. 이 페이지의 숫자는 두 종류다. 화면 크기와 좌표는 전달한 Figma 파일에서 직접 잰 실측값이고, 화면·컴포넌트·토큰·색상 수는 산출물의 규모다. 사용자 성과 수치는 아직 없다. 인지 부하와 오류율을 측정하지 않았으므로 "인지 부하를 줄였다"고 쓰지 않는다. 아이트래킹은 진행 중이다. 결과가 나오면 이 페이지를 고친다. ## 사람이 개입하는 지점 - **AI가 하는 일** – 번호판 인식 AI가 차량을 등록 · 미등록 · 불확실 · 미인식으로 분류해 결과를 화면에 표시한다. - **사람이 하는 일** – 인식 결과는 조종자가 최종 확인한다. 미인식이 생기면 조종자가 로봇을 그 위치로 다시 이동시켜 재촬영한다. 설계 기준 03(미인식 및 비상상황 대응 지원)에 따라 화면에 재촬영 기능을 배치했다. 통신 이상과 비상 상황은 토스트로 즉시 알려 사람이 바로 판단하게 했다. ## 회고 ### 맞았던 것 - **개발 제약은 설계가 끝난 뒤의 장애물이 아니라, 설계 전의 입력이다.** 기술 회의에서 구현 가능 여부를 먼저 확인하고 화면을 그렸다. - **상시 주시 화면에서 좌표는 상태가 바뀌어도 그대로여야 한다.** 버튼을 위치로 기억해 누르는 사용자에게는 정보보다 자리가 먼저다. 8가지 상태 조합에서 이동이 0px이다. - **색은 발생 빈도 × 조치 필요성에 배분한다.** 자주 생기는 것에 강한 색을 쓰면 정말 중요한 것이 묻힌다. - **통합은 복사가 아니라 번역이다.** 다른 팀의 디자인 언어는 남기고 구조만 우리 체계로 옮겼다. - **예외 화면은 원인 진단이 아니라 안전 확인으로 시작한다.** 여정 분석에서 조종자는 장애의 원인보다 제어 가능 여부를 먼저 본다는 것이 드러났다. 화면의 첫 줄을 거기에 맞췄다. ### 틀렸던 것 - **상태를 잘 보여주면 다음 행동은 따라온다고 봤다.** 아니었다. 번호판 패널에는 상태 단어만 있고 정작 번호가 없었다. 결과를 보여주는 일과 다음 동작을 말하는 일은 다른 일이었다. - **대량 변경은 스크립트로 끝난다고 봤다.** 인스턴스 override와 텍스트 잘림이 대량으로 생겼다. 화면 11장과 라벨 20개를 복구하고 잘린 텍스트 50개를 다시 쟀다. 자동화가 만든 오류는 자동화로만 잡힌다는 것을 그때 배웠다. - **조합안을 늘리면 비교가 쉬워진다고 봤다.** 늘릴수록 무엇이 달라졌는지 읽기 어려워졌다. 한 번에 하나만 바꿔 비교하는 쪽으로 다시 줄였다. ### 다음에 확인할 것 - 인지 부하와 오류율. 아이트래킹이 진행 중이고, 결과가 나오면 이 페이지의 숫자를 채운다. - 기본형과 와이드형 중 어느 배치가 실제 조종에서 나은지. 2차 사용자 조사에서 확인한다. - 알림 줄을 늘 띄우려고 영상 높이 36px을 내준 교환이 옳았는지. 조종자가 어느 쪽을 택하는지 아직 모른다. - 접힘 상태의 레일에 남긴 정보가 충분한지. 인식 켜짐 여부와 미등록 건수만으로 되는지 확인하지 않았다. --- ### Glide — 자율주행 멀미 저감 시스템 https://jaeyongbae.com/ko/work/glide/ 기간: 2026.04 – 2026.06 · 역할: 기획 · UX · 프로토타입 (1인) · 팀: 1인 흔들리기 2~7초 전에 미리 알려 탑승자가 스스로 자세를 잡게 하는 자율주행 멀미 저감 시스템. 같은 멀미 지표를 센서 보드 · 웹 관제 · iOS 앱 세 곳에 같은 식으로 구현. ## 요약 ## 개요 먼저 알리는 것이 이 제품의 전부다. 차가 흔들린 뒤에 달래지 않고, 흔들리기 2–7초 전에 알린다. 몸을 먼저 대비시키려는 설계다. 예고만으로는 끝나지 않는다. 자율주행차의 탑승자는 앞을 보지 않는다. 영상을 보고, 일하고, 마주 앉는다. 화면을 보고 있지 않은 사람에게 화면은 채널이 아니다. 그래서 움직임을 먼저 예측하고, 그다음에 지금 그 사람이 실제로 알아차릴 수 있는 감각을 고른다. 이 두 문장이 시스템의 골격이다. 제품은 네 레이어로 나뉜다. L0 경로 지능, L1 실내 제어, L2 감각 신호, L3 웨어러블이다. 차량 제어 권한이 필요한 L1이 조직적으로 가장 어렵다. 권한 없이 되는 L0과 L2부터 단독으로 성립하도록 나눴다. 웹 관제 콘솔은 따로 정리했다 – [Glide Console](/ko/work/glide-saas/) ## 문제 - **원인** – 시각과 전정기관이 충돌한다. 자율주행에서는 전방을 보지 않는 시간, 비운전 활동, 마주 보는 좌석이 모두 늘어난다. 마주 보는 좌석 배치가 멀미를 유의미하게 늘린다는 연구가 있다(MDPI, 2025). - **규모** – 자율주행 탑승자의 6~10%가 중등도 이상의 멀미를 정기적으로 겪는다는 연구가 있다(Sivak & Schoettle). 미국인의 최대 3분의 1이 차멀미를 겪는다는 조사도 있다(NIH · Mcity). - **역설** – 멀티태스킹을 피하면 멀미는 해결된다. 하지만 그 순간 자율주행의 핵심 가치가 사라진다. ## 핵심 결정
**침묵** – '침묵 = 신뢰'를 원칙으로 적었다. 직진 정속 구간에서는 알림이 0이다. 계속 말하는 시스템은 곧 꺼진다. **13단계 개입** – 개입은 심각도에 비례한다. 상시 노출 버튼(D0)에서 시작해 제안, 자동 적용 후 통보를 거쳐 정차와 재출발(D12)까지 13단계다. 모든 단계에 되돌리기 버튼을 둔다. 회복 프로토콜은 이와 별도로 3단계다. 멀미 지표가 10을 넘으면 화면을 어둡게 하고 시트를 리클라이닝한다(설계값 38도). 18을 넘으면 정차할 안전한 위치를 찾는다. **예고 거리** – max(40m, 속도 × 예고 시간 × 민감도). **멀미 지표(MSDV)** – 가속도를 제곱해 시간에 따라 누적하고, 0~100의 Glide Score로 바꾼다. 상태 경계는 4 · 10 · 18이다(설계값). 센서 보드, 웹 콘솔, iOS 앱이 같은 식을 쓴다. 보드에서 잰 값과 앱이 보여주는 값이 같은 언어로 읽힌다. **이름이 같은 두 점수** – 경로 점수는 타기 전의 예측이고, 주행 점수는 타는 중의 누적이다. 이름은 같지만 공식이 다르다. **아직 설계안** – 멀미와 시간의 가중치를 비용 함수로 풀고, 최적해 대신 슬라이더 위의 한 점을 사용자가 고르게 한다. 이 구조는 아직 설계안이다. 구현하지 않았다.
## 과정 ### 리서치 - **측정 지표** – 국제 표준(ISO 2631-1)에 뿌리를 둔 **MSDV**를 골랐다. 멀미를 재는 세 방식(MSDV, MISC, FMS)을 비교한 결과다. 표준 지표여야 외부와 같은 언어로 이야기할 수 있다. - **경쟁 분석** – 비어 있는 것은 기술이 아니라 **통합**이었다. Apple Vehicle Motion Cues, ClearMotion, Bosch, Toyota, Holoride를 비교했다. 측정, 예측, 예고, 설명이 한 흐름으로 이어진 곳은 없었다. 이 영역은 선행기술이 밀집해 있다. '원천 기술'이라고 부르지 않는다. - **검증 방법** – 주관 보고만으로는 판단할 수 없었다. 물리(IMU 기반 MSDV), 생체(심박·머리 자세), 주관(MISC·FMS), 행동(고개 숙임·손-입 가림 제스처를 CV로 감지), 이 네 축을 함께 봤다. 네 축이 같은 방향을 가리킬 때만 효과가 있다고 판정하도록 설계했다. 네 축은 모두 구축했지만 표본이 적어 통계적 유의성은 아직 없다. - **데이터** – Tmap 경로와 POI, OSM/Overpass, 서울 TOPIS를 실제로 붙였다. ### 디자인 - **설계 원칙 다섯 가지** – 예고는 골든타임 · 침묵 = 신뢰 · 임계값에서만 발화 · 감각 채널의 우선순위 · 탑승자를 탓하지 않는 말투("모실게요"). - **햅틱** – 225ms 켜짐, 100ms 꺼짐, 225ms 켜짐 패턴이다. 실제로 타 보며 조율했다. 방향마다 세기 곡선이 다르다. 커브에서는 진동을 위에서 아래로 흘려 고개를 커브 안쪽으로 기울이게 한다. 흔들림에 그냥 쏠리는 대신 스스로 자세를 잡게 하는 것이다. - **화면** – 차량 화면 5가지 상태, 휴대폰 상단 알림(Dynamic Island) 6가지 상태, 위젯 3종과 실시간 현황 2종, 알림 문구 50개 이상이다(산출물). - **하드웨어가 UX에 거는 제약** – 오버헤드 모니터는 목을 들게 해서 오히려 멀미를 유발할 수 있다. 그래서 이 화면의 정보 밀도를 가장 낮게 잡았다. ### 프로토타입 세 부분이 같은 멀미 지표로 움직인다. 보드는 실제 움직임을 재고, 콘솔은 그것을 보며 조율하고, 앱은 탑승자에게 전한다. 보드와 앱은 직접 붙지 않는다. 웹을 경유한다. - **센서 보드** – Arduino와 MPU6050 두 개(차량용 · 머리용), 좌우 진동 모터. 50Hz로 측정하고 시작할 때 200개 샘플로 보정한다. - **웹 관제 콘솔** – 멀미 지표를 지도 위에서 보고, 사람이 뒤에서 시나리오를 재현하는 실험 도구다. - **iOS 앱** – SwiftUI, CoreMotion, 에어팟의 머리 움직임 센서, 햅틱. 빌드는 통과했다. TestFlight 배포는 아직이다. 프라이버시 매니페스트와 권한 정리는 끝냈고 남은 것은 유료 개발자 계정과 서명이다. 실패도 적어 둔다. 보드의 모션 센서가 통신(I2C)으로 인식되지 않아 실시간 측정이 막혔다. 아이폰의 CoreMotion을 대체 경로로 만들었다. 보드가 없어도 가짜 센서 값으로 같은 화면을 재현한다. 데모는 최악의 환경에서도 돌아간다. 센서 주기도 어긋났다. GPS는 1Hz, IMU는 50Hz다. 맞추려 하는 대신 역할을 나눴다. GPS는 예고 시점을, IMU는 실시간 강도를 맡는다.
**보드** – Arduino, MPU6050 두 개, MAX30102 심박 센서, 좌우 진동 모터. 50Hz 측정, 시작 시 200개 샘플 보정. 심박은 연구용 보드에서만 잰다. 소비자용 iOS 앱은 건강 데이터를 쓰지 않는다. **차량 화면** – Waveshare ESP32-S3-Touch-AMOLED-1.32, 466×466 오버헤드 모니터, LVGL V8. **웨어러블 목업** – OpenSCAD로 파라메트릭 모델을 잡고 Fusion 360에서 곡면을 다듬어 Bambu Studio로 슬라이싱했다. 이어피스는 유양돌기에 닿는 진동 모터(21×30×3mm)를 쓴다. 오픈형 이어폰의 착용 구조를 먼저 조사했다. 비전 밴드는 관자놀이에 LRA 두 개를 두고 따로 제어한다. 이어훅 곡선이 끊겨 hull() 체인 방식으로 바꿨다. 실제 제품의 착용 구조를 먼저 보는 편이 빨랐다. **iOS** – CMHeadphoneMotionManager로 에어팟의 머리 자세를 받고, AVAudioEnvironmentNode로 공간음을 만든다. TrueDepth 영상은 저장하지 않는다.
#### 활동 ### 연구 콘솔 알고리즘이 완성되기 전에 예고와 침묵부터 검증해야 했다. 그래서 실험 도구를 먼저 만들었다. 사람이 뒤에서 개입 시점과 강도를 조작하고, 탑승자에게는 자동으로 보이게 하는 도구다. 센서, 시뮬레이션, 오디오, 햅틱, 비전을 한 화면에서 맞춘 이 콘솔은 따로 정리했다 – [Glide Console](/ko/work/glide-saas/) ## 결과 같은 구간을 Glide를 켠 상태와 끈 상태로 주행시켜 MSDV 누적 곡선을 비교한 값이다. 비교를 돌린 도구는 [연구 콘솔](/ko/work/glide-saas/)의 시뮬레이션 엔진이다. 위 세 숫자는 모두 자체 시뮬레이션 결과다. 실차 대조군 실험은 하지 않았다. 표본이 적어 통계적 유의성도 없다. 출처가 불분명한 "멀미 40% 감소" 같은 숫자를 발견한 뒤로는 모든 수치에 실측 · 시뮬레이션 · 설계값 · 인용 중 무엇인지 태그를 붙였다. ## 사람이 개입하는 지점 - **자동** – 멀미 지표(MSDV)를 계속 잰다. 임계값을 넘기 전에 먼저 알린다. - **사람** – 개입은 심각도에 비례한다. 가벼운 제안에서 시작해 자동 적용 후 통보, 필요하면 정차까지 13단계다. 모든 단계에 되돌리기 버튼이 있다. 시간과 편안함을 맞바꾸는 결정은 언제나 탑승자가 한다. - **침묵도 설계** – 임계값 아래에서는 말하지 않는다. 계속 말하는 시스템은 곧 꺼진다. ## 회고 ### 맞았던 것 - **하나의 지표를 세 곳에 같은 식으로 구현한 것.** 보드에서 잰 값과 콘솔이 그린 곡선과 앱이 보여주는 점수가 같은 언어로 읽혔다. 세 곳의 공식이 달랐다면 어느 값을 믿을지부터 다퉜을 것이다. - **예고를 제품의 중심에 둔 것.** 감지와 완화는 이미 여럿이 한다. 예고로 탑승자의 자세를 바꾸는 쪽이 이 제품이 방어할 수 있는 지점이었다. - **데모는 최악의 환경을 가정해 만든 것.** 센서가 죽었을 때 가짜 센서 경로가 시연을 살렸다. ### 틀렸던 것 - **설계값을 몸보다 믿었다.** 예고 시간 1.5 / 2 / 3초는 문서에서는 충분했고 실제로 타 보니 늦었다. 지켜야 할 것은 숫자가 아니라 경험이었다. - **보드와 앱이 직접 붙을 줄 알았다.** 모션 센서가 I2C에서 인식되지 않았다. 지금도 보드는 웹을 경유한다. - **UX의 일관성 문제를 화면 문제로 봤다.** 대개 정보 구조의 문제였다. 여러 곳에 흩어진 차량 설정 화면을 하나의 공통 컴포넌트로 합쳤다. - **소비자용 호출 앱을 먼저 만들 수 있다고 봤다.** 방향을 자동차 회사에 넣는 SDK와 차량에 상관없이 쓰는 동반 앱으로 바꿨다. B2C는 지역에 묶이고 B2B는 그렇지 않다. 그리고 실험용으로 만든 관제 도구가 이미 고객사가 쓸 화면이었다. ### 다음에 확인할 것 - **실차 대조 실험.** 지금 효과 수치는 전부 시뮬레이션이다. 같은 구간을 실제 차량에서 A/B로 돌려야 한다. - **네 축이 같은 방향을 가리키는지.** 축은 모두 만들었다. 표본이 부족하다. - **TestFlight 배포.** 남은 것은 유료 개발자 계정과 서명이다. - **블루투스 직접 연동과 개인화 모델.** 사람마다 예고 시간이 달라야 하는지 아직 모른다. --- ### 칸칸 — 지하철 칸별 혼잡도 미니앱 https://jaeyongbae.com/ko/work/kankan/ 기간: 2026.05 – 2026.09 · 역할: 기획 · 디자인 · 개발 · 운영 (1인) · 팀: 1인 live: https://kankan-eta.vercel.app 모든 길찾기 앱이 최단 경로를 알려줄 때, 앉아서 갈 수 있는 칸을 알려주는 토스 미니앱. 기획부터 디자인, 개발, 심사, 운영까지 1인으로 진행했다. ## 요약 ## 개요 경로는 이미 안다. 남은 결정은 어느 칸에 타는가다. 지도 앱은 최단 경로까지만 알려준다. 앉아 갈 수 있는 칸은 사용자가 매번 감으로 고른다. 매일 지하철을 타며 느낀 불편에서 시작했다. 칸칸은 토스 안에서 도는 미니앱(앱인토스)이다. 기획, 디자인, 개발, 심사 대응, 운영을 1인으로 맡았다. 심사를 통과해 출시했다. 라이브: [kankan-eta.vercel.app](https://kankan-eta.vercel.app) ## 문제 문제는 한 문장이다. **어느 칸에 타야 앉아 가는가.** - **자리는 매번 감으로 찾는다** – 매일 지하철을 타는 사람도 어디에 서야 앉는지는 감으로 정한다. - **지도 앱은 칸을 보지 않는다** – 네이버·카카오 지도는 최단·최적 경로만 보여준다. 칸별 혼잡도는 없다. - **타깃** – 출퇴근·등하교 때 자리를 원하지만 정보가 없어 오늘도 서서 가는 지하철 이용자. ## 핵심 결정 ## 과정 ### 제약 속 설계 플랫폼, 인프라, API의 제약을 기획 초기에 파악했다. 제약마다 디자인과 개발 결정에 반영했다. - **앱인토스 배포 정책** – 진입 즉시 팝업 금지, 외부 앱 유도 금지, 뒤로가기 차단 금지를 모두 지켰다. 뒤로가기 버튼을 없애고 네이티브 제스처에 맡겼다. 이 조건을 맞춘 뒤 심사를 통과했다. - **WebView 환경** – 앱인토스 SDK와 웹 프레임워크 가이드를 따랐다. 네이티브 코드 없이 WebView 안에서 끝냈다. - **API 무료 한도** – 혼잡도는 자주 바뀌지 않는다. 배치로 모아 Supabase에 캐싱하고 실시간 호출을 줄였다. 하루 1,000건 한도 안에서 운영한다. 지속 운영 비용은 0원이다. ### 디자인 토스 디자인 시스템(TDS) 컴포넌트를 그대로 썼다. 토스 앱 안에서 이질감 없이 보인다.
- **SearchBar** – 역 검색 입력. - **Badge** – 혼잡도 표시(색상 코딩). - **CTAButton** – "칸 추천받기", 해야 할 행동 하나. - **NavigationBar** – 브랜드 로고와 가운데 정렬 타이틀.
### 데이터
- **칸별 혼잡도 · 하차 비율** – 퍼즐 API(지오비전 SK), 30분 단위, 1~8호선. 배치로 수집해 Supabase에 캐싱하고 시간대별로 조회한다. - **빠른환승 칸 번호** – 국토교통부 CSV와 서울교통공사 API. 두 출처를 교차검증해 오류 77건을 고치고 456건을 정적 데이터로 번들했다. - **유지보수** – 혼잡도는 배치 스크립트로 Supabase를 갱신한다. 역 정보가 바뀌면 빠른환승 데이터를 다시 검증해 교체한다. API 한도는 Vercel 로그로 확인한다.
## 결과 출시한 것이 결과다. 심사를 통과해 토스 안에서 돌고 있다. 사용 지표는 아직 재지 않았다. ## 사람이 개입하는 지점 - **자동** – 공공데이터를 두 출처로 교차검증해 미리 캐시에 쌓는다. - **사람** – 교차검증에서 어긋난 77건은 사람이 확인해 고쳤다. 라이브 API가 불안정한 구간은 검증된 456건을 정적 데이터로 번들했다. **틀린 값을 실시간으로 내보내지 않는다.** ## 회고 ### 맞았던 것 - **같은 데이터도 맥락이 바뀌면 다른 서비스가 된다.** 혼잡도 데이터는 이미 있었다. 탑승 직전이라는 맥락에 맞추자 전혀 다른 가치가 됐다. - **틀린 값을 내보내지 않기로 한 결정.** 최신값 대신 검증된 456건을 택했다. 커버리지는 1~8호선에서 멈췄지만 화면에 잘못된 칸 번호는 올리지 않는다. - **비용을 없앤 것도 디자인 결정이었다.** 혼자 만든 서비스를 오래 열어 두려면 운영비가 0이어야 했다. ### 틀렸던 것 - **공공데이터가 서로 맞을 거라고 봤다.** 두 출처를 맞춰 보니 77건이 어긋났다. 한 출처만 믿었다면 틀린 칸 번호가 그대로 나갔을 것이다. - **실시간 값이 항상 낫다고 봤다.** 라이브 API의 빠른환승 정보는 실제와 달랐다. 최신인지보다 맞는지가 먼저였다. ### 다음에 확인할 것 - **추천이 맞았는지 재지 않았다.** 추천한 칸에서 실제로 앉았는지 확인할 방법이 아직 없다. - **혼잡도는 30분 단위 시간대 값이다.** 그날의 실제 혼잡도와 얼마나 벌어지는지 모른다. - **호선 확대** – 1~8호선 밖에서도 같은 품질의 칸별 데이터가 나오는지 확인해야 한다. 9호선과 수도권 광역철도(GTX)가 다음 후보다. - **알림** – 출발 전 푸시로 칸을 알려주는 방식이 탑승 직전 판단보다 나은지 아직 모른다. --- ### GLIO — 원고 하나로 인쇄용 PDF부터 점자까지 https://jaeyongbae.com/ko/work/glio-works/ 기간: 2026.07 – 진행 중 · 역할: 1인 창업 – 기획 · 디자인 · 개발 · 팀: 1인 원고 하나를 한국어 조판 인쇄 PDF, EPUB3, 큰글자, 접근성 PDF, 점자로 만드는 AI 출판 제작 도구. 자체 한국어 조판 엔진과 macOS 앱, MCP 서버까지 1인으로 만들고 있다. ## 요약 ## 개요 원고 하나를 넣으면 인쇄용 PDF, EPUB3, 큰글자, 접근성 PDF, 점자가 함께 나온다. 네 부분으로 만들었다. - **엔진** – Python · FastAPI. HarfBuzz 셰이핑, 자체 줄바꿈, 한국어 조판 규칙 데이터. - **스튜디오** – 의존성 없는 단일 파일 웹 UI. - **macOS 앱** – SwiftUI. 엔진을 HTTP 대신 로컬 프로세스로 부른다. 원고와 폰트가 기기를 떠나지 않는다. - **MCP 서버** – 작업물 분석, 사양 생성, 사전 검사, 교정지 렌더, 견적, 주문 요청 도구를 AI 클라이언트에 연다. 결제는 실행하지 않고 승인 링크만 돌려준다. 아직 출시하지 않았다. 접근성 교정을 첫 제품으로 준비하고, 조판은 그다음에 낸다. ## 문제 책 한 권을 만들면 인쇄용 조판, EPUB, 큰글자, 점자가 각각 따로 원고를 다시 해석한다. 교정도 그만큼 반복된다. 한국어 조판에는 일본어의 JIS X 4051 같은 표준 구현이 없다. 접근 가능한 형식은 이제 의무다. 유럽 접근성법(2025년 6월)과 한국의 디지털포용법(2026년 1월)이 시행된다. ## 핵심 결정
- **사용자는 좌표가 아니라 역할을 고른다** – 단락마다 스타일을 덮어쓸 수 있으면 제목 40개 중 하나만 다르게 보이는 사고가 생긴다. 블록의 역할만 고르게 했다. mm와 좌표는 엔진이 정한다. - **모르면 본문으로, 덜 해로운 쪽으로 틀린다** – 원고를 잘못 구조화하면 모든 포맷이 함께 틀린다. 저자의 Word 스타일을 먼저 읽고, 그다음 레이아웃을 추정한다. LLM은 마지막에만 선택적으로 쓴다. 확신이 없으면 본문으로 둔다.
## 과정 ### 실제 책으로 검증하기 – 국립현대미술관 출판 지침 디자이너가 만든 실제 책을 기준으로 삼았다. 국립현대미술관(MMCA)의 『출판 지침』 2판(2020)에는 같은 원고(docx)와 인쇄된 결과물이 모두 남아 있다. 같은 원고를 GLIO에 넣고 나온 결과를 실제 책과 나란히 비교했다. 8월 15–16일 이틀 동안 이 책 하나로 결과 파일 114개를 내며 엔진을 고쳤다. - **판형은 맞췄다** – 첫 결과는 161×256mm였다. 반복하며 실제 책의 125×220mm로 맞췄다. - **쪽수는 다르다** – 실제 책은 300쪽, GLIO는 263쪽이다. 같은 원고가 더 촘촘히 짜였다는 뜻이다. 행간과 여백을 실제 책의 밀도에 맞추는 것이 다음 과제다. - **서체는 다르다** – 실제 책은 Janson · AG 최정호 · Akzidenz 같은 상용 서체를 쓴다. GLIO는 서버에서 쓸 수 있는 OFL 서체(EB Garamond · Noto Serif KR)를 쓴다.
원고와 실제 출판물이 함께 남아 있는 책 다섯 종을 넣고, 결과가 실물에 가까워질 때까지 돌렸다. 8월 14일 저녁부터 16일 자정까지 결과 PDF 483개가 쌓였다. 한 권마다 인쇄용 · 펼침면 · 사용자경로 세 갈래를 매번 함께 냈다. | 출판물 | 원고 | 결과 파일 (산출물) | 실물 (실측) | GLIO (실측) | 첫 결과 → 끝 (실측) | |---|---|---|---|---|---| | MMCA 출판 지침 1판 (2018) | docx | 144개 | 300쪽 | 265쪽 | 220 → 265쪽 | | MMCA 출판 지침 2판 (2020) | docx | 114개 | 300쪽 | 263쪽 | 219 → 263쪽 | | MMCA 소장품 기술지침 (2023) | docx | 111개 | 88쪽 | 61쪽 | 36 → 61쪽 | | 한성부입니다 (전시 도록) | docx + 도판목록 xlsx | 59개 | 176쪽 | 288쪽 | 289 → 288쪽 | | 서울시립미술관 소장품 기술지침 | docx + 도판목록 xlsx | 55개 | 52쪽 | 60쪽 | 47 → 60쪽 | 쪽수가 늘어난 것은 실패가 아니다. 첫 결과는 각주와 도판 자리를 통째로 흘려보내고 있었다. 반복하면서 각주 87개, 도판 표기 207곳, 용어 설명 원고가 제자리를 찾았고, 그만큼 쪽이 늘었다. 위 다섯 장은 모두 GLIO가 만든 최종 결과 PDF에서 그대로 뽑은 지면이다. 편집하거나 다시 그리지 않았다. 『한성부입니다』에서는 한국어와 영어, 일본어가 한 지면에 놓인다. #### 무엇이 걸렸나 원고를 하나씩 넣을 때마다 엔진이 부서졌다. 고친 순서가 곧 기록이다. - **RTF에서 한글이 조용히 사라졌다** – 오류도 없이 글자만 없어졌다. 인코딩 경로를 다시 짰다. - **PDF 원고를 올리면 무한 로딩에 빠졌다** – 쪽 단위로 끊어 읽게 바꾸고, 브라우저 회귀 시험을 붙였다. - **한글 원고가 전부 제목이 됐다** – 개요 문단 모양을 못 읽어 본문까지 장 제목으로 올라갔다. - **첫 장 제목이 책 제목이 됐다** – MMCA 원고에서 「1부 미술 출판에 대하여」가 표지·속표지·판권에 찍혔고, 지은이는 워드가 넣은 「Un-named」였다. 원고 머리를 본문에서 떼고, 거기 적힌 것이 파일 속성을 이기게 했다. - **도판을 올리면 격자 설정이 죽었다** – 조판을 통째로 다시 짜던 것을 부분 갱신으로 바꿨다. - **미리보기가 느려 반복이 끊겼다** – 11배 빠르게 고치고(실측), 만드는 중이라고 알리게 했다. #### 아직 안 돌린 것 미술 잡지 원고 세 편과 포브스 잡지 자료는 넣지 않았다. 잡지는 단행본과 흐름이 다르다. 한 지면 안에서 단이 바뀌고, 사진이 글을 감싼다. 지금 엔진은 그 배치를 다루지 못한다. 위 쪽수는 모두 실물 PDF와 GLIO 결과를 직접 센 실측값이다. 실물은 상용 서체와 디자이너의 판면을 쓰고, GLIO는 OFL 서체와 기본 설정을 쓴다. 같은 원고에서 같은 구조가 나오는지를 봤다. 디자인을 똑같이 만들지는 않았다. 두 쪽수를 그대로 우열로 읽을 수 없다.
## 결과 접근성 검사에서 PDF/UA 9개 항목 중 통과가 5개에서 7개로 늘었다. 자동 수정 전후를 같은 파일로 재서 얻은 실측값이다. 남은 두 항목은 대체 텍스트라 사람이 쓴다. 조판 속도는 1.76배가 됐고, 같은 원고 20,413줄 중 바뀐 줄은 없었다. 아직 출시 전이다. 내 손에 있는 원고로만 검증했고, 외부 고객의 책으로는 확인하지 못했다. ## 사람이 개입하는 지점 - **자동** – 원고 하나에서 인쇄 PDF, EPUB3, 큰글자, 접근성 PDF, 점자까지 한 번에 만든다. 조판 결과는 사람 눈이 아니라 규칙이 먼저 검사한다. - **사람** – 규칙이 잡지 못하는 자리는 편집자가 고친다. 그림 설명, 표의 읽는 순서, 이름의 표기가 그렇다. 도구는 초안을 끝까지 밀고, 판단은 남겨 둔다. ## 회고 ### 맞았던 것 - **AI는 결정만, 그리는 것은 코드.** 조판을 1.76배 빠르게 고친 뒤에도 결과 20,413줄 중 바뀐 줄이 없었다. 엔진이 LLM 모듈을 불러오지 못하게 테스트로 막은 것이 그 경계를 지켰다. - **라이선스도 설계다.** AGPL · GPL 라이브러리는 쓰지 않고, 폰트는 OFL만 쓴다. 좋은 도구여도 배포할 수 없으면 쓸 수 없다. - **첫 제품을 접근성 교정으로 정했다.** 통과와 실패가 문서로 정해져 있어, 고칠 자리를 매번 바로 찾았다. 조판의 좋고 나쁨은 그렇게 판정되지 않는다. ### 틀렸던 것 - **판형과 구조가 맞으면 지면도 실제 책에 가까워질 줄 알았다.** 판형은 맞췄지만 쪽수는 300쪽 대 263쪽으로 남았다. 밀도는 판형과 다른 문제였다. - **도판 중심의 도록도 같은 엔진으로 덮을 줄 알았다.** 『한성부입니다』는 실물 176쪽, GLIO 288쪽이다. 글이 흐르는 책과 도판이 자리를 잡는 책은 다른 규칙을 쓴다. - **워드 파일의 속성을 믿었다.** 지은이가 「Un-named」로 찍혔고, 1부 제목이 책 제목이 됐다. 그 뒤로는 원고에 적힌 것이 파일 속성을 이긴다. - **원고의 서식을 읽으면 구조를 알 수 있다고 봤다.** 한글 원고에서 본문이 전부 장 제목으로 올라갔다. 확신이 없을 때 본문으로 두는 규칙을 그때 넣었다. ### 다음에 확인할 것 - 행간과 여백을 실제 책의 밀도에 맞출 수 있는지. 지금은 같은 원고가 더 촘촘히 짜인다. - 도판 중심의 도록과 잡지 원고. 한 지면 안에서 단이 바뀌고 사진이 글을 감싸는 배치는 아직 못 다룬다. - IDML로 넘긴 뒤 디자이너가 InDesign에서 어디까지 이어 갈 수 있는지. - 내 원고가 아닌 실제 고객의 책. 다섯 종은 모두 내가 고른 책이다. --- ### Commit — 창업지원 공고 × 익명 빌더 커뮤니티 https://jaeyongbae.com/ko/work/commit/ 기간: 2026.06 – 2026.07 · 역할: Founder – 기획 · 디자인 · 풀스택 · 운영 · 팀: 1인 live: https://commit.ai.kr 흩어진 정부 창업지원 공고를 하나의 피드로 모으고, 그 위에 익명 빌더 커뮤니티를 얹은 모바일 우선 웹앱. 1인으로 28일 만에 출시했고, 확실하지 않은 금액은 채우지 않고 비워 뒀다. ## 요약 ## 개요 Commit은 공공데이터를 제품 정보로 바꾸는 일을 제품의 절반으로 잡았다. 공고 API가 주는 것은 기관 표기가 1,722종으로 흩어진 원문이다. 크롤러가 매일 그것을 모아 7단계로 정규화하고, 제품은 정리된 결과만 보여준다. 그 위에 공고를 **기관 계정이 올린 글**처럼 다뤘다. 공고 목록과 커뮤니티 피드가 같은 골격을 쓴다. 기관 페이지는 사람의 프로필과 같은 컴포넌트로 그린다. 공고를 발견하고, 익명으로 아이디어를 검증받고, 실행을 기록하는 일이 한 타임라인에서 이어진다. 제품은 모바일 우선 PWA다. 홈 화면에 설치하면 네이티브 앱처럼 열린다. 라이브: [commit.ai.kr](https://commit.ai.kr) ## 문제 공고를 찾는 일부터 이미 어렵다. - **출처가 흩어져 있다** – 운영 DB 기준 기관 표기만 1,722종이다. - **원문이 지저분하다** – 기관명 중복, 인코딩이 깨진 "?", 제목 앞의 "(재공고)(연장)" 같은 괄호. - **금액이 없다** – 공고 API에는 지원금액이 없다. 금액은 별도의 사업정보 API에만 있다. - **정렬이 맞지 않다** – 수집한 목록은 등록순으로 온다. 공고에서 반드시 지켜야 하는 기한은 마감일뿐이다. - **찾은 다음이 없다** – 실명 커뮤니티에는 설익은 아이디어를 올리기 어렵다고 봤다. ## 핵심 결정 ## 과정 ### 리서치 결론은 "아무도 안 한다"가 아니라 **통합이 비어 있다**였다. K-Startup, 기업마당, 링커리어·위비티, 아웃스탠딩·플래텀, 디스콰이엇, 인디해커스·Product Hunt, 노션을 한 표에 놓고 비교했다. 공고를 모으는 곳, 창업 뉴스를 쓰는 곳, 만드는 과정을 공유하는 곳은 각각 있었다. 셋을 잇는 곳만 없었다. 데이터를 직접 열어 보고 찾은 것도 있다. 창업 기간·연령 필드는 "가능한 범위 전체"를 나열하는 경우가 많았다. 그대로 태그를 붙이면 모든 공고에 모든 태그가 붙었다. ### 디자인 기준은 "토스의 정보 위계 + Threads의 타임라인"이다. 파랑은 행동, 초록은 살아 있음을 뜻한다. 임의의 값은 쓰지 않는다. - **토큰** – 타입 7단(11 / 12 / 13 / 15 / 17 / 20 / 24), 버튼 36 / 44 / 48, 라운드 8 / 12 / 16 / full, 색 토큰 15종 × 라이트·다크 2테마, Pretendard 한 가지 서체에 자간 −0.02em. 모두 설계값이다. - **행동 색과 링크 색을 나눴다** – 강조 파랑을 바꾸자 본문 속 파란 링크가 읽히지 않았다. 버튼 색과 글 속 링크 색을 분리했다. - **반응형 세 벌** – 768px 미만 / 768px 이상 / 1280px 이상. 가운데 콘텐츠 640px, 오른쪽 레일 360px. 모바일 탭 타깃은 36px에서 44px로 키웠다. 공통 컴포넌트 6종은 화면을 다 만든 뒤에 뽑았다. 흩어져 있던 alert() 27곳이 하나의 toast()가 됐다. 전역 스켈레톤 한 벌은 라우트별 15벌이 됐다. 디자인 시스템은 앞에서 만들면 추측이고, 뒤에서 만들면 관찰이다. ### 개발
Python 크롤러가 매일 공고를 모아 7단계로 정리한다. 제목은 정규식 5단계로 다듬는다. 중복된 기관명을 떼고, 깨진 인코딩을 지우고, 앞머리 괄호 묶음을 풀고, 공백을 정리하고, 같은 공고의 회차를 묶는다. 같은 규칙을 과거 데이터에도 소급 적용했다. 알림은 고유 키로 중복 발송을 막는다. 실행마다 하트비트를 남긴다. 36시간 넘게 수집이 없으면 경보가 울린다. GitHub Actions로 돌고, 추가 비용은 없다. 다중 페이지 백필만 개인 맥의 launchd에서 돈다. 맥이 꺼져 있으면 그 작업은 멈춘다.
Supabase(PostgreSQL) 위에 테이블 24개, 뷰·RPC 12개. 검색은 3단계로 쌓았다: 오타에 강한 트라이그램 검색 → pgvector 의미 검색(내장 임베딩 모델 gte-small) → 자동완성과 맞춤 가중치. 그 위에 임베딩 유사도로 비슷한 공고, 제목 시리즈로 과거 같은 공고, 기관별 임베딩 중심값으로 비슷한 기관을 붙였다. 공고 상세에 카드 3개를 두니 산만해서 하나로 합쳤다. RPC가 실패하면 클라이언트 쪽 결과로 대신한다. 한계도 그대로 적는다. LLM 호출은 없다. 공고 요약과 자격 진단은 규칙 기반이다. 외부 유료 API를 썼다면 비용 때문에 검색 기능 자체를 넣지 못했을 것이다.
commit_logs 테이블에는 CHECK 제약을 걸었다. figma_url · github_commit_hash · image_url · link_url 중 최소 하나가 없으면 행이 저장되지 않는다. is_verified는 GENERATED 컬럼이다. Figma나 GitHub 링크가 있으면 자동으로 true가 된다. 말이 아니라 실행으로 증명하게 만드는 규칙을 DB 제약으로 박아뒀다.
기관 로고도 금액과 같은 규칙을 따른다. 파비콘 서비스가 빈 아이콘을 '성공'으로 돌려줬기 때문에 자동 수집을 믿지 않았다. 손으로 확인한 로고 116곳, 도메인 매칭 210곳, 핫링크가 막혀 파일로 저장한 17곳이다. 이름 앞부분 매칭으로 산하 조직까지 덮는다. 그래도 표기 1,722종 전체에는 한참 못 미친다.
28일 동안 938개 파일이 바뀌었다(+27,927 / −6,233줄). 코드는 118개 파일 · 10,536줄, 컴포넌트 47개다. 모두 산출물 수치다. 시행착오 13건은 따로 기록했다. 피드에 4일치만 보이던 limit 문제, UTC와 한국 시간의 날짜 어긋남, 광고 스크립트가 미리 불러오기로만 들어가 소유권 확인이 실패한 문제, 흰 로고 SVG가 라이트 테마에서 사라져 결국 currentColor 기반 인라인 컴포넌트로 바꾼 일 등이다.
## 결과 제품은 완성됐다. 제품이 옳은지는 아직 모른다. 안 된 것도 된 것만큼 적는다. - **가입 14명 (실측)** – 공식 봇 계정 5개, 개인 9명. 개인 9명은 대부분 본인과 지인이다. - **사람 글 33개 대 봇 뉴스 407개 (실측)** – 타임라인에 쌓인 글의 대부분은 사람이 아니라 봇 계정의 뉴스다. 빈 피드를 스타트업 뉴스로 채우기로 한 결정의 결과다. - **매출 0원 (실측).** 월 인프라 비용도 0원이다. - **CSP는 아직 Report-Only다** – 위반을 막지 않고, 수집 엔드포인트도 없어 관찰조차 되지 않는다. "공고 발견과 실행 기록을 합치면 이탈이 줄어든다"는 가설은 아직 검증 전이다. 3단 검색이 단순 텍스트 검색보다 나은지도 측정하지 않았다. 사용자가 적어 비교할 표본이 없다. ## 사람이 개입하는 지점 - **자동** – Python 크롤러가 매일 공고를 모아 7단계로 정규화하고, 실행마다 하트비트를 남긴다. 36시간 넘게 수집이 없으면 알린다. 글쓰기·신고 같은 행동에는 종류별 레이트리밋을 걸었다. - **사람** – 금액 매칭은 커버리지보다 정확도를 택했다. 규칙이 확신하지 못하는 공고는 숫자를 비우고 원문을 보게 했다(22.1%). 자동으로 숨은 글은 운영자가 삭제하거나 되살린다. 운영자 도구는 페이지 진입이 아니라 서버 액션마다 권한을 다시 확인한다. - **아예 안 맡긴 것** – 런타임에 LLM을 부르지 않는다. 금액 추정도, 공고 요약도 규칙 기반이다. 틀릴 자리를 만들지 않는 편이 틀린 답을 고치는 것보다 싸다. ## 회고 ### 맞았던 것 - **모르는 숫자를 비워 둔 결정.** 금액 커버리지는 22.1%에서 멈췄다. 대신 화면에 있는 금액은 원문과 같다. 공공데이터를 제품 정보로 바꿀 때 가장 비싼 실수는 빈칸이 아니라 틀린 값이라고 봤다. - **외부 의존이 죽어도 화면은 살아야 한다.** 검색 RPC, 로고, 금액 매칭이 모두 실패했을 때의 모습을 먼저 설계했다. - **디자인 시스템을 뒤에서 만든 것.** 화면을 다 만든 뒤에 뽑아서 추측이 아니라 관찰이 됐다. - **수집하지 않은 데이터는 유출되지 않는다.** 익명이라는 제품 결정이 규제 비용까지 같이 낮췄다. 탈퇴 버튼은 출시 전 체크리스트에 넣었다. ### 틀렸던 것 - **행 단위 권한이 컬럼까지 막아 준다고 봤다.** RLS는 '어떤 행'만 통제한다. '어떤 컬럼'은 GRANT의 일이다. 그 사이로 전 회원의 이메일이 열릴 수 있었다. - **커뮤니티를 먼저 만들면 사람이 온다고 봤다.** 검색으로 들어온 사람이 찾은 것은 공고였다. 커뮤니티 기능을 걷어내고 공고 중심으로 바꿨다. - **자동 수집이 성공을 돌려주면 결과물도 맞다고 봤다.** 파비콘 서비스는 빈 아이콘을 '성공'으로 응답했다. 그다음부터 로고는 손으로 확인했다. - **UX가 어긋나는 것을 화면 문제로 봤다.** 대부분은 정보 구조 문제였다. 화면을 고치는 대신 소유권을 한 곳으로 모아야 풀렸다. ### 다음에 확인할 것 - **통합 가설.** 발견과 기록을 한 타임라인에 두면 이탈이 줄어드는지, 사용자 10명에서 100명 사이에서 처음 확인할 수 있다. - **검색의 효용.** 3단 검색이 단순 텍스트 검색보다 나은지 A/B로 재야 한다. 지금은 표본이 없다. - **금액 커버리지를 올리는 방법.** 22.1%를 올리려면 K-Startup 하나뿐인 출처부터 늘려야 한다. - **어뷰즈 대응.** 레이트리밋, 자동 숨김, 차단은 만들었지만 실제 트래픽에서 시험된 적이 없다. - **남은 빚** – 테스트 코드 0개, 마이그레이션만으로 재현되지 않는 원격 DB, Report-Only에 멈춘 CSP. --- ### FLATTEN — 흩어진 졸업전시를 하나의 인덱스로 https://jaeyongbae.com/ko/work/flatten/ 기간: 2026.08 – 진행 중 · 역할: 기획 · 디자인 · 개발 · 팀: Quotely 여러 대학의 디자인 졸업전시를 학교 경계를 넘어 한 곳에서 찾아보는 인덱스. 사람 · 프로젝트 · 과정 · 기관 · 연도를 잇는 기록 인프라의 첫 단계. ## 요약 ## 개요 콘텐츠 제품의 데이터 모델과 운영 구조를 처음부터 설계한 작업이다. 첫 대상은 졸업전시다. 누구나 볼 수 있고, 해마다 반복되고, 날짜와 장소가 분명하다. 학생들도 알리고 싶어 한다. 화면은 샘플 데이터를 넣은 개발 빌드다. 아직 공개 배포 전이고, 실제 전시 일정이 아니다. 사용자 수치나 성과는 없다. ## 문제 대학 프로젝트의 기록은 학교 사이트, 한 해만 열리는 전시 사이트, 인스타그램, 비핸스, PDF로 흩어진다. 그 사이에서 **누가 · 무엇을 · 어느 과정에서 · 어디서 · 언제** 했는지를 잇는 관계가 사라진다. 링크만 모아 두면 그 관계는 돌아오지 않는다. 관계를 되살리려면 관계를 저장하는 구조가 먼저 있어야 한다. ## 핵심 결정
**추가 비용 0원으로 설계한다.** 검증 전의 제품이 비용 때문에 닫히면 안 된다. 이벤트는 모아서 보내고, 매일 밤 집계해 대시보드가 원본을 훑지 않게 했다. 유료 분석 제품은 쓰지 않는다. 0원은 설계값이고, 운영 실측치는 공개 배포 뒤에 나온다. **확대해서 보는 포스터 벽.** 수백 개의 전시를 한 번에 훑어보되 느려서는 안 된다. 최대 900개 타일만 그린다(설계값). 멀어질수록 디테일을 줄이고, 가까이 볼 때만 이미지를 불러온다.
## 과정 ### 데이터 - **원천** – 대학알리미의 2023년 학과 목록(공공데이터포털) 52,214행. - **디자인 학과 마스터** – 52,214행에서 217개 기관의 786개 학과를 추렸다. 학과 이름만으로는 디자인 학과인지 가릴 수 없어 기관 단위로 확인했다. 1차 대상 90개 학과를 우선순위로 나눴다(설계값). - **구조** – 테이블 20개. 사람, 프로젝트, 과정, 기관, 연도를 잇는 방향으로 설계했다. 전시(edition)는 과정(program)에 붙고, 과정은 학과에, 학과는 기관에 붙는다. ### 개발 - **운영 도구가 먼저다** – 공개 화면보다 관리자 대기열을 먼저 만들었다. 수집한 후보는 사람이 날짜·장소·취소 여부를 확인해야 게시된다. - **메타데이터 카드가 기본 표현이다** – 포스터가 없어도 카드가 성립하도록 타이포그래피만으로 설계했다. 권리가 확인된 포스터는 그 위에 얹힌다. - **비용을 구조로 눌렀다** – 이벤트는 배치로 보내고 매일 밤 집계한다. 대시보드는 집계 테이블만 읽는다. ## 회고 공개 배포 전이다. 사용 데이터로 검증된 것은 아직 없다. 아래는 만드는 동안 유지된 판단과 지금 남아 있는 질문이다. ### 맞았던 것 - **화면보다 관계를 먼저 정한 것.** 학교 페이지, 학과 페이지, 연도 목록이 각각 다른 화면이 아니라 같은 관계의 다른 단면이 됐다. 나중에 작업·사람으로 넓힐 때 스키마를 다시 짜지 않아도 된다. - **과정과 에디션을 나눈 것.** 연도를 잇는 것이 이 제품의 유일한 구조적 이점이라, 그 분리가 제품의 근거 자체였다. - **첫 제품을 운영 도구로 잡은 것.** 사람이 확인하는 시간이 서비스의 상한이라는 판단은 지금도 유효하다. ### 틀렸던 것 - **포스터를 인덱스의 기본 이미지로 쓰려고 했다.** 포스터는 그 자체로 누군가의 작업이다. 권리를 확인할 방법이 없어서 중립 메타데이터 카드를 기본 표현으로 다시 만들었다. - **공공데이터 목록 하나로 마스터가 만들어진다고 봤다.** 학과 이름만으로는 디자인 학과가 추려지지 않았다. 217개 기관을 따로 확인하고, 1차 대상을 90개로 다시 좁혔다. - **사용 데이터가 반박한 판단은 아직 없다.** 지금까지 바뀐 것은 전부 만드는 동안의 판단이다. ### 다음에 확인할 것 - **핵심 지표가 움직이는지** – 한 세션에서 서로 다른 학교를 2곳 이상 보는 비율. 첫 시즌의 실측값으로 계속할지를 정한다. - **운영 도구의 실제 처리 시간** – 전시 하나를 확인해 올리는 데 사람이 몇 분 쓰는지 아직 재지 않았다. 이 값이 커버리지의 상한이다. - **포스터 없는 카드가 눌리는지** – 중립 메타데이터 카드가 포스터 없이도 클릭되는지 모른다. - **다음 축** – 졸업전시에서 작업, 사람, 캡스톤, 협업으로 넓힐지는 첫 시즌의 검증 결과로 정한다. --- ### Gatherly — 삼성전자 가전사업부 산학 프로젝트 https://jaeyongbae.com/ko/work/gatherly/ 기간: 2026.03 – 2026.06 · 역할: 데이터 시각화 설계 · 코드 프로토타입 · UX 라이팅 · 팀: 팀 프로젝트 삼성전자 가전사업부와 한 산학 프로젝트. 파트너사 자료가 함께 있어 내용을 공개하지 않는다. 필요하시면 따로 요청해 주시면 자료를 드린다. ## 요약 ## 개요 삼성전자 가전사업부(DA)와 함께 한 산학 프로젝트다. 2026년 3월에 시작해 6월에 끝났다. 팀 프로젝트였고, 팀이 함께 한 일과 내가 맡은 일이 다르다. - **팀이 함께 한 것** – 필드 리서치, 페르소나, Figma 화면, 발표 자료. - **내가 맡은 것** – 데이터 시각화 설계, 코드 프로토타입, UX 라이팅 체계. ## 과정 ### 리서치 리서치는 팀이 함께했다. 방법만 적는다. - **실사용자 서면 인터뷰 7명** – 해당 제품을 실제로 쓰는 사용자. 2026.03.25–30. - **가구 단위 대면 인터뷰 3가구** – 3인·4인·5인 가구를 방문해 구성원을 한 명씩 만났다. 2026.03.27–29. - **다이어리 스터디 3명** – 20대 여성·20대 남성·40대 여성. 2026.03.25–28. - **전문가 인터뷰와 매장 관찰 1명** – 오프라인 매장에서 판매 담당자를 인터뷰하고, 사람들이 실제로 화면을 어디부터 보는지 관찰했다. - **데스크 리서치** – 트렌드 정리와 경쟁 제품 비교. ### 프로토타입 같은 데이터를 여러 방식으로 그려 비교하는 도구를 먼저 만들었다. 화면을 고른 뒤 근거를 찾는 순서를 뒤집기 위해서다. - **시각화 렌더러 13종** – 같은 데이터셋을 13가지 방식으로 그려 나란히 비교했다. 후보 6종으로 좁히고, 최종 기본값 1종을 골랐다. 전부 직접 쓴 코드다(산출물). - **비교 기준을 먼저 정했다** – 짧은 시간에 읽히는가, 값의 크기가 바로 보이는가, 여러 값을 한 화면에 담는가, 불확실성을 표현하는가. 이 네 가지로 평가했다. - **불확실성을 시각 속성으로 옮겼다** – 확률은 색온도로, 신뢰도는 경계의 안정성으로 나타냈다. 확실하지 않은 값이 확실해 보이면 안 됐다. - **UX 라이팅** – 문구 28개의 1:1 수정안을 쓰고, 확률 구간별 분기까지 넣어 60여 개 문안으로 정리했다. 확실하지 않은 값에 확신하는 말투를 쓰지 않는 규칙을 함께 정했다. 프로토타입은 시나리오 데이터로 돈다. 학습된 예측 모델은 없다. 화면의 숫자는 전부 화면 설계용 예시 값이다. 예측 정확도를 측정한 수치는 없다. **공개하지 않는 것** – 파트너사 자료가 함께 있어 다음은 이 페이지에 싣지 않는다. 삼성이 제공한 내부 디자인 가이드라인의 수치와 서체 이름, 내부 화면과 스크린샷, 아직 공개되지 않은 제품의 세부 사항, 파트너사의 내부 수치와 판단. 자료는 따로 요청하시면 드린다. [jaeyongbae11@gmail.com](mailto:jaeyongbae11@gmail.com)으로 연락 주시면 된다. --- ### Distance of Thinking — 언어 모델의 확률장을 비행하는 설치 작업 https://jaeyongbae.com/ko/work/distance-of-thinking/ 기간: 2026.05 – 2026.06 · 역할: 개념 · 인터랙션 · 개발 (1인) · 팀: 1인 관람객이 언어 모델의 실제 다음 토큰 확률장 속을 비행하고, 그 비행 경로가 곧 모델의 답이 되는 인터랙티브 설치 작업. ## 요약 ## 개요 관람객은 우주선을 몰고 모델이 계산한 확률의 터널을 지난다. 통과한 단어가 하나씩 답으로 확정된다. 클라우드 API 대신 로컬 모델을 쓴다. 그래서 전시장에서 인터넷 없이 돌아간다. 아래 화면과 녹화는 모두 전시 모드에서 로컬 Ollama의 Llama 3가 실제로 낸 확률로 만들었다. 조종은 마우스(기울기 센서 대신), 온도는 마우스 휠(다이얼 대신)로 했다. ## 문제 이 작업은 AI를 '생각하는 존재'가 아니라 **다음 토큰의 확률을 반복해서 계산하는 시스템**으로 다룬다. 조건은 하나였다. 확률을 은유로 그리지 않고 모델이 실제로 계산한 값을 쓴다. 이 작업은 환각을 **확률이 낮은 쪽으로 수렴한 결과로 모델링했다.** 실제 언어 모델에서 환각이 왜 생기는지를 설명하는 주장은 아니다. 작업이 보여주는 것은 "낮은 확률을 계속 고르면 문장이 어떻게 무너지는가"까지다. ## 핵심 결정 ## 과정 ### 작동 방식 1. **토큰으로 나누기** – 관람객이 입력한 문장을 실제 Llama 3 토크나이저로 나눈다. 2. **의미 공간** – 토큰마다 4,096차원 임베딩을 받아 3차원으로 투영하고, 가까운 토큰끼리 선으로 잇는다. 3. **다음 토큰 후보** – 모델에 한 토큰씩 요청해 상위 6개 후보와 그 확률을 받는다. 가장 확률 높은 후보가 정면에, 낮은 후보가 바깥 고리에 놓여 터널을 이룬다. 4. **조종** – 기울기 센서(MPU6050)로 가지를 고르고, 로터리 다이얼로 온도를 바꾼다. 온도는 화면의 장을 넓힌다. 같은 값이 모델에도 그대로 전달된다. 5. **무너지는 문장** – 낮은 확률의 가지로 벗어날수록 작업이 불안정성 값을 올리고, 철자가 어긋난 '유령' 단어를 낸다. 모델의 출력이 아니라 작업이 정한 규칙이다. ### 전시 준비 - **전시 모드** – 운영 UI를 숨기고, 75초 동안 입력이 없으면 스스로 도는 화면으로 넘어간다. - **예열** – 관람 전에 모델을 미리 불러오는 버튼. 생성이 실패해도 로컬 대체 흐름이 화면을 이어간다. - **네트워크** – 센서를 읽는 Web Serial은 보안 컨텍스트에서만 돌아간다. 그래서 클라우드 배포 대신 사설 네트워크의 HTTPS 주소 하나로 운영한다. ## 회고 ### 맞았던 것 - **보여주는 것이 사실이어야 설득된다.** 확률을 흉내 내는 대신 실제 값을 쓰기로 하자, 작업의 주장과 구현이 같은 말을 했다. - **로컬 모델을 고른 것.** 실제 확률을 받을 수 있고, 전시장에서 인터넷 없이 돌아간다. 클라우드 API였다면 둘 다 잃었다. - **입력을 하나 버린 것.** 흔들기를 빼자 조작과 작업의 전제가 어긋나지 않았다. ### 틀렸던 것 - **한 모델로 두 언어를 감당할 수 있다고 봤다.** 한국어를 잘 쓰는 모델이 영어에서는 같은 말을 되풀이했다. 언어에 따라 모델을 나눴다. - **흔들어서 문장을 무너뜨리는 것이 좋은 인터랙션이라고 봤다.** 재미는 있었지만 원인이 관람객의 손으로 옮겨가, 작업이 말하려던 것과 반대가 됐다. - **센서를 쓰면서 클라우드에 올리면 된다고 봤다.** Web Serial은 보안 컨텍스트를 요구했다. 사설 네트워크의 HTTPS 한 주소로 운영 방식을 다시 짰다. ### 다음에 확인할 것 - **관람객이 '확률'을 읽어내는지 모른다.** 전시장에서 관람 기록을 남기지 않았다. 이 작업이 개념을 전달하는지 측정한 값은 없다. - **실물 조형물은 만들지 못했고,** 아두이노 컨트롤러는 실제 연결 테스트를 마치지 못했다. 지금까지의 조종은 모두 마우스 대체 입력이다. - **장시간 안정성** – 몇 시간을 연달아 돌렸을 때 로컬 모델과 시리얼 연결이 버티는지 확인하지 않았다. --- ### NUN — 눈높이를 맞추는 좌석 https://jaeyongbae.com/ko/work/nun/ 기간: 2026.03 – 2026.07 · 역할: 기획 · UX 설계 · 팀: 기아 DEX 산학 앉는 사람의 눈높이를 맞추는 좌석. 모터 없이 앉는 하중만으로 한쪽이 내려가고 반대쪽이 올라오는 오리가미 구조로, 공원 벤치에서 자율주행 실내까지 같은 원리를 옮겼다. {/* NUN – 기아 DEX 산학. 아래 숫자는 산출물의 개수이고, 사용자 검증 수치는 아직 없다. */} ## 요약 ## 개요 기아 DEX와 함께 한 공유 모빌리티 실내 프로젝트에서 출발했다. 목표는 공간이 강요하는 세 가지 긴장(관계·공간·신체)을 없애는 것이었다. 그중 눈높이 축을 실제로 구현할 수 있는지가 남은 질문이었다. NUN은 그 질문을 끝까지 파고든 결과다. 기획에서 실현성 검증으로 이어지는 작업이다. 검증은 시뮬레이션과 종이 모형까지다. 실물 목업과 사용자 테스트는 하지 않았다. ## 문제 자율주행 레벨 4 이상에서는 '운전'이라는 역할이 사라지고, 공유 모빌리티에서는 모르는 사람과 함께 타는 일이 기본값이 된다. 그때 탑승자는 세 가지 긴장을 강요받는다고 봤다. - **관계의 긴장** – 눈높이의 비대칭. - **공간의 긴장** – 시야를 고를 수 없음. - **신체의 긴장** – 몸과 공간이 맞지 않음. 동승 형태, 신체 조건, 이동 목적은 탑승할 때마다 다시 정해진다. 고정된 실내는 그 전부에 같은 상태를 준다. ## 핵심 결정 ## 과정 ### 리서치 - **논문 기반 데스크 리서치** – 높이 차이가 위계를 만든다는 연구, 가변 좌석이 유연성은 높이지만 사생활은 해친다는 연구, 조망-피신(Prospect–Refuge) 이론 등. 인용은 저자와 연도까지만 쓴다. 수치를 그대로 옮기지 않았다. 위요감의 기본 범위를 정할 때 참고한 논문은 저자와 제목을 확정하지 못해 이 페이지에 숫자로 쓰지 않았다. - **구조 리서치** – 오리가미 패턴 6종(Kresling, Yoshimura, Miura tube, Bellows, Waterbomb, Resch)을 수직 변화 · 하중 · 제작성으로 비교했다. Kresling은 압축과 비틀림이 연동되고 쌍안정이라 코어 후보로 남았다.
발표된 연구 세 편을 참고했다. Sarrus 자기잠금 링키지(Kim et al., Science Robotics 2018)는 1자유도 직선 운동과 직교 접힘 특이점 잠금을 함께 가진다. 이중변형 오리가미(Kim et al., Science Robotics 2019)는 펼침 뒤에 팽창이 오는 준순차 변형으로, 감싸는 동작의 근거가 된다. 가변 강성(Park et al., IEEE RA-L 2023)은 패싯 버클링으로 강성을 바꾼다. 여기서 설계 원칙 하나를 정했다. 스칼라 입력 하나와 국소 기하 프로그래밍으로, 액추에이터 없이 분산·순차 동작을 만든다. 부품마다 모터를 달지 않고 구조 자체가 신호와 동력의 전달 매질이 된다.
하중지지 · 컨셉 부합 · 감쌈 · 평상시 평탄성 · 전개 연출 · 제작 용이성 · 양산 확장성 · 전개 중 안전성. 여덟 항목을 같은 표에 놓고 비교해 골격 + 장력막 하이브리드를 골랐다. 한 안이 모든 항목에서 이기지는 않았다.
### 디자인 - **인터페이스 3단계** – 탑승 전 앱에서 상태를 미리 고른다. 차 안에서는 슬라이더 3개와 프리셋 3개로 조절한다. 이후에는 자세·압력 센서와 도시의 맥락(터널 진입, 강변, 정체)으로 상태 전환을 제안하고, 탑승자가 수락하거나 거절한다. - **시나리오 6가지** – 눈높이 비대칭, 몸과 공간의 불일치, 중요한 대화, 도시 속 피크닉, 혼자만의 공간, 비 오는 날의 쉼터. - **시나리오마다 판정 지표를 먼저 정했다** – 주관 지표(편안함 척도, 위계 인식 문항, 재이용 의향), 행동 지표(상태 전환 횟수, 제안 수락률, 유지 시간), 생체 지표(GSR·HR·HRV). 측정은 하지 않았다. 지표 설계까지다. ### 개발 이 단계의 목표는 디지털 변수와 물리 메커니즘이 같은 곳을 가리키게 하는 데 있었다. 프리셋은 하드웨어가 아니라 데이터고, 데이터는 소프트웨어 업데이트로 늘어난다.
세 축은 소프트웨어 변수다. `eyeLevel.offset`(연속량)·`eyeLevel.matchMode`(auto|manual|off), `view.aperture`(0~100)·`view.mode`, `enclosure.ratio`·`enclosure.curl`. 실내 상태는 `{eyeLevel, viewAperture, enclosure}` 3차원 벡터다. 세 축 모두 연속량이라 상태는 무한하다. 그중 심리적으로 의미 있는 점 3개를 프리셋(의도된 긴장·조망·피신)으로 정의했다. 프리셋은 하드웨어가 아니라 데이터라서, 프리셋을 늘리는 일은 소프트웨어 업데이트로 끝난다.
L0 구조(오리가미 골격·잠금, 하드웨어), L1 구동(무게 구동 메커니즘, 하드웨어), L2 제어(세 축의 목표값을 궤적과 안전 구속으로 바꿈, 소프트웨어), L3 경험(프리셋·씬·자동 제안 규칙, 소프트웨어·OTA), L4 서비스(구독·개인화·파트너 콘텐츠, 소프트웨어). 하드웨어가 끝나는 선과 소프트웨어가 시작하는 선을 먼저 그었다. `POST /cabin/state`로 세 축의 목표값을 보낸다. `POST /cabin/preset`은 프리셋을 부른다. `GET /cabin/capability`는 그 차량이 지원하는 축과 범위를 돌려준다. `POST /cabin/suggest`가 제안을 띄우면, 탑승자의 수락·거절이 `cabin.suggestion.accepted`·`.rejected` 이벤트로 남아 학습 데이터가 된다. 구현된 서버가 아니라 스케치다.
### 프로토타입 - **물리 시뮬레이터 17종(산출물)** – 네 갈래로 나눴다. 무게 구동 시소군 3종(강체링크 · 롤링 로커 · 평행사변형), 순수 오리가미군 5종(접이 apex 시소 · Kresling 트위스트 · 아코디언 · 등맞댄 웨이브 · 지면지지형), 공압군 6종, 메커니즘 스터디군 3종(지렛대 · 아코디언 · Sarrus 직선운동). - **설계 → 검증 → 제작 파이프라인** – 강체 패널 사슬 시뮬레이션(PBD), GPU 오리가미 시뮬레이터 개조, Python 접힘 패턴 생성기, 전개도 SVG 내보내기. - **새 개념은 기존 파일을 덮지 않고 새 파일로 쌓았다** – 버려진 안도 근거로 남긴다. 의사결정 이력을 나중에 따라갈 수 있어야 한다고 봤다. ## 결과 결과는 산출물과 검증 설계까지다. 사용자 성과는 없다. - **검증 수준** – 시뮬레이션과 종이 모형. 실물 목업은 만들지 않았고, 실사용자 테스트도 하지 않았다. - **확인한 한계** – 극단적인 무게비에서는 무게 구동만으로 눈높이를 완전히 맞출 수 없다. - **측정하지 않은 것** – 편안함, 위계 인식, 긴장 완화. 지표는 설계했지만 값은 없다. ## 회고 ### 맞았던 것 - **좋은 해법은 기능을 더해서가 아니라 제약을 다시 봐서 나온다.** 모터를 빼자 좌석의 문제가 다르게 보였다. 높이를 맞춰야 하는 두 사람은 이미 서로 다른 무게로 구조를 누르고 있었다. - **세 축을 소프트웨어 변수로 정의한 것.** 프리셋이 하드웨어가 아니라 데이터가 되면서, 경험을 늘리는 일이 업데이트가 됐다. - **자동 실행 대신 제안과 수락으로 둔 것.** 공간을 알아서 바꾸는 시스템은 또 하나의 강요다. 수락·거절 기록이 개인화의 재료도 된다. ### 틀렸던 것 - **제어를 더 정교하게 만들면 된다고 봤다.** 모터와 텐던으로 정밀 제어는 됐다. 그런데 공공·공유 환경에서는 전력과 유지보수가 정밀함보다 먼저 문제가 된다. - **무게 구동이면 모든 체격 조합을 맞출 수 있다고 봤다.** 극단적인 무게비에서는 못 맞춘다. 해결하지 못한 것을 해결한 척하면 그다음 설계가 전부 틀어진다. - **논문 수치를 설계 파라미터로 바로 쓸 수 있다고 봤다.** 참고한 연구 하나는 저자와 제목을 확정하지 못했다. 그래서 그 숫자는 페이지에서 뺐다. ### 다음에 확인할 것 - **실사용자 검증** – 눈높이가 맞았을 때 위계 인식이 실제로 줄어드는지 아무것도 재지 않았다. 설계한 지표로 첫 측정을 해야 한다. - **물리적 한계** – 반복 내구성, 소음·진동, 온도, 충돌 안전. 시뮬레이션에서 다음 단계로 넘어가려면 실물이 필요하다. - **무게 구동의 유효 범위** – 어느 무게비까지 맞출 수 있는지 실물로 재야 한다. 0W도 실물에서 다시 확인할 값이다. - **원가와 규제** – 공유 차량 실내에 들어가려면 양산 원가와 안전 규제를 통과해야 한다. --- ### KTX 정보 표시 — 탑승 전–이동 중–도착 후의 정보 구조 https://jaeyongbae.com/ko/work/ktx/ 기간: 2026 봄 · 역할: 기획 · UX 설계 (개인) · 팀: 1인 live: https://www.behance.net/gallery/245415477/Redesigning-the-KTX-Passenger-Information-Display 짧은 시간 안에 많은 정보를 전해야 하는 KTX 객실 화면을, 기능이 아니라 승객의 이용 흐름을 기준으로 다시 짠 작업. ## 요약 정보를 더하지 않고 순서만 다시 정했다. 기능별로 나뉘어 있던 객실 화면을 탑승 전–이동 중–도착 후의 흐름으로 다시 배열했다. ## 개요 독일 교환학기에 매일 탄 도이치반(DB)의 일관된 표기 체계가 출발점이었다. KTX 객실 화면은 짧은 시간에 여러 정보를 전해야 한다. 기존 구조는 기능 단위였다. 다음 역, 도착 시각, 환승, 편의시설, 안내 문구가 같은 무게로 놓였다. 지금 필요한 정보를 매번 찾아야 했다. 화면을 늘리지 않기로 했다. 정보를 더하면 찾는 시간도 늘어난다. 대신 순간마다 무엇을 먼저 읽게 할지 정했다. ## 결과물 - **흐름으로 나눈다** – 탑승 전, 이동 중, 도착 후로 순간을 나눴다. 각 순간에 필요한 정보만 남기고 나머지는 뺐다. - **다음 역 · 도착 · 어느 쪽 문** – 위계를 이 셋으로 고정했다. 다음 역과 도착 시각은 멀리서 읽히는 크기로 두고 나머지는 뒤로 물렸다. 문이 열리는 순간에는 어느 쪽 문인지만 크게 남는다. - **역명 다국어 체계** – 역 이름의 한국어, 영어, 일본어, 중국어 표기를 한 규칙으로 묶었다(4개 언어 · 산출물). 본문에서는 한국어와 영어가 한 레이아웃 체계를 함께 쓴다. 두 언어가 자리를 다투지 않는다. - **컴포넌트** – 상단 바, 역 목록, 진행 막대, 안내 배너, 편의시설을 같은 규칙으로 묶었다(5종 · 산출물). ## 회고 - **더하지 않고 순서를 정했다.** 화면 수는 늘리지 않았다. 일의 대부분은 순간마다 무엇이 먼저인지 정하는 것이었다. - **트레이드오프** – 한 순간에 하나를 크게 두면 나머지는 늦게 읽힌다. 환승과 편의시설은 도착 구간으로 미뤘다. - **검증하지 않은 것** – 사용성이 나아졌다고 말할 근거가 없다. 실제 차량의 시야 거리와 조도, 승객 대상 검증을 하지 않았다. 그래서 개선 수치는 쓰지 않았다. --- ### HarikomiMaker — 접어 묶을 수 있게, 쪽을 다시 앉히는 맥 앱 https://jaeyongbae.com/ko/work/harikomi-maker/ 기간: 2025.12 · 역할: 기획 · 디자인 · 개발 (1인) · 팀: 1인 중철 제본을 위해 PDF의 쪽 순서를 다시 앉히고 재단선을 그려 내보내는 macOS 앱. 원본을 절대 늘이거나 줄이지 않고, 안 맞으면 안 맞는다고 말한다. ## 요약 ## 개요 중철(가운데를 접어 스테이플로 묶는 방식)에서는 1쪽과 마지막 쪽이 한 장에 함께 인쇄된다. 그 배치를 계산하는 macOS 앱이다. GLIO의 전사다. 편집에서 반복되는 판단을 소프트웨어로 옮기는 일을 여기서 시작했다 – [GLIO](/ko/work/glio-works/). ## 문제 쪽수는 4의 배수여야 한다. 접었을 때 순서가 맞으려면 장의 앞뒤마다 어떤 쪽이 어디에 놓일지 계산해야 한다. 소책자 하나마다 같은 계산을 반복했다. 손으로 하면 틀리고, 틀린 것은 인쇄한 뒤에 보인다. 이 앱이 그 계산을 사람 대신 한다. ## 핵심 결정 ## 결과 같은 앱으로 내보낸 A4 중철 시트다. 왼쪽이 원본 쪽, 오른쪽이 접으면 순서가 맞는 시트다. Swift 757줄, 7개 파일, 외부 의존성 0개다(산출물). 사용 지표는 없다. 쓰는 사람이 나 하나다. ## 회고 - **도구는 거절할 줄 알아야 한다.** 자동으로 맞춰 주는 대신 멈추고 이유를 말하는 편이, 인쇄에서는 더 친절하다. - **트레이드오프** – 거절하면 사람이 원본을 고쳐야 한다. 조금 넘칠 때도 앱은 그냥 멈춘다. 빠른 출력보다 판형의 정확함을 택했다. - **남은 일** – 여러 장짜리 문서를 내보낼 때 첫 장에서 PDF 컨텍스트가 닫히는 문제가 있다. 4-up 배치와 도련 처리는 아직 없다. 다른 사람의 작업 흐름에서는 검증하지 못했다. --- ### Synthetic Vision Fund — 믿음을 만드는 인터페이스에 관한 전시 웹 https://jaeyongbae.com/ko/work/synthetic-vision-fund/ 기간: 2025.11 – 2026.01 · 역할: 기획 · 디자인 · 개발 (1인) · 팀: 1인 실재하지 않는 AI 투자 플랫폼이다. 기사, 투자 버튼, 결제, 확인 화면이라는 익숙한 절차를 그대로 흉내 냈다. 인터페이스와 용어가 어떻게 신뢰를 만드는지 보여 주는 전시용 웹이다. 실재하지 않는 서비스다. 전시를 위해 만든 가상의 AI 투자 플랫폼이다. 실제로 돈이 움직이지 않는다. ## 요약 ## 개요 Synthetic Vision Fund는 실재하지 않는 AI 투자 플랫폼이다. 지금 스타트업과 벤처 투자 문화가 쓰는 언어, 인터페이스, 절차를 그대로 따라 했다. 기사를 읽고, 투자 버튼을 누르고, 결제와 확인 화면까지 지나는 동작을 빠짐없이 재현했다. 제대로 된 금융 시스템에 참여한 것 같은 착각이 생긴다. 슈투트가르트 Merz Akademie에서 만들어 전시했다. ## 문제 겨냥한 대상은 AI라는 기술이 아니다. 인터페이스와 용어와 디자인 관습이 어떻게 신뢰를 만드는지다. 익숙한 순서는 그 자체로 근거처럼 읽힌다. ## 핵심 결정 ## 회고 ### 맞았던 것 - **설명하지 않고 재현한 판단.** 작품 안에 비판을 붙이지 않았다. 같은 절차를 직접 지나간 사람만 자기 믿음을 본다. - **관습이 신뢰를 만든다는 판단.** 익숙한 순서와 익숙한 단어가 설득의 대부분을 맡았다. ### 틀렸던 것 - **브랜드의 완성도가 설득의 핵심이라고 봤다.** 아니었다. 로고와 생성 그래픽보다 결제 단계의 순서가 더 강하게 작동했다. - **기록을 남기지 않기로 한 대가를 가볍게 봤다.** 관객이 어디까지 갔는지 말할 수 있는 자료가 하나도 없다. ### 다음에 확인할 것 - **의도한 1.5초 지연(설계값)** – 신뢰의 신호로 읽히는지, 그냥 느린 사이트로 읽히는지 구분하지 못했다. - **의심이 시작되는 지점** – 관객이 몇 번째 결제에서 이상함을 알아차리는지 모른다. - **전시 기록** – 아무것도 저장하지 않기로 했으므로, 다음에는 사람이 관찰 기록을 따로 남겨야 한다. --- ### Glide Console — 멀미 지표를 실시간으로 보는 웹 관제 https://jaeyongbae.com/ko/work/glide-saas/ 기간: 2026.05 – 2026.06 · 역할: 기획 · UX · 프론트엔드 (1인) · 팀: 1인 글라이드의 멀미 지표를 지도 위에서 보는 관제 화면. 서울 25개 자치구 점수와 진행 중인 주행, 실시간 이벤트를 한 화면에 놓고, 사람이 뒤에서 시나리오를 재현하는 실험 도구로 썼다. [Glide](/ko/work/glide/)의 연구 도구다. 알고리즘이 완성되기 전에 UX 가설을 검증하려고 먼저 만들었다. ## 요약 ## 개요 - **실험 제어** – 사람이 개입 시점과 채널과 강도를 직접 고른다. 탑승자 쪽 화면은 자동 시스템과 똑같이 보인다. - **자치구 점수** – 서울 전체 가중 평균을 0~100으로 보여준다. 높을수록 안전하다. 25개 구를 안전 · 주의 · 위험 · 매우 위험으로 나눠 분포를 함께 놓았다. - **위험 상위 5개** – 점수가 가장 낮은 구를 순서대로 세운다. 어디를 피해 경로를 잡을지 결정하는 화면이다. - **활성 운행** – 라이브 · 시뮬 · 게임 · 대기 네 가지 상태로 나눈 현재 주행 수. - **이벤트 기록** – 급제동, 급회전, 회복 조치, 경로 비교 요청이 시각과 함께 흐른다. 참가자 코드(P-001)로 묶여 나중에 세션 단위로 되짚을 수 있다. ## 문제 - **알고리즘이 먼저 완성되기를 기다릴 수 없었다** – 예고 시간, 침묵의 임계값, 감각 채널 전환은 모두 사람이 어떻게 느끼는지에 달린 문제다. 코드가 그 판단을 대신하기 전에 답을 알아야 했다. 사람이 대신 개입을 재현하는 방식(Wizard of Oz)으로 알고리즘보다 UX를 먼저 검증했다. - **왜 한 화면인가** – 멀미 가설을 검증하려면 센서, 시뮬레이션, 오디오, 햅틱, 비전(카메라) 튜닝이 동시에 맞아야 했다. 다섯 가지를 따로 다루는 도구로는 한 번의 주행을 그대로 재현할 수 없었다. - **지금** – 원래 연구 도구였다. 사업 방향이 바뀐 뒤 이 콘솔은 그대로 B2B 고객사용 제품 자산이 됐다. ## 핵심 결정
**센서** – 하드웨어가 붙어 있지 않으면 가짜 IMU 값으로 자동 대체한다. 보드가 없어도 같은 화면이 돈다. **시뮬레이션** – 캔버스 위에서 주행을 돌려 방위 변화로 회전을 찾아내고, 거기서 예고 신호를 자동으로 만든다. 같은 구간을 Glide를 켠 상태와 끈 상태로 돌려 비교할 수 있다. **오디오** – 100Hz로 동기 신호를 내고, 횡가속도가 임계를 넘으면 세기를 올린다. 아두이노 모터로 진동을 동시에 낸다. **비전** – 웹캠으로 머리 자세와 손-입 가림 제스처를 읽어 회복 단계를 한 칸 올린다. 영상은 저장하지 않는다.
## 과정 ### 지도 지도는 레이어 여섯 장을 겹친다. 멀미 밀도 히트맵, 자치구 폴리곤, 실시간 도로 속도, 돌발 상황, 신호등, 횡단보도. TOPIS 교통과 Tmap 도로, OSM/Overpass를 붙였다. ### 데이터 Supabase 한 곳에 일곱 개 표를 둔다. 참가자, 세션, 이벤트, 멀미 지수 시계열, 햅틱 발동 기록, 차량 위치, 자치구 점수. 세션의 모드는 라이브 · 시뮬 · 게임 · 대기 넷 중 하나다. 같은 화면으로 실차 데이터와 시뮬레이션을 모두 재현하기 위해서다. 보드가 없어도 가짜 센서 값으로 같은 화면이 돈다. ## 결과 - **본편 수치가 여기서 나왔다** – 이 콘솔의 시뮬레이션 엔진(`simDriveEngine.ts`)으로 같은 구간을 Glide on/off로 돌려 MSDV 누적 곡선을 비교했다. [Glide](/ko/work/glide/) 결과의 멀미 지표 수치(−77% · 시뮬레이션)가 그 비교값이다. 실차 대조군 실험은 하지 않았다. - **네 축을 한 화면에 모았다** – 물리(IMU 기반 MSDV), 생체(심박 · 머리 자세), 주관(MISC · FMS), 행동(카메라로 읽는 제스처). 네 축이 같은 방향을 가리킬 때만 효과가 있다고 판정하도록 설계했다. 네 축 모두 만들었지만 표본이 적어 통계적 유의성은 없다. - **배포** – Vercel 프로덕션에 올렸다. 이 페이지의 영상은 아래 세 가지를 고친 뒤 다시 찍은 화면이다. ## 회고 ### 맞았던 것 - **알고리즘보다 도구를 먼저 만든 것.** 예고와 침묵이 통하는지 코드가 판단하기 전에 확인했다. 그리고 실험용으로 만든 관제 화면이 그대로 고객사가 쓸 제품 자산이 됐다. - **보드 없이도 같은 화면이 돌게 한 것.** 하드웨어가 빠졌을 때 실험과 시연이 멈추지 않았다. - **스키마를 레포에 남겨 둔 것.** 데이터베이스가 사라진 뒤 새 프로젝트에 그대로 다시 올렸다. ### 틀렸던 것 - **배포하면 끝이라고 봤다.** 넉 달 만에 화면이 비었다. 원인 세 가지가 겹쳤다. - **데이터베이스가 사라졌다** – 무료 플랜에서 오래 쉬던 프로젝트가 삭제됐다. 주소가 응답하지 않는 수준이 아니라 이름 자체가 사라졌다. - **지도 공급자가 정책을 바꿨다** – 키 없이 쓰던 타일에 "API KEY REQUIRED" 워터마크가 찍히기 시작했다. 키가 필요 없는 다른 타일로 갈아탔다. - **조건 하나가 거꾸로였다** – 자치구 패널이 늘 0이던 이유는 데이터가 아니라 `if (!cancelled || !data) return;` 한 줄이었다. 정상 응답에서도 늘 빠져나갔다. - **빈 화면을 먼저 데이터 문제로 의심했다.** 원인은 코드 한 줄이었다. 서비스는 고쳐 두면 끝나지 않는다. 남이 정한 무료 한도와 정책이 바뀌면 멀쩡하던 화면이 조용히 빈다. ### 다음에 확인할 것 - **표본을 늘려 네 축을 맞춰 보는 것.** 축은 다 있고 사람이 부족하다. - **보드와 앱의 직접 연동.** 지금은 웹을 경유한다. 블루투스 직접 연동은 아직 손대지 않았다. - **남의 무료 한도에 기댄 부분이 또 어디에 남아 있는지.** --- ### 리블: ON THE WAY — Pleos 입점 타당성 검토 https://jaeyongbae.com/ko/work/pleos/ 기간: 2026.09 · 역할: 타당성 검토 · 화면 설계 (개인) · 팀: 1인 현대차 Pleos에 리블을 올릴 수 있는지 검토한 기록. 제약을 먼저 찾고, 화면을 줄이는 대신 상황을 좁혔다. 리블의 ON THE WAY 갈래다. 본편: [Reevl](/ko/work/reevl/) ## 요약 리블을 차 안으로 옮길 수 있는지 검토했다. 답은 "그대로는 안 된다"였다. 플랫폼 제약을 먼저 찾고, 화면을 줄이는 대신 쓰는 상황을 하나로 좁혔다. 화면 세 장은 설계까지 했고 아직 만들지 않았다. ## 개요 현대차의 인포테인먼트 Pleos Connect를 대상으로 한 개인 검토다. 2026년 9월에 했다. 현대자동차그룹 UX 스튜디오 서울의 리서치 크루로 참여하며 플랫폼을 실제 차 안에서 만져 봤다. ## 문제 리블은 웹과 모바일에서 쓰는 부동산 터미널이다. 차 안은 여덟 번째 표면이다. 앞의 일곱 곳에서 통하던 가정이 여기서 하나 더 깨진다. 화면이 있으면 보여줄 수 있다는 가정이다. ## 핵심 결정 ## 과정 실현성은 이미 가진 것으로 확인했다. 차량 위치에서 주변 단지를 띄우는 일은 리블이 쓰는 자산만으로 된다. 단지 좌표 45,000개와 시군구별 nearby 샤드(67KB)가 있어 서버를 더 두지 않아도 된다. 화면은 세 장으로 정했다. 임장 모드(주차 중, 현위치 주변 단지 카드 세 장과 지도 핀), 단지 한 장(대표 시세를 크게 두고 전세가율 · AI 1년 · 역세권 · 배정초 네 칸과 AI 브리핑), 주행 중 안내다. 규격은 12.3인치 와이드 기준 1920×720, 색은 리블의 다크 토큰을 쓴다. 세 장은 설계 단계에서 멈췄다. 이 검토의 목적은 제약을 확인하는 데 있었다. 구현은 하지 않았다. ## 결과 --- ### Close to Miracles — 허드슨강 착수 사고의 조종실 음성 기록을 편집하다 https://jaeyongbae.com/ko/work/hudson/ 기간: 2025.12 – 2026.01 · 역할: 편집 · 타이포그래피 (개인) · 팀: 1인 2009년 US 에어웨이즈 1549편의 조종실 음성 기록(CVR) 전사본을 32쪽 책과 614×861mm 포스터로 옮긴 작업. 시각은 쪽번호가 되고, 채널은 단이 된다. ## 요약 ## 개요 2009년 1월 15일, US 에어웨이즈 1549편은 이륙 직후 새 떼와 충돌해 두 엔진을 잃고 허드슨강에 내려앉았다. 승객 150명과 승무원 5명이 모두 살아 나왔다. 원문은 미국 교통안전위원회(NTSB)가 공개한 조종실 음성 기록 전사본이다. 문장은 그대로 두고, 구조만 다시 짰다. ## 결과물 - **시각이 쪽번호가 된다** – 15:00:32에서 15:30:44까지, 쪽마다 그 지면이 담은 시각을 쪽번호로 매겼다. 쪽을 넘기는 일이 시간이 흐르는 일이 된다. - **채널이 단이 된다** – 조종실 안(HOT·CAM), 무선 교신(RDO·INTR), 자동 경고(GPWS), 기내 방송(PA)을 각각 다른 단에 놓았다. 누가 어디에 대고 말했는지 읽기 전에 보인다. - **한 가지 서체로** – 본문은 IBM Plex Mono, 제목과 설명은 IBM Plex Sans. 모든 발화가 같은 폭을 쓰므로 침묵과 동시 발화가 공간으로 드러난다. - **같은 데이터를 책과 포스터로** – 614×861mm 한 면에 전체 기록을 앉혔다. 책은 시간순으로 읽히고, 포스터는 사고 전체가 한눈에 들어온다. ## 회고 - **편집은 해석이다.** 문장을 바꾸지 않아도, 무엇을 단으로 나누고 무엇을 쪽번호로 삼느냐가 이해를 정한다. - **트레이드오프** – 포스터는 전체를 한눈에 보여 주지만 순서대로 읽기 어렵다. 책은 그 반대다. 그래서 같은 데이터를 두 형태로 만들었다. - **남은 것** – 포스터의 자동 조판에서 생긴 작업용 표식이 파일에 일부 남아 있다. 다시 찍는다면 그 정리부터 해야 한다. --- ### Hi, High! — 대한민국공군 온보딩 키트 https://jaeyongbae.com/ko/work/airforce-onboarding/ 기간: 2024 가을 · 역할: 개인 live: https://www.behance.net/gallery/245410791/-Hi-High-On-Boarding-Kit · press: https://kookbang.dema.mil.kr/newsWeb/20231228/1/ATCE_CTGR_0010050000/view.do Hi, High!는 공군에 입영한 사람을 응원하는 온보딩 키트다. 군 기관의 기존 이미지에서 벗어나 일관된 브랜드 경험을 만들고, 구성원의 정체성을 강화하는 것이 목표였다. {/* 2021–2024 visual work, from the printed portfolio "Records & Memories" (기록과 기억). */} ## 요약 공군본부 미디어콘텐츠과의 인하우스 디자이너로 1년 9개월(2023년 10월–2025년 6월) 일하며 만든 작업이다. Hi, High!는 공군 입영자에게 주는 온보딩 키트다. 2024년 가을에 설계하고 발주와 납품까지 맡았다. 같은 기간에 한 다른 작업은 [고마워 우리의 도깨비](/ko/work/airforce-dokkaebi/)에 있다. ## 개요 소속은 공군본부 공보정훈실 미디어콘텐츠과다. 6만 명 규모 조직의 공식 커뮤니케이션을 만드는 부서다. 이 부서가 운영하는 유튜브 채널 '대한민국 공군'은 2023년 12월 누적 조회수 1억 뷰를 넘었다 ([국방일보, 2023.12.27](https://kookbang.dema.mil.kr/newsWeb/20231228/1/ATCE_CTGR_0010050000/view.do)). 타우러스 실사격 1510만 뷰, '레 밀리터리블' 662만 뷰를 낸 채널이다. 굿즈와 인쇄물도 같은 톤을 써야 했다. 온보딩 키트의 기준은 군 기관의 관행이 아니라 그 채널이었다. ## 결과물 기성품에 로고만 찍지 않았다. 남대문 상가와 모나미 본사를 직접 찾아가 소재의 촉감과 사용감을 하나하나 검수했다. 플래너, 노트, 큐브 메모지, 쇼핑백은 한 세트로도, 따로도 쓸 수 있게 설계했다. 배포 조건이 바뀌어 전체 패키지를 그대로 배포할 수 없게 되자 단품 배포로 전략을 바꿨다. 구성품마다 쓰임을 따로 둔 덕에 키트를 다시 만들지 않고 전환했다. 납품은 혼자 하지 않았다. 대량 발주는 공급업체와, 배포는 다른 부서와 조율해 마쳤다. ## 회고 디자인 파일이 끝이 아니었다. 소재와 발주 수량, 배포 경로가 결과물의 절반을 정했다. --- ### 고마워 우리의 도깨비 — 대한민국공군 F-4 퇴역 기념 굿즈 https://jaeyongbae.com/ko/work/airforce-dokkaebi/ 기간: 2024 봄 · 역할: 개인 press: https://www.aeroflap.com.br/en/south-korea-makes-special-flight-to-say-goodbye-to-f-4-phantom/ F-4 팬텀 퇴역을 기념해 만든 굿즈다. 미디어데이와 퇴역식 등 행사의 기념품으로 쓰였다. 55년을 복무한 기체를 친근한 스타일로 그려 전 세대가 함께 기억하게 했다. {/* 2021–2024 visual work, from the printed portfolio "Records & Memories" (기록과 기억). */} ## 요약 공군본부 미디어콘텐츠과의 인하우스 디자이너로 1년 9개월(2023년 10월–2025년 6월) 일하며 만든 작업이다. F-4 팬텀 퇴역 TF에서 기념 굿즈를 만들고 유튜브 콘텐츠를 함께 기획했다. 같은 기간에 한 다른 작업은 [Hi, High!](/ko/work/airforce-onboarding/)에 있다. ## 개요 국방부 주관 F-4 팬텀 퇴역 TF에서 굿즈를 맡았다. 굿즈는 미디어데이와 퇴역식의 공식 기념품으로 쓰였다. 1960년대 중반부터 220여 대가 한국 하늘을 지켰다. F-4는 2024년 5월 고별 비행으로 55년의 임무를 마쳤다. 팬텀 4대와 차세대 전투기 KF-21 2대가 경기 · 전라 · 경상 상공을 세 시간 동안 함께 날았다. 공식 퇴역식은 6월 7일이었다. 이 비행은 국외 항공 매체에도 실렸다 ([Aeroflap, 2024.05.13](https://www.aeroflap.com.br/en/south-korea-makes-special-flight-to-say-goodbye-to-f-4-phantom/)). ## 결과물 기체가 아니라 팬텀의 상징인 도깨비를 다시 그렸다. 한국화풍의 친근한 도깨비로 옮겨, 퇴역식에 모인 전 세대가 같은 대상을 기억하게 했다. 같은 그림을 미디어데이와 퇴역식 굿즈에 함께 썼다. 함께 기획한 유튜브 콘텐츠 「팬텀을 찾아서」는 40만 뷰를 기록했다. 기존 시리즈의 3배다. 이 공로로 미디어콘텐츠과가 2024년 '공군을 빛낸 인물' 단체상을 받았다. 부서 단위 수상이다. ## 회고 결정권자는 디자이너가 아니었다. 그래서 근거를 눈에 보이게 했다. AI 도구로 수십 개의 변형을 만들어 나란히 놓자, 취향의 문제가 선택의 문제로 바뀌었다. --- ### 콤마프로젝트 — 휴식을 재정의하다 https://jaeyongbae.com/ko/work/comma-project/ 기간: 2023 여름 · 역할: 3인 팀 · 웹 디자인 기여도 100% (캐릭터 일러스트 제외) 학교 안의 소외된 공간을 쉼터로 되살리고, 그 공간을 안내하는 웹사이트를 만들었다. 늘 쫓기듯 사는 일상을 Doing이라 정의하고 잠시 멈추기를 권했다. 잡념을 지우고 ‘나’에게 집중하는 시간이 Being이다. 우리는 그 시간을 본질적인 휴식이라 불렀다. {/* 2021–2024 visual work, from the printed portfolio "Records & Memories" (기록과 기억). */} ## 요약 학교 과제로 시작해 실제 공간과 작동하는 웹사이트까지 만든 작업이다. 2023년 여름, 3인 팀에서 웹 디자인을 맡았다. 학교 안의 소외된 공간을 쉼터로 되살리고, 그 공간을 안내하는 사이트를 만들었다. ## 개요 쫓기듯 사는 시간을 Doing, 잡념을 지우고 '나'에게 집중하는 시간을 Being이라 불렀다. Being을 본질적인 휴식으로 정의하고 잠시 멈추기를 권했다. 과제는 제안서로 끝날 수도 있었다. 대신 공간을 직접 정리하고 원칙을 세워 실제로 운영했다. ## 결과물 웹사이트는 Our Zone, Map, Archive로 나눴다. 공간을 소개하고, 위치를 찾게 하고, 기록을 남기는 순서다. 창문에는 캐릭터 그래픽을 붙여 공간과 사이트가 같은 그래픽을 쓰게 했다. 캐릭터 일러스트는 팀원이 그렸다. ## 회고 목업으로 끝나는 웹 디자인과 실제로 돌아가는 사이트는 다른 일이었다. 구현 가능한 범위를 먼저 확인하고 화면을 다시 잡았다. --- ### 초점을 맞추다 — 시각장애에 대한 편견을 푸는 편집 · 그래픽 https://jaeyongbae.com/ko/work/focus-on-them/ 기간: 2022 겨울 · 역할: 개인 『초점을 맞추다』는 시각장애인을 향한 편견과 오해를 푸는 작업이다. 그 분야를 이해하는 태도를 세우는 것이 목표였다. {/* 2021–2024 visual work, from the printed portfolio "Records & Memories" (기록과 기억). */} ## 요약 『초점을 맞추다』는 시각장애인을 향한 편견과 오해를 푸는 편집 · 그래픽 작업이다. 2022년 겨울에 혼자 만들었다. 그래픽을 화면 안에서 합성하지 않고 직접 만들어 촬영했다. ## 결과물 책 한 권과 키 비주얼 포스터, 그래픽 두 점을 만들었다. 그래픽은 만화경과 빛을 모티프로 삼았다. 키 비주얼은 포토샵 합성 대신 상황을 직접 연출해 촬영했다. ## 회고 과정을 바꾸자 결과가 달라졌다. 손으로 만들어 찍은 질감은 합성으로 재현하지 못했다. --- ### 실험적 타이포그래피 — 타이포그래피 에세이 · 시각시 · 시각소설 https://jaeyongbae.com/ko/work/experimental-typography/ 기간: 2022 가을 · 역할: 개인 · 수업 수업 과제로 타이포그래피 에세이, 시각시, 시각소설을 만들었다. 일관된 톤과 매너로 모든 작업이 하나의 흐름을 갖게 했고, 그 결과를 순서대로 보여준다. {/* 2021–2024 visual work, from the printed portfolio "Records & Memories" (기록과 기억). */} ## 요약 타이포그래피 에세이, 시각시, 시각소설 세 종을 만들었다. 2022년 가을 수업 과제로 혼자 작업했다. 세 결과물에 같은 편집 규칙을 적용했다. ## 결과물 규칙을 먼저 정했다. 판형과 그리드, 서체 조합, 제목과 본문의 위계를 세 작업에 똑같이 적용했다. 실험은 그 규칙을 어기는 방식으로만 했다. 펼침면 배열표를 따로 만들었다. 글자 크기와 자간, 행의 방향이 어느 펼침면에서 바뀌는지 표에서 정하고 순서를 통제했다. ## 회고 실험은 규칙을 버리는 일이 아니었다. 기본 위계를 먼저 잡아 둔 뒤에야 어긋난 배열이 읽혔다. --- ### 지적자본론 — 책 리디자인 https://jaeyongbae.com/ko/work/intellectual-capital/ 기간: 2022 여름 · 역할: 개인 · 표지 및 내지 일부 『지적자본론』은 마스다 무네아키가 자신의 경영 철학을 담은 책이다. 그 철학의 핵심은 ‘고객 가치의 창출’과 ‘라이프스타일 제안’이다. 그 생각에 맞는 방식과 언어로 책을 다시 디자인했다. {/* 2021–2024 visual work, from the printed portfolio "Records & Memories" (기록과 기억). */} ## 요약 마스다 무네아키의 『지적자본론』을 다시 디자인했다. 2022년 여름, 표지와 내지 일부를 혼자 맡았다. 마이크로 타이포그래피를 처음 제대로 다룬 작업이다. ## 결과물 기존 판을 요소 단위로 뜯어 원래 디자이너의 의도를 먼저 읽었다. 그다음 본문 서체와 크기, 자간, 행간, 장 도입부의 위치를 다시 정했다. '고객 가치의 창출'과 '라이프스타일 제안'이라는 책의 주장을 표지와 내지 디자인으로 옮겼다. ## 회고 리디자인은 취향을 바꾸는 일이 아니었다. 기존 의도를 정확히 읽어 낸 만큼만 바꿨다. --- ### The Unseen — 본능의 시각화 https://jaeyongbae.com/ko/work/the-unseen/ 기간: 2022 봄 · 역할: 개인 본능이 사람의 몸에서 작용하는 방식을 시각화했다. 두 포스터는 세로로 이어지는 시리즈다. ‘본능’이라는 단어의 어원(찔러서 반응을 일으킴)에서 출발했다. {/* 2021–2024 visual work, from the printed portfolio "Records & Memories" (기록과 기억). */} ## 요약 '본능'을 하나의 시각 규칙으로 줄인 포스터 두 점이다. 2022년 봄에 혼자 만들었다. 단어의 어원인 '찔러서 반응을 일으킴'을 그대로 규칙으로 썼다. ## 결과물 규칙은 하나다. 찌르는 힘과 그에 반응하는 몸. 두 포스터를 세로로 이어 한 시리즈로 묶었다. 힘은 위에서 아래로 전달된다. ## 회고 보이지 않는 대상을 그리려면 규칙을 하나로 줄여야 했다. 심미성보다 그 규칙에 설득력이 있는지를 먼저 확인했다. --- ### 접촉; 다시 — 제24회 한국예술종합학교 영화과 졸업영화제 https://jaeyongbae.com/ko/work/kart-film-festival/ 기간: 2021 겨울 · 역할: 팀(봉사 활동) · 프로그램북 기여도 100% 한국예술종합학교 영화과가 해마다 여는 졸업영화제의 디자인물을 만들었다. 슬로건 「접촉; 다시」는 코로나 시기의 특수성을 담았다. 트레일러 영상이 이를 낚시로 풀어냈다. 그 컨셉에 맞춰 낚시와 물고기를 모티프로 디자인했다. {/* 2021–2024 visual work, from the printed portfolio "Records & Memories" (기록과 기억). */} ## 요약 실제로 배포하고 협업한 가장 이른 작업이다. 2021년 겨울, 제24회 한국예술종합학교 영화과 졸업영화제의 디자인물을 졸업준비위원회와 함께 만들었다. 64쪽 프로그램북은 혼자 맡았다. ## 개요 슬로건 「접촉; 다시」는 코로나 시기의 특수성을 담았다. 트레일러 영상은 이를 낚시로 풀었다. 디자인도 낚시와 물고기를 모티프로 삼아 같은 이야기를 이었다. 과제가 아니라 실제 행사였다. 프로그램북과 현장 배너를 만들어 상영 현장에서 관객에게 배포했다. ## 결과물 64쪽, 169×231mm. 상영작 소개와 시간표, 인터뷰가 들어 있다. 실제 인쇄본을 그대로 넘겨 볼 수 있다. ## 회고 프로그램북의 내용은 다른 팀이 확정하는 정보였다. 그래서 디자인팀 안보다 팀 사이의 소통이 더 중요했다. 편집 디자인을 모른 채 시작해 불특정 다수에게 배포하는 인쇄물을 끝까지 만들었다. --- ## 실험 ### 디자인 판단 https://jaeyongbae.com/ko/experiments/ai-design-critique/ 출시한 제품에서 내린 판단 여섯 개. 화면은 멀쩡해 보였는데 실제로는 실패했던 순간들, 그 근거와 바꾼 것. ## 질문 화면은 멀쩡해 보여도 실제 사용에서 틀릴 수 있다. 그러면 무엇을 보고 틀렸다고 판단하는가. 이 질문은 프로젝트마다 다시 나왔다. 아래 여섯 개에는 내 판단을 반박한 근거와 그 뒤에 바꾼 것을 적었다. 숫자는 각 프로젝트 페이지와 같다. ## 01. 리뷰를 통과한 기능 12종이 한 화면에서 무너졌다 2026년 8월 27일, [Reevl](/ko/work/reevl/)에 기능 12종을 하루에 공개했다. 각 기능은 리뷰를 통과했다. 몇 시간 만에 이탈률이 24%에서 62%로 올랐고, 체류 시간은 226초에서 40초로 떨어졌다. RageClick 36건이 찍혔는데 관측 기간 중 그날뿐이었다(GA4 · Clarity 실측). 세션 리플레이를 하나씩 봤다. 기능이 아니라 화면이 문제였다. 눌릴 것처럼 생겼는데 안 눌리는 요소, 누르면 보던 화면이 초기화되는 필터, 읽는 순서 없이 늘어난 정보. 원인 6개를 찾아 고쳤다. 8월 29일 RageClick 0건, DeadClick은 98건에서 18건. 9월 1일 이탈률 29%, 체류 115초로 돌아왔다(실측). - **반박된 것** – 리뷰를 통과한 화면은 괜찮다는 가정. 기능 12종은 각각 맞았고, 한 화면에 함께 놓인 결과가 틀렸다. - **바꾼 것** – 리뷰는 "좋아 보이나"까지만 답한다. 그래서 출시할 때 내 판단을 반박할 수 있는 지표를 같이 켠다. ## 02. 맞히지 못하는 숫자는 정밀하게 보여 주지 않는다 Reevl의 1년 전망은 단지 순위 적중도(IC)가 0.19였고 분기의 93%에서 양수였다. 2년 이상은 단지 단위 IC가 0.01이었다. 사실상 맞히지 못하는 숫자다. 금액을 원 단위로 찍으면 아래에 무슨 주석을 달아도 확신으로 읽힌다. 그래서 장기 예측은 금액을 표시하지 않는다. 워크포워드 검증을 통과한 지역 단위(IC 0.16)로만 보여 준다. 검증 성적 자체도 한 번 나를 속였다. 라벨 계산에 미래 정보가 새어 들어가 IC가 두 배로 부풀었다. FEATURE_LAG=2로 고쳤다. 모델 업그레이드 5종 중 4종은 실측 뒤 기각했다. - **반박된 것** – 좋아 보이는 검증 성적은 믿어도 된다는 가정. - **바꾼 것** – 정밀도는 시각적 주장이다. 데이터가 받치지 못하면 화면이 주장하지 않게 했다. ## 03. 모르는 금액은 추정하지 않고 비운다 [Commit](/ko/work/commit/)의 공고 API에는 지원금액이 없다. 금액은 별도의 사업정보 API에만 있다. 그래서 매칭이 확실한 공고에만 금액을 표시한다. 11,757건 중 2,595건, 22.1%다(산출물). 빈칸을 모델로 채우면 커버리지는 오르고 신뢰는 떨어진다. 틀린 금액 하나가 맞는 금액 여러 개보다 신뢰를 더 깎는다고 봤다. 규칙이 확신하지 못하면 숫자를 비우고 원문으로 보낸다. 런타임 LLM 호출은 아예 없다. 공고 요약과 자격 진단도 규칙 기반이다. 같은 판단을 로고에도 적용했다. 파비콘 서비스가 빈 아이콘을 '성공'으로 돌려줬다. 그래서 손으로 확인한 기관 116곳의 로고만 쓴다. - **반박된 것** – 자동화가 성공을 보고하면 결과도 맞다는 가정. - **바꾼 것** – 기본값을 넣는 것도 하나의 주장이다. 모르면 비운다. ## 04. 상승은 빨강, 하락은 파랑으로 고정했다 해외에서는 초록이 상승이다. 한국 시장을 보는 사람은 빨강을 상승으로 읽는다. 여기서는 빨강이 맞다. 관습은 꾸밈이 아니라 정보다. 화면마다 알아서 하게 두면 언젠가 어긋난다. 그래서 등락 색은 디자인 토큰(up · down)으로만 존재하고, 제품 어디에서도 초록은 상승을 뜻하지 않는다. 토큰은 코드에서 역으로 뽑아 Figma 라이브러리로 다시 만들었다. 변수 140개 · 스타일 28개 · 컴포넌트 23개다(v1.0, 2026년 9월 17일 · 산출물). 지켜지는 정도는 빌드마다 잰다. 색 98.5% · 타이포 100% · z층 95.2%(ds_scan 실측). - **반박된 것** – 일관성은 지키려고 애쓰면 지켜진다는 가정. - **바꾼 것** – 규칙을 어길 수 없는 자리에 뒀다. ## 05. 멀쩡해 보였지만 기준 미달이던 색 두 개 [SAI](/ko/work/sai/)에서 보조 글자는 4.49:1, 강조색 위 흰 글자는 3.88:1이었다. 둘 다 WCAG AA 미달인데 내 눈에는 멀쩡해 보였다. 5.05와 4.77로 고쳤다(실측). 그래서 눈으로 보는 대신 검사를 걸었다. Playwright 테스트 32개를 데스크톱(1440×900)과 모바일에서 돌린다. 콘솔 오류가 하나라도 나면 실패로 처리하고, axe로 WCAG 2.1 AA를 확인한다(산출물). - **반박된 것** – 화면에서 멀쩡해 보이면 기준을 넘는다는 가정. - **바꾼 것** – 잴 수 있는 것은 재서 정한다. 눈은 두 번째 의견이다. ## 06. 기능 순서가 아니라 필요한 순간 순서로 [KTX 정보 표시](/ko/work/ktx/)의 객실 화면은 기능 단위로 나뉘었다. 다음 역, 도착 시각, 환승, 편의시설, 안내 문구가 같은 무게로 놓였다. 승객은 필요한 것을 매번 찾아야 했다. 필요한 순간을 기준으로 다시 짰다. 탑승 전, 이동 중, 도착 후. 다음 역과 도착 시각, 운행 상태는 객실 반대편에서도 읽히는 크기로 두고 나머지는 뒤로 물렸다. 문이 열릴 때는 어느 쪽 문인지만 크게 띄웠다. 한국어와 영어는 같은 레이아웃 체계를 쓴다. 역 이름의 네 가지 표기도 같은 규칙으로 놓았다. 정보를 더하지 않았다. 순서만 정했다. - **아직 확인하지 못한 것** – 실제 차량의 시야 거리와 조도, 승객 대상 검증. 사용성이 좋아졌다는 숫자는 없다. ## AI가 만든 결과를 판단할 때 매일 AI와 함께 코드를 쓰고, AI가 만든 내용이 들어가는 제품을 운영한다. 같은 질문을 여기에도 적용한다. - **생성이 아니라 체계가 결정한다.** 생성된 화면이 Reevl의 토큰 밖으로 나가면 화면이 아니라 토큰을 고쳤다. - **틀릴 수 있는 자리에는 두지 않는다.** Commit은 런타임에 모델을 부르지 않는다. 틀릴 자리를 만들지 않는 편이 틀린 답을 고치는 것보다 쌌다. - **생성된 제안에는 근거를 붙인다.** SAI의 제안 카드에는 출처가 된 발화가 붙고, 사람이 수락하기 전에는 노트가 되지 않는다. - **로그가 아니라 결과물을 본다.** 내 파이프라인이 6주 동안 성공을 보고하는 사이 네이버 블로그 발행은 멈춰 있었다. 감시 필터의 오류로 서버 에러 11,891건이 0건으로 보고됐다. 지금은 발행된 결과물을 감시한다. ## 화면을 볼 때 던지는 네 가지 질문 1. **이 화면에서 할 일이 뭔가.** 사용자가 하러 온 일을 한 문장으로 말해 보고, 그게 제일 쉽게 되는지 본다. 2. **무엇이 제일 크게 보이나.** 크기와 굵기와 위치는 전부 중요도를 말한다. 다 같은 크기면 아무 말도 하지 않는 셈이다. 3. **색에 뜻이 있나.** 상승과 하락, 정상과 지연을 가리키는지 아니면 꾸밈인지. 4. **잴 수 있는 게 뭔가.** 명도 대비, 초점 순서, RageClick, 체류 시간, 적중도. 잴 수 있으면 취향으로 다투지 않는다. ## 아직 모르는 것 여섯 개 모두 내가 만든 제품에서 나왔다. Reevl과 Commit은 1인 제품이고, SAI는 3인 팀에서 내 몫이 UX와 디자인 시스템, 프론트엔드였다. 남의 화면을 두고도 같은 판단이 나오는지는 아직 보여 줄 재료가 없다. --- ### 비전 기반 인터페이스 https://jaeyongbae.com/ko/experiments/vision-interface/ 클릭 대신 몸의 움직임을 입력으로 받는 인터페이스. 머리 기울기, 시선, 손이 각각 무엇을 할 수 있는지 실제 작업에서 확인했다. ## 질문 몸을 입력으로 받을 수 있는가. 받는다면 무엇까지 읽고 무엇은 읽지 않을 것인가. 프로젝트 세 개에서 같은 질문이 돌아왔다. 자동차 안, 관제실, 전시장이다. 세 곳 다 손이 자유롭지 않거나 화면이 멀다. 포인터 대신 머리 기울기와 시선, 손을 각각 어디까지 쓸 수 있는지 봤다. ## 근거 - **머리 기울기 – [Glide](/ko/work/glide/)** – 에어팟의 머리 움직임 센서와 CoreMotion으로 탑승자의 머리 자세를 받는다. 차가 흔들리기 2~7초 전에 햅틱으로 먼저 알린다(설계값). 커브에서는 진동을 위에서 아래로 흘려 고개를 커브 안쪽으로 기울이게 한다. 몸을 읽어서 다시 몸에 말하는 구조다. - **시선 – [Feasix AI](/ko/work/feasix-ai/)** – 순찰 로봇 관제 화면에서 시선은 입력 장치가 아니다. 설계를 판정하는 자료로 쓰기로 정했다. 아이트래킹은 아직 돌리지 않았다. 인지 부하와 오류율도 측정하지 않았다. 그래서 인지 부하를 줄였다고 쓰지 않는다. - **손 – [Distance of Thinking](/ko/work/distance-of-thinking/)** – 관람객이 잡는 손잡이가 조종간이다. 기울기 센서(MPU6050)로 확률장의 가지를 고르고 로터리 다이얼로 온도를 바꾼다. 카메라를 쓰지 않으니 어두운 전시장을 전제로 설계했다. 다만 아두이노 컨트롤러는 실제 연결 테스트를 마치지 못했다. 공개한 녹화와 화면은 마우스와 휠로 조작했다. - **버린 입력 – Distance of Thinking** – 센서를 흔들어 환각을 일으키는 입력은 뺐다. 그 입력을 두면 환각의 원인이 관람객의 손에 남는다. 환각은 확률 낮은 선택의 결과여야 했다. 몸을 입력으로 받는다고 모든 움직임을 입력으로 만들지는 않았다. ## 지금까지의 답 **몸 데이터에는 비용이 따른다.** Glide는 건강 데이터 연동을 뺐고 얼굴 영상은 저장하지 않는다. 멀미 지표는 클라우드 없이 폰에서 적분한다. 대가로 감지 정확도를 잃었다. 애초에 보내지 않은 데이터는 규제 대상도 아니다. 잃은 정확도는 양산 단계의 차량 내장 센서로 되찾는 편이 맞다고 봤다. **시선은 입력이 아니라 근거로도 쓴다.** 시선으로 누르게 만들면 오인식이 곧 오조작이 된다. 관제 화면에서는 시선을 설계의 판정 자료로 두는 편이 안전하다고 봤다. **센서가 카메라보다 나을 때가 있다.** 기울기 하나로 되는 일에 카메라를 쓰면 조명과 사생활과 연산이 전부 따라온다. Glide의 검증 축 네 개 중 행동 축은 고개 숙임과 손-입 가림 제스처를 CV로 잡는다. 이 축은 검증용이고 제품의 입력이 아니다. 네 축은 모두 만들었지만 표본이 적어 통계적 유의성은 없다. **몸을 읽을수록 설명이 더 필요해진다.** 시스템이 먼저 움직이면 사람은 이유를 묻는다. Glide가 왜 지금 알렸는지를 늘 함께 말하는 이유다. 임계값 아래에서는 말하지 않는다. ## 아직 모르는 것 - **아이트래킹** – Feasix AI의 2차 검증은 계획이고 결과는 없다. - **실차 검증** – Glide의 효과 수치는 전부 시뮬레이션이다. 머리 자세를 읽어 미리 알린 것이 실제로 멀미를 줄였는지는 같은 구간의 대조 실험으로 확인해야 한다. - **컨트롤러** – Distance of Thinking의 하드웨어 조종은 실제 연결 테스트가 남았다. --- ### MPU6050 모션 실험 https://jaeyongbae.com/ko/experiments/mpu6050-motion/ 가속도계로 멀미를 숫자로 재고, 그 숫자를 몸이 먼저 아는 진동으로 바꿨다. Glide의 하드웨어가 여기서 나왔다. ## 질문 불편을 숫자로 바꿀 수 있는가. 그리고 그 숫자를 만드는 보드가 죽으면 제품은 어떻게 되는가. [Glide](/ko/work/glide/)의 하드웨어가 여기서 나왔다. 아두이노 보드 하나로 "지금 이 차가 얼마나 멀미를 일으키는가"를 숫자로 만들었다. 그 숫자가 임계값을 넘기 전에 손목을 두드리는 단계까지 갔다. 여기서 정한 측정 방식과 진동 패턴이 그대로 제품의 하드웨어가 됐다. 실패도 그대로 남았다. ## 왜 재야 했나 멀미는 "불편하다"는 말로만 오간다. 그러면 나아졌다는 주장도 확인할 방법이 없다. 재는 법이 먼저 필요했다. 지표는 MSDV를 골랐다. 멀미를 재는 세 방식(MSDV, MISC, FMS)을 비교한 결과다. 국제 표준 ISO 2631-1에 근거가 있어서 남들과 같은 단위로 이야기할 수 있다. 재는 것만으로는 아무것도 바뀌지 않는다. 숫자가 몸에 닿아야 한다. ## 어떻게 했나 - **센서 두 개** – MPU6050을 차체와 머리에 각각 붙였다. 멀미는 차의 움직임이 아니라 차와 머리의 차이에서 온다. - **50Hz, 200샘플 보정** – 시작할 때 200개 샘플로 정지 상태를 잡아 중력을 뺀다. 이후 50Hz로 적분해 MSDV를 계산한다(설계값). - **진동 패턴** – 225ms 켜짐, 100ms 꺼짐, 225ms 켜짐. 실제로 차에 타 보며 골랐다. 한 번 길게 울리면 놀랐고, 짧게 두 번은 알림으로 읽히지 않았다. - **좌우 분리** – 모터를 좌우로 나눠, 어느 쪽으로 쏠릴지를 세기 차이로 먼저 알렸다. ## 된 것과 안 된 것 **된 것.** 정지 보정을 마치면 손으로 흔드는 정도의 움직임도 MSDV 곡선에 잡혔다. 임계값을 넘기 2초쯤 전에 진동을 보냈다. 이 2초가 Glide의 예고 시간 2~7초의 출발점이다(설계값). **안 된 것.** 보드에 붙인 MPU6050 두 개가 I2C 버스에서 동시에 잡히지 않았다. 주소 충돌과 배선을 며칠 뒤졌지만 끝내 둘을 같이 읽지 못했다. 실시간 측정이 여기서 막혔다. **센서 주기도 어긋났다.** GPS는 1Hz, IMU는 50Hz다. 맞추려 하는 대신 역할을 나눴다. GPS는 예고 시점을, IMU는 실시간 강도를 맡는다. **그래서 만든 두 번째 경로.** 아이폰 CoreMotion으로 같은 식을 다시 구현해 대체 경로로 삼았다. 보드가 없어도 가짜 센서 값으로 같은 화면이 돌아간다. 센서가 죽은 날 이 경로가 시연을 살렸다. ## 여기서 남은 규칙 **측정 단위를 먼저 고른다.** 표준 지표를 쓰면 같은 값을 여러 곳에 같은 식으로 구현할 수 있다. Glide에서는 센서 보드와 웹 콘솔과 iOS 앱이 같은 MSDV 식을 쓴다. 보드에서 잰 값과 앱이 보여 주는 값이 서로 어긋나지 않는다. **데모는 최악의 환경을 가정해 만든다.** 대체 경로가 없으면 하드웨어 하나가 발표를 결정한다. **실패한 배선은 제품 구조로 남는다.** I2C가 안 된 결과가 지금의 구조다. 보드와 앱은 직접 붙지 않고 웹을 경유한다. 이 숫자는 책상과 짧은 실차 주행에서 얻었고, 대조군을 둔 실험이 아니다. Glide 페이지의 −77%는 시뮬레이션 결과다. --- ### 제너러티브 UI https://jaeyongbae.com/ko/experiments/generative-ui/ 모델이 실행 중에 화면을 조립할 때, 무엇을 맡기고 무엇을 사람이 쥐고 있어야 하는가. ## 질문 모델이 실행 중에 화면을 만들 때, 무엇을 모델에 맡기고 무엇을 시스템이 쥐고 있어야 하는가. 세 프로젝트를 거쳐 한 문장으로 정리됐다. **내용은 모델이, 형식은 시스템이.** ## 왜 선을 그어야 했나 모델이 화면 전체를 만들면 일관성과 신뢰가 먼저 무너진다. 반대로 전부 고정하면 모델을 쓸 이유가 없다. 답은 그 사이에 있다. 세 프로젝트에서 그 선을 각각 다른 자리에 그었다. ## 근거 - **제안은 모델, 결정은 사람 – [SAI](/ko/work/sai/)** – 제안 카드는 고정 컴포넌트이고, 상태는 제안 · 진행 · 완료 · 닫힘 네 가지다. 그 안의 내용만 그때그때 생긴다. 사람이 수락한 제안만 노트가 되고, 제안 자체는 노트 본문에 섞이지 않는다. 동시에 답을 기다리는 제안은 2개까지다(설계값). - **근거 없는 생성은 화면에 올리지 않는다 – SAI** – 출처가 된 발화나 자료가 없는 제안은 띄우지 않는다. AI가 만든 것은 파란 글로우와 'AI 생성' 배지로 구분한다. AI 기본법의 고지 의무도 여기 걸린다. 확신도는 카드 채움의 강도로 나타내고, 모르는 것은 모른다고 쓴다. 자료 카드는 읽고 있는 값을 덮지 않고 대기열과 배너로 알린다. - **런타임 모델 호출을 아예 뺐다 – [Commit](/ko/work/commit/)** – 공고 요약과 자격 진단은 규칙 기반이다. 런타임 LLM 호출은 없다. 비용과 환각 두 가지 때문이다. 금액과 기간과 자격은 정규화한 데이터가 말하고, 규칙이 확신하지 못하면 숫자를 비운다. 금액이 붙은 공고는 11,757건 중 2,595건, 22.1%다(산출물). - **모델의 확률을 형식이 받는다 – [Distance of Thinking](/ko/work/distance-of-thinking/)** – 모델이 실제로 낸 다음 토큰 후보 6개와 확률을 공간으로 세웠다. 생성된 글이 화면을 만드는 게 아니라, 모델의 계산을 고정된 형식이 받는다. 색은 쓰지 않고 밀도와 투명도, 크기, 움직임으로만 뜻을 전한다. ## 지금까지의 답 **형식이 고정돼야 배운 것이 계속 쓰인다.** 컴포넌트가 매번 달라지면 사용자는 매번 다시 배운다. **근거가 붙지 않은 생성물은 수락 대상이 아니다.** 무엇을 듣고 그렇게 말했는지가 보여야 사람이 누를지 정한다. **런타임 생성은 비용이다.** 미리 계산할 수 있는 것은 미리 계산했다. Commit에서는 모델을 아예 부르지 않는 쪽이 옳았다. 틀릴 자리를 만들지 않는 편이 틀린 답을 고치는 것보다 쌌다. ## 아직 모르는 것 - **수락률** – SAI에서 어떤 제안이 수락되고 어떤 제안이 무시되는지 측정하지 않았다. 이 숫자가 없으면 제안 시점을 고칠 근거도 없다. - **제안 2개 제한** – 설계값이다. 실제 회의에서 몇 개가 적당한지 세어 보지 않았다. - **규칙 기반의 한계** – Commit의 규칙이 비운 77.9%가 정말 알 수 없는 값인지, 규칙을 더 쓰면 줄어드는 값인지 구분하지 못했다. --- ### Three.js 인터랙션 https://jaeyongbae.com/ko/experiments/threejs-interaction/ 웹의 3차원을 배경이 아니라 읽을 것으로 쓰는 방법. 확률장 속을 비행하는 설치 작업에서 시험했다. ## 질문 3차원이 정보 구조를 만드는가, 배경을 만드는가. 정보 구조를 만들지 않으면 쓰지 않는다. ## 왜 이 질문인가 웹의 3D는 대부분 스크롤에 반응하는 장식이다. 화면은 무거워지고 읽을 것은 늘지 않는다. 3차원이 필요하려면 2차원으로 못 하는 일을 해야 한다. 거리가 곧 유사도이고 이동이 곧 선택인 공간이 그렇다. ## 근거 - **좌표에 뜻이 있는 경우 – [Distance of Thinking](/ko/work/distance-of-thinking/)** – Three.js로 언어 모델의 다음 토큰 확률장을 세웠다. 토큰마다 4,096차원 임베딩을 3차원으로 투영하고, 가까운 토큰끼리 선으로 잇는다. 매 단계 상위 6개 후보가 확률 순서로 놓여 터널을 이룬다. 가장 확률 높은 후보가 정면, 낮은 후보가 바깥 고리다. 관람객이 통과한 토큰이 그대로 답으로 확정된다. 4일 22커밋으로 만든 프로토타입이다(산출물). - **2차원으로 충분한 경우 – [Synthetic Vision Fund](/ko/work/synthetic-vision-fund/)** – p5.js로 만든 생성 이미지를 배경이 아니라 상품의 얼굴로 썼다. 같은 질문에 3차원이 답이 아니었던 경우다. 여기서는 공간이 아니라 절차가 신뢰를 만들었다. - **이 사이트** – 3D가 하나도 없다. 프로젝트를 읽는 데 좌표가 필요하지 않다. three.js 의존성 자체를 넣지 않았다. ## 지금까지의 답 **좌표에 뜻이 있을 때만 3차원이 낫다.** 확률장에서는 가까울수록 그럴듯한 다음 단어다. 이 규칙 하나로 화면에 설명을 붙일 필요가 없어졌다. **이동이 곧 선택이어야 한다.** 보여 주는 것과 실제로 일어나는 것이 다르면 3차원은 그림이 된다. 그래서 샘플링에 직접 개입해 비행 경로가 답이 되게 했다. 가만히 날면 가장 확률 높은 경로를 따른다. **장식이면 빼는 게 낫다.** 이 사이트에 3D가 없는 이유다. 읽는 일에 좌표가 필요하지 않으면 무게만 늘어난다. ## 아직 모르는 것 - **하드웨어 조종** – 기울기 센서로 가지를 고르는 구조는 만들었지만 아두이노 컨트롤러의 실제 연결 테스트를 마치지 못했다. 공개한 녹화는 마우스와 휠로 조작했다. - **장시간 안정화** – 전시 모드는 75초 동안 입력이 없으면 스스로 도는 화면으로 넘어간다. 장시간 전시에서의 안정성은 확인하지 않았다. - **배포 제약** – 센서를 읽는 Web Serial은 보안 페이지가 필요해 사설 네트워크의 HTTPS 주소 하나로 운영했다. 일반 배포 환경에서 같은 조종을 붙이는 방법은 아직 없다. ---