Front J

"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의 분기처리가 사용자의 이해를 도와줄 것이라는 착각을 버려라

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

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

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

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

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

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

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

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

AI는 내 편일까, 내 적일까.

JonghwanWon — Mon, 31 Mar 2025 22:58:18 +0900

AI를 실제 업무에서 활용하며 왠지모를 불안함을 느끼신 적이 있나요.

AI에 기대는 것 같아서 불안해요.
AI가 너무 잘하니까.., 내가 설 자리가 없어지는 느낌이에요.
AI 자주 활용하다보니, 내 사고력이 퇴화되는 느낌이에요.

좋은 질문을 하며, 적절히 활용하고 “나”의 판단으로 완성하는 것

AI를 함께 일하는 동료라고 생각하면 조금 달라집니다.

이것이 진짜 “AI 활용 능력”입니다.

지난 주말, 많은 시간을 Cursor와 Copilot이 지원하는 여러 모델들을 활용해 코드를 작성해보고, ChatGPT의 모델들과 대화하고 흐름을 분석하는 실험에 투자했습니다.

이 과정을 통해, 프롬프트의 구조, 설계에 따라 AI의 반응이 완전하게 달라진다는 걸 체감합니다.

'AI 아직 멀었네' 라고 생각했던 것이 파일럿의 문제였다는 것을 알아차렸죠.

(인터넷에는 이미 너무나 좋은 AI 프롬프트 가이드가 아주 많은데요, 보기만 하는 것과 직접 해보는 것은 다릅니다.)

좋은 질문을 하기 위한 학습, 그리고 지금까지 나의 질문에 왜 그렇게 동작할 수 밖에 없었는지 이해할 수 있었습니다.

ChatGPT에 추가된 Project와 설계한 구체적인 프롬프트로 함께 일하는 동료를 만들어보았습니다.

‘선배님들’ - 개발 철학과 판단을 묻는 멘토

Dan Abramov, Kent C. Dodds, Tanner Linsley의 관점에서의 조언과 코드리뷰, 개발 트렌드에 대한 이야기 등

VoC 분석 전문가 - 사용자의 말에서 인사이트를 찾는 데이터 분석가

리뷰, 고객 피드백 등 자연어에서 감정과 문제를 분석하고, 인사이트를 제안하는 분석가

작명소 - 변수, 함수, 컴포넌트 이름을 함께 고민해주는 네이밍 파트너

의미, 맥락, 관용 표현을 고려하여 더 나은 이름을 제안

Amplitude 선생님 - 튜터

Amplitude 용어, 이벤트의 구조, 실전 분석 연습까지 시켜주는 선생님

프롬프트 설계 도우미 - 질문을 더 잘하는 법을 알려주는 친구

AI는 도구입니다. 도구, 내가 더 일을 잘하도록 지원해주는 도와주는 도구요.

이 도구는, 누구든지 해당 분야의 “준 전문가” 수준으로 만들어줍니다. 그래서 때로는 두렵습니다.

하지만, “전문가”로 만드는 그 차이는 도구를 이해하고 다루는 것에 달려있습니다.

대 AI 시대. 좋은 질문을 던질 수 있는 사람, 스스로 판단하고 이를 응용할 수 있는 사람이 되는 것이 중요한 것 같습니다.

해석과 추론

JonghwanWon — Sat, 8 Mar 2025 23:52:14 +0900

무언가를 만들어 나간다는 것은 단순한 창조 행위가 아니다.

오히려 기존의 것들을 깊이 이해하고, 필요에 따라 조합하며, 점진적으로 발전시키는 과정에 가깝다.

메이커에게는 두 가지 상반된 사고방식이 필요하다.

하나는 '해석'하는 능력이다. 이미 존재하는 것을 분석하고 의미를 파악하는 것.

다른 하나는 '추론'하는 능력이다. 보이지 않는 것까지 예측하고 새로운 가능성을 탐색하는 것.

이 두 가지 사고방식이 어떻게 작용하는지, 영화 식스 센스(The Sixth Sense, 1999)를 통해 살펴보자.

결말을 알고 사건을 해석하는 것 - 해석의 관점

식스 센스를 처음 본 사람이라면, 영화의 결말에서 큰 충격을 받았을 것이다.

"말콤 박사는 처음부터 유령이었다!"

처음에는 눈치채지 못했던 사실이 밝혀지는 순간, 우리는 영화의 장면들을 다시 떠올리게 된다.

왜 말콤과 그의 아내는 대화를 하지 않았을까?
왜 콜은 말콤과만 소통했을까?
왜 말콤이 현실 세계의 사물과 직접적인 상호작용을 하지 않았을까?

영화의 장면을 다른 관점에서 다시 보게 된다. 결말을 알고 난 뒤에야, 그동안 놓쳤던 단서들이 보이기 시작한다.

처음에는 자연스럽게 보였던 장면들이 사실은 숨겨져 있던 진실을 드러내고 있었다는 것을 깨닫는다.

이것이 해석의 과정이다.

