@ GS칼텍스GS Caltex VOC AI Dashboard
Sole architect and engineer of the VOC AI Dashboard, manual review replaced by 1,000+/day auto-classification across 4 integrated channels.
The app was built; couriers were short, so in the end I went out and delivered myself.
My first company was a startup. I was a junior backend on a traditional-market delivery platform, and back then I believed that writing good code made you a good developer. Designing in the meeting room and coding in front of a monitor — that was all I knew of dev work.
On launch day, orders came in faster than expected. There were not enough couriers to handle them. The CEO's call was firm — "Even the developer goes out and delivers right now." Honestly I was a little disappointed at first. I wanted to handle bigger systems, fancier tech, and a traditional-market delivery app was not the picture I had in mind. But once I put on a helmet and went into the market, there was a scene the meeting room had never shown me.
Field notes
There was a shop where the notification never stopped
In one shop the new-order alert went off once and never turned off — the meeting room had never surfaced that bug.
The owner did not know how to turn it off
The screen was hard to read, the dismiss flow was opaque, and more than a few owners were stuck on it.
These were users who could not reach the support channel
They were not the kind of users who would file a ticket — we never heard about it, and the bug was bothering them every day.
Whatever I was about to build, I started by looking at what business impact the feature was supposed to produce. The picture came before the code.
How it actually reaches the person on the other end — I sketched that before writing code. The code came out of the sketch.
Like the shop owners in the market alley, some users will not actively file a problem. I built that into the assumption layer of the work — we have to go and find it.
Picturing the market alley, I started every new feature with the same question. That one line became the first question for everything I built after.
Realization
Code → product
From someone who writes good code to someone who sees what the product is actually for
Habit
Start with why
Business impact and user path before any code
Assumption
Users who cannot reach support
Go and find them on purpose
The question
"Who is standing behind this code"
The first question for any new feature
“One screen used by one shop owner in a market alley became the first question I ask before any new feature.”
Put on a delivery helmet and walked the market alleys. Saw a notification bug the meeting room had never surfaced, and shop owners who could not reach the support channel at all.
Started every new feature by asking "who is standing behind this code" — sketched the why, the business impact, and the user path before writing any of it.
From then on, every new feature started in the market alley — the shift from "writes good code" to "sees what the product is actually for".
What happens when product, design, dev, and ops all run through one pair of hands.






More work