Front J

UX 법칙은 정답이 아니라 관찰의 언어다

JonghwanWon — Sun, 19 Jul 2026 23:20:04 +0900

제품을 만들다 보면 이상한 순간을 자주 만난다.

설명은 더했는데 이해는 느려지고, 선택지는 늘렸는데 결정은 어려워진다.

사용자를 위했다고 생각하지만 결과는 반대다.

이런 순간에 UX 법칙은 정답을 주지 않는다. 단지 우리가 무엇을 놓쳤는지 볼 수 있는 이름을 준다.

왜 사용자는 설명을 읽지 않는 건가.

왜 모든 것을 보여주었는데 중요한 것은 보지 못하는 건가.

왜 거의 끝난 일은 마무리하고 싶어 지는 건가.

사람의 행동은 제각각이지만, 그 안에는 반복되는 패턴이 존재한다.

Laws of UX는 그 패턴을 인터페이스를 만드는 사람이 사용할 수 있는 언어로 정리한다.

하지만 법칙을 안다는 것과 좋은 제품을 만드는 것은 다르다.

선택지를 줄인다고 언제나 좋은 것도 아니고, 버튼을 크게 만든다고 모든 문제가 해결되는 것도 아니다.

법칙은 설계를 대신해주지 않는다.

다만 우리가 더 나은 질문을 던질 수 있게 만든다.

매일 만드는 화면과 흐름을 다시 보기 위한 기록이다.

낯섦을 넘어 경계를 연결하고, 더 나은 질문을 던질 수 있도록.

효율을 가장한 비효율

JonghwanWon — Sun, 12 Jul 2026 11:59:27 +0900

일이 앞으로 나아가고 있다기보다, 앞으로 가는 척하고 있다는 느낌이 들 때가 있다.

1년 전쯤만 해도 나는 그 차이를 잘 몰랐다.

기능은 계속 만들어졌고, 겉으로는 아무런 문제가 없어 보였다.

팀이 적극적으로 AI를 사용하기 시작한 뒤로는 생산성도 더 높아진 듯했다.

처음에는 분명 좋은 변화라고 생각했다.

PD는 자신이 구상한 기능을 직접 만들기 시작했고, PO는 제품 정책과 기술적 제약을 더 빠르게 파악할 수 있었다.

FE는 간단한 API를 설계했고, BE는 간단한 화면을 구현했다.

흔히 말하는 역할의 경계가 빠르게 흐려지고 있었다. 그 모습은 꽤 멋져 보였고, 동시에 조금 두렵기도 했다.

기획 초안은 금방 나왔다. 스펙은 빠르게 정리됐고, 화면의 문구도 몇 번의 프롬프트만으로 그럴듯해졌다.

예전 같으면 여러 사람이 모여 이야기했을 내용을 한 사람이 정리해 공유할 수 있게 됐다.

그러던 어느 순간부터 묘한 불편함이 생겼다.

기능을 개발하는 동안 막연한 의구심이 들었다.

기획 문서를 다시 들여다보니, 우리가 만들고 있는 기능이 정말 고객의 문제를 해결하고 가치를 전달할 수 있을지 확신하기 어려웠다.

처음에는 AI가 만든 문서가 문제라고 생각했다. 하지만 AI는 시킨 대로 했을 뿐인걸 안다.

문제는 우리가 그 문서를 너무 빨리 믿었다는 데 있었다. 문서는 이미 완성된 것처럼 보였다.

그래서 더 위험했다.

비어 있는 문서는 우리가 무엇을 모르는지 드러낸다.

반면 AI로 작성한 그럴듯한 문서는 우리가 모른다는 사실을 감춘다.

역할의 경계가 흐려지고 더 넓게 본다는 말은 생각보다 위험할 수 있다.

넓게 본다는 것이 각 영역의 깊이를 가볍게 여겨도 된다는 뜻은 아니기 때문이다.

전문성 없는 확장은 빠르다. 하지만 그 빠름은 자주 다른 사람의 시간을 가져다 쓴다.

AI를 활용해 다른 역할을 흉내 내는 것은 그 사람의 일을 대신할 수 있다는 뜻이 아니다.

생산성을 높이기 위해 만든 결과물이 오히려 조직에서 가장 중요한 사람들의 시간을 더 많이 쓰게 만들기도 한다.

AI Slop은 단순히 품질이 낮은 콘텐츠의 문제가 아니다. 겉으로는 효율처럼 보이지만, 실제 비용은 다음 단계로 밀려난다.

효율을 가장한 비효율이다.

내가 무엇을 알고 무엇을 모르는지, 어떤 판단은 내가 할 수 있고 어떤 판단에는 다른 사람의 기준이 필요한지 알아야 한다.

그 경계를 알 때 협업은 더 정확해진다.

전문성은 벽이 아니다. “여기부터는 내 일이 아니야”라고 선을 긋기 위한 것도 아니다.

프로덕트를 만든다는 것은 결국 수많은 결정을 쌓아가는 일이다.

