besoluble 님의 블로그

[7월 TIL #7] 썸네일 이미지 작업기: 목적을 정하니 프롬프트가 달라졌다

besoluble 장은솔 — Fri, 10 Jul 2026 01:35:32 +0900

회사 블로그 활성화를 담당하는 동료분이 계신다. 나는 개인 블로그를 꾸준히 쓰고 브랜딩을 좋아해서, 그 분의 일에 오지랖을 부리고 싶어졌다. 시작은 블로그 목록을 열어본 것이었다. 글마다 대표 이미지의 화풍이 제각각이었다. 3D 렌더도 있고, 자막을 얹은 밈 스타일도 있고, 만화 컷도 있고, 화면 캡처도 섞여 있었다. 한 블로그의 글이라는 느낌이 들지 않기도 했고, QA가 안 된(?) AI로 만든 이미지들이 글로 들어가는 흥미로운 진입점이 되어주지 못하고 있다는 느낌을 받았다.

대표 이미지의 화풍이 글마다 달랐던 이전 상태

그래서 퀄리티 있는 썸네일을 제안해야겠다는 생각으로 이미지를 만들어보기 시작했다. 처음엔 이미지가 예쁘게 나오지 않아서 만족하지 못했다. 그런데 시안을 여러 장 만들수록 화풍이 아니라 "이 이미지가 무엇을 위한 것인가"라는 질문을 정리해봐야겠다는 생각이 들었다.

이 이미지는 무엇을 위한 것인가

화풍을 바꿔가며 만든 시안들

여러 이미지를 뽑아봐도 마음에 들지 않은 원인은 명확했다. "이번엔 이런 느낌"으로 화풍만 바꿨을 뿐, 그 이미지가 어떤 역할을 해야 하는지는 정하지 않았다. 기준이 없으니 매번 새로 시작하는 셈이었고, 결과도 매번 달랐다.

막힌 지점에서 내 개인 블로그를 떠올렸다. 나는 글마다 펭귄이 등장하는 손그림을 넣는다. 흑백에, 일부러 어설프게 그린 낙서다. 그 이미지의 목적은 그날 내 상황과 감정을 솔직하게 드러내는 것이다. 잘 그리는 게 목적이 아니라서, 전문성보단 공감이 되는 그림을 필요로 한다.

회사 블로그 썸네일의 목적과 여기서 갈린다. 개인의 감정이 아니라 회사가 추구하는 가치를 상징해야 하고, 글의 주제를 품위 있게 압축해야 한다. 그래서 개인 블로그용 프롬프트와 회사 블로그용 프롬프트를 나란히 놓고, 각 축이 어떻게 갈리는지 하나씩 정리해봤다.

개인용(왼쪽)과 회사용(오른쪽) 프롬프트 비교

매체·화풍	흑백 손그림 낙서	플랫 벡터 에디토리얼 일러스트(16:9)
일관성의 축(고정 대상)	캐릭터(펭귄)를 고정	스타일 시스템을 고정
기능	구체적 상황을 서술	주제를 개념으로 추상화
표현 방식	보이는 소품을 그대로 묘사	상징으로 치환(범고래·심해)
색	지정 없음(사실상 흑백)	심해 블루 계열, HEX 위계까지 명시
밀도·구도	규정 없음(자유)	낮은 밀도, 핵심 하나 + 보조 2~3개
톤·무드	어설프게, 안 귀엽고 안 매끈하게	차분하고 침착하고 품위 있게
네거티브 제약	과한 완성도를 막음	브랜드 위반(글자·로고 등)을 막음

한 줄로 요약하면, 개인용 프롬프트의 대표 문장은 NOT CUTE, NOT POLISHED, 즉 어설픔을 지키는 것이고, 회사용의 대표 문장은 CALM, COMPOSED, DIGNIFIED, 즉 품위를 지키는 것이다. 두 프롬프트의 지향점이 이 두 구절에 압축돼 있다.

회사용에서 가장 깎았던 부분은 이미지의 톤을 지시하는 부분이었다. "차분하게"라고만 쓰면 AI가 해석할 여지가 너무 넓었고, 그렇다고 구체적인 개체를 넣자니 가치를 지향하는 추상적인 이미지에서 벗어났다. 그러다가 AI가 적합한 표현을 찾아주어 넣게 되었다.

THE POISE OF AN ORCA GLIDING THROUGH DEEP WATER

직역하면 "깊은 물속을 미끄러지듯 나아가는 범고래의 poise"다. poise는 번역이 까다로운 단어인데, 침착함과 평정심, 흔들리지 않는 안정감과 기품을 한꺼번에 담고 있다. 이 구절은 그림에 범고래를 그리라는 지시가 아니다. 바로 앞의 CALM, COMPOSED, DIGNIFIED MOOD를 받아서, 그 분위기가 어느 정도여야 하는지를 비유로 못 박는 장치다. 색 지정이 심해 블루 계열이라, 그 세계관과 맞는 생물을 골라 무드를 설명한 것이다. 회사를 상징하는 범고래의 이미지를 개체를 제외하고 상징적으로 표현하면서 "진지하고 무게감 있되 음침하지 않은" 요구와도 맞았다.

썸네일에는 검색이라는 목적도 있었다

여기까지는 브랜딩과 일관성 쪽 이야기다. 그런데 이 작업에는 나 혼자 판단하지 못한 축이 하나 더 있었다. 블로그 활성화를 맡은 분이 알려준 것인데, 검색 결과에서 썸네일이 정사각형으로 잘려 노출되기 때문에, 타이틀과 로고가 그 정사각형 영역 안에 들어와 있어야 검색 노출에 유리하다는 것이었다.

검색 결과에서 정사각형으로 잘리는 영역(빨간 테두리)에 타이틀과 로고를 배치한 가이드

이 관점은 브랜딩과 결이 다르다. 이미지 위에 얹는 타이틀과 로고는 정사각형 안쪽에 배치해야 잘려나가지 않는다. SEO 관점를 고려해본 적은 처음이라 흥미로운 지점이었다.

한 세트로 정리됐다

목적과 축을 정하고 나니, 같은 프롬프트 골격에 주제만 바꿔 넣어도 톤이 유지됐다.

같은 스타일 시스템으로 만든 썸네일

글 목록 전체도 달라졌다.

제각각이던 대표 이미지가 한 세트로 정리된 모습

더 반가웠던 건 그 다음이다. 정리한 프롬프트를 넘겨드렸더니, 마지막 글 하나는 그분이 직접 썸네일을 만들어 올리셨다. 내가 이미지 몇 장을 대신 만들어준 게 아니라, 그분이 혼자 만들 수 있는 규칙을 넘겨드린 셈이 됐다.

예쁘게는 마지막 문제였다

돌아보면 이번 작업에서 오래 걸린 건 이미지를 뽑는 일이 아니라, 이 이미지가 무엇을 위한 것인지 정하는 일이었다. 모든 사소한 일도 결국 취향의 문제가 아니라 목적을 정하고 그 목적에 맞는 조건을 세우는 일이라는 걸 다시 생각하게 되었다. 개인 블로그의 어설픈 펭귄 이미지를 만든 경험이 회사 블로그의 품위 있는 심해를 만드는 데에 도움이 된 점도 뿌듯했다. 굿!

[7월 TIL #6] 채팅창을 벗어난 AI: UI 놓고 분류해보기

besoluble 장은솔 — Thu, 9 Jul 2026 00:16:45 +0900

최근 채팅 형태를 넘어서 AI UI에 대해 [7월 TIL #1] 채팅창을 벗어난 AI: 4단계 GUI 진화와 자율성에서 내용을 정리했다. 오늘은 동료 분께서 관련 주제로 n년간 모으신 자료들을 제공해주신 것을 하나씩 열어보며, 실제 제품에 적용된 모습 위주로 모아봤다. 이전 글에서 세워둔 4단계 프레임에 맞춰 정리했다. 다만 프레임에 따른 분류에 보는 관점에 따라 이견이 있을 수 있다.

자율성에 따른 4단계

1단계: 행동 표면 (The Verb Surface)
- "명령을 버튼으로 압축하다"
- 제거하는 것: 프롬프트 '설정(Setup)'의 수고.
2단계: 생성형 캔버스 (The Generative Canvas)
- "수정 가능한 결과물을 바로 띄우다"
- 제거하는 것: 결과물을 내 작업창으로 '옮기는 과정(Translation)'.
3단계: 위임형 에이전트 (The Delegated Agent)
- "알아서 일하고 결과만 보고하다"
- 제거하는 것: 매 단계마다 개입해야 하는 '중간 감독(Supervision)'.
4단계: 무의식적 캡처 (The Ambient Capture)
- "프롬프트조차 생략하다"
- 제거하는 것: '프롬프트 명령 그 자체'.

1단계: 행동 표면 (The Verb Surface) - "명령을 버튼으로 압축하다"

- 제거하는 것: 프롬프트 '설정(Setup)'의 수고.

Labeling

NotebookLM, 본인 캡처

여러 소스들을 보면서 "이 글들의 내용을 분석해서 어울리는 주제별로 카테고리를 만들고 묶어줘"라고 길게 프롬프트를 짤 필요 없음. 상단에 있는 "주제를 기준으로 소스에 자동 라벨 지정"이라는 버튼 하나로 복잡한 명령을 압축해 버렸기 때문.

Do the Obvious Thing

https://allenpike.com/2025/post-chat-llm-ui/

4단계 관점 (프롬프트 명령 그 자체를 생략):
그저 평소처럼 글을 쓰고 있었을 뿐인데, AI가 사용자의 입력 맥락을 배경에서 실시간으로 포착(Ambient)하여 오류를 잡아내고 Fix errors라는 툴팁을 띄웠음. 유저가 무슨 앱에서 무엇을 하고 있는지 실시간으로 파악해 적절한 행위를 제시.

2단계 관점 (결과물을 옮기는 과정 제거):
오류를 수정하기 위해 별도의 사이드바 창을 열거나, AI가 추천한 올바른 문장을 복사해서 내 글에 붙여넣을 필요가 없음. 사용자가 작업 중인 텍스트 에디터(캔버스) 안에서 Tab 키 하나만 누르면 그 자리에서 즉시 올바른 표현으로 텍스트가 교체됩니다.

Clean Up

https://allenpike.com/2025/post-chat-llm-ui/

2단계: 생성형 캔버스 (The Generative Canvas) - "수정 가능한 결과물을 바로 띄우다"

- 제거하는 것: 결과물을 내 작업창으로 '옮기는 과정(Translation)'.

Adept AI의 줌(Zoom) UI

https://www.youtube.com/watch?v=PAy_GHUAICw

+ 실제 줌 기능 구현 트윗 데모: https://t.co/TdSrSsKs3i
구글맵처럼 화면을 줌인/줌아웃(추상화 사다리, Ladder of Abstraction)하며 상호작용하는 줌 가능한 문서 실험

2단계 + 3단계
제거하는 수고: 목록을 엑셀로 옮겨적는 번역 과정(2) + 호스트에게 일일이 묻는 노가다(3)
작동: 답변을 줄글이 아니라 '산점도 → 테이블 → 카드'로 이어지는 반응형 캔버스로 띄워 줌인/아웃으로 조작. 그래프에서 특정 클러스터를 동그라미 치고 "얼리 체크인 되는지 물어봐" 하면 AI가 병렬로 메시지 발송·보고.

Google DeepMind의 Music AI Sandbox

https://deepmind.google/blog/music-ai-sandbox-now-with-new-features-and-broader-access/

제거하는 수고: 완성 오디오를 DAW로 내보내는 과정
작동: mp3 다운로드 대신, 생성 클립을 멀티트랙 타임라인 위 편집 가능한 블록으로 즉시 정렬. EXTEND/EDIT로 작업 공간 안에서 바로 이어붙이고 수정.제거하는 수고: 코드 블록을 복사해 정확한 위치에 붙여넣는 과정
작동: 실제 작동하는 웹 화면에서 수정할 요소(h2 등)를 직접 클릭해 그 자리에서 AI에게 수정 요청. 코드와 최종 결과물이 하나의 캔버스로 통합.

Replit의 Element Editor

https://replit.com/blog/element-editor

제거하는 수고: 코드 블록을 복사해 정확한 위치에 붙여넣는 과정
작동: 실제 작동하는 웹 화면에서 수정할 요소(h2 등)를 직접 클릭해 그 자리에서 AI에게 수정 요청. 코드와 최종 결과물이 하나의 캔버스로 통합.

3단계: 위임형 에이전트 (The Delegated Agent) - "알아서 일하고 결과만 보고하다"

- 제거하는 것: 매 단계마다 개입해야 하는 '중간 감독(Supervision)'.

(메모)
"3단계는 UI로 드러나지 않는다"는 것 자체가 흥미롭습니다. 3단계(위임형 에이전트)의 핵심은 "AI가 백그라운드에서 알아서 여러 스텝을 처리하고 결과만 보고"하는 건데, 이건 본질적으로 화면에 보여줄 게 없는 단계예요. 에이전트가 뒤에서 20개 작업을 도는 장면은 스크린샷이 안 됩니다.
순수 3단계 예시 보강용 대표적인 3단계 사례들
- 딥리서치류 (Deep Research 등): 질문 하나 던지면 수십 개 소스를 알아서 돌고 리포트만 반환
- 코딩 에이전트 (Claude Code, Cursor 에이전트 모드 등): "이 버그 고쳐줘" → 파일 여러 개 수정하고 PR까지
- 컴퓨터 유즈/예약 에이전트: "이 조건으로 예약해줘" → 사이트 돌아다니며 대신 클릭

4단계: 무의식적 캡처 (The Ambient Capture) - "프롬프트조차 생략하다"

- 제거하는 것: '프롬프트 명령 그 자체'.

Inline Feedback

https://allenpike.com/2025/post-chat-llm-ui/

제거하는 수고: 검증 요청 명령 자체(4) + 근거를 내 글로 복붙하는 과정(2)
작동: 우측 렌즈들(Devil's Advocate 등)이 작업 맥락을 배경 감지해 허점을 지적하고, 반박 근거를 별도 챗창이 아니라 문서 위 인라인 팝업으로 표시. +Add로 내 글에 즉시 삽입.
제거하는 수고: 완성 오디오를 DAW로 내보내는 과정
작동: mp3 다운로드 대신, 생성 클립을 멀티트랙 타임라인 위 편집 가능한 블록으로 즉시 정렬. EXTEND/EDIT로 작업 공간 안에서 바로 이어붙이고 수정.

Summary and Synthesis

https://allenpike.com/2025/post-chat-llm-ui/

제거하는 수고: 요약 요청 명령(4) + 알림을 일일이 거르는 감독(3)
작동: OS 백그라운드로 밀려드는 알림을 스스로 포착하고, 중요도를 알아서 판단해 최종 요약만 보고.

Ghost Text UI

https://stackoverflow.com/questions/72878625/vscode-insiders-how-to-stop-showing-ghost-text-suggestions

Google AI Studio, 본인 캡처

제거하는 수고: 지시어 입력 자체(4)
작동: 그냥 타이핑하는데 AI가 맥락을 캡처해 다음 코드를 유령 글씨로 제안. 별도 창이 아닌 현재 코드창에 바로 떠서 Tab으로 즉시 적용(2단계 인터랙션 결합).

마무리
1. 결국 중요한 건 "이 제품이 유저의 어떤 문제를 푸는가", 그리고 "그걸 얼마나 진심으로 해결하고 싶은가"다.
이 두 가지가 분명할 때 비로소 '게으른 채팅창'을 만들지 않게 된다. 앞의 사례들이 프롬프트나 복붙, 감독 같은 수고를 굳이 없앤 것도, 결국 유저의 문제를 진짜로 끝까지 해결하려 했기 때문이다.
2. 제작자의 상상력도 결국 아는 만큼이다.
"UI와 AI가 이렇게까지 만날 수 있다"는 걸 직접 보고 인풋으로 쌓아두는 게 정말 중요하다. 이런 사례들을 알고 있어야, 내가 만들 때도 채팅창 너머의 형태를 떠올릴 수 있다. (Shout out to AK.. ‍♂️)
3. 그래서 다음엔, 문라이트나 내가 일상에서 만들어 쓰게 될 AI 도구에 이 관점을 하나라도 직접 적용해보려 한다.
보는 데서 그치지 않고 한 번 만들어봤으면 더 재밌었을 것 같아서 살짝 아쉽다. 만들어봐야지 ㅎㅎ 굿!

[7월 TIL #5] 아는 것과 하는 것 사이 knowing-doing gap

besoluble 장은솔 — Wed, 8 Jul 2026 09:41:00 +0900

어제 두 가지 일을 하는 내내 묘하게 괴로웠다. 하나는 다음 날 있을 팀 미팅 진행안을 준비하는 일이었고, 다른 하나는 새 기능 하나를 동료와 함께 방향을 잡는 일이었다. 성격이 꽤 다른 두 일인데, 괴로움을 느낀 포인트가 비슷했다.

미팅 준비는 "여기까지만 준비하면 된다"를 스스로 못 정해서 범위가 계속 커졌고, 짝작업은 대화를 나눌수록 머릿속이 오히려 더 복잡해졌다. 바라는 건 큰데 그걸 무엇부터 어떻게 할지가 안 잡히니까, 정리되지 않은 상태였다. 문제는 그 사실 자체가 아니라 마음이 급해서 그 미정의 상태를 못 견디는 + 이걸 내가 해낼 수 있다는 자신감이 부족한 상태에 있다는 셀프 진단을 내렸다.

방법을 몰라서가 아니었다

처음엔 방법을 몰라서라고 생각했다. 그런데 사실 이런 상황을 다루는 좋은 방법을 나는 알고 있다. 큰 기회를 잘게 쪼개 작은 실험으로 검증하는 Opportunity Solution Tree도, 유저 여정을 관통하는 가장 얇은 한 조각부터 내보내는 스토리맵의 슬라이싱도 개념으로는 익숙하다. 문제는 그렇게 끝까지 해본 적이 한 번도 없다는 것이다. 해본 적이 없으니, 이 뿌연 중간 과정이 결국엔 뭔가로 정리된다는 걸 몸이 믿지 못한달까..

아는 것과 하는 것 사이

이 간극에 이름을 붙여준 글을 하나 읽었다. 교사들을 위한 뉴스레터를 쓰는 Peps McCrea의 The Knowing-Doing Gap이다. 좋은 교육법을 배우고 남에게 권하기까지 하면서도, 정작 자기 수업에서는 예전 방식대로 하고 그 모순을 스스로 눈치채지 못한다는 이야기다. 저자 본인의 예가 인상적이었다. 인지부하 이론을 분명히 배웠는데도, 학생들이 혼자 문제를 푸는 시간에 옆에서 계속 설명을 늘어놓고 있더라는 것이다.

https://snacks.pepsmccrea.com/p/the-knowing-doing-gap

McCrea는 아는 것이 하는 것으로 넘어가려면 네 가지가 다 있어야 한다고 말한다.

Insight: 그 개념을 이해하는 것
Model: 잘 해내는 예시를 실제로 보는 것
Practice: 피드백을 받으며 직접 연습하는 것
Habit: 그 행동을 습관으로 굳히는 것

이 중 하나라도 없으면 배운 건 실제 행동으로 바뀌지 않는다. 내 상태를 여기에 대보니 분명했다. 나는 Insight 하나만 갖고 있었다. 잘하는 사람이 이걸 실제로 어떻게 하는지 본 적도(Model), 작게라도 직접 끝까지 해본 적도(Practice), 그게 몸에 밴 적도(Habit) 없었다. 그래서 결국 이 글에 나오는 "Most of the time what we do is what we do most of the time." 즉 우리가 하는 일의 대부분은 평소에 가장 많이 하던 그것을 하게 된다. 만약 이걸 깨지 못하면 설계와 의도는 모호한채로 솔루션부터 개발하고 있을 것이다.

그런데 이게 진짜 정답일까

여기까지 왔을 때 한 가지가 더 걸렸다. 설령 내가 그 방법들을 연습해서 습관으로 만든다 해도, 그것만으로 이 문제가 다 풀리진 않았을 것 같았다. 우리 제품은 이미 굴러가고 있다. 유저는 각자의 방식으로 이미 쓰고 있고, 검색과 라이브러리와 뷰어가 서로 얽혀 있어서 하나를 건드리면 다른 게 흔들린다. 여기엔 "되나 안 되나"가 없다. 그래서 무엇을 남길지 기준을 내가 직접 세워야 하는데, 그 기준이 없으니 무엇을 골라도 자의적으로 느껴진다. 어제 느낀 애매함의 정체가 이거였다. 고를 게 없어서가 아니라, 고르는 기준을 스스로 만들어야 하는데 그걸 안 해본 것이다.

결국 이미 있는 것을 두고 무엇을 개선할지 정하는 일은, 여러 조건을 한꺼번에 저울에 올려 판단하는 일이다. 어떤 유저를 볼지, 어떤 불편이 더 급한지, 그걸 고치면 다른 기능과 어떻게 맞물리는지, 이번 주에 감당할 수 있는지. 어떤 방법론도 이 판단을 대신 내려주지 않는다. 방법은 가이드만 줄 뿐이고, 마지막 판단은 불확실한 채로 우리가 내려야 한다.

그래서 앞으로는

정리하다보니 아직 안 해본 일 앞에서 당연히 나오는 반응이라는 생각이 들었다. 그래서 일단 앞으로는 이렇게 해봐야겠다는 것을 정리해봤다. 근데 진짜 이게 내재화돼서 나만의 방식으로 진짜 풀어봐야 뭐라 말할 수 있을 것 같다.

조급함부터 인정한다. 정리되지 않은 상태를 못 견디고 마음이 급해져서 괴롭다는 걸 인식하자..
혼자만의 결정으로 두지 않는다. 어디까지를 논할지부터 동료와 함께 처음부터 얘기하면 된다.
나에게 맞는 방법을 의도적으로, 반복해서 찾는다. 결국 필요한 건 이미 있는 어떤 방법을 나만의 것으로 활용하는 과정이고 그건 여러 번의 연습으로만 만들어진다.

으아아. 굿...

[7월 TIL #4] 상반기 팀 리뷰: AS-IS 개선하는 사람, TO-BE 설계하는 사람

besoluble 장은솔 — Tue, 7 Jul 2026 09:03:35 +0900

상반기 팀 리뷰를 했다. 성과를 평가하는 자리라기보다, 지난 반년 동안 팀과 개인이 어떤 방향으로 변했고, 어떤 방식으로 성장했는지를 돌아보는 시간에 가까웠다. 그래서 회고가 끝나고 나서도 “이번 반기에 뭘 했더라?”보다 “나는 팀 안에서 어떤 역할을 하고 있었지?”, “우리는 어떤 방식으로 일하는 팀이 되어가고 있지?” 같은 질문이 더 오래 남았다.

먼저 기억을 복원하고, 그다음 질문에 답했다

이번 회고에서 좋았던 점은 시작부터 기억에만 의존하지 않았다는 것이다. 각자 먼저 에이전트와 함께 자신의 상반기를 정리했다. 예를 들면 “내 이름이나 계정으로 1월부터 6월까지 Notion과 Slack에서 한 일을 찾아 활동 로그로 정리해줘” 같은 프롬프트를 돌리고, 지난 반년 동안 했던 일을 먼저 펼쳐보았다. 이 과정 덕분에 회고 시트를 채울 때 완전히 빈 화면 앞에서 기억을 짜내는 느낌이 아니었다. 이미 각자의 머릿속에는 어느 정도 자기 상반기의 재료가 정리되어 있었다. 그 상태에서 회고 질문을 따라가며 필요한 장면을 꺼내고, 의미를 붙이고, 동료들과 이야기를 나눴다.

단계	질문	무엇을 보려는 질문이었나
체크인	오늘 컨디션은 어떤지, 이유는 무엇인지	지금의 상태를 가볍게 공유하기
팀의 변화와 성장	연초의 우리와 지금의 우리는 무엇이 달라졌는지	팀이 어떤 방향으로 성장했는지 보기
팀 KEEP / TRY	유지할 것과 새롭게 시도할 것은 무엇인지	팀의 다음 반기 방향 잡기
개인 성장 TOP 3	내가 상반기에 성장한 부분은 무엇인지	스스로 인식한 성장 정리하기
동료 코멘트	동료가 보기엔 나는 어떻게 성장했는지	내가 못 본 변화를 타인의 시선으로 보기
개인 KEEP / TRY	피드백까지 보고 유지/시도할 것은 무엇인지	개인 성장의 다음 액션 잡기
역할 회고	나는 어떤 역할에 가까웠는지	팀 안에서의 기여 방식을 이해하기

질문을 따라가며 내가 적은 답들

연초의 우리 vs 지금의 우리 — 무엇이 달라졌나
팀의 변화에 대해 나는 가장 먼저 “일회성에서 지속가능성으로”라는 말을 적었다. 상반기 초반에는 개별 화면이나 실험에 대응하는 일이 많았다면, 시간이 지나면서 디자인 시스템, 운영 분류, 모니터링처럼 다음에도 재사용될 수 있는 자산을 만들려는 움직임이 늘었다고 느꼈다. 또 하나는 직관에서 근거로 옮겨갔다는 점이었다. 실험 데이터, 리서치 방법론, 플랫폼 가이드라인을 바탕으로 판단하려는 흐름이 팀 전반에 생겼다. 유저 인터뷰나 학교 방문처럼 실제 유저를 만나는 일도 많아졌고, 중국 유저 리서치나 국제화, 글로벌 광고처럼 국내를 넘어 실제 글로벌 실행으로 이어진 일도 있었다.

내가 상반기에 성장한 부분 TOP 3
개인 성장으로는 세 가지를 적었다. TIL을 통해 성장하는 루틴을 찾은 것, 기획력과 추진력을 팀에 활용하게 된 것, UX/UI에 대한 기준과 관점이 쌓이고 있다는 것. 적을 때는 “내가 요즘 이런 쪽으로 성장하고 있나 보다” 정도의 감각이었는데, 동료들의 코멘트를 읽고 나니 이 세 가지가 조금 더 구체적인 형태로 보였다. 동료들이 반복해서 말해준 것은 크게 네 가지였다. 첫째, TIL은 단순히 매일 쓰는 기록이 아니라 회고와 학습이 쌓이면서 생각의 질을 높이는 루틴이 되고 있었다. 둘째, 블로그나 스터디, 문서로 쌓은 UX/UI 관점은 나 혼자만의 공부가 아니라 팀의 UX/UI 이해도를 높이는 데에도 조금씩 기여하고 있었다. 셋째, 문서에서 why와 근거가 더 잘 드러나면서 팀원이 내 맥락과 판단 과정을 이해하기 쉬워졌다는 피드백이 있었다. 넷째, 유저 리서치 이후 바로 개선으로 연결하는 실행력이 좋았다는 말도 있었다. 특히 UI 개선에 대해 “유저의 눈높이에서 반발자국 앞선 지점”을 노렸다는 피드백이 기억에 남는다.

그래서 이 챕터의 KEEP은 단순히 “TIL 계속 쓰기”가 아니었다. TIL을 통한 성장 루틴을 유지하고, UX/UI 관점과 기준을 팀에 공유하고, why와 근거가 드러나는 문서를 쓰고, 유저 눈높이에 맞춘 빠른 실행력을 이어가는 것이었다. 내가 혼자 쌓고 있다고 생각한 것들이 사실은 팀의 판단 기준이나 제품 개선 방식과 연결되고 있었다는 점이 중요했다. 반대로 TRY는 그 성장의 다음 단계에 가까웠다. 지금까지 쌓은 UX/UI 관점을 개인 인사이트에 머무르게 하지 않고 팀이 함께 참고할 수 있는 원칙이나 체크리스트로 명문화하기. 좋은 글이나 인사이트를 TIL에만 남기지 않고 팀 문서, 세미나, 디자인 리뷰 기준 같은 팀 자산으로 확장하기. 그리고 기획력과 추진력을 더 의도적으로 써서 유저 문제 발견 → 개선안 설계 → 실행 → 회고까지 이어지는 작은 사이클을 주도해보기.

전체적으로 모아보니 보인 다섯 가지

다시 정리해보니 크게 보면 회고 포인트는 5개였다.

AI 활용은 익숙해졌고, 이제는 기준과 검증의 단계
그냥 많이 쓰는 것보다 문키/제니스/리뷰하네스가 팀원처럼 안정적으로 일하게 만들기.
유저를 만나는 활동은 늘었고, 이제는 소화 체계가 필요
인터뷰·방문·개밥먹기에서 얻은 인풋을 제품 의사결정으로 연결하는 구조 만들기.
팀은 안정됐고, 이제는 더 공격적인 실험이 필요
편안함을 유지하되 대학교 방문, 타 제품 깊게 써보기, 연구 지원처럼 직접 부딪히는 시도.
개인 학습은 쌓였고, 이제는 팀 자산으로 바꿀 때
나에게는 이게 특히 중요해 보였다. TIL, UX/UI 관점, 문서의 why와 근거를 개인 기록에서 팀의 기준/체크리스트/리뷰 언어로 확장하기.
부분 개선은 잘했고, 이제는 큰 흐름 설계 연습
상반기에는 유저의 불편을 발견하고 빠르게 개선하는 경험을 쌓았다면, 하반기에는 그 개선들이 어떤 하나의 사용자 경험으로 이어져야 하는지까지 더 넓게 보고 싶다.

지금의 역할과 해보고 싶은 역할

회고에는 내가 상반기에 어떤 역할을 주로 했는지 돌아보는 항목도 있었다. AI 시대에는 엔지니어링, 제품, 디자인 같은 직무 경계보다 Prototyper, Builder, Sweeper, Grower, Maintainer 같은 역할 원형으로 팀을 볼 수 있다는 내용의 보리스 체니의 X 글 에서 가져오신 부분이었다. 내 답변을 모아보면 나는 Sweeper와 Grower에 가장 가까웠다.

역할과 내 답변

Prototyper	⚪️낮음. 새로운 시도나 아이디어는 있지만, 핵심 강점은 아이디어 발산보다 유저 근거 기반 개선에 가까웠다.
Builder	중간. 리서치 후 바로 UI 개선 작업으로 연결하는 실행력은 있지만, 인프라나 프로덕션화보다는 제품 개선 쪽에 가까웠다.
Sweeper	높음. UI/UX 기준을 만들고, 과하지도 덜하지도 않은 개선을 하며 제품 경험을 정리하는 역할이 강했다.
Grower	높음. 유저 인터뷰, 건대 방문, UX/UI 개선처럼 이미 있는 제품을 유저 관점에서 더 잘 맞게 반복 개선했다.
Maintainer	⚪️낮음. 안정성, 보안, 성능, 운영 소유보다는 UX 품질, 학습, 제품 개선 쪽 기여가 더 두드러졌다.

나는 완전히 새로운 무언가를 많이 던지는 사람이라기보다, 이미 있는 제품을 유저의 맥락에 맞게 다듬고 정리하는 쪽에 가까웠다. 그런데 동시에 Prototyper나 Builder 역할도 더 해보고 싶다는 생각이 들었다. 결국 유저 경험을 크게 설계한다는 것은 단순히 기존 화면을 개선하는 것만으로는 부족하기 때문이다. 새로운 흐름을 상상하고, 그것을 빠르게 형태로 만들어보고, 팀원들과 함께 검증하는 경험이 필요하다. 그런데 아직 나는 개선에는 익숙하지만 큰 그림을 설계하는 일에는 아직 어려움을 느낀다. 하지만 경험이 없어서 어렵다면, 시도하지 않는 한 계속 못하는 상태로 남을 수밖에 없으니까 뭔가 깨는 경험이 필요할 거 같다.

하반기 목표와 남은 생각

결론적으로 모아보니 상반기에는 성장하는 방법을 찾았다면, 하반기에는 그 성장을 팀이 함께 쓸 수 있는 형태로 남기는 데에 신경을 써야겠다는 생각이 든다. 혼자 쌓은 생각을 혼자만의 기록으로 끝내지 않고, 더 나은 제품 판단과 더 좋은 사용자 경험으로 이어지게 만들고 싶다. 이번 회고를 하면서 은근히 제품이 아닌 나에 대한 피드백을 들을 일이 별로 없구나 하는 생각도 했다. 평소에는 기능이 잘 나갔는지, 실험 결과가 어땠는지, 문서가 충분히 명확했는지를 많이 본다. 그런데 내가 어떤 방식으로 성장하고 있는지, 팀 안에서 어떤 역할을 하고 있는지, 다른 사람에게는 내 변화가 어떻게 보이는지를 들을 기회는 많지 않았다. 그래서 이 시간이 더 의미 있었던 것 같다. 앞으로는 더 주도적으로 피드백 받을 수 있게 시간을 만들어봐야겠다. 피드백 루프를 만드는 게 중요하다는 걸 알면서 참 쉽지 않다. 아무튼 굿!

[7월 TIL #3] UI 리뉴얼 작업기: 의사결정은 혼자 존재하지 않는다

besoluble 장은솔 — Sun, 5 Jul 2026 23:41:16 +0900

지난달에 "완벽한 체계를 선언하지 말고, 매일 하나씩 좋은 의사결정을 저장하자"는 7일 챌린지를 시작했다([6월 TIL #10] 디자인 시스템 앞에서 자꾸 멈추는 이유). 버튼 하나, 색 하나, 검색 결과 아이템 하나여도 된다는 규칙이었다. 색 토큰 정리부터 시작했는데, 며칠 만에 멈췄다.

그 멈춘 시점부터 제품의 핵심인 PDF Viewer UI를 전반전으로 리뉴얼하는 작업을 했고, 오늘 1차 작업을 끝냈다. 오늘은 그 2주 반의 작업과 그때 내린 결정들을 문서로 정리했다. 내가 봐도 급발진같아 보이긴 하는데(ㅋㅋ..) '하나씩'에서 '전체 리뉴얼'로 변경한 이유는, 어떤 의사결정도 혼자 존재하지 않는다는 걸 그 '하나씩'을 시도하다가 알게 됐기 때문이다. 하나의 결정이 컴포넌트와, 더 나아가 기능 그리고 경험에 연결돼 있었다.

하나를 정하려면 전체가 필요했다

챌린지 논리대로라면 "오늘은 이것 하나만 결정"하면 되는 날들이 있었다. 그런데 버튼이든 색이든 폰트든, 하나를 표준화하려고 들면 그게 어디에 왜 쓰이는지 전체를 알아야 기준이 정해졌다. 개별 요소 하나만 떼어서는 결정할 수 없었다. 예를 들어 타이포가 그랬다. 원본 제품엔 폰트 크기 체계가 없어서 몇 가지로 줄여 기준을 잡기로 했다. 그런데 몇 개로, 어떤 기준으로 줄일지 생각하다 보니, 어떤 크기를 남기고 버릴지는 그 크기가 상단바·사이드바·배지·본문 어디에 왜 쓰이는지 전체를 알아야 정해졌다. 타이포 하나의 기준이 제품 전체에 연결돼 있었다.

타이포 사이즈라는 결정 하나가 모든 것들과 엮여 있었다.

개별 최적화에서 근거와 목적으로

돌아보면 "매일 하나씩"은 멈춰 있던 작업을 시작하게 하려는 장치지 그 자체가 디자인 시스템을 만드는 방법은 아니었던 것 같다. 내가 목표로 적은 것도 "좋은 의사결정을 저장하는 경험을 만드는 것"이었다. 좋은 결정은 개별 요소가 아니라 그것을 관통하는 근거와 목적에서 나올 것 같다는 생각에 개별 결정을 멈추고 근거부터 정리했다.

근거는 두 곳에서 같은 지점을 가리켰다. 유저 구독 취소 설문 신호는 무엇이 불편한지를, Nielsen 사용성 휴리스틱 평가는 왜 불편한지를 짚었다. 17개월간 응답에서 "UI가 불편함"은 여섯 개 분기 내내 반복해서 상위 불편으로 꼽혔다. 휴리스틱으로 점검하니 시스템 상태의 가시성, 재인 > 기억, 일관성 위반이 반복 확인됐다. 두 근거가 같은 지점을 가리켰고, 며칠 전 공부한 지각된 가치와 인지된 비용 개념을 목적의 두 축으로 삼았다. 인지된 비용을 낮추고, 지각된 가치를 높인다.

새 기능이 아니라 규칙을 다시 세운 것

인지된 비용은 이걸 쓰는 데 드는 상호작용 비용(interaction cost), 곧 머리 쓰기(판단·기억)와 몸 쓰기(클릭·이동)다. 지각된 가치는 이걸 써서 얻는 이득, 첫인상과 이득의 가시성이다. 각 변경이 두 축 중 어디에 해당하는지 표시하고, 그 판단의 근거로 UX 원칙을 적었다. 몇 개만 보면 이렇다.

버튼 상태: 켜짐이 hover의 흐린 복제본이라 무엇이 활성인지 판별하기 어려웠다. 켜짐에만 전용 표시(칩 배경과 안쪽 테두리)를 줬다. → 비용↓ (시스템 상태의 가시성)
사이드바: 닫으면 안의 것이 통째로 사라져 기능이 있는지도 몰랐다. 접어도 아이콘 레일이 남고, 하이라이트·설명·주석 탭에 실시간 개수 배지를 달았다. → 가치↑·비용↓ (재인 > 기억)
설명 팝오버: PDF 확대 배율에 묶여 크기가 함께 커지고 작아졌다. 화면 좌표 기준 카드로 분리해 배율과 무관하게 일정한 크기로 뒀다. → 비용↓ (예측 가능성)

이런 식으로 공통 기반, 상단바, 사이드바, 설명 팝오버, 설정까지 다섯 개 영역에 걸쳐 열세 개 항목을 같은 형식으로 정리했다.

뒤늦게 이름을 알게 된 것

돌아보면 그땐 "매일 하나씩 저장하자"는 규칙으로 작업을 시작해보려 했다. 다시 생각해보니 그건 근본적으로 개별로는 정할 수 없는 일이었다. 하나의 결정이 전체에 연결돼 있어서, 하나씩 떼어 저장한다는 접근이 성립하기 어려웠다. 이 작업을 정리하다 인터페이스 인벤토리라는 방법을 알게 됐다. 제품의 UI 조각을 전부 모아 시스템으로 정리하는 작업인데, 애초에 개별 요소를 하나씩 떼어 판단할 수 없다는 전제에서 출발한다. 내가 부딪힌 게 이 전제였다. 개별로는 못 정하고 전체를 놓고 정해야 한다는 것. 이건 따로 더 공부해보려 한다.

오늘 1차 작업을 마무리하고 내일 팀원들에게 공유하기 위한 문서를 작성하며, 이 작업을 하게 된 생각의 흐름을 정리해보고 싶었다. 동료들과 유저들에게 받게 될 반응이 두렵기도 하면서 더 좋아지길 바라며 한 작업이기 때문에 듣게 될 좋은 피드백이 기대되기도 하는 그런 상태이다. 만드는 과정에서 동료 1명에게밖에 보여주지 않았다는 게 두려움이 더 크다는 증거 같은데, 그래도 이걸 깨고 솔직한 피드백을 받고 진짜 개선을 위한 개선 작업에 더 가까워져야겠지. 암튼 굿!

[7월 TIL #2] Slop 경계하기: 우리는 유저/구매자가 듣고 싶은 말을 하고 있는가?

besoluble 장은솔 — Fri, 3 Jul 2026 00:54:36 +0900

오늘 사내 AX 공유회에서 다른 팀 동료가 발표를 했다. AX 관련 보고서를 AI와 함께 어떻게, 어떤 의도로 만들었는지 공유해주셨다.

무언가를 직접 만드는 사람은 자연스럽게 "무엇을, 어떻게 만들었나"에 관심이 쏠린다. 그래서 발표도 대체로 이런 기능이 있고, 이런 기술을 썼다는 이야기로 흐른다. 듣는 사람이 뭘 궁금해하는지보다 만든 사람이 하고 싶은 말이 앞선다. 그런데 이 동료분이 만드신 자료는 말하는 사람이 아니라 듣는 사람에서 출발했다. 기능과 기술을 앞세우는 대신, 이걸 읽을 사람이 누구이고 그 사람이 30초 안에 무엇을 이해해야 하는지부터 정하고 시작했다.

예쁜 문서가 아니라, 설득되는 문서

자료의 표지 제목부터가 "AI로 예쁜 문서가 아니라, 설득되는 문서를 만들기"였다. 목적을 예쁜 문서 만들기가 아니라, 잠재 고객이 우리 회사가 AX에 진심이라는 걸 빠르게 이해하게 만드는 데 뒀다. 그래서 독자부터 정의했다. AX 도입을 결정하고 예산과 조직 변화를 승인하는, 비슷한 제안서를 이미 여러 개 받아본 바쁜 의사결정자다. 그런 독자가 문서를 읽는 방식은 이렇다.

“30초 안에 훑어보고, 걸리는 곳만 다시 찾아 읽고, 장식이 과한 페이지는 건너뛴다. 그래서 1페이지부터 무엇을 말하려는 문서인지 분명해야 하고, 건너뛰며 읽어도 메시지가 이어져야 한다.”

또 공감되고 인상 깊었던 부분이 있었다. 내용을 제대로 읽지 않고 AI에게 "알아서 예쁘게 만들어줘"라고 하면, AI slop을 넘어 예쁜 쓰레기가 된다. 보기에만 좋고, 실제 해본 것보다 크게 말하고, 모든 페이지가 같은 카드와 그라데이션으로 반복되고, 정작 독자가 읽는 방식과는 상관없는 정보가 나열되는 문서다. AI를 쓰면 결과물이 그럴듯해 보이기 때문에, 오히려 이 함정에 빠지기 더 쉽다.

그래서 이 자료에서 디자인은 가장 마지막 단계였다. 작업 순서는 이랬다.

원문 이해: AX 원문과 내부 맥락을 먼저 읽는다
독자 정의: 누가, 어떤 방식으로 읽는가
메시지 구조: 설득 흐름과 증거를 배치한다
디자인: 메시지를 실어 나르는 그릇

만드는 사람의 말과 듣는 사람의 말

기능을 나열하고 기술 스택을 나열하는 건 전부 만든 사람 관점의 정보다. 직접 만든 입장에서는 하나하나가 다 중요하고 애착이 가서 그걸 말하게 된다. 그런데 듣는 사람은 "무슨 기술을 썼대"로 판단하지 않는다. "이게 나한테 뭘 해주는데", "이걸 맡기면 뭐가 달라지는데"로 판단한다. 만드는 사람이 하고 싶은 말과 듣는 사람이 듣고 싶은 말은 자주 어긋나는데, 만든 사람의 자리에서는 그 차이가 잘 보이지 않는다.

이 자료는 순서를 반대로 잡았다. "독자가 30초 안에 무엇을 이해해야 하는가"에서 역산해서, 보고서 전체를 하나의 설득 흐름으로 설계했다. 왜 이걸 제대로 해야 하는지, 그 주장을 뒷받침하는 증거는 무엇인지, 그래서 무엇을 제안하는지가 한 줄기로 이어진다. 발표든 문서든 내가 평소 흐릿하게만 느끼던 이 차이를 또렷하게 보여줘서 속이 시원(?)했다.

이 문서 자체가 AX의 작은 사례였다

이 보고서 자체를 AI 코딩 에이전트(Codex)와 함께 만드셨다는 점도 인상적이었다. 한 번에 "완성해줘"라고 던지지 않았다. 80~90개의 작은 지시로 쪼갰다.

"이 문장을 줄바꿈해라"
"이 타이틀을 92%로 줄여라"
"로고 그림자를 제거해라"
"커버 이미지를 더 밝고 신뢰감 있게 바꿔라"
"HTML 기준으로 PDF를 다시 export해라"

사람은 편집장이자 디렉터, 그리고 고객 관점의 리뷰어로 방향과 판단 기준을 잡고, AI는 HTML·CSS 편집과 PDF 변환 같은 반복 실행을 맡았다.

알게된 것 — slop을 경계한다는 것

발표를 보고 AI slop을 경계하면서 작업하는 게 생각보다 중요하다는 생각을 했다. AI를 쓰면 뭐든 그럴듯한 결과물이 금방 나온다. 그래서 겉모습에 만족하고 거기서 멈추기 쉽다. slop을 경계한다는 건 그 지점에서 한 번 더 묻는 일이다. 이게 정말 어떤 목적을 충분히 달성할 만한 결과물인지 그냥 그럴듯해 보이는 작품인지.

그 경계가 일의 본질을 다시 생각하게 한다. 이 문서를 만든 사람은 "예쁘게"에서 멈추지 않고 "누구를 설득하는가"로 계속 돌아갔다. 도구가 현란할수록 도구 자체에 매몰되기 쉬운데, slop을 경계하는 태도가 그 일의 목적을 먼저 생각하게 해준다는 걸 느꼈다. 굿!

[7월 TIL #1] 채팅창을 벗어난 AI: 4단계 GUI 진화와 자율성

besoluble 장은솔 — Thu, 2 Jul 2026 07:22:58 +0900

출처 정리
1. [아티클] "AI Interface Design: Why Chat Is the Wrong Default" - Adaline Labs (2026.06.13)
핵심 내용: 챗봇이 AI 프로덕트의 기본값이 되어서는 안 되며, 4가지 대안적 인터페이스(행동 표면, 캔버스, 위임, 무의식적 캡처)로 진화해야 함.
2. [영상] "Andrej Karpathy: Software Is Changing (Again)" - Y Combinator
핵심 내용: 텍스트로 AI와 대화하는 것의 한계를 지적하고, 맞춤형 GUI와 자율성 슬라이더를 갖춘 '부분 자율성 앱(Partial Autonomy Apps)'의 필요성 강조.
3. [영상] "Apple WWDC 2026 keynote in 25 minutes" - The Verge (2026.06.09)
핵심 내용: 애플이 새로운 운영체제 전반에 앞서 말한 '포스트 챗봇(Post-Chat)'의 4가지 UI 패턴을 어떻게 실제 프로덕트로 구현해 냈는지 보여주는 사례들.

↓ 최근 관심 있는 주제의 소스 3가지를 통합해 정리한 글입니다.

요즘 AI와 다양한 GUI의 결합을 볼 때마다 관련된 사례를 레퍼런스로 모아둬야겠다는 생각을 많이 합니다.
문제 제기: 많은 서비스가 챗봇 창을 도입하지만, 빈 텍스트 창에 매번 "나는 누구고, 이건 어떤 맥락이고..."라며 프롬프트를 치는 것은 너무 피곤하고 비효율적입니다. 안드레 카파시의 말을 빌려보면, 이는 1960년대 시커먼 터미널 창과 대화하는 것과 같습니다.

ChatGPT 2022년 11월. 출처: AI Interface Design: Why Chat Is the Wrong Default - Adaline Labs "Source: Introducing ChatGPT"

해결책: 이제 AI는 챗봇 창을 벗어나, 유저의 작업 화면(GUI) 위에서 함께 노는 '부분 자율성 앱(Partial Autonomy Apps)'으로 진화해야 합니다.

AI 인터페이스가 진화하는 4가지 고도화 단계

프롬프트를 치는 유저의 수고는 줄어들고, AI의 자율성은 높아지는 4단계 흐름과 사례들입니다.

1단계: 행동 표면 (The Verb Surface) - "명령을 버튼으로 압축하다"
- 제거하는 것: 프롬프트 '설정(Setup)'의 수고.
- 개념: 구구절절 맥락을 설명할 필요 없이, 유저가 텍스트를 선택하고 "번역해 줘", "요약해 줘" 같은 행동(동사) 버튼만 누르는 방식입니다.

Claude Code의 AskUserQuestion(인터랙티브 질문 UI) 2026

- 사례: 코딩 에디터인 커서(Cursor)의 인라인 편집이 대표적이다. 코드를 선택하고 cmd-K를 눌러 원하는 변경 사항을 짧게 입력하면, AI가 수정한 코드를 화면에 빨간색(삭제)과 초록색(추가)의 디프(Diff)로 즉시 보여준다. 유저는 줄글로 피드백을 주는 대신, 눈으로 차이를 확인하고 cmd-Y(수락)나 cmd-N(거절) 단축키 하나로 검증을 끝낸다.

2단계: 생성형 캔버스 (The Generative Canvas) - "수정 가능한 결과물을 바로 띄우다"
- 제거하는 것: 결과물을 내 작업창으로 '옮기는 과정(Translation)'.
- 개념: AI가 줄글로 대답하는 대신, 유저가 직접 만지고 수정할 수 있는 온전한 결과물을 작업 화면에 바로 띄워줍니다.

ChatGPT 캔버스 모드. 출처: AI Interface Design: Why Chat Is the Wrong Default - Adaline Labs "Source: ChatGPT Canvas"

- 사례: NotebookLM의 오디오 오버뷰는 재생 가능한 오디오 파일을, Claude Artifacts와 OpenAI Canvas는 제자리에서 즉시 편집할 수 있는 문서를 만듭니다. 애플의 이미지 플레이그라운드(Image Playground)에서도 사용자가 화면 속 케이크에 동그라미를 치고 "양초를 추가해 줘"라고 자연어로 지시하면 이미지 내에서 즉각 결과물을 수정해 줍니다.

3단계: 위임형 에이전트 (The Delegated Agent) - "알아서 일하고 결과만 보고하다"
- 제거하는 것: 매 단계마다 개입해야 하는 '중간 감독(Supervision)'.
- 개념: 큰 목표만 주면, AI가 여러 단계를 거쳐 스스로 작업하고 유저는 중간 감독을 생략할 수 있습니다.
- 사례: 애플의 사파리(Safari)는 AI가 에이전트처럼(agentically) 사용자를 대신해 웹사이트들을 돌아다니며 비밀번호를 스스로 변경해 줍니다. 또한 "퇴근할 때 파트너에게 도착 예정 시간을 메시지로 보내줘"라고 말하면, 단축어(Shortcuts) 앱이 지도와 메시지 앱을 연동하는 자동화 로직을 알아서 구축해 냅니다. 터미널에 존재하는 Claude Code도 그렇습니다. 사용자가 과업을 던지면, 에이전트는 파일을 읽고, 코드를 편집하고, 테스트를 실행하며 알아서 작업합니다. (Cursor의 에이전트 모드, OpenAI Codex 등도 포함)

4단계: 무의식적 캡처 (The Ambient Capture) - "프롬프트조차 생략하다"
- 제거하는 것: '프롬프트 명령 그 자체'.
- 개념: 유저가 AI를 부르지 않아도, 백그라운드에서 유저의 맥락을 인지하고 알아서 결과물을 챙겨주는 궁극의 단계입니다.
- 사례: 애플의 새로운 'Siri AI'는 화면 인지(onscreen awareness) 능력을 통해 현재 유저가 무슨 앱에서 무엇을 하고 있는지 실시간으로 파악합니다. 또한 항공사에 비행기 표 변경 전화를 걸면, 폰 앱이 이메일에 있는 예약 확인 코드를 알아서 화면에 띄워줍니다.

채팅 인터페이스에 머물러 있는 이유

대부분의 제품이 챗봇에 머물러 있는 이유 4가지 패턴의 방향성을 아는 것과 실제로 출시하는 것은 다릅니다. 챗봇은 제품 팀이 선택할 수 있는 정치적으로 가장 안전한 인터페이스입니다. "어떤 사용자 문제를 뾰족하게 해결할 것인가"라는 어려운 제품 기획의 고민은 미룰 수 있기 때문입니다. 반면 "행동(동사) 버튼을 추가하자"는 것은 전혀 다른 문제입니다. 이는 어떤 동사가 가장 중요한지 합의해야 하는 전략(Strategy) 작업이며, 이 합의에 도달하지 못하는 팀은 만만한 챗봇으로 도망칩니다. 또한 채팅 지표는 겉보기에 훌륭한 '참여도(Engagement)'처럼 보입니다. 사용자당 메시지 수, 세션 길이 등이 올라가면 대시보드는 이를 긍정적인 신호로 포장하여 팀에게 보상을 줍니다. 더불어 챗봇은 어떤 구체적인 약속도 하지 않으므로 실패했을 때 책임 소재를 피하기 좋습니다. 챗봇이 이상한 답을 하면 유저는 "내가 프롬프트를 잘못 썼나" 하고 자책하지만, 버튼(행동 표면)이 작동하지 않으면 유저는 제품을 비난하기 때문입니다.

당신의 제품이 챗봇에 갇혀 있는지 확인하는 3가지 질문 진단법
1. 사용자가 제품이 이미 알고 있는 정보를 제품에게 얼마나 자주 말합니까?
(10번 중 3번 이상이라면 사용자를 피곤하게 만들고 있는 것입니다.)
2. 채팅창을 없앤다면 상위 10개 핵심 사용 사례 중 몇 개가 살아남겠습니까?
(살아남는 기능들은 모두 동사, 캔버스, 위임형 에이전트 속에 들어가야 합니다.)
3. 새로운 사용자가 단 한 문장도 타이핑하지 않고 90초 이내에 실제 작업을 끝낼 수 있습니까?
(대답이 '아니오'라면, 병목 현상의 원인은 AI 모델이 아니라 당신의 채팅창입니다.)

Adaline Labs의 아티클에 따르면, 이 중 두 개 이상에 적신호가 켜진다면 당신에게 필요한 해결책은 더 나은 프롬프트 템플릿을 제공하는 것이 아니라 완전히 다른 인터페이스 표면을 짜는 것입니다.

향후 2년, 이것이 의미하는 바 최첨단 AI 모델들은 점차 성능이 수렴(상향 평준화)하고 있습니다. Anthropic, OpenAI, Google 모델들은 대부분의 작업을 서로 비슷하게 잘 처리합니다. 결국 경쟁의 핵심은 어떤 모델을 쓰느냐가 아니라, 팀이 그 모델에 어떤 '인터페이스'를 씌우느냐에 달려 있습니다. 2026년 제품 조직에서 가장 가치 있는 인재는 어떤 AI 기능에 동사를 부여하고, 어떤 것은 캔버스로 띄우며, 어떤 것은 백그라운드에 숨길지 결정할 수 있는 사람입니다. 앞으로 해야 할 일은 간단합니다. 챗봇 창을 고집하는 것을 멈추고, 행동(동사) 버튼을 출시하십시오.

핵심 인사이트 (결론)

자율성 슬라이더와 통제선(Leash): AI가 고도화될수록 중요한 것은 유저가 AI에게 통제권을 얼마나 넘길지 유연하게 조절할 수 있는 '자율성 슬라이더(Autonomy Slider)'를 설계하는 것입니다.
마무리: AI가 작업 화면 안에서 거칠게 제안(Generation)하면, 우리는 시각적 GUI를 통해 찰나의 순간에 검증(Verification)하는 것. 이것이 제가 앞으로 프로덕트를 디자인(또는 기획)할 때 반드시 담아내고 싶은 차세대 인터페이스의 핵심입니다.

[6월 TIL #19] 지각된 가치와 인지적 비용에 대한 고찰

besoluble 장은솔 — Tue, 30 Jun 2026 23:57:13 +0900

사용성 피드백과 문제 인식
오늘 연구실 교류 프로그램의 일환으로 건국대학교를 방문하여, 현재 담당하고 있는 '문라이트(Moonlight)' 서비스를 소개하는 시간을 가졌다. 이때 한 사용자로부터 "UX/UI가 복잡하다"는 피드백을 받았다. 처음 사용하는 입장에서 기능의 존재와 사용법을 한 번에 알아차리고 익히기 어렵다는 것이었다. 내가 처음부터 설계한 화면이 아니기에 어디서부터 손을 대야 할지 막막하다는 방어적인 생각도 들었지만, 현재 담당자로서 책임감을 가지고 문제를 하나씩 해결해 나가야겠다고 생각을 고쳐먹었다.

처음에는 사용자의 인지적 부담을 줄이기 위해 '기억(Recall)보다 재인(Recognition)을 우선하라'는 원칙에만 집중했다. 사용자가 기능을 스스로 떠올리게 하지 않으려면 화면에 UI 요소들을 적극적으로 노출해야 한다고 생각했다. 하지만 모든 힌트와 선택지를 화면에 꺼내두면 오히려 화면이 난잡해지고 복잡해지는 모순이 발생했다. 이 딜레마를 해결할 방법을 찾던 중, UX 연구 기관인 닐슨 노먼 그룹(NN/g)의 아티클 '사용자 인터페이스에서의 지각된 가치(Perceived Value in User Interfaces)'를 접하고 이를 깊이 있게 학습했다.

기대 효용과 정보 취식 이론을 통한 사용자의 가치 판단
NN/g의 아티클에 따르면, 사용자가 웹사이트나 제품에 계속 머물지 여부는 '기대 효용(Expected Utility)'에 의해 결정된다. 기대 효용은 사용자가 사이트에서 얻을 수 있다고 예상하는 이점인 '지각된 가치(Perceived Value)'와, 그 이점을 얻기 위해 치러야 하는 노력인 '지각된 비용(Perceived Cost)'을 저울질하여 산출된다. 이는 동물이 야생에서 먹이를 찾을 때 얻을 수 있는 에너지와 소모되는 에너지를 계산하는 '정보 취식 이론(Information-foraging theory)'과 동일한 맥락이다.

여기서 지각된 가치란 제품이나 서비스가 사용자의 특정 목표 달성에 기여할 것이라 믿는 주관적인 가치를 뜻한다. 사용자는 웹사이트의 첫 페이지에 나타난 시각적 요소(콘텐츠 양, 그래픽 등)를 통해 단 몇 초 만에 가치를 판단한다. 만약 화면이 너무 많은 정보로 난잡(Cluttered)하게 구성되어 있으면, 사용자는 후광 효과(Halo Effect)에 의해 기업이 디테일에 신경 쓰지 못한다고 판단하며 비즈니스 전체의 수준까지 평가절하하게 된다.

또한, 디자인이 전달하는 지각된 가치는 비즈니스의 실제 가치 제안과 일치해야 한다. 예를 들어, 싱가포르 항공은 차분한 디자인으로 '높은 비용과 훌륭한 서비스'라는 가치를 전달하는 반면, 저가 항공사인 타이거에어는 밝은 색상과 빽빽한 할인 정보 배치로 '저렴한 가격'이라는 정체성을 명확히 한다. 타이거에어의 항공권이 고급스러운 디자인을 취한 싱가포르 항공보다 비싸다면, 사용자는 웹사이트 디자인이 준 기대감과 실제 결과가 충돌하여 이탈할 것이다.

지각된 비용 감소와 인지적 균형을 위한 UX 전략
기대 효용을 높이기 위해서는 지각된 가치를 높이는 것뿐만 아니라 '지각된 비용'을 낮추는 것이 필수적이다. 지각된 비용은 사용자가 사이트를 이용할 때 얼마나 수고스러울 것이라고 예상하는지를 의미하며, 한눈에 보기에 사용하기 쉽다는 인상(convey ease of use)을 주지 못하면 사용자는 즉시 탐색을 포기한다.

그렇다면 화면의 난잡함을 없애 지각된 비용을 낮추면서도, 필요한 시점에 기능을 직관적으로 알아차리게 하는 '재인' 원칙을 어떻게 동시에 만족시킬 수 있을까? NN/g가 강조한 '정보의 요약과 난잡함 제거' 원리를 바탕으로, 외부의 실무 UX 지식을 더해 다음의 두 가지 구체적인 UI 전략을 도출했다.

- 점진적 공개(Progressive Disclosure)
복잡성을 낮추는 가장 대표적인 방법이다. 초기 화면에는 사용자가 가장 자주 사용하는 핵심 기능만 노출하여 지각된 비용을 최소화한다. 나머지 세부 기능은 직관적인 레이블이 달린 버튼이나 메뉴 안에 숨겨두어, 사용자가 필요할 때 스스로 기억(Recall)해 내는 대신 명확한 단서를 보고 찾아갈 수 있도록(Recognition) 설계한다.
- 적시(Just-in-Time)의 컨텍스트 기반 UI
평소에는 보조 UI 요소들을 숨겨두어 시각적 난잡함(Clutter)을 방지한다. 대신, 사용자가 특정 행동을 수행하거나 오류에 직면하는 바로 그 맥락에만 관련 툴팁이나 설정 버튼을 노출한다. 이를 통해 사용자는 인지적 과부하 없이 당면한 문제를 시각적으로 확인하고 해결할 수 있다.
- 정보의 의미 있는 청킹(Chunking)과 시각적 그룹화
정보를 의미 있는 형태로 요약하는 것이 중요하다. 수십 개의 메뉴를 텍스트로만 쭉 나열하면 인지적 과부하와 난잡함을 유발한다.

문라이트 UI 개선 적용: 강제적 모달 제거와 적시 노출
학습한 개념과 UX 전략을 종합하여, 문라이트 서비스에서 즉시 변경할 UI 요소를 하나 선정했다. 번역 언어와 논문의 원문 언어가 동일하게 설정되었을 때 화면 중앙을 가로막는 경고 모달(Modal) 창이다.

기존의 모달은 사용자의 작업 흐름을 강제로 차단하고 창을 닫는 추가 행동을 요구하므로, 사용자가 겪는 실제 상호작용 비용과 지각된 비용을 모두 급증시키는 원인이었다.

이를 개선하기 위해 모달을 완전히 제거하고, 앞서 정리한 '점진적 공개'와 '적시(Just-in-Time) 노출' 방식을 결합하여 적용할 계획이다. 오류가 발생한 상황에서 사용자의 시선이 가장 먼저 향하는 '번역 결과' 영역 바로 근처에 작은 툴팁이나 설정 버튼을 띄우는 것이다. 평소에는 버튼을 숨겨두어 화면의 복잡도를 낮추고, 문제가 발생한 순간에만 해결책을 제공함으로써 사용자의 탐색 흐름을 끊지 않고 자연스럽게 문제를 재인(Recognition)하도록 개선할 것이다. 굿!

*참고 문헌: Aurora Harley, "Perceived Value in User Interfaces", Nielsen Norman Group (2016)

[6월 TIL #18] 코드가 아니라 '의도'가 정본인 개발 시스템

besoluble 장은솔 — Mon, 29 Jun 2026 23:58:28 +0900

AI와 함께 효율적인 개발을 위해 "문서 먼저 쓰고 작업하자"는 시도를 몇 번 해봤다. 작업 전에 무엇을 만들지, 어떤 규칙을 지킬지 문서로 정리해두는 방식이다. 그런데 문서를 적어둬도 코드가 그대로 따라오지는 않았다. 시간이 지나면 문서와 실제 코드가 어긋났고, 어긋났다는 사실조차 아무도 알려주지 않았다. 결국 문서는 "한때 그렇게 하기로 했던 메모"로 남았다.

오늘 이 문제를 정면으로 푼 설계를 봤다. 문서가 코드를 실제로 강제하려면 무엇이 필요한가. 아직 활용 가능할 정도로 흡수하진 못했지만, 적어도 내 "문서 먼저"가 왜 매번 실패했는지는 분명해졌다.

무엇을 공부했나 — 코드가 아니라 '의도'가 정본인 시스템

이 시스템의 전제는 분명하다. 코드가 정본(source of truth)이 아니라는 것이다. 정본은 사람이 내린 상위 의사결정, 즉 "제품이 사용자에게 무엇을 약속하는가"이고, 코드와 테스트 그리고 화면은 그 약속이 지켜졌다는 증거(evidence)일 뿐이다. 의도가 위에 있고 구현이 아래에 있다.

그 의도를 막연한 선언으로 두지 않고, 세 개의 축으로 구조화한다.

의도 선언 축 (종단): 큰 경험 영역(Experience) → 약속이 발동되는 순간(Moment) → 그 순간 제품이 내거는 약속(Promise). 의도를 위에서 아래로 점점 구체화한다.
실현 제약 축 (횡단): 보안, 응답 속도, 설명 충분성처럼 여러 약속을 가로지르는 공통 규약은 Aspect로 따로 뺀다. 관점지향 프로그래밍(AOP)의 aspect를 코드가 아니라 제품 약속 레벨로 끌어올린 것이다. 종단 약속과 부모-자식이 아니라 서로 엮인다(weaving).
검증 축: 각 약속을 증거에 닫는다. 결정적으로 확인하는 합격 기준(Acceptance Check)과, 실제 런타임 출력으로 의도가 달성됐는지 판정하는 의미 검토(Intent Check)로 분해된다.

여기까지는 잘 짜인 문서 체계처럼 보인다. 내가 늘 걸리던 의문은 그다음이다. 이렇게 적어둔다고 코드가 정말 그걸 따르나. 이 시스템이 다른 지점은, 그 문서를 강제력으로 바꾸는 장치가 네 겹으로 박혀 있다는 데 있었다. 먼저 한눈에 보면 이렇다.

① 셀 수 있는 그래프: 약속을 ID로 엮인 노드로 두고, 다음 단계까지 연결됐는지 기계가 센다.
② 실행 가능한 증거: 모든 약속을 실제 코드를 돌리는 테스트까지 내려보낸다.
③ 증거 없음 = 차단: 검증 안 된(unknown) 약속은 그 자체로 출시를 막는다.
④ 증명을 다시 의심: 통과한 테스트조차 변형(mutation)·교차검토로 한 번 더 깬다.

① 약속을 '글'이 아니라 셀 수 있는 그래프로 묶는다

약속은 줄글이 아니라 타입이 있는 노드다. 어떤 Experience의 어떤 Moment에 속하는지, 어떤 Acceptance Check로 쪼개지는지, 어떤 증거가 그걸 닫는지, 어떤 Aspect가 걸리는지, 현재 판정이 무엇인지가 전부 ID로 적혀 있다. 그리고 이 ID는 다른 문서의 실제 ID와 일치해야 한다. 가리키는 대상이 없는 ID는 끊긴 링크로 잡힌다.

그 위에 추적성 기수(traceability cardinality) 규칙이 얹힌다. "각 노드는 최소 몇 개의 다음 노드와 연결돼야 하는가"를 정책 파일로 선언하고(약속 하나는 Acceptance Check 하나 이상, Acceptance Check 하나는 증거 행 하나 이상 같은 식이다), 검증기가 실제 그래프를 세서 미달이면 막는다. "문서가 존재한다"보다 강한 "문서가 다음 단계까지 실제로 엮여 있다"를 기계가 세는 것이다.

② 모든 약속을 실행 가능한 증거로 내려보낸다

약속의 각 합격 기준은 증거 원장(Evidence Ledger)의 한 행으로 내려간다. 그 행에는 실제로 돌릴 수 있는 명령과, 그 명령이 실행하는 테스트가 적혀 있다. 그리고 한 단계 더 본다. 그 테스트가 진짜 제품 코드를 불러다(import) 실행하는지까지 확인한다. 그럴듯한 가짜 입력만 만들어놓고 실제 코드 경로를 건드리지 않는 테스트는, 초록불이어도 약속을 닫지 못한다. "잘 동작한다"는 산문이 아니라 "이 명령을 돌리면 이 코드가 이렇게 동작한다"만 증거로 인정된다.

③ '증거 없음'을 중립이 아니라 차단으로 둔다

이게 제일 결정적이었다. 판정이 합격·불합격 두 값이 아니라 met · not-met · unknown 세 값이고, unknown(아직 검증 안 됨)도 not-met과 똑같이 출시를 막는다. 증거 없음이 중립이 아니라 차단이다. 대부분의 문서-우선 방식에서는 "아직 확인 안 함"이 초록불로 조용히 통과하지만, 여기서는 증명되기 전 기본값이 빨간불이다.

그래서 약속을 새로 선언하면 그 약속은 처음에 unknown 상태라 그 자체로 release를 막는다. 증거로 닫기 전까지 빨간불이 풀리지 않으니, 문서만 써두고 넘어가는 경로가 구조적으로 막혀 있다. 항공기로 치면 출항 전 점검 항목 하나라도 미확인이면 비행기를 못 띄우는 것과 같다. "아마 괜찮을 것"은 통하지 않는다.

최종 release 판정도 한 값이 아니라 세 축의 곱이다. 의도가 실제로 달성됐는가(Intent), 약속과 증거를 잇는 추적에 치명적 결함이 0인가, 횡단 제약(Aspect)이 모두 박혔는가. 셋 중 하나만 비어도 빨간불이고, 어디서 깨졌는지 알 수 있도록 세 축을 합쳐 한 줄로 뭉개지 않고 항상 분리해서 보여준다.

④ 통과한 증명조차 다시 의심한다

테스트가 초록불이어도 그게 진짜 불변식을 지키는지는 별개다. 그래서 증명 자체를 한 겹 더 공격한다. 코드 값을 일부러 틀리게 바꿔도 테스트가 안 깨지면(mutation testing) 그 테스트는 불변식을 지키지 않는 가짜로 본다. 어떤 상수를 검사하는 테스트는 그 상수가 바뀌면 반드시 깨지도록 묶어, 상수와 테스트가 같이 움직여 틀려도 통과하는 false-pass를 막는다. 약속 문장과 합격 기준이 의미상 같은 걸 가리키는지는 또 다른 LLM이 판정하고, 그 판정 모델은 작성 모델과 달라야 한다. 같은 모델이 쓰고 같은 모델이 채점하면 같은 맹점을 공유하기 때문이다.

알게된 것 — 강제력은 의지가 아니라 구조다

여기까지 보고 내 "문서 먼저"를 돌아봤다. 내 문서는 그래프로 세어지지 않았고, 실행 가능한 증거로 내려가지도 않았고, 안 지켜져도 아무것도 막지 않았고, 통과한 증명을 다시 의심하지도 않았다. 그러니 지켜질 이유가 없었다. 문서가 코드를 강제하는 건 작성자의 의지나 성실함이 아니라, 그걸 AI 지킬 수 있는 구조로 전환해두었는가의 문제였다.

횡단 제약이 실제 코드에 어떻게 박혀 검증되는지, 의미 검토용 모델을 어떻게 운영하고 비용을 감당하는지는 더 들여다봐야 한다. 그래도 다음에 또 "문서 먼저"를 시도한다면, 적어도 세 번째, 즉 증명되지 않은 것을 기본 차단으로 두는 것부터는 작게라도 흉내 내보려 한다. 굿!

[6월 TIL #17] 채팅창을 넘어선 AI 인터페이스: 안드레 카파시가 말하는 '부분 자율성'

besoluble 장은솔 — Mon, 29 Jun 2026 01:09:22 +0900

최근 인공지능이 발전하면서 많은 서비스가 앞다투어 AI 챗봇을 도입하고 있다. 하지만 과연 '텍스트 채팅'이 AI와 소통하는 가장 효과적인 방법일까? 전 테슬라 AI 디렉터 안드레 카파시(Andrej Karpathy)가 Y Combinator에서 진행한 강연, Andrej Karpathy: Software Is Changing은 이 질문에 대한 새로운 관점을 제시한다.

1. Software 3.0 시대의 도래
카파시는 소프트웨어 패러다임이 다시 한번 크게 변화하고 있다고 말한다. 개발자가 직접 코드를 작성하던 전통적 방식이 'Software 1.0'이고, 신경망이 데이터를 통해 가중치를 학습하는 것이 'Software 2.0'이라면, 이제는 인간의 자연어(영어 등)를 프롬프트로 삼아 거대 언어 모델(LLM)을 다루는 'Software 3.0' 시대가 열렸다는 것이다. 이제 우리는 일상 언어로 고도의 컴퓨팅 시스템을 제어할 수 있게 되었다.

2. 채팅의 한계와 '부분 자율성 앱(Partial Autonomy Apps)'
하지만 AI의 결과물을 단순히 채팅 창의 텍스트로만 확인하는 것은 비효율적일 수 있다. 카파시는 챗GPT와 텍스트로만 대화하는 것을 과거 1960년대 운영체제의 터미널 창과 대화하는 것에 비유한다.

이를 극복하기 위해 등장한 개념이 바로 '부분 자율성 앱(Partial Autonomy Apps)'이다. AI가 모든 것을 알아서 처리하는 '독립된 로봇'을 당장 완성하기보다는, 인간이 직접 통제하면서 능력을 확장할 수 있는 '아이언맨 수트(Iron Man Suit)' 형태의 소프트웨어를 지향하자는 접근이다.

3. 생성(AI)과 검증(인간)의 시각적 피드백 고리
부분 자율성 앱의 핵심은 맞춤형 GUI(Application-specific GUI)에 있다. 코딩 에디터인 '커서(Cursor)'가 대표적인 예다. 커서는 AI가 변경한 코드를 텍스트로 길게 설명하지 않고, 작업 화면 내에서 삭제된 부분은 빨간색, 추가된 부분은 초록색으로 직관적으로 보여준다.

AI가 빠르게 작업물을 생성(Generation)하면, 인간은 시각적 정보를 통해 단축키 하나로 이를 신속하게 검증(Verification)한다. 텍스트를 하나하나 읽는 대신 시각적인 차이를 확인하는 것은 인지 에너지를 덜 소모하게 하여 인간과 AI의 협업 효율을 높인다.

4. 자율성 슬라이더(Autonomy Slider)와 통제선(Leash)
AI는 때로 오류를 범할 수 있는 불완전한 시스템이므로 사용자가 통제권을 가지는 것이 중요하다. 카파시는 앱 내에 '자율성 슬라이더(Autonomy Slider)'를 두어야 한다고 설명한다. 커서에서 단순 자동완성부터 전체 프로젝트 수정까지 사용자가 단축키로 AI의 개입 수준을 자유롭게 조절할 수 있는 것과 같은 맥락이다.

동시에 AI가 의도한 목적을 벗어나지 않도록 적절한 통제선(Leash)을 구축해야 한다. 예를 들어 교육 앱의 경우, 챗봇에게 다짜고짜 "물리를 가르쳐줘"라고 텍스트로 입력하면 AI가 맥락을 잃기 쉽다. 대신 실러버스(강의 계획서) 같은 중간 결과물을 화면에 제시하고 인간이 먼저 확인하게 함으로써, 정해진 커리큘럼 내에서만 AI가 작동하도록 설계하는 식이다.

이 주제를 깊게 살펴보게 된 시작점은 최근 읽고 있던 책 속의 짧은 문장이었다. AI 언어 학습 앱 'else'의 프로덕트 디자이너가 "이제는 AI가 화면 내에서 더 잘 놀 수 있는 인터페이스 설계가 필요하다"며 카파시의 강연 영상을 추천했기 때문이다.

이 문장은 나의 최근 경험과도 맞물렸다. Adaline Labs의 아티클 ['Post-Chat Interface for AI Products']를 읽으며 "챗봇 형태가 유일한 정답은 아니다"라는 방향성(Why)에는 공감했지만, 정작 '어떻게(How)' 구현해야 할지는 다소 모호하게 느껴졌다. 며칠 전, 시간 관리 AI 앱을 기획하는 디자이너 지인에게 이 글을 바탕으로 의견을 나눌 때도 스스로 생각이 충분히 정돈되지 않아 피드백이 추상적으로 전달된 아쉬움이 있었다.

하지만 책의 추천을 계기로 카파시의 영상을 찾아본 후, 모호했던 부분들이 훨씬 명확해졌다. 만약 내가 그때 "AI가 화면 위에서 제안을 시각적으로 던지고(Generation), 인간이 이를 빠르게 검증(Verification)하는 구조"가 생산성 앱의 중요한 요소라는 점을 인지했더라면 어땠을까? 지인에게 "채팅형 UI에서 일정을 줄글로 설명하게 두기보다, 캘린더 위에서 변경된 스케줄을 시각적 차이로 띄워준 뒤 유저가 빠르게 승인하게 만들자"고 더 구체적으로 제안할 수 있었을 것이다.

단순히 채팅 창을 벗어나는 것을 넘어, 생산성 툴에서는 시각적 GUI와 자율성 슬라이더로 검증 효율을 높이고, 교육 앱에서는 실러버스를 통해 AI의 통제선을 구축하는 것. 결국 어떤 목적성을 가지고 AI를 활용할 것인가에 달렸다. 굿!