이미 주어진 것들을 다시 살펴보며 의미를 찾아내고, "왜 이런 선택이 이루어졌을까?"를 고민하는 것이다.

메이커의 관점에서 생각해 보자.

제품을 만들다 보면, 반드시 기존의 시스템이나 기능을 뜯어보게 되는 순간을 마주하게 된다.

처음부터 직접 만든 것이 아니라, 누군가 만들어 놓은 것을 이어받아 유지보수하거나 개선해야 하는 상황, 다음과 같은 질문들이 이어진다.

기존 제품의 디자인이나 기능은 왜 이렇게 구성되어 있을까?
이 구조에는 어떤 의도가 있었던 걸까?
당시의 요구사항과 의사결정, 그리고 제약사항은 무엇이었을까?

이것을 모르고 무작정 뜯어고치면 오히려 더 큰 문제가 발생할 수도 있다.

식스 센스에서 결말을 알기 전까지 단서를 알아차리지 못했던 것처럼, 제품을 개발하는 것에도 처음에는 보이지 않던 이유들이 있다.

그래서 메이커는 단순히 "이건 잘못됐다"가 아니라,

"왜 이렇게 만들었을까?"를 생각할 필요가 있다.

해석적 사고는 단순하게 이해하는 것을 넘어, 기존의 것을 디딤돌 삼아 더 나은 방향을 모색하는 과정이다.

결말을 모르는 상태에서 사건을 추론하는 것 - 추론의 관점

반대로, 식스 센스를 처음 보는 사람은 결말을 모른다. 어떤 방식으로 이야기를 따라가게 될까?

영화의 초반부부터 단서를 하나씩 모아가며 이야기의 퍼즐을 맞춰나간다.

콜이 유령을 본다고 말한다.
말콤 박사는 콜을 돕기 위해 상담을 진행한다.
콜이 실제로 유령과 대화하는 장면들이 나온다.

관객은 아직 결말을 알지 못한 채, 영화 속 단서들을 가지고 논리를 전개해 나간다.

"콜은 왜 유령을 볼 수 있는 걸까?"

"말콤은 콜을 어떻게 도울 수 있을까?"

그러나 중요한 단서들을 놓칠 수도 있다.

영화 속에서 말콤은 단 한 번도 현실 세계의 사람들과 대화하지 않는다.

하지만 그 사실을 인식하지 못하고, 그저 "아내와 사이가 나빠졌나 보다."라고 생각하며 넘긴다.

이것이 추론의 과정이다.

주어진 정보만으로 완전한 결론을 내릴 수 없지만, 가설을 세우고 끊임없이 검증해 나가는 것.

다시, 메이커의 관점에서 생각해 보자.

새로운 제품을 기획하는 일은 결과를 모르는 상태에서 시작하게 된다.

정답이 정해져 있는 것이 아니라, 필요한 정보를 바탕으로 논리를 전개하고, 여러 가능성을 실험하면서 방향을 찾아나간다.

문제를 해결하기 위해서 어떤 기능이 필요할까?
이 기능이 기존의 사용자에게 어떤 영향을 줄까?
기존의 다른 제품들과 차별화될 수 있을까?

이 과정에서 한 가지 중요한 사실이 있다.

단서는 항상 있지만, 그것을 올바르게 해석하지 못할 수도 있다는 것이다.

영화를 처음 볼 때 중요한 단서를 놓치듯이, 제품을 기획할 때도 "내가 보고 싶은 것만 보는 오류"에 빠질 수 있다.

따라서 추론적 사고는 단순한 아이디어의 생성이 아니라, 여러 가능성을 검증하고 수정하는 과정을 이야기한다.

식스 센스의 이야기를 다시 떠올려보면, 이 영화는 해석과 추론이 절묘하게 균형을 이루는 구조다.

처음 볼 때는 추론적 사고를 하며 결말을 예상해 나간다. 결말을 알고 나면, 해석적 사고를 통해 장면들을 다시 돌아본다.

이 과정은 제품을 개발하는 과정과도 많이 닮아 있다.

새로운 기능을 기획할 때는 추론적 사고를 통해 논리를 전개하고, 기존 제품을 개선할 때는 해석적 사고를 통해 구조를 분석하고 더 나은 방향을 찾는다.

해석은 추론을 돕는다

기존의 제품을 충분히 이해하지 못한 채 새롭게 만들려고 하면, 불필요한 시행착오가 반복될 수 있다.

추론은 해석을 돕는다

새로운 가능성을 탐색하지 않으면, 기존의 방식에만 갇혀 발전할 수 없다.

다시 말해, 해석과 추론을 반복하는 것(지속적인 반복과 학습)은 제품은 더 나은 방향으로 개선해 나아갈 수 있게 한다는 이야기이다.

메이커는 단순히 무언가를 창조하는 사람이 아니다.

존재하는 것을 깊이 이해하고, 새로운 가능성을 탐색하며, 끊임없이 개선하는 사람이다.

해석하며 배우고, 추론하며 나아가자.

그렇게 우리는 더 나은 제품을 만들고 더 나은 세상을 만들어 나갈 수 있다.