무엇을 보여주고, 무엇을 숨길지.

무엇을 시스템이 감당하게 하고, 무엇을 사용자에게 맡길지.

무엇을 지금 만들고, 무엇을 만들지 않을지.

이 결정들은 단순한 산출물이 아니다.

각자의 전문성 위에서 내려져야 하며, 동시에 서로의 전문성과 연결되어야 한다.

요즘은 역량 강화라는 말을 조금 다르게 생각하게 된다.

더 많은 일을 할 수 있게 되는 것이 역량 강화일까.

AI를 이용해 더 많은 역할의 말을 흉내 낼 수 있게 되는 것이 성장일까.

역량 강화는 내가 만드는 결과물의 양이 늘어나는 일이 아니라, 내가 내리는 판단의 품질이 높아지는 일에 가깝다.

범위를 확장한다는 것은 그 판단을 더 넓은 맥락에 연결하는 일이다. 넓어지기 전에 먼저 깊어져야 한다.

깊이 없는 확장은 결국 얕은 문제 해결을 만든다. 얕은 문제 해결은 빠르게 보이지만, 실제로는 문제를 해결하지 못한다.

반대로 깊이를 가진 확장은 조금 느려 보인다.

질문이 많아지고, 결정은 신중해진다.

문서에는 우리가 모르는 것이 그대로 드러난다.

그것은 실패의 비용을 앞에서 치르고, 이후의 협업 비용을 줄이는 일이다. 결국 결정의 품질을 높이는 과정이다.

마지막에 남는 것은 사람의 판단이고, 판단의 품질은 전문성으로부터 나온다.

요즘 좋은 팀이란 무엇인지 다시 생각한다.

모두가 모든 일을 하는 팀이 좋은 팀일까. 아니면 각자의 일을 지키면서 서로의 일을 모르는 팀이 좋은 팀일까.

아마 둘 다 아닐 것이다.

좋은 팀은 각자의 전문성을 가지고 있으면서도 서로의 영역을 이해하려는 팀이다.

서로를 대신하려 하기보다 연결하려는 팀이다. 빠르게 만들기 전에 무엇을 판단해야 하는지 먼저 묻는 팀이다.

앞으로 역할의 경계는 계속 흐려질 것이다. 그 흐름을 막을 수도 없고, 막을 필요도 없다고 생각한다.

내가 가장 자주 판단해야 하는 영역에서는 나만의 기준을 가지고 있어야 한다는 것은 잊지 말아야겠다.

깊이 판단하지 못한다면 넓음은 쉽게 소음이 된다. 소음은 생산성이라는 이름으로 팀 안에 쌓인다.

지금 우리는 역량을 강화하고 있는가. 아니면 역할의 모양만 넓히고 있는가.

AI로 사고를 확장하고 있는가. 아니면 사고하지 않은 결과물을 빠르게 만들어내고 있는가.

프로덕트를 만든다는 것은 결국 낯선 문제를 계속 마주하는 일이다.

그 낯섦 앞에서 필요한 것은 더 빠른 척하는 것도, 더 많이 아는 척하는 것도 아니다.

필요한 것은 각자의 전문성으로 다시 질문하는 태도다.

이 결정에는 누구의 판단이 필요한가.

이 문서는 어떤 책임을 남기는가.

이 결과물은 다음 사람의 일을 줄이는가, 늘리는가.

이 속도는 진짜 속도인가, 아니면 비용을 뒤로 미룬 것인가.

스스로 이런 질문을 던지고 답할 수 있을 때, 비로소 팀은 넓어질 수 있다고 생각한다.

얕게 넓어지는 것이 아니라, 깊이를 가진 채 넓어지는 것.

어쩌면 이것이 진짜 역량 강화에 더 가까운 모습일지도 모르겠다.

"r"을 세도록 명령하지 말고, "r"을 세는 함수를 만들도록 하라

JonghwanWon — Fri, 27 Feb 2026 00:01:48 +0900

최근, AI 활용 방식에 대해 팀 안팎으로 같은 이야기를 반복하고 있다.

"r"을 세도록 명령하지 말고, "r"을 세는 함수를 만들도록 하라

벌써 몇 년이나 흘렀지만, 이런 질문이 화제가 되었던 적이 있다.

"Strawberry"에는 "r"이 몇 개 있는가?

사람이 보기에는 분명한 답인데도, 당시의 AI는 엉뚱한 개수(2개)를 내놓았다.

지금은 많은 모델이 정답(3개)을 맞히게 되었지만, 이 질문이 남기고 간 인사이트는 여전히 유효하다.

AI에게 정답을 말하게 하지 말고, 정답을 계산하는 함수를 만들게하라.

왜 이 문장이 중요한가?

1. LLM은 본질적으로 확률적 시스템이다.

2. context-window와 출력 토큰의 한계가 존재한다.

