besoluble 님의 블로그

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

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

최근 채팅 형태를 넘어서 AI UI에 대해 [7월 TIL #1] 채팅창을 벗어난 AI: 4단계 GUI 진화와 자율성에서 내용을 정리했다. 오늘은 동료 분께서 관련 주제로 n년간 모으신 자료들을 제공해주신 것을 하나씩 열어보며, 실제 제품에 적용된 모습 위주로 모아봤다. 이전 글에서 세워둔 4단계 프레임에 맞춰 정리했다. 다만 프레임에 따른 분류에 보는 관점에 따라 이견이 있을 수 있다.자율성에 따른 4단계1단계: 행동 표면 (The Verb Surface)- "명령을 버튼으로 압축하다"- 제거하는 것: 프롬프트 '설정(Setup)'의 수고.2단계: 생성형 캔버스 (The Generative Canvas)- "수정 가능한 결과물을 바로 띄우다"- 제거하는 것: 결과물을 내 작업창으로 '옮기는 과정(Tran..

어제 두 가지 일을 하는 내내 묘하게 괴로웠다. 하나는 다음 날 있을 팀 미팅 진행안을 준비하는 일이었고, 다른 하나는 새 기능 하나를 동료와 함께 방향을 잡는 일이었다. 성격이 꽤 다른 두 일인데, 괴로움을 느낀 포인트가 비슷했다.미팅 준비는 "여기까지만 준비하면 된다"를 스스로 못 정해서 범위가 계속 커졌고, 짝작업은 대화를 나눌수록 머릿속이 오히려 더 복잡해졌다. 바라는 건 큰데 그걸 무엇부터 어떻게 할지가 안 잡히니까, 정리되지 않은 상태였다. 문제는 그 사실 자체가 아니라 마음이 급해서 그 미정의 상태를 못 견디는 + 이걸 내가 해낼 수 있다는 자신감이 부족한 상태에 있다는 셀프 진단을 내렸다.방법을 몰라서가 아니었다처음엔 방법을 몰라서라고 생각했다. 그런데 사실 이런 상황을 다루는 좋은 방법을..

상반기 팀 리뷰를 했다. 성과를 평가하는 자리라기보다, 지난 반년 동안 팀과 개인이 어떤 방향으로 변했고, 어떤 방식으로 성장했는지를 돌아보는 시간에 가까웠다. 그래서 회고가 끝나고 나서도 “이번 반기에 뭘 했더라?”보다 “나는 팀 안에서 어떤 역할을 하고 있었지?”, “우리는 어떤 방식으로 일하는 팀이 되어가고 있지?” 같은 질문이 더 오래 남았다. 먼저 기억을 복원하고, 그다음 질문에 답했다이번 회고에서 좋았던 점은 시작부터 기억에만 의존하지 않았다는 것이다. 각자 먼저 에이전트와 함께 자신의 상반기를 정리했다. 예를 들면 “내 이름이나 계정으로 1월부터 6월까지 Notion과 Slack에서 한 일을 찾아 활동 로그로 정리해줘” 같은 프롬프트를 돌리고, 지난 반년 동안 했던 일을 먼저 펼쳐보았다. 이..

지난달에 "완벽한 체계를 선언하지 말고, 매일 하나씩 좋은 의사결정을 저장하자"는 7일 챌린지를 시작했다([6월 TIL #10] 디자인 시스템 앞에서 자꾸 멈추는 이유). 버튼 하나, 색 하나, 검색 결과 아이템 하나여도 된다는 규칙이었다. 색 토큰 정리부터 시작했는데, 며칠 만에 멈췄다. 그 멈춘 시점부터 제품의 핵심인 PDF Viewer UI를 전반전으로 리뉴얼하는 작업을 했고, 오늘 1차 작업을 끝냈다. 오늘은 그 2주 반의 작업과 그때 내린 결정들을 문서로 정리했다. 내가 봐도 급발진같아 보이긴 하는데(ㅋㅋ..) '하나씩'에서 '전체 리뉴얼'로 변경한 이유는, 어떤 의사결정도 혼자 존재하지 않는다는 걸 그 '하나씩'을 시도하다가 알게 됐기 때문이다. 하나의 결정이 컴포넌트와, 더 나아가 기능 그리..

오늘 사내 AX 공유회에서 다른 팀 동료가 발표를 했다. AX 관련 보고서를 AI와 함께 어떻게, 어떤 의도로 만들었는지 공유해주셨다.무언가를 직접 만드는 사람은 자연스럽게 "무엇을, 어떻게 만들었나"에 관심이 쏠린다. 그래서 발표도 대체로 이런 기능이 있고, 이런 기술을 썼다는 이야기로 흐른다. 듣는 사람이 뭘 궁금해하는지보다 만든 사람이 하고 싶은 말이 앞선다. 그런데 이 동료분이 만드신 자료는 말하는 사람이 아니라 듣는 사람에서 출발했다. 기능과 기술을 앞세우는 대신, 이걸 읽을 사람이 누구이고 그 사람이 30초 안에 무엇을 이해해야 하는지부터 정하고 시작했다.예쁜 문서가 아니라, 설득되는 문서자료의 표지 제목부터가 "AI로 예쁜 문서가 아니라, 설득되는 문서를 만들기"였다. 목적을 예쁜 문서 만들..

📚 출처 정리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" - ..

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

AI와 함께 효율적인 개발을 위해 "문서 먼저 쓰고 작업하자"는 시도를 몇 번 해봤다. 작업 전에 무엇을 만들지, 어떤 규칙을 지킬지 문서로 정리해두는 방식이다. 그런데 문서를 적어둬도 코드가 그대로 따라오지는 않았다. 시간이 지나면 문서와 실제 코드가 어긋났고, 어긋났다는 사실조차 아무도 알려주지 않았다. 결국 문서는 "한때 그렇게 하기로 했던 메모"로 남았다. 오늘 이 문제를 정면으로 푼 설계를 봤다. 문서가 코드를 실제로 강제하려면 무엇이 필요한가. 아직 활용 가능할 정도로 흡수하진 못했지만, 적어도 내 "문서 먼저"가 왜 매번 실패했는지는 분명해졌다. 무엇을 공부했나 — 코드가 아니라 '의도'가 정본인 시스템이 시스템의 전제는 분명하다. 코드가 정본(source of truth)이 아니라는 것이..

최근 인공지능이 발전하면서 많은 서비스가 앞다투어 AI 챗봇을 도입하고 있다. 하지만 과연 '텍스트 채팅'이 AI와 소통하는 가장 효과적인 방법일까? 전 테슬라 AI 디렉터 안드레 카파시(Andrej Karpathy)가 Y Combinator에서 진행한 강연, Andrej Karpathy: Software Is Changing은 이 질문에 대한 새로운 관점을 제시한다.1. Software 3.0 시대의 도래카파시는 소프트웨어 패러다임이 다시 한번 크게 변화하고 있다고 말한다. 개발자가 직접 코드를 작성하던 전통적 방식이 'Software 1.0'이고, 신경망이 데이터를 통해 가중치를 학습하는 것이 'Software 2.0'이라면, 이제는 인간의 자연어(영어 등)를 프롬프트로 삼아 거대 언어 모델(LLM)..