JeongTaehwan

usetaehwan 시리즈 4편. 3편에서 이 디자인 시스템으로 제 사이트를 만들었습니다. 이번 편은 시스템을 남에게 보여주는 페이지를 만든 이야기입니다. 순서가 통념과 달랐고, 그 순서가 결과를 바꿨습니다. 결과물: ui.usetaehwan.page"스토리북부터 만들어야지"라는 통념디자인 시스템을 만들면 다음 수순은 정해져 있는 것처럼 보입니다. 스토리북을 깔고, 컴포넌트마다 스토리를 쓰고, 카탈로그를 배포하는 것. 저도 그럴 생각이었습니다.그런데 시스템을 보여주고 피드백을 받았을 때 이런 말을 들었습니다."스토리북도 사실 디자이너나 프론트 개발자나 보기 편한 거니까. 상용성을 본다면 화면을 구성할 거고, 이렇게 바꾸려 할 때 시스템이 생각한 플로우대로 적용되는지까지 보여져야."곱씹을수록 맞는 말이었습..

각(Gak) 시리즈 7편 겸 스킬 저장소 이야기. 지난 편에서 만드는 AI와 트집잡는 AI를 다른 회사에서 데려왔습니다. 그 구조로 2주를 돌렸고, 서로 다른 저장소에서 같은 종류의 사건이 두 번 일어났습니다. 둘 다 "그럴듯한 판단"이 측정 앞에서 무너진 이야기입니다.1부 — 정의가 데이터 앞에서 깨졌다이 화면은 앱의 주장 그 자체다각(Gak)의 두 번째 사이클은 통합 타임라인이었습니다. 이 앱이 존재하는 이유를 눈으로 보여주는 화면입니다. 주장은 이렇습니다. "리그 일정만 보면 여유로워 보이는 팀이, 전 대회를 합치면 밀집 구간에 있다."숫자로는 이미 확인돼 있었습니다. 맨체스터 유나이티드 2023-24 시즌.리그만 전 대회경기 수3852간격 중앙값7.0일4.0일밀집 구간0개3개이 표를 화면으로 옮기..

usetaehwan 시리즈 4편. 3편에서 이 디자인 시스템으로 제 사이트를 만들었습니다. 이번 편은 시스템을 남에게 보여주는 페이지를 만든 이야기입니다. 순서가 통념과 달랐고, 그 순서가 결과를 바꿨습니다."스토리북부터 만들어야지"라는 통념디자인 시스템을 만들면 다음 수순은 정해져 있는 것처럼 보입니다. 스토리북을 깔고, 컴포넌트마다 스토리를 쓰고, 카탈로그를 배포하는 것. 저도 그럴 생각이었습니다.그런데 시스템을 보여주고 피드백을 받았을 때 이런 말을 들었습니다."스토리북도 사실 디자이너나 프론트 개발자나 보기 편한 거니까. 상용성을 본다면 화면을 구성할 거고, 이렇게 바꾸려 할 때 시스템이 생각한 플로우대로 적용되는지까지 보여져야."곱씹을수록 맞는 말이었습니다. 스토리북은 컴포넌트를 하나씩 꺼내 보..

각(Gak) 시리즈 5편. 지난 편에서 같은 화면의 기간 정의를 세 번 바꾸고 멈췄습니다. 이번 편은 그 뒤에 무엇을 바꿨는지, 그리고 바꾼 구조가 첫 사이클에서 실제로 무엇을 잡아냈는지에 대한 이야기입니다.멈춘 자리에서 다시지난 편의 결론은 "코드 문제가 아니었다"였습니다. 진단 기간의 정의가 세 번 바뀌는 동안 backend 연산, 응답 계약, frontend 뷰모델, 프롬프트가 매번 같이 흔들렸습니다. 원인은 결함이 아니라 질문의 부재였습니다. "한 화면에서 분모가 몇 개여야 하는가"를 정의한 적이 없었던 겁니다.그래서 입력 화면은 기획부터 다시 시작하기로 했습니다. 그런데 "기획을 한다"는 게 구체적으로 뭘 하는 걸까요. 혼자 책상에 앉아 요구사항을 쓰면 될까요? 해봤는데 안 됐습니다. 제가 쓴 ..

각(Gak) 개발기 4 — 기획 없이 만들면 어떻게 되는가지난 글에서3편에서 진단 기능을 만들었습니다. 상대 강도를 계산하고, AI에게 문장을 맡기고, 결장 데이터까지 붙였죠. 데이터가 제 편을 들어주지 않았다는 이야기도 했고요.이번 글은 그 다음에 일어난 일입니다. 만든 걸 다시 열어봤더니 제가 만든 화면을 제가 못 읽었습니다.내가 만든 화면을 내가 못 읽었다며칠 만에 진단 페이지를 열고 이런 질문이 들었습니다."이 진단, 언제 기준이지?"화면에는 이런 것들이 있었습니다.최근 폼: 3승 1무 2패밀집 구간: 3개경기 간격 중앙값: 4일상대 평균 순위: 10.4위경기당 결장: 6.6명전부 맞는 숫자였습니다. 그런데 기간이 제각각이었습니다.지표 실제 기간폼, 상대 강도최근 6경기밀집 구간, 간격 중앙값시즌..