3. 따라서 “전부 찾아서 보고해”는 그럴듯 해 보이는 답을 줄 수 있어도 완전성을 보장하지는 못한다.

관점을 조금 바꿔보자.

- AI에게 결과를 요구하지 않는다.

- AI에게 결과를 계산하는 절차를 만든다.

- 사람은 절차의 신뢰도를 검증한다.

이렇게 바꾸면, AI 활용이 "잘 맞히게 만드는 요령"같은게 아니라 "재현 가능한 시스템"으로 만들 수 있다.

P2D: Probabilistic to Deterministic

작업을 다음과 같은 단계로 진행해보자.

1. 질문을 계산 문제로 변환한다.

- Before: "이 패턴을 사용하는 곳을 전부 찾아줘"

- After: "이 패턴을 탐지하기 위한 스캐너 스크립트를 작성해줘"

2. 결정적 산출물을 먼저 만든다.

- 코드 탐지 스크립트

- AST Transform (w/ jscodeshift)

- lint rule

3. AI의 역할을 생성/해석으로 제한한다.

- 탐지와 변환의 실행은 도구(script)가 담당하고, AI는 스크립트의 작성과 결과 요약을 담당한다.

4. 검증 루프를 닫는다.

- "누락 없음"을 선언하지 않고, "누락 가능성을 구조적으로 낮춘 근거"를 남긴다.

실무에서 활용했던 상황들은 다음과 같다.

1. Deprecated 컴포넌트 마이그레이션

AI에게 직접 변경하게 하면, 사람의 검증 비용은 폭증하기 마련이다.

반대로 AST 기반 변환으로 바꾸면, 반복 작업은 "규칙"으로 고정되어 누락 리스크는 급격하게 줄어든다.

2. 특정 패턴 전수 조사

AI에게 자연어 요청만으로는 사례가 누락되기 쉽다.

패턴 스캐너를 먼저 만든 후, 결과를 해석하면 "찾았다"가 아니라 "탐지 규칙에 의해 파악된 것"이 된다.

3. 특정 라우트에서 참고하는 API 전수 파악

요약 보고에 의존하면 불안하다. 스크립트를 통해 사용처를 분석하면 빠짐없이 모두 파악할 수 있다.

AI를 활용한 생산성은 다음과 같이 정의할 수 있다.

"얼마나 그럴듯하게 답했는가"가 아니라, "얼마나 재현 가능한 절차를 만들었는가"

이 기준에서 바라보면, 좋은 프롬프트는 화려한 질문이 아니라 검증 가능한 파이프라인으로 연결되는 질문이라고 볼 수 있다.

AI와 함께 일하며 수시로 생각한다.

나는 지금 AI에게 "r"을 세게 하고 있는가, 아니면 "r"을 세는 시스템을 만들고 있는가

AI와 함께한 1년

JonghwanWon — Tue, 17 Feb 2026 21:51:07 +0900

AI와 본격적으로 함께한 지 벌써 1년이란 시간이 흘렀다.

정확하게는 감독자로서, 지휘자로서, 조율자로서의 1년이 지나갔다.

지난 1년은 변화의 연속이었고, 가장 큰 변화는 업무 방식의 근본적인 전환이었다.

80% 손코딩 → 80% 에이전트 코딩으로 이동했다.
쌓여 있던 기술 부채는 "몇 번의 대화"만으로도 해소될 가능성을 보여주었다.
Write First, Decide Later.
일단 만들어보고 결정하는 접근이 가능해졌다. 이제 "작동하는 프로토타입"은 누구나 만들 수 있게 되었다.

업무를 넘어 일상 전반에서도 AI를 활용하고 있지만, 솔직히 말하면 여전히 혼란스럽다.

모두가 다른 말을 한다

Geek News에는 낙관과 비관이 끊임없이 교차한다.

Reddit에는 바이브 코딩으로 만들어진 프로젝트가 쏟아지지만, 상당수는 비슷한 결과물을 재현하는 수준에서 머무르기도 한다.

누군가는 AI가 내어놓은 결과에 감탄하고, 누군가는 결과가 형편없다고 이야기한다.

누군가는 "AI 활용을 잘못한 것"이라 하고, 누군가는 "당신의 역량이 드러난 증거"라고 이야기한다.

누군가는 무언가를 만들어 가치를 전달하는 과정을 좋아하고,

누군가는 깊이 있게 문제를 해결하는 과정을 좋아한다.

그럼 우리는, 내가 중요하게 여기던 가치를 재정렬해야 할까?

아무도 정답을 모른다.

이 혼란은 경력의 많고 적음을 떠나, 전 세계 개발자들이 동시에 겪는 현상이다.

누구도 틀리지 않았다. 다만, 준비되지 않은 상태에서 너무 빠르게 세상과 업무 방식이 바뀌고 있을 뿐이다.

분명한 건 하나다.

1년 전, 2년 전으로 되돌아가지는 못한다.

채택은 늘고, 신뢰는 떨어진다.

