Showcases / 해부
이 사이트를 만들며 실제로 부딪힌 결정들을 전시합니다. 저자의 답을 보기 전에, 먼저 당신이라면 어떻게 했을지 골라 보세요.
ReactNext라는 사이트에서, 데모를 React로 만들지 않았다
쇼케이스 메뉴를 만들었다. 메인과 전혀 다른 디자인의 데모들 — 다크 테마 AI 챗, 에메랄드 톤 쇼핑몰 — 을 한 사이트에 들여야 한다. 메인은 막 전 라우트 검증을 끝낸 상태다. 당신이라면 어떻게 격리하겠는가?
판단해 보기 →전시 02 · 데이터 설계답글이 달린 댓글을 지우면, 답글은 누구의 것인가
에세이에 댓글과 답글을 붙였다. 어느 날 누군가 답글이 달린 자기 댓글을 지운다. 화면에는 무엇이 남아야 하는가?
판단해 보기 →전시 03 · 운영·수익들어오던 광고 수익을 새 페이지에서 뺐다
3년 운영한 블로그에 AdSense가 붙어 있고, 크진 않아도 매달 돈이 들어온다. 사이트를 '저자의 생각'을 읽는 곳으로 개편한다. 광고는 어떻게 하겠는가?
판단해 보기 →전시 04 · 제품 설계좋아요 버튼에 로그인을 요구하지 않았다
에세이에 👍 반응을 단다. 익명 방문자의 중복 클릭을 어떻게 막겠는가?
판단해 보기 →전시 05 · 콘텐츠 전략3년 치 글 277편을 지우지도, 새 옷을 입히지도 않았다
사이트의 정체성을 바꾼다. 옛 정체성으로 쓴 3년 치 글 277편은 어떻게 하겠는가?
판단해 보기 →전시 06 · 브랜드·디자인아테네 학당을 가져오는 대신, 소실점부터 다시 그렸다
소개 페이지 하단에 라파엘로 「아테네 학당」의 분위기를 들이고 싶다. 어떻게 하겠는가?
판단해 보기 →전시 07 · 콘텐츠 전략해부를 JSON으로 쓰지 않았다
해부 전시를 계속 쓰려고 한다. 구조 필드(질문·선택지·결정)와 장문의 근거 산문이 한 몸인 콘텐츠다. 일곱 편째부터 어떤 형식으로 작성하겠는가?
판단해 보기 →전시 08 · 제품 설계내 판단을 기록하는 도구에서, AI에게 판단을 맡기지 않았다
해부 컴포저에 BYOAI를 붙인다. 사용자가 자기 AI로 초안을 만들어 붙여넣는 흐름이다. 그런데 해부는 '내 판단의 기록'이다. AI에게 어디까지 시키겠는가?
판단해 보기 →전시 09 · 브랜드·디자인잘 돌아가던 회랑을, 굳이 다시 그렸다
소개 페이지 하단의 1점 투시 회랑이 이미 라이브로 잘 동작한다. 다만 위쪽이 살짝 잘려 미완성처럼 보이고, 애니메이션은 하나뿐이며 선이 단조롭다. 멀쩡히 돌아가는 그림을 어떻게 하겠는가?
판단해 보기 →전시 10 · 콘텐츠 전략쇼케이스에 잘 만든 데모를 더 채우지 않았다
사이트에 쇼케이스 메뉴가 있다. AI에게 시키면 멋진 데모를 얼마든지 더 뽑을 수 있다. 그런데 이 사이트는 'AI가 써준 기술 블로그'를 비판하며 개편한 곳이다. 쇼케이스를 무엇으로 채우겠는가?
판단해 보기 →전시 11 · 운영·수익한 글자 때문에 깨진 빌드를, 새 파일로 덮지 않았다
CSS 파일에서 닫는 중괄호 하나가 빠져 프로덕션 빌드가 깨졌다. 마침 그 파일의 검증된 새 버전을 통째로 들고 있다. 어떻게 복구하겠는가?
판단해 보기 →전시 12 · 콘텐츠 전략데모 소스를 공개하며, 전시 01을 절반 되짚었다
전시 01에서 나는 데모를 정적 단일 파일로 만들겠다고 했다. 메인 앱과 얽히지 않게, 빌드도 라우트도 공유하지 않게. 그런데 데모가 12종까지 늘자 욕심이 생겼다 — 이 원본 프로젝트를 자산으로 보관하고 싶고, 가능하면 사람들이 GitHub에서 가져갈 수 있게 하고 싶다. 그러려면 단일 파일을 포기하고 Vite·React 프로젝트로 만들어야 한다. 과거의 내 결정을 뒤집는 것인가, 아니면 그 결정의 무엇이 핵심이었는지 다시 보는 것인가.
판단해 보기 →전시 13 · 아키텍처AI 데모에 OpenAI를 못 썼다 — CORS와 '서버 없음' 사이에서
AI 데모를 만들려면 방문자가 브라우저에서 직접 모델을 호출해야 한다 — 데모는 정적 파일이고 사이트 서버를 경유하지 않으니까(전시 01). 그런데 OpenAI API는 브라우저 CORS를 허용하지 않는다. 쓰려면 프록시 서버를 둬야 하는데, 그건 '서버 없음' 원칙을 깬다. 'OpenAI도 지원'이라는 매력을 위해 원칙을 굽힐 것인가, 아니면 CORS가 되는 Gemini만으로 갈 것인가.
판단해 보기 →전시 14 · 아키텍처·신뢰방문자의 키를, 내 서버에 태우지 않았다
AI 데모를 실제로 돌리려면 API 키가 필요하다. 가장 편한 길은 내 서버 키를 공유하는 것 — 하지만 비용과 악용 위험이 있고, 무엇보다 데모가 사이트 서버에 묶여 전시 01을 깬다. 그렇다고 가짜(mock) 응답만 보여주면 'AI 데모'가 가짜인 셈이다. 방문자에게 자기 키를 넣게 하되, 그 키를 어떻게 다룰 것인가 — 편의를 위해 서버가 관리할 것인가, 아니면 한 번도 만지지 않을 것인가.
판단해 보기 →전시 15 · 아키텍처·신뢰AI 데모를, 키 없이도 완결되게 만들었다
BYOA 데모는 방문자가 자기 키를 넣어야 실제로 돈다. 그런데 방문자 대다수는 키가 없다. 키 없는 사람에게 '키를 입력하세요'라는 빈 화면만 보이면, 그건 데모가 아니라 진입 장벽이다. 샘플을 보너스로 둘 것인가, 아니면 샘플만으로 데모가 완결되게 할 것인가.
판단해 보기 →전시 16 · AI 역할에이전트에게, 승인 게이트를 달았다
relay 데모는 자연어 목표('노트북 담고 쿠폰 적용해서 결제 직전까지')를 받아 여러 단계를 스스로 실행하는 에이전트다. AI가 알아서 끝까지 처리하게 두는 게 '똑똑해' 보인다. 하지만 그게 옳은가 — AI가 사람 대신 결정을 내리며 자동으로 흘러가는 것이. 매끄러움을 위해 자율에 맡길 것인가, 아니면 각 단계를 사람이 승인하게 할 것인가.
판단해 보기 →전시 17 · AI 역할AI에게, '모르면 모른다'고 답하게 했다
docent 데모는 긴 문서에 대해 질문을 받는다. AI가 매끄럽게 다 답해주는 게 친절해 보인다 — 하지만 문서에 없는 내용을 그럴듯하게 지어내면 그건 환각이고, 이 사이트가 비판해 온 바로 그것이다. '항상 답을 주는' 챗봇으로 만들 것인가, 아니면 '근거가 있을 때만, 없으면 없다고' 답하게 할 것인가.
판단해 보기 →전시 18 · AI 역할프롬프트를 강화하는 대신, 함수를 고쳤다
챗봇에게 '쇼케이스 보여줘'라고 하면 실험만 나오고 해부가 빠졌다. system prompt에 '해부도 함께 보여줘'라고 더 세게 쓸 수 있다 — 하지만 그건 여전히 모델의 선의에 기대는 확률적 방법이라, 또 빠질 수 있다. 프롬프트를 강화할 것인가, 아니면 함수가 해부를 반드시 반환하게 코드로 보장할 것인가.
판단해 보기 →전시 19 · AI 역할챗봇에게 본문을 주지 않았다 — 안내자이지, 대독자가 아니다
사이트 챗봇이 해부 글의 본문(rationale)까지 읽어주면 더 '친절'해 보인다. 하지만 그러면 챗봇이 원문을 대체하고, 방문자는 글을 직접 읽지 않게 된다. 챗봇을 '다 답해주는 비서'로 만들 것인가, 아니면 '이런 글이 있다'고 안내만 하는 도슨트로 둘 것인가.
판단해 보기 →전시 20 · 절제·선별잘 만든 mock 셋을, 갤러리에서 지웠다
처음 쇼케이스를 채운 세 데모 — AI 어시스턴트 UI, 커머스 스토어프런트, 랜딩 — 는 정직하게 'mock'이라 표시돼 있었다. 동작하는 척이 아니라, 페어 프로그래밍으로 만든 인터랙티브 목업이라고. 그런데 실험 틀에 의도가 분명한 데모 열둘이 쌓이자, 이 셋이 거슬리기 시작했다. 'AI 어시스턴트 UI'도 '스토어프런트'도 '랜딩'도, 어디에나 있는 것들이다. 무엇을 왜 골랐는지가 없다. 남겨서 갤러리를 채울 것인가, 지워서 기준을 지킬 것인가.
판단해 보기 →전시 21 · 원칙·아키텍처검색을, 정적에서 런타임으로 바꿨다
검색 범위를 에세이와 해부까지 넓히려 했다. 그런데 발행된 에세이는 DB에서 오고(force-dynamic), 빌드 시점엔 그 내용을 알 수 없다 — 정적 search.json을 만들 수가 없다. 빌드타임 인덱스라는 익숙한 방식을 고수할 것인가, 아니면 런타임 API로 갈아탈 것인가.
판단해 보기 →