각(Gak) 개발기 3 — 진단을 만들면서 배운 것들지난 글에서2편에서 하루 100번밖에 못 부르는 API로 동기화 파이프라인을 만들었습니다. 데이터는 쌓였는데 아직 아무것도 진단하지 못하는 상태였죠.이번 글은 그 데이터로 실제 진단을 만든 이야기입니다. 그리고 만들고 나서 처음 돌려봤을 때, 예상과 다른 답이 나왔습니다.리그만 보면 안 보이는 것먼저 이 앱을 만든 이유부터 확인해야 했습니다.기획할 때 정한 핵심 주장은 이거였습니다. "리그·컵·유럽대항전을 가로질러 봐야 진짜 일정이 보인다." 주중에 유럽 원정을 다녀오고 주말에 리그를 뛰는 그 부담이 리그 성적에 나타난다는 거죠.그럴듯한 말이지만 증명한 적은 없었습니다. 그래서 실제 데이터로 재봤습니다.맨체스터 유나이티드의 2023-24 시즌입니다.리그..

각(Gak) 개발기 2 — 외부 API를 DB에 캐싱하는 파이프라인지난 글에서1편에서는 코드를 쓰기 전에 API부터 찔러본 이야기를 했습니다. 그 과정에서 제약 네 개를 찾았고, 그중 하나가 이번 글의 출발점입니다.무료 티어는 하루 100요청.처음엔 이게 그냥 불편한 숫자인 줄 알았습니다. 만들다 보니 이 숫자가 백엔드 구조 전체를 결정했습니다.산수가 안 맞는다가장 단순한 구조는 사용자가 화면을 열면 그때 API를 부르는 겁니다. 프론트에서 백엔드로, 백엔드가 API-Football로, 받아서 그대로 돌려주는 방식이죠.이 구조의 문제는 계산기를 두드려보면 바로 나옵니다.사용자 한 명이 팀 하나를 조회 = 최소 1요청사용자 100명 = 100요청 = 그날 끝한 사람이 화면을 새로고침만 몇 번 해도 하루치가..

두 번째 사이드 프로젝트 '각(Gak)' — 기획을 세 번 갈아엎은 하루두 번째 프로젝트를 시작하며첫 프로젝트 Orbit을 배포까지 마치고 손을 뗐습니다. 학습 기록을 남기면 3D 행성이 테라포밍되는 앱이었고, 프론트엔드 개발자가 백엔드와 배포까지 직접 해보는 게 목적이었습니다.두 번째 프로젝트를 고민하면서 정한 원칙이 하나 있었습니다. Orbit과 같은 걸 증명하면 안 된다.Orbit은 프론트엔드 인터랙션과 비주얼, 3D를 보여주는 프로젝트였습니다. 비슷한 걸 하나 더 만들면 포트폴리오가 두꺼워지는 게 아니라 반복될 뿐입니다. 그래서 두 번째는 데이터와 AI, 기능 설계를 보여주는 쪽으로 잡았습니다.주제는 축구로 정했습니다. 제가 오래 본 도메인이고, 데이터가 많고, 무엇보다 만들면서 제가 쓸 것 같았..

학습 동기부여 웹앱 'Orbit' — 로컬에서만 돌던 앱을 인터넷에 올리기까지지난 글에서[첫 풀스택 앱] 에서 백엔드 API부터 3D 행성, 마크다운 기록, 구글 로그인까지 만들었습니다. 하지만 로컬에서만 도는 앱이었죠. localhost:3000을 벗어난 적이 없었습니다.이번엔 이걸 실제로 배포했습니다. 세상 누구나 접속할 수 있는 주소를 가진 앱으로요. 그 과정에서 겪은 것들을 정리합니다. 배포는 "한 번에 되는 법이 없다"는 걸 몸으로 배웠습니다.왜 AWS를 쓰지 않았나배포를 고민할 때 가장 먼저 든 생각은 "AWS를 써야 하나"였습니다. 이력서에 그럴싸해 보이니까요.하지만 결론은 쓰지 않는 것이었습니다. AWS로 EC2, RDS, VPC, 보안그룹을 직접 세팅하면 배우는 건 많지만, 개인 프로젝트..

학습 동기부여 웹앱 'Orbit' — 백엔드 API부터 SVG 행성까지, 혼자 다 만들어본 기록지난 글에서[프론트엔드 개발자가 백엔드를 직접 세팅하기로 했다] 에서 Next.js + FastAPI 모노레포를 세팅했습니다. 두 서버가 각자 살아있다는 것만 확인한 상태였죠.이번엔 실제로 동작하는 앱을 만들었습니다. DB를 붙이고, API를 짜고, 로그인을 구현하고, 화면을 그렸습니다. 그 과정에서 배운 것들을 정리합니다.데이터를 설계하는 일가장 먼저 한 건 "무엇을 저장할 것인가"를 정하는 일이었습니다.Orbit은 학습 주제를 행성으로 만들고, 기록을 남길수록 그 행성이 테라포밍되는 앱입니다. 그래서 저장할 건 두 가지였습니다.행성(Planet) — 학습 주제. 이름, 난이도, 생성일기록(Record) — ..