AI가 생성한 코드의 채택률은 올라가는데, 코드의 신뢰는 떨어진다는 이야기를 흔하게 볼 수 있다.

AI를 많이 쓰는 팀은 코드가 머지되는 양이 늘었지만, 동시에 코드리뷰 시간이 늘어나고, PR 크기가 커지고, 워크플로우의 병목은 코드 작성에서 코드 리뷰로 이동했다.

"이해 부채"라는 흥미로운 키워드도 등장한다. 리뷰가 "도장 찍기"가 되고, "대충 맞아 보이니까" 머지하는 순간들이 늘어간다.

채택률이 올라갈수록 신뢰가 떨어지고, 리뷰가 병목이 된다.

생산성은 오르는데 품질이 흔들리는 이 역설은 지금 우리가 어디쯤 와 있는지 정확히 보여준다.

핵심 역량은 새 기술이 아니라 "판단력"

Matteo Collina는 가장 중요한 기술이 판단력이라고 말한다.

시스템을 설계하고, 무엇을 만들지 결정하는 일
구현이 의도와 맞는지 판단하는 일
AI가 확신을 담아 제시한 코드가 "겉보기엔 맞지만 실제로는 틀린 경우"를 잡아내는 일
프롬프트로 전달할 수 없는 맥락을 이해하는 일

그리고 동시에, 이건 새로운 기술이 아니라고 이야기한다.

시니어 엔지니어가 늘 해오던 그 역량이었고, 다만 이제는 "여러 기술 중 하나"가 아니라, "핵심 기술"이 되었다는 차이만 있다는 것이다.

리뷰가 병목이라는 것을 받아들이고, 그 병목을 개선하려 노력한다.
패턴을 더 빠르게 인식하고, 흔한 오류 유형을 정리하고, 검증을 더 효율화한다.

Addy Osmani는 더 단호하다.

아키텍처를 생각하고, 코드를 리뷰하고, 모든 줄을 이해하는 책임은 여전히 사람에게 있다고 이야기한다.

제출하는 코드에는 당신의 이름이 들어간다.
그 코드에 대한 책임은 당신에게 있다.

AI로 생산성을 높일 수는 있다. 하지만, 숙련으로 가는 지름길은 아니다. 핵심은 여전히 인지적 노력에 있다.

AI를 "학습 도구"로 쓰느냐, "결과 생성기"로 쓰느냐에 따라 학습 결과는 극단적으로 갈린다.

완벽하지 않아도 괜찮다. 다만, 호기심을 잃지 않고 배우는 자세를 유지해야 한다.

Daniel Miessler는 한 발 더 나아가 이야기한다.

AI를 적극적으로 활용해 생존해야 한다고.

Human 1.0: Survival — "Will I survive today?"
Human 2.0: Corporate — "What is my value to the economy?"
Human 3.0: Creative — "What do I want to create and contribute?"

"Creative"는 창의적인 자기 표현, 오직 인간만이 만들 수 있는 고유한 가치로 정의된다.

현재 재직 중인 회사의 CTO도 1년 전 비슷한 결을 내게 이야기해주었다.

AI 활용 역량은 점점 기본기에 가까워질 것이다.
하지만 엔지니어의 정체성은 "코드를 쓰는 사람"이 아니라 "문제를 해결하는 사람"이다.
경험에서 비롯된 판단력, 협력, 설명할 수 없는 매력 — 인간다움이 더 귀해질 수 있다.

조직에서 벌어지는 문제

개인을 넘어, 팀 차원의 문제도 짚어볼 필요가 있다.

워크슬롭(workslop)은 겉으로는 그럴듯해 보이지만 실제로는 일을 진전시키지 못하는 AI 생성 업무물을 뜻한다.

AI 도구가 쉬워질수록 완성도 높은 결과물을 빠르게 만들 수 있다.

문제는 그 결과물이 도움이 되지 않거나, 불완전한 상태일 확률이 높다는 데 있다.

워크슬롭의 가장 큰 문제는 작업 부담을 뒤로 미룬다는 것이다.

받는 사람이 내용을 해석하고, 수정하고, 재작업해야 한다.

혹시 이런 경험이 있었는가?

읽자마자 당황스러운 기분이 든다
"이게 뭐지?"라는 의문이 든다
AI로 텍스트 블록만 잔뜩 생성한 것이 아닌지 의심된다

이런 경험이 있다면, 워크슬롭을 받은 것이다.

더 무서운 것은 단지 생산성 문제로 끝나지 않는다는 점이다.

워크슬롭은 흥미롭게도 관계에도 영향을 준다고 한다.

워크슬롭을 받은 사람은, 발신자를 덜 창의적이고, 덜 유능하고, 덜 신뢰할 수 있다고 한다.

AI와 협업했다고해서 품질 기준을 낮출 수는 없다.

사람이 단독으로 만든 작업물과 동일한 기준이 필요하다.

그래서, 앞으로 무엇이 중요해질까

정리하면 이렇다.

코드는 더 빨리 만들어진다. 그래서 검증(리뷰/테스트/이해)가 병목이 된다.
생산성은 올라간다. 그러나, 신뢰/품질이 따라오지 않으면 그 비용은 뒤로 밀린다.
결국 차이는 "코딩 속도"가 아니라 판단력과 통제력에서 난다.

이건 기술의 문제가 아니라, 업의 중심이 어디로 옮겨가고 있는지에 대한 문제일지도 모른다.

오랜만에 AI의 도움 없이 글을 써보니, 뇌가 조금 활성화된 느낌이 든다.

평소 같았으면 마무리를 AI에게 맡겼을지도 모른다. 하지만 지금은 이런 결론을 사람이 쓰는 일이 더 의미 있게 느껴진다.

대체할 수 없는 개발자, 그리고 인간의 본질은 무엇일까.

세상은 어떻게 변하고, 어떤 역량이 중요해지고, 무엇이 가치를 두어야 할까.

요즘은 이런 "인간다운 글"이 오히려 유니크해졌다고도 한다.

마지막으로, 현실도 잊지 말아야 한다.

소프트웨어 엔지니어는 학습하라고 돈을 받고 있는게 아니라, 비즈니스 가치를 전달하라고 돈을 받는다.

AI는 실력을 대신해주지 않고, 드러낸다.

JonghwanWon — Sat, 24 Jan 2026 00:10:23 +0900

어딜 가나 AI 에이전트에 대한 이야기를 듣게 된다.

사람 하나를 더 고용한 것처럼, 유능한 주니어 개발자를 옆에 앉혀 둔 것처럼 말한다.

그 말이 완전히 틀렸다고 하기도 어렵다. 분명히 빠르고, 생각보다 많은 일을 해내고 있다.

AI 에이전트를 본격적으로 사용한 지도 벌써 수개월이 흘렀다.

유튜브 요약기 구조를 따라 만들어보는 것에서 시작해,

AI 기반 서비스들이 제공하는 가치를 일부 직접 구현해보기도 했다.

최근에는 tauri를 활용해 데스크톱에서 겪는 작은 불편을 해소하는 도구를 직접 만들어 사용하고 있다.

몇 번의 경험이 쌓일수록, 묘한 감정이 든다.

누구나 쉽게 원하는 제품을 뚝딱 만들어 낼 수 있는 시대다. 이미 눈앞에 와있다.

그렇다면, 경쟁력은 어디서 오는가.

누구나 AI를 통해 빠르게 만들어낼 수 있다.

문제는 무엇을 만들었느냐가 아니라, 어떤 생각으로 만들었느냐다.

AI는 빈칸을 채워주지만, 방향까지 정해주지는 않는다.

답을 만들어내지만, 그 답이 맞는지 판단하지는 않는다.

그 판단과 책임은 아직까지 사람에게 남아 있다.

"AI를 잘 쓰는 사람"이라는 말은 조금 다르다.

프롬프트를 잘 쓰는 사람이 아니라, 생각을 잘 정리할 줄 아는 사람.

문제를 쪼개고, 가설을 세우고, 결과를 비판적으로 바라볼 수 있는 사람.

AI는 과정을 대신해주지 않는다. 오히려 그 과정이 부족할수록, 부족함을 더 또렷하게 드러낼 뿐이다.

AI를 대신 생각해 주는 존재로 인정하는 순간, 성장은 멈춘 것과 같다.

하지만 사고를 확장하고 검증해 주는 도구로 사용한다면, AI는 분명 강력한 동료가 될 수 있다.

AI는 앞으로 더 똑똑해지고, 더 자연스럽게 사람의 말을 이해하게 될 것이다.

그리고 그만큼, 우리가 어떤 사람인지도 더 분명히 드러나게 될 것이다.

AI는 실력을 대신해주지 않는다.
사고력, 문제 정의 능력, 기준과 판단력을 그대로 결과물에 반영하는 거울에 가깝다.

그 거울 앞에서 생각하기를 멈추지 않는 사람이 되어야겠다.

사고의 깊이에서 나오는 경쟁력.

앞으로 가져가야 할 가장 중요한 능력이라 믿는다.

2025 회고: 다음에 잘하자

JonghwanWon — Sat, 27 Dec 2025 23:40:17 +0900

크라잉넛의 공연과 함께한 카운트다운 판타지에서 2025년을 맞이했던 기억이 아직도 선명한데, 어느새 그 해가 저물어 간다.

샴페인 풍덩 데킬라 원샷
생맥주 마셔 인생 즐겨
어차피 모든 게 잘 안될 거야
다음에 잘하자 데킬라 원샷

좋아하는 밴드였기 때문이었을까, 아니면 노래의 가사 때문이었을까.

2025년 한 해만큼은, 이왕이면 후회 없이 잘 보내보자고 마음먹었던 것 같다.

생각한 대로 모든 일이 이루어진다면 얼마나 좋을까.

역시나, 세상일을 그렇게 호락호락하지 않다.

돌이켜보면 올 한 해는 정말 다사다난했다.

어떤 순간에는 설명할 수 없는 상실이 갑작스럽게 찾아왔고,

어떤 순간에는 당연하다고 믿었던 관계들이 조용히 끝나 있었다.

말해야 했던 순간에는 침묵했고, 늦게 도착한 진심과 미련은 그 자리를 채우고 남아있다.

시간이 지나갔다는 사실은, 지나간 그 모든 것들을 더욱 선명하게 만든다.

지나간 시간은 되돌릴 수 없고, 내뱉은 말은 다시 주워 담을 수 없다는 걸 온몸으로 배운다.

내가 만들어왔다고 믿었던 역할 역시 생각보다 쉽게 정리될 수 있다는 사실.

그마저도 더 빠르고 냉정한 방식으로 대체될 수 있으리란 현실이 묵직하게 다가오기도 했다.

그럼에도 불구하고 멈출 수는 없었다. 남겨진 시간 속에서 계속 만들고, 배우고 질문했다.

사람이 아닌 것과의 대화 속에서 오히려 내 자신을 더 많이 들여다보게 되기도 했다.

무엇을 놓쳤는지, 어디서부터 어긋났는지를 조용히 되짚는 시간들이었다.

기회는 따로 주어지는 것이 아니라, 지금 이 순간의 태도 속에 존재한다.

완벽하지 않아도 좋다. 도망치지 말고, 미루지 말고, 선택의 책임을 피하지 않는 쪽을 택하자.

이렇게 또 깊이 기억될 하나의 해를 떠나보낸다.

아쉽고, 쓰리고, 여전히 미련이 남아있지만,

붙잡기보다 흘려보내기

JonghwanWon — Tue, 2 Sep 2025 00:55:35 +0900

성장이라는 것을 오랜 시간 동안 오해했던 것 같다.
더 많이 알고, 더 많이 쌓는 일이 곧 성장이라고 믿었다. 하지만 시간이 지나며 성장은 덜어내고 정리하는 능력에 가깝다는 것을 느낀다.
무엇을 더할지가 아니라 무엇을 비워낼지, 무엇을 먼저 둘지, 무엇을 과감히 보내줄지가 성장을 가른다.

무상 (無常)
모든 것은 계속 변화하며, 고정된 상태로 머물지 않는다는 불교의 근본 교리

세상은 끊임없이 바뀐다.
관계도, 요구도, 우리가 일하는 환경도 끊임없이 흐른다. 모든 것은 서로 기대어있고, 혼자서는 완성되지 않는다.
어느 한쪽으로 기울어진 극단은 쉽게 무너지기 마련이다. 일하는 태도 역시 흐름을 전제로 만들어야 한다.

오면 만나고, 가면 헤어지고, 말 걸면 대답하면 된다.
제품도 팀도 그렇다.
중요한 것은 “붙잡기”보다 “흘려보내기”이다. 시작이 있다면 끝이 있고, 끝낼 수 있어야 다시 시작할 수 있다.
붙잡아 두는 힘보다, 무사히 보내는 것이 마음을 가볍게 만든다.

성장한다는 것은 문제를 더 빠르게 푸는 재주 따위가 아니다. 더 적은 전제조건으로, 더 작게 시도하고, 더 쉽게 되돌리는 습관이다.

복잡한 해결책을 들이밀기 전에 가정을 줄여라.
거대한 배포 대신 작은 변경을 자주 하라.
실패가 두렵지 않도록 되돌릴 길을 먼저 닦아놓아라.

속도는 손이 빨라서가 아니라, 배움이 빨라서 생기는 결과다.
배움이 빠르다는 것은 관찰이 가능하고, 가설을 시험하기 쉬우며, 잘못된 선택을 안전하게 되돌릴 수 있다는 뜻이다.

성장이란 간결하다.
덜어내고, 정리하고, 되돌릴 수 있게 한다.
만남과 헤어짐을 일상의 규칙으로 받아들이는 순간, 더 가볍게 일할 수 있고, 더 분명하게 배울 수 있다.
남는 것은 집착이 아니라 지식이고, 쌓이는 것은 피로가 아니라 신뢰가 된다.

오늘도 작게 시작하고, 쉽게 끝내고, 또 다른 시작을 준비한다.
이것은 지금 내가 이해하는 성장의 모양이다.

잘못된 설계가 남긴 것

JonghwanWon — Fri, 8 Aug 2025 20:34:18 +0900

애초에 어떻게 설계했어야 했을까?

복잡한 정책들이 얽혀있는 제품 관련 논의 중, 동료로부터 이런 질문이 나왔다.

아무도 답을 모른다. 정답이 없는 질문이다.
이렇게 제품 기능이 발전될 줄 누구도 몰랐고, 설계가 잘못되었다는 사실은 뒤늦게 천천히 찾아온다.
현재 상태를 잘못된 설계라 판단하고, 새로운 설계로 바꾼다 하더라도 언젠가 또다시 “애초에 어떻게 설계했어야 했을까?”라며 말하고 있을지 모른다.

잘못된 설계는 단순히 실패가 아니다.
과정에서 우리는 어떤 선택이 문제를 일으키는지 몸소 겪었고, 언젠가 비슷한 상황에서 이 방향으로 가게 된 가면 고려해야 할 것들과, 안 된다는 확실한 근거를 얻게 된다.

만약 잘못된 설계를 한 번도 경험하지 않았다면,
더 나은 구조에 대한 고민조차 할 수 없었을 것이다.

실패는 없다.
실패처럼 보이는 모든 순간들은
오히려 앞으로 나아가기 위한 방향을 제시한다.

그렇다면 이것을 “성공하기 위한 마일스톤”으로 바라보는 것은 어떨까.
경험과 시행착오가 남긴 것이 오늘의 나를 성장시켰다고 말이다.

“실패는 방향과 구체성을 부여한다. 그때의 시행착오 덕분에 이번에는 더 나은 선택을 할 수 있다.”

AI 시대, 사고의 외주화와 인간의 역할

JonghwanWon — Wed, 28 May 2025 23:37:42 +0900

드라이기를 하나 사는 데도 우리는 생각보다 많은 과정을 거친다.
“드라이기가 필요해”라는 단순한 목적에서 시작해, “온라인에서 살까? 오프라인에서 살까?”, “쿠팡에서 찾아볼까?”, “어떤 브랜드가 좋지?”, “이 제품은 평이 괜찮네?”, “근데 가격은 좀…” 수많은 선택지를 탐색하고, 비교하고, 고민하다 결국 하나를 선택한다.

이런 사고의 흐름은 단순히 소비에서 끝나지 않는다.
우리의 사고는 대부분 이런 구조를 따른다.

요구사항(목적): 어떤 필요나 문제 인식

사고: 다양한 가능성 탐색과 브레인스토밍

고려: 조건에 따라 비교와 판단

결정: 최종 선택

과거에는 이 모든 과정을 스스로 처리했지만, 이제는 AI가 그 일부를 도와준다. 예를 들어 “드라이기 추천해 줘”라고 말하면, AI는 브랜드, 성능, 가격 등 다양한 정보를 분석해 사용자 대신 수많은 선택지를 정리해 준다. 사용자는 그중에서 골라내기만 하면 된다.

다시 말해 사고의 일부를 AI에게 외주 주는 시대다.

그렇다고 AI가 모든 걸 결정해 주는 것이 항상 정답일까? 단연코 아니다. 중요한 건 인간의 통찰과 판단력이다.
같은 데이터를 보더라도 어떤 기준을 우선시할지, 어떤 조건이 더 중요한지를 판단하는 것은 인간의 역할이다. “왜 이걸 선택했는가?”에 대한 답은 여전히 우리 손에 있다.

이러한 변화는 제품을 만드는 방식에도 영향을 준다.
이전에는 어떤 기능을 갖췄느냐가 중요했다. 하지만 지금은 대부분의 제품이 비슷한 수준의 기능을 제공한다.

기능 중심의 경쟁은 더 이상 의미가 없고, 경험 중심의 차별화가 중요한 시대가 되었다.

“이 기능이 있다”보다, “이걸 쓰는 경험이 좋다”는 것이 제품 선택의 핵심이 된다.
구현하는 것 에서 경험을 구현하는 것으로, 시대가 변화하는 만큼 일하는 방식도 변화하고 있다.

이는 기획, 디자인, 개발 등 하나의 역할에 해당되는 이야기가 아니다. 역할의 경계가 모호해지듯 모두 마찬가지로 적용된다.
이제는 단순히 요구사항을 충족하는 것이 아니라, 사용자가 목적을 말하는 순간의 사고를 확장하며 그 흐름에 맞는 경험을 설계할 수 있어야 한다.
기능을 만드는 것이 아니라, 사고와 판단의 여정을 설계하는 것이 중요해진 것이다.

"AI는 당신의 일을 빼앗지 않는다. 하지만, AI를 잘 활용하는 사람이 당신의 일을 대신할 수는 있다."

반복적이고 구조화된 작업은 AI에게 넘겨지는 속도가 점점 빨라지고 있다.

문제는 “AI가 내 일을 대체할까?”가 아니라 “나는 AI를 얼마나 잘 활용할 수 있는가?”다.

도구가 바뀌면 일하는 방식도 따라서 바뀌기 마련이다. 이 변화를 받아들이지 못하면 당연하게도 도태될 수밖에 없다.

반면 AI를 도구나 동료로 삼아, 판단의 보조로 활용할 수 있는 사람은 더 많은 기회를 가지게 된다.

결국 AI 시대는 배운 사람이 아니라, 활용하는 사람이 이기는 시대다.
이제는 스스로 묻고 답해야 한다.
“나는 AI와 함께 일할 준비가 되었는가?”

사용자 중심 행동의 잘못된 발현: 과잉친절

JonghwanWon — Mon, 31 Mar 2025 23:12:30 +0900

사용자 중심 설계는 제품의 성공을 위해 반드시 필요하다. 하지만 때로는 사용자를 위한다는 마음이 오히려 제품을 망치는 결과를 초래하기도 한다.
디자이너의 지나친 우려는 오히려 사용성을 떨어뜨리기도 하고, 개발과정에 복잡성을 추가하기도 한다.
한마디로 "과잉친절"이다.

보다 효과적인 접근방법은 없을까?

테슬러의 법칙과 복잡성의 본질

사용자 경험(UX) 분야에는 유명한 법칙이 하나 있다. 바로 테슬러의 법칙(Tesler’s Law)이다.

모든 시스템은 일정 수준 이상의 복잡성을 줄일 수 없으며, 줄인 복잡성은 어딘가로 이동될 뿐이다.

제품 설계 과정에서 피할 수 없는 복잡성은 반드시 존재하며, 디자이너가 간소화하지 않은 복잡성은 고스란히 사용자의 몫이 된다는 것을 의미한다. 과잉친절은 복잡성을 제품에서 사용자에게로 떠넘기는 현상 중 하나라고 할 수 있다.

과잉친절은 왜 발생하는가?

디자이너는 기본적으로 사용자의 불편을 최소화하려고 노력한다. 사용자가 조금이라도 혼란을 겪을 가능성이 보이면, 도움말을 추가하거나 조건부 인터페이스를 붙이는 식으로 대응한다. 처음엔 사용자에게 친절한 디자인처럼 보일 수 있다. 그러나 사용자의 행동 패턴과 실제 경험은 다르다.

과잉친절은 다음과 같은 문제를 만들어 낼 가능성이 매우높다.

정보 과부하
긴 설명은 읽히지 않는다. 사용자는 즉각적 이해를 원한다.

혼란 증가
지나친 설명과 조건부 인터페이스는 오히려 사용자의 혼란을 가중한다.

유지보수의 어려움
조건이 추가될 때마다 설계가 복잡해져 유지보수가 어려워진다.

사용자는 즉시 이해되지 않는 인터페이스를 만나는 순간, 그것을 배우기 위해 노력하지 않는다. 긴 설명은 읽히지 않고, 오히려 사용자는 더 많은 혼란과 피로를 느끼게 된다.

즉시 이해되지 않는다는 이유로 툴팁이나 팝오버, 장황한 설명, UI의 분기처리가 사용자의 이해를 도와줄 것이라는 착각을 버려라

지나치게 친절해지고 있다는 느낌이 들면, 문제를 덮기 위한 설명과 장치를 추가하기보다 디자인 설계와 흐름 자체를 점검해보아야 한다.
진짜 사용자 중심 디자인은 다음과 같은 접근에서 시작된다.

텍스트가 아닌 흐름을 점검하라
즉각적으로 이해되지 않아 설명이 필요하다면 이미 설계가 잘못된 것이다. 텍스트로 설명을 덧붙이는 대신, 설계를 단순화하거나 직관적으로 만들어야 한다.

기본값과 명확한 선택지 제공하기
사용자가 복잡한 결정을 내릴 필요가 없도록 명확한 기본값을 제공하거나, 선택지를 간소화해야 한다. 선택지를 늘리는 것이 아니라 가장 좋은 선택지를 미리 제시하는 편이 더 효과적이다.

사용자 관찰과 피드백에 집중하기
사용자의 행동을 관찰해 보면 진짜 필요한 설명과 불필요한 설명이 무엇인지 알 수 있다. 가설이 아니라 실제 사용자 피드백을 기반으로 설계를 결정하는 것이 좋다.

사용자 중심 행동이란 사용자의 입장을 이해하는 것이다. 하지만 사용자를 위한다는 생각이 지나쳐, 친절을 빙자한 복잡한 설계로 이어지면 오히려 사용자의 경험을 망칠 수 있다. 디자이너의 고민은 더 복잡한 설명과 조건으로 해소되지 않는다. 제품이 즉시 이해될 수 있도록 다시 설계의 근본을 살펴봐야 한다.

테슬러의 법칙은 우리에게 중요한 교훈을 준다. 복잡성은 제거되지 않고 이동할 뿐이다. 즉, 디자이너가 해소하지 않은 복잡성은 그대로 사용자에게 전달되어 사용자의 경험을 떨어뜨린다.

사용자를 위한다는 마음이 지나치게 발현된 과잉친절은 사용자에게 더 많은 책임과 피로를 전가한다. 그러므로 복잡성을 관리할 책임은 디자이너에게 있다는 것을 잊지 말아야 한다.

진정한 사용자 중심 설계는 복잡성을 덜어내는 것에서 시작한다.
사용자는 친절한 설명이 아니라 처음부터 이해하기 쉬운 제품을 원한다.