장소 이름 고르기가 가장 어려운 페이지입니다

8. tick... tick... BOOM!

점심뭐먹지 — Mon, 15 Jun 2026 21:26:45 +0900

0. Tick... Tick...

배경의 노트는 의문으로 가득 차 있다

시계소리는 보통 긴장감, 그리고 아슬아슬함을 떠오르게 한다.

극중 이 시계소리는 조용히 들리다가도, 점점 재촉하듯 크게 들리는등, 심리를 자극한다.

째깍, 째깍. 누구나 시간과 경쟁하는 순간을 겪기 마련이다.

마치 시험 2주 전 겨우 80% 맞춰두고 남은 수업들 몰아 듣던 나처럼.

1. 꽉 들어찬 8비트, 학기가 끝났다!

컴퓨터의 이해 수업 하나를 빼먹어서 99%로 끝나긴 했지만, 아무튼 학기가 끝났다.

성적은 아직이지만, 대충 유추해보니 B의 향연 속에 숨어있는 A와 C.

그래도 급하게 짐 싸서 대전 내려오고 컴퓨터 망가져서 폰으로 공부한 거 치고 이정도면 선방했다는 느낌.

과목별로 한줄씩 후기를 정리해보자면

컴퓨터의 이해: 깊게면 한없이 깊게 갈 수 있지만 간단하게 컴퓨터에 대한 교양이라 그닥 어렵지 않았던, 개론의 개론
파이썬 프로그래밍 기초: 새로 찍은 강의이기도 하고, 교수님이 정말 의욕을 가득가득 담아서 만든 티가 확 났다.
데이터베이스시스템: 시험은 정말 잘봤는데 중간대체시험에서 점수를 왕창 깎아먹어서 알파벳이 하나 바뀐 그 과목.
이산수학: 손진곤 교수님이 이번 학기를 마지막으로 은퇴하셔서 나로써는 1학기의 한정판 수업. 수학에 대한 열정도 느껴지고, 되도록이면 쉽게 쉽게 가르치시려는 게 보여서 한 주에 다른 과목 3개 정도의 시간을 따로 빼둘 정도였다.
컴퓨터 보안: 교수님이 도식과 함께 설명해주셔서 집중만 하면 정말 유익했던 시간. 정보처리기사 시험의 보안 쪽은 이 수업을 토대로 개념을 다시 잡기 참 좋은 느낌이다.
소프트웨어 공학: 다 좋은데 교수님이... 약간 그 과시다. 잠 오는 계열의 그 과. 강의는 틀어뒀지만 나중에 워크북으로 따로 공부했다.

2. Code in Place 완주

방송대 다니면서 또 다른 원격교육을 듣는 것도 기묘한 기분이었다

Code in Place를 결국 완주했다.

Certificate는 나중에 나오겠지만, 한 줄 쓸 수 있는 무언가는 얻었다.

간만에 방치해두고 있던 영어도 쓸 겸 신청했었는데 이래저래 도움이 되었었다.

무엇보다도 영어로 어떻게 코딩을 가르치는지 접해볼 수 있었던 귀한 경험이 되었다.

방송대보다 좀 더 '공동체'라는 개념을 심으려 노력한다는 느낌도 들었다.

월요일 아침마다 라이브 여는 교수님이라던가, 같이 문제 푸는 방을 줌으로 만든다거나.

이런 건 좀 학교에서 따라해도 괜찮지 않나...? 같은 생각이 들었는데 말이지.

여기는 파이널 프로젝트를 보통 내게 되어있는데,

어떤 걸 할까 고민하다, 시험공부도 남아있었고 시간도 정말 없었어서 (...) AI가 랜덤으로 단어를 골라서 시작하는 wordle을 만들었다.

터미널에서 바로 플레이 해볼 수 있도록 만들었다.

(이사 + 입사가 겹쳐서 + 컴퓨터 고장나서 서울 올라가 있던 하루 안에 만들어야 했다. 정말 뭘 할 시간이 없었다!)

해보는 곳은 여기

https://codeinplace.stanford.edu/cip6/share/CCaIq8P24SyNHtI3AzIP

구글 스터디잼은 야심차게 시작했지만 이것저것 겹치며 이건 좀 건성건성 들었다.

다른 거 할 게 너무 많았어서 (...) 미루고 미루다 보니 결국은 핸즈온 세션 3개를 꼬박꼬박 들었다.

이번 학기엔 뭘 많이 벌렸었는데, 구글 스터디잼에 이르러서는 정말 캐퍼시티 초과라는 게 느껴졌었다.

3. 입사

그리고 스케쥴이 터져나가던 내 5, 6월 일정의 가장 많은 지분을 차지하던 게 바로 입사였다.

사전교육도 빡세게 듣고, 입사일에서 일주일도 안남은 시간에 통보를 받고, 대전 쪽에 있어서 이사 준비하고 새로 적응하고 하다보니 시간은 훅 가는데, 훅 가는 만큼 바로 시험이 다가왔다.

그래서 입사한 뒤에 뭐했냐면 오랜만에 리눅스 다시 잡아보고, 정말 빅-한 데이터들을 만지고 있고, 앞으로도 만져볼 예정이다.

파이썬을 정말 신나게 만지고 있다. 연구 과정도 쭉 따라가는... 여정이 될 거 같은데 벌써부터 모델 설계하고 머리가 아파오고 있다.

4. 정처기 공부

22일부터 2차 정처기 실기 신청이니, 다시 또 정처기 공부도 다시 잡아봐야 한다. 그래도 학교 수업에서 이것저것 좀 해둬서 마음이 조금 놓인달까. 성장일지 처음 시작할 때 분명 6개월 안의 목표였는데, 음... 3월인가에 썼으니 아직 목표로는 유효하겠지.

... 금년 안에는 어떻게든 따내야지.

5. 대전 생활

고향은 외국이고, 한국와서 가장 먼저 살던 곳이 대전이었다.

신기한 게 서울 올라가서 생활하는 동안 지리나 지명 다 잊어버린 줄 알았는데 지나다니다보니 슥슥 머리 속 한 구석에서 다시 익숙한 단어들이 살아나더라. 그래서 남들보다 더 빠르게 익숙해진 거 같다.

지금 거주하는 방도 그렇지만, 대전은 원래 버스가 더 유용한 수단이긴 했었다. 문제는 버스가 간혹 30분에 한대 오거나, 15분에 한대 오거나 하는, 서울 사람들이 들으면 '그런 곳에서 어떻게 살아요?' 하는 상황이 발생한다는 것.

그래서 요새 타는 게 자전거다.

타슈라는 대전시에서 운영하는 공유자전거가 있는데, 1시간 안쪽으로 빌리면 공짜.

배터리가 없다던가,

출근시간만 되면 이미 다 회사 근처로 옹기종기 몰려가서 자전거 찾기가 힘들다는 사소한 문제점이 있다거나,
그래서 본의아니게 카카오 자전거를 더 많이 타게 된다거나

... 아무튼 도시 자체는 자전거 타고 돌아다니기가 참 편하게 되어있었다.

서울에 비하면 자전거도로도 잘 되어있어서, 단차도 적고, 급경사도 적어서 자전거 타고 돌아다니기가 정말정말 편하다.

시험 때문에 서울 올라갔다가 자전거 도로 보고 '아이고 이렇게나 졸렬할 수가' 같은 말이 절로 나올 정도로.

자전가 타고 냉면 먹으러 연구단지를 횡단하거나, 둔산까지 자전거 끌고 나간다거나 하면서 즐기는중.

대전 살 때 학교에서 매번 체험학습으로 가던 한빛탑도 자전거 타고 슝하고 다녀와봤다.

~~덕분에 엑스포다리는 사실 맥도날드에서 만든 거라는 외지인 상대의 장난에 안걸려들 수 있었다.~~

성심당을 자주들 물어보시는데, 이미 동네 빵집 느낌이라 잘 안가기 시작했다.

가장 가까운 지점이 당장 자전거타고 15~20분 거리이기도 하고.

6. 토이프로젝트

이런 상황이니 서버도 굴릴수 있나하면 절대로 아니다. 중간에 노트북도 맛이 가는 상황이 맞이하다보니 개발은 거의 회사에서만 하고 있는 상황이고, 방에선 아무것도 못하고 있었다.

주말에 시험치러 올라갈 때마다 몰아서 후다닥 하곤 하는데, 꽤 난감한 요청이 왔었다.

VKOSPI도 넣어주세요 (한국형 공포지수)

이게 그... KRX에서만 다루는 데이터라 API가 딱히 없고, 계산 하기도 당장 하루만에 구현하기는 어려워서, 이것저것 시도하다 일단 그냥 내려왔는데, 결국 결론은 KRX에서 열어주는 데이터마켓 통해서 받아내야 하는 거 아닌가 싶어지더라.

좀 여유가 생겨야 개발도 마저 할 텐데, 일단은 돈 모아서 이 노트북부터 바꾸든지 해야지...

7. BOOM!

They're singing Happy Birthday
You just want to lay down and cry
Not just another birthday
It's 30/90

뮤지컬계의 역사에 한 획을 그을 전설적인 작품을 쓰려 하지만, 하릴 없이 30살이 되었다는 것이 존의 상황이었다.

째깍이는 시계소리는 존 스스로가 설정해둔 제약이고, 조바심이었지만, 결국 나중에 시계소리로부터 해방된다.

무엇인가가, 펑하고 터지는 순간은 무언가 부서지는 것이기도 하지만, 한편으로는 시원함도 가져다 준다.

Rent에서의 Roger 역시 'One song glory'라는 곡에서 비슷한 고민을 하듯, 작중에서 존은 결국 작품을 완성하고, 일종의 해방을 겪는다.

로저와 다른 점은, 존은 방황한 끝에 작품을 하나 끝내고, 한 사이클을 돌았다는 것이다.

회사 다닐 때 늘 하던, 그리고 으레 나도 듣던 이야기가 있다.

세상에는 두가지 작가가 존재한다고, 마감을 안지키는 작가와, 마감을 지키는 작가.

한 사이클을 돌려본다는 건 그만큼 중요하다.

마감이라는 제한이 생기고, 그 안에서 트레이드 오프를 해야 한다.

최소는 빠르고 가볍지만 값을 절하당하기 마련이고,

최대는 모두가 좋아하겠지만 그만한 시간과 자원을 가질 수 없다.

결국 최대와 최소 사이의 '최적'을, 시간이라는 조건 앞에서 늘 트레이드 오프 해야 하는 게 되는 거다.

펑 하고 터지는 순간은 무언가 부서지는 것이기도 하지만, 한편으로는 시원함도 가져다준다.

이번 학기는 유독 바쁘게 보냈던 것 같다.

학교 강의에, 과외 강의 2개에, 중간에 입사가 결정되어 사전교육까지.

수학 개념 제대로 잡아보겠다며 이산수학 전에 수학 강의도 하나 더 듣고, 토이프로젝트도 돌려보고.

무조건 만족스럽지는 않았다. 특히 성적이.

그래도 '이렇게 바쁜 와중이니 C까지는 내려가지 말자, B라도 사수하자'는 목표를 세웠고, 수학 빼곤 완수했다.

일본학과는 쉬운 게 많아 여유가 있었는데, CS과 오니 여긴 또 어려운 것투성이다.

그래도 그 난리 속에서 한 사이클을 완주해냈다. 어찌 됐든 한 바퀴를 돌았다는 게 어디야.

사실 너무 고생해서, 다음 학기는 좀 편하게 갈까 진지하게 고민 중이다. 가령, 6과목을 다 듣지는 말까, 같이.

'직장에서도 배울 게 산더민데 이 와중에 6과목을, 그것도 전부?'라는 생각이 반,

'그래도 이걸 빨리 끝내야 다음 스텝으로 넘어가지'라는 생각이 반이다.

아무튼 이제 방학이고, 조만간 교내 소프트웨어 경진대회도 온다.

이것도 회사 다니면서 어떻게든 해봐야 할 거 같다.

아참, 제목 스타일을 바꿨는데, 단순히 8비트 운운하며 '1바이트가 찼다!' 하면 지루하고 현학적이니, 좀 더 활동적이고 임팩트 넘치는 Tick Tick BOOM!을 제목으로 잡아봤다. ~~겸사겸사 숫자 놀음에서 좀 탈피해보려고.~~

7. His acts being seven ages

점심뭐먹지 — Sat, 23 May 2026 00:03:45 +0900

0. Intro

"All the world's a stage, And all the men and women merely players; They have their exits and their entrances; And one man in his time plays many parts, His acts being seven ages."
— William Shakespeare, As You Like It (뜻대로 하세요)

"온 세상은 무대요, 모든 인간은 단지 배우일 뿐이라. 그들은 퇴장하기도 하고 등장하기도 하며, 사람은 살아가면서 다양한 역할을 맡으니, 그의 연극은 7단계로 나뉜다."

셰익스피어 연극에 등장하는 이 유명한 독백은 인간의 삶을 7단계의 역할극으로 정의한다. 사실 나이에 따라 인간의 발달 단계를 관찰하고, 거기에 맞춰 삶을 서술하는 방식은 셰익스피어가 처음이 아니다. 멀리 고대 그리스 시절부터 이어져 온 유서 깊은 서사적 장치다.

인간은 수를 탐구하는 만큼이나 수에 신비주의를 투영하길 좋아했다. 피타고라스학파라던가, 이스라엘의 수비학이라던가. 자연계의 기하학적 법칙을 발견할 때마다, 그 숫자와 인간사의 법칙을 어떻게든 끼워 맞춰 설명하려 애썼다. 특히 만물의 근원을 수로 보았던 고대 그리스의 피타고라스 학파에게 '7'은 특별했다. 1과 자기 자신으로밖에 나누어지지 않는 외로운 소수(Prime Number)이자, 영혼을 뜻하는 3과 육체를 뜻하는 4의 결합으로서 '완전함'을 상징했으니까. 문학사에서 인간의 생애 주기를 굳이 7년 주기설이나 7단계 단계론에 집착해 끼워 맞추려 했던 것도 이러한 수비학적 전통과 무관하지 않다.

이러한 수비학과 연극적 비유들을 가만히 들여다보고 있으면, 결국 '인간이 수행하는 역할'에 대한 이야기로 귀결된다. 고전 비극에서 거대한 플롯(Plot)이라는 시스템이 정해둔 구조가 먼저일까, 그 안을 채우는 인물(Character)이라는 객체가 먼저일까. 사람이 주어지는 배역을 그저 따라가는 것인지, 아니면 인간이 스스로 그 역할을 만들어가는 것인지는 고대 그리스 비극 시대부터 이어진 오랜 논쟁이다.

1. 학교 수업: 데이터베이스 시스템 (데베시)

거창한 역할론은 잠시 접어두고, 일단 이번 막에서 내가 맡은 배역들부터 점검해 보자.
아침 강의라는 건 본질적으로 위험을 내포하고 있다. 강의를 한참 열심히 듣던 도중, 야속하게도 중간에 수면질환이 예고 없이 터져버렸다. 정신을 차려보니 이미 상황은 종료되어 있었고, 야심 차게 준비하려던 과제는 구경도 못 한 채 날아갔다.

결국 출석대체시험이라는 정면 돌파로 노선을 전환했다. 과제로 편하게 점수를 챙기려던 안일함은 압수당했고, 이제는 순수한 텍스트와 쿼리문으로 증명해야 하는 서바이벌이 되었다. 시험 범위가 넓어지겠지만, 뭐 어쩌겠는가. 오히려 데이터베이스의 깊은 곳까지 강제로 다이빙할 기회라고 생각하기로 했다.

2. 자격증: 정보처리기사

슬슬 정처기 책의 먼지를 털어내고 다시 공부를 시작했다. 달력을 보니 6월이면 당장 실기 접수다. 지난번 가채점을 하며 '실수만 안 했어도...' 하고 복기했던 기억들이 남아있다. 1학기 수업 들었던 것들이 조금씩 구멍을 메워주는 느낌이 있긴 하다. 다시 잘 준비해 봐야지 뭐.

3. 토이 프로젝트: 최소한의 비용으로 일단 운영중

일단 서비스가 돌아는 가고 있고, 생각보다 주변에서 평이 좋아서 당장은 이대로 굴려도 되겠다는 생각도 좀 든다.

간안에 봤던 학교 선배에게 공유해줬더니 '안그래도 집에서 주식 때문에 고통받고 있었는데 이걸로 한시름 덜었다' 라며 치킨 교환권을 쏘더라. 잘 만든 프로젝트는 역시 돈이 되는구나...?

그로스톡 발표 전에 안티그라비티 테스트해본다고 프론트를 한번 엎어봤었는데, 결과가 생각보다 나쁘지 않다.

가드레일이나 기존의 md파일을 무시하고 구현부터 무작정 하던 게 좀 문제였는데, 2.0 나오고 또 뭔가 바뀌었다니 어디 얼마나 바뀌었는지 다시 또 깔아서 해봐야겠다.
남은 건 서버 구축에 머신러닝까지 돌리는 건데, 이건 설계까진 해뒀다. 당장 내가 뭘 처리하기엔 지금 시간이 촉박해서 두고 있을 수 밖에 없는 느낌이긴 하지만.

4. 구글 스터디 잼: 일정이 폭주하는 달

5월은 정말 일정이 폭주하는 달이다. 최소한의 리액션으로만 참여하고 있지만, 그래도 핸즈온 워크샵을 틈틈이 챙겨보며 GCP를 이해하고 있다.

최근 워크샵에서 Stitch에 Cloud Run을 연계하는 아키텍처를 보았는데, 구글의 속내가 투명하게 들여다보이는 듯했다. '자사 생태계 안에서 간단한 서버리스 인프라를 구축하고, 거기에 프론트를 얹어서 웹앱을 뚝딱 만들게 하겠다'는 그림. IO2026을 보면서도 그런 느낌이 좀 들었었는데, 직접 써보니 확실히 느껴졌다. 아직 핸즈온 세션이 2개가 더 남아있는데, 첫번째가 가장 쉬운 무언가였던 느낌이라 나머지도 기대가 된다.

5. Code in Place: 영어로 코딩을 배운다는 것

스탠퍼드에서 주관하는 파이썬 코스, Code in Place는 여러모로 신선한 자극을 준다. 영어로 지식을 주입받는 것은 여러모로 한국에서 코딩을 배우는 것과는 관점이 또 달라서 새롭기 때문이다.

특히 for문과 while문을 설명하는 방식이 꽤 이채로웠다. 한국의 주입식 교육에서는 대개 조건문이나 반복문이라며 다소 딱딱하게 가르치곤 한다. 그런데 여기서는 루프를 아주 직관적으로 Countable(셀 수 있는가) 하냐, 혹은 Uncountable(셀 수 없는가) 하냐로 뚝 잘라 구분 짓더라. 혹은 영어 한 문장을 딱 놓고 여기에 for나 while loop, and나 or 조건을 설명한다.
한국에서 가르치는 거 만큼 복잡한 논리를 배울 필요가 없다는 느낌이랄까.

이학, 공학은 흔히 언어를 대체할 수 있는 말이고, '우리는 수식으로 대화한다' 같은 이야기나 생각을 꽤나 하지만, 만들어진 배경이나 가르치는 걸 보면 언어의 역할을 마냥 무시할 수는 없는 느낌이라 재미있게 배우고 있다.

현재 5/8 지점까지 왔다. 총 6주차까지 수업이 진행되니, 6주차 이후에는 개인 프로젝트를 만들어 제출해야 한다. 파이썬의 기초적인 룰 안에서 뭘 만들지 고민중이다.

6. 그로스로그 (Growth Log) 개발 세미나 발표: 기획의 중심 잡기

최근 그로스로그 개발세미나에서 발표를 진행했다. 그동안 프론트를 빌드하고, 서버리스 아키텍처를 붙여가며 맨땅에 헤딩했던 이야기들을 정리해 공유하는 자리였다. 조만간 교내 경진대회를 대비한 팀 빌딩도 있을 예정이라, 이번에는 개발 테크닉보다는 '기획' 부분에 조금 더 포커스를 맞췄다. 난 지금 현업 개발자가 아니기도 하고, 현업 분들이 아무래도 그런 건 더 잘 알테니까.

포커싱을 맞춘 게 애초에 '개발을 하려 하고 있거나, 막 시작한 분들'이라는 건 발표자였던 나 자체가 현업에서 일하던 사람은 아니었고, 만든 것도 대단히 엄청나신 무언가가 아니었기 때문이다.

요즘은 ai가 좋아서, ai랑 돌려보며 기획을 다듬다보면 - ai와 함께 내 기획서를 계속해서 재귀 돌리며 이터레이션 하다보면 - 꽤나 그럴싸한 것을 만들 수 있다. 하지만 그 화려한 이터레이션의 홍수 속에서 개발자가 중심을 잡는 방법은 결국 하나밖에 없다는 결론에 도달했다.

내가 만들고 싶은 것을 단 한 문장으로 정의하고, 끝까지 그 문장을 유지하는 것.

AI와 프롬프팅으로 대화를 나누다 보면, AI가 제안하는 화려한 기능에 휘둘려 내가 처음에 뭘 만들려고 했는지 본질을 잃어버리기 십상이다. 중심축으로 되돌아오는 복원력이야말로 지금 시대의 개발에서 가장 중요한 덕목이 아닐까.

'어떻게 개발을 끝마쳤어요?' 라는 질문을 나중에 들었을 때는 '아, 그럴수도 있겠구나' 싶었다.

기초도 모르던 나도 리액트 처음 배울 때 되게 힘들었던 기억이 났었다. 그 때는 JPA까지 같이 커리큘럼에 담겨서 정말 호되게 고생했었더랬다. ~~이거 아직 개발 끝난 게 아닌데~~

7. 인턴 합격과 사전 교육

새로운 기회가 찾아왔고, 사전 교육을 이수했다. 교육 내용 중 '국가과학기술기본계획'이라는 문서를 살펴볼 기회가 있었는데, 이게 생각보다 재미있었다.

우리가 흔히 구직 사이트에서 보는 수많은 공고와 예산들이, 결국은 이 거대한 문서 한 장에서 파생되어 사방으로 쪼개져 내려오는 것이기 때문이다. 정책의 큰 흐름과 설계도를 읽는 법을 배우고 나니, 단순히 과학 정책이나 연구 분야를 넘어 세상을 보는 시야가 한 뼘 더 넓어진 기분이다. 개발자도 방구석 코드만 볼 게 아니라 이런 거대한 흐름을 봐두면 확실히 뼈와 살이 될 거 같았다.

8. Google IO2026. AWS Summit Seoul

IO2026은 새벽에 인터넷으로 봤고, AWS summit seoul은 직접 현장에 찾아가봤다.

아무래도 회사 사람들이 가서 새 기술은 뭔지, 새 기술들은 뭔지 보는 느낌이었어서, 규모도 생각보다 컸고, 생각보다 행사도 돈을 많이 들인 티가 났다.

io2026에서는 구글이 앞으로 어떻게 나아갈지에 대한 방향이 엿보였고, AWS summit에서는 현재 산업이 어떻게 돌아가는지를 볼 기회를 가질 수 있었다.

구글은 stitch라던가, gemini omni등에서도 보이듯, 클로드에서 보이던 'AI 프롬프트 창에서 바로 웹을 만들어 가시화 한다'라는 것을 벤치마크 하고, 거기서 한 발 더 나아가 '우리가 클로드가 쥐고 있던 프론트엔드 작성 툴을 탈환한다'라는 의지가 보였다. geimi3.1은 분명 실패에 가까웠지만 - 그나마 실패에서 조금 더 끌어올려서 수성까지 어찌어찌 한 걸 보면 마냥 실패는 아닌가...? - 안티그라비티에 올인한 이유가 있었구나... 싶어졌다.

안티그라비티가 사실상 구글 AI의 한 축이 되었다.

솔직히 AWS만 빼놓고 보자면 이게 AWS summit인지 AI summit인지 모를 정도로 AI 천지이기도 했지만, 덕분에 AI를 정말 여기저기 다 넣어보려고 하는구나... 같은 감상도 있었다.
올해에 눈에 띄었던 건 슬슬 AI를 보안에 넣는 제품들이 눈에 확 띄었다는 점이었던 것 같다.

다만, 바깥의 AI가 제품을 공격하는 양상인데,방어쪽의 AI가 어떻게 얼마나 예상하고 탐지해낼지가 흥미로웠다.

나도 지금 보안 에이전트 따로 만들어서 테스트하고 굴리고 있었어서, 이 부분이 꽤 이채로웠다.

9. 다시 1레벨부터

인턴으로 발령 날 연구원이 확정되었다. 대전에 있던 연구원이다. 감사하게도 내 전공과 잘 매칭되는 업무를 배정받은 것 같아 다행이라는 생각 반, 다시 적응하려면 또 고생 좀 하겠구나가 반. 현재 서 있는 곳에서 하던 일들을 하나씩 줄여나가며 이삿짐을 싸는 게 감정적으로 그리 쉽지만은 않기 때문이다. 어느 연구소인지도 몰라서 어떻게 될지도 아직 모르기도 하다. 가보면 알겠지... 같은 느낌.

과거에 이런저런 프로젝트를 리딩하기도 했고, 직책을 맡아보기도 했지만, 이제 대전에서는 다시 고개를 숙이고 배움을 청하는 '인턴'의 위치로 돌아간다. 몸가짐을 가다듬지 않으면... 하며 스스로 경계선을 긋는 중이다. 자만하지 말고, 조심스럽게, 그러나 단단하게 스텝을 밟아야지.

10. Outro

이번 일지의 시작점이었던 숫자 '7'로 다시 돌아와 본다.
고대 그리스인들은 7을 더 이상 쪼개지지도 결합하지도 않는 고결한 '완전수'이자 행운의 숫자로 여겼고, 셰익스피어는 그 7이라는 숫자에 인간의 인생 단계를 박제하듯 고정된 배역으로 끼워 맞췄다.

하지만 도서관에 잠들어있는 고전 문학과 달리, 실제 삶이라는 텍스트는 그렇게 타임라인대로 고분고분 흘러가지 않는다. 요즈음 시대에 과거의 나이 기준을 잣대로 들이밀며 "몇 세에는 무조건 어떤 배역을 맡아야 한다"고 고집한다면, 아마 현대의 삶은 부조리극이 되었을 것이다. 고전의 대본 어디에도 오늘날 우리가 마주하는 복잡한 시스템과 변칙적인 동선은 적혀있지 않기 때문이다.

결국 중요한 건 시스템이 내어준 고정된 배역에 나를 끼워 맞추는 정형화된 연기가 아니다. 그로스로그 발표에서 다루었던 이야기처럼, '작품의 본질을 단 한 문장으로 정의하고, 주변의 화려한 변주와 이터레이션 속에서도 중심 서사를 잃지 않는 복원력'이 핵심이다. 무대 위에 들이닥치는 텍스트가 아무리 방대할지라도, 그것을 어떻게 해석하고 소화해낼지는 온전히 배우의 몫이기 때문이다.

새로운 필드에서의 생활이 곧 시작된다.

어떤 즐거움과 경이가 나를 기다릴까? 그리고 거기서 내 배역은 또 어떻게 달라질까.

6. six sick bricks

점심뭐먹지 — Sun, 19 Apr 2026 02:01:15 +0900

0. Intro

“Fox in socks,
Knox in box,
six sick bricks…”
- Fox in socks (Dr.Suess)

오늘은 Tongue Twisters, 잰말놀이를 가져왔다.

미국에서 자란 사람들이라면 한번 쯤은 들었을 닥터 수스의 문장.

요샌 유튜브에서도 볼 수 있는 거 같더라

https://m.youtube.com/watch?v=_RAIDsIuaqg

ox와 ocks로 대구를 맞췄다

영문학에서는 이러한 압운과 라임으로 말장난하는 걸 굉장히 좋아하는데, 따지고 보면 어릴 때부터 이런 걸 꽤나 잰말놀이로 보고 배우는 느낌이다.

오래 전으로 거슬러 올라가면 셰익스피어의 소네트에도 이런 기법들이 들어가있고,

가깝게는 타블로의 영어 랩에도 보면 이런 요소가 꽤 들어가있곤 하다.

... 자, 저는 여러분이 뭐라고 말할 지 압니다.
“닥터 수스 우리 학교 출신이잖아.”
알게 뭡니까, 닥터 수스 얘기 이제 지겨워요. 까놓고 얘기해봅시다.
닥터 수스는 이런 식으로 라임을 맞췄다고요.

fafloozle이랑 saznoozle

문학계에서는 이런 걸 사기라고 부르죠.
- 코난 오브라이언, 다트머스 대학 축사에서 (유튜브링크)

코난 오브라이언도 언급한 바로 그 닥터 수스 되시겠다.

여담이지만 저 fafloozle과 saznoozle은 그냥 닥터 수스 작가가 압운 맞추려고 만든 단어다 (...)

책장을 한번 싹 정리할 때, 이런저런 책들을 꽤 버렸더랬다.

그리고 닥터수스 동화책들을 발견했고, 이건 내가 집어다 내 방 책장에 꽂아뒀다.

가끔 영어 발음이 굳어간다 생각될 때 꺼내서 읽어보곤 한다.

일단 무대를 중국이라 우기고 있는 동화이다.

비슷한 거로는 'Tikki Tikki Tembo'가 있다.

이름이 ' Tikki Tikki Tembo-no Sa Rembo-chari Bari Ruchi-pip Peri Pembo'인 아이 이야기.

이쪽은 수한무, 寿限無랑 비슷한 이야기다.

1. 학교 수업

3주째 41%

여전히 41%. 정보처리기사 실기 시험이 한번 끝났으니 이제 다시 우다다 들어야할 시간이다.

밀린 것들 싹 채우려면 아무래도 고난의 행군이 될 거 같은 느낌.

그래도 파이썬이나 데이터베이스 같이 1주에 한번씩 강의가 추가되는 강의들은 확 몰아서 들어버리는 보람이 있을 거 같다.

2. 노션

수업도 손을 못대고 있었는데 노션이야 뭐 달라진 게 있을리가.

그래도 학교 스케쥴 같은 걸 적어놔서 꽤 도움이 되고 있다. 출석수업이라던가.

3. 정보처리기사

그래서 이렇게 노션이고 수업이고 다 던져두고 친 시험은 과락.

잘 아는 문제들이고, 맞출 수 있었던 문제들중 실수가 많았다.

가채점 보면서 다시 복기하는중.

2회에는 제대로 따내야지.

4. 토이프로젝트

소소한 문제들이 있다.

야후 API가 미국시간에 맞춰서 날아오는 느낌이라, 한국 시간으로 아침에는 꽤 그래프가 평평하다.

당장 잡을까, 싶다가도 어차피 서버랑 디비 올리면 나중에 수정될 문제로 두고 있어서 일단은 두는 중.

서버 아키텍처를 짜고, 설계 검증을 하는 중이다.

다음 날 장 예측으로 머신러닝도 돌려보려 하고 있어서, 이래저래 공부가 될 거 같다.

야후 서비스에 장애가 터지니 내 사이트도 데이터를 못 받아와서 같이 장애가 생기는 (...) 일도 있었어서 수정했다.

남의 문제에 덩달아 내 코드의 허점도 발견했던 셈.

자세한 건 여기에 올려두었다.

5. 구글 스터디 잼

수업이랑 같이 병행하면서 구글 스터디 잼을 다시 끌어 올려볼 생각이다.

아무리 그래도 클라우드나 AI는 들어야지 싶어서.

과외수업이 2개나!

6. Code in Place

학교 수업과는 다른 각도에서 파이썬 수업 하나 더 듣는 느낌.

스탠퍼드에서 하는 공개 강의인 Code in Place가 당첨되었다.

수업을 어떻게 할까, 하다가 목요일 저녁으로 맞춰놨다.

과외수업까지 병행하려니 이거 참 바빠질 거 같다

7. 일본 개발자 커뮤니티에 투고 해본 이야기(2)

시리즈물로 2편을 올렸다.

Static 페이지에서 React로 전환한 이유, 그리고 전환하며 사용한 것들, 어떤 것들을 고려해야하는지를 정리해서 올렸다.

하도 안쓰고 있어서 일본어도 유지할 겸, 뭔가 했다는 흔적도 남길 겸 매주 한번씩은 올려보려고 하고 있다.

기본적으론 여기 올린 글들을 기반으로 다시 쓰는 작업을 하니, 다음 편은 운영하며 겪었던 것들을 묶어서 올려보면 되려나 싶다.

https://qiita.com/RinRie_3R/items/312ed5624c6e12b71c88

元ゲームデザイナーが家族のためウェブサイトを作った話(2) - Qiita

元ゲームデザイナーが家族のためウェブサイトを作った話(2) 一言結論：画面を3タブに分け、サーバ状態はTanStack Queryに寄せたことで、UXと実装コストの両方が改善しました。これは、自作の

qiita.com

8. 그로스톡

그로스톡 행사 이전에 약속이 있어서 참석을 못할 거 같았다가 시간이 생겨서 부랴부랴 참석했다.

예전에 만들던 플젝이 생각났다. 지금 고도화 하는거 끝나면 이것도 해볼까...

사회적 기업 언급이 있어서 예전에 만들던 프로젝트가 생각났다.

이런저런 해외여행에 필요한 정보들을 쭉 모아둔 사이트를 만들고 있었는데, 너무 정보 나열 위주라 만들다 일단 보류한 프로젝트.

연사로 등장한 회장님이 공개한 이력서를 보니

'바쁘게 살면 저정도로 사람이 일을 해낼수 있구나...' 같은 생각부터 들었다.

안그래도 요새 '프로그래밍에 뭔가를 좀 더 해보고 싶은데 어떡할까...' 같은 생각을 좀 하고 있긴 하다.

어학... 은 보통 누구나 다 하니 좀 미묘하고. 뭔가 다른 도메인이랑 프포그래밍이 시너지가 나면 굉장한 느낌이라, 그런 쪽으로 고민을 하는중.

9. Outro

이런저런 생각을 하면서 집에 오는 길에, 문득 오늘 키워드가 생각났다. six. 잰말놀이에서 꺼냈던 그 단어인데, 장르에 따라 꽤 다른 얼굴을 하고 있다.

주사위의 눈은 6이고, 보통 6을 가장 행운의 수로 여기곤 한다.

그리고 6이 나올 확률은 적기에, 꽤 귀한 것으로 취급되곤 한다.

(룰북에 따라선 전혀 반대인 경우도 있지만)

작년 고티를 휩쓸었던 명작, 발더스게이트3는 Dungeon & Dragons의 룰을 모태로 만든 게임이다.

설정을 알고 보면 지독하게도 고증들을 이것저것 넣어둔 걸 알 수 있는 영화.

크리티컬 석세스와 펌블. trpg에서의 운명은 주사위에 따라 결정된다 해도 과언이 아니다

아까까지 6을 이야기하다 왜 20이지? 싶으실 수도 있겠다.

이 게임에서 주사위는 20면체다. 소드코스트에서는 6이 그저 그런 의미로 변하는 마법.

여담이지만, 이 발더스게이트는 개인적으로는 '파이널 판타지 택틱스 전설의 오우거 배틀' 이후로 간만에 본 게임기획이 하드캐리한 게임이라 평가중.

마작과 비슷한 게 trpg라, 플레이할 줄 아는 사람 넷이 모이는 게 참 힘들다.

이 게임은 그걸 컴퓨터랑도 가능하게 했고, 게임을 설계하고 이끌어가는 GM역할도 해준다!

심지어 4명이서 접속해서 같이 세션을 플레이할 수도 있다!

불편을 해소해주는 게임시스템이라니, 이런 신선함은 꽤 오랜만이다.

주사위는 난이도를 무작위로 올리기도 하고, 내려주기도 하지만, 게임에서 주사위를 굴릴 때, 펌블이 나도 보통 빠르게 다음 수를 찾게 된다.

그로스톡에서도 그렇고, 이야기를 듣다보니 떠오른 말이 있다.

'지금은 아쉽겠지만, 그 아쉬운 걸 잘 정리해서 다음 프로젝트에 잘 써먹어보자고'
- 같이 일하던 동료

확실히, 여러 번 코인을 넣고 스타트 버튼을 다시 누를 수 있는 건 어른의 특권이긴 하다.

2회 시험도 다시 잘 준비해봐야겠다. 아무래도 시험이 주사위 놀이가 되면 좀 그러니까.

말 그대로 '실력으로' 주사위 눈을 6을 띄워봐야지.

6. 아무튼 내 잘못은 아닌 거 같은데

점심뭐먹지 — Sun, 19 Apr 2026 00:27:52 +0900

0. Intro

가족이 내가 만든 페이지를 그럭저럭 쓰는데, 어느 날 숫자가 안나온다는 이야길 했더랬다.

1. 무슨 상황일까

지금의 내 페이즈는 야후 API를 못 받아오면 아무 로직이 동작할 수 없는 구조라, 빠르게 확인을 했었다.

확인해보니 API를 못받아오는 게 아니라, API를 받아올 때 58초정도나 기다려야 했던 것.

2. 뭐가 문제였을까

문제는 간단했다. 야후 API 서버 상태가 안좋아서, 전반적으로 응답 속도가 느렸던 것.

3 days ago가 당시에 다운되었던 상황.

이 날 부랴부랴 확인해보니, 다운디텍터에서는 이 날 모든 야후 서비스에서 장애징후를 표시하고 있었다.

3. 그러면 왜 58초나?

이건 더 간단했다.

이전 코드

    return Promise.all(items.map(([ticker, range, interval]) => {
      const url = `https://query1.finance.yahoo.com/v8/finance/chart/${encodeURIComponent(ticker)}?interval=${interval}&range=${range}`;
      return fetch(url, { headers: { 'User-Agent': 'Mozilla/5.0' } })
        .then(upstream => {
          if (!upstream.ok) return { ticker, range, error: upstream.status };
          return upstream.json().then(json => {
            const result = json.chart.result[0];
            return {
              ticker,
              range,
              data: {
                quote: extractQuote(result),
                history: extractHistory(result),
              }
            };
          });
        })
        .catch(e => {
          console.error(`[yahoo] batch error for ${ticker}:`, e.message);
          return { ticker, range, error: 'Upstream Error' };
        });
    }))

겉으로 보면 문제는 단순했다.
야후 API 서버 상태가 좋지 않아 응답 속도가 전체적으로 느려진 것.

하지만 진짜 문제는 따로 있었다.

나는 58개의 요청을 Promise.all로 한 번에 보내고 있었고,
모든 요청이 끝날 때까지 하나의 응답을 기다리는 구조였다.

이 구조에서는

하나라도 느린 요청이 있으면
전체 응답이 같이 지연된다

즉, 평소에는 문제가 없지만
외부 API가 느려지는 순간, 지연이 그대로 증폭되는 구조였던 것.

그래서 단순한 API 지연이
→ 58초짜리 응답 대기로 이어졌다.

4. 그래서 어떻게 고쳤나

새 코드

function wait(ms) {
  return new Promise(resolve => setTimeout(resolve, ms));
}

async function fetchYahooChart(ticker, range, interval) {
  const url = `https://query1.finance.yahoo.com/v8/finance/chart/${encodeURIComponent(ticker)}?interval=${interval}&range=${range}`;
  let lastError;

  for (let attempt = 1; attempt <= MAX_FETCH_ATTEMPTS; attempt += 1) {
    try {
      const upstream = await fetch(url, { headers: { 'User-Agent': YAHOO_USER_AGENT } });
      if (!upstream.ok) {
        lastError = upstream.status;
      } else {
        const json = await upstream.json();
        const result = json.chart?.result?.[0];
        if (!result) {
          lastError = 'No chart result';
        } else {
          return {
            ticker,
            range,
            data: {
              quote: extractQuote(result),
              history: extractHistory(result),
            },
          };
        }
      }
    } catch (e) {
      lastError = e.message;
    }

    if (attempt < MAX_FETCH_ATTEMPTS) {
      await wait(150 * attempt);
    }
  }

  console.error(`[yahoo] fetch failed for ${ticker} ${range}/${interval}:`, lastError);
  return { ticker, range, error: lastError ?? 'Upstream Error' };
}

async function mapWithConcurrency(items, limit, worker) {
  const results = new Array(items.length);
  let nextIndex = 0;

  async function runWorker() {
    while (nextIndex < items.length) {
      const currentIndex = nextIndex;
      nextIndex += 1;
      results[currentIndex] = await worker(items[currentIndex]);
    }
  }

  const workerCount = Math.min(limit, items.length);
  await Promise.all(Array.from({ length: workerCount }, runWorker));
  return results;
}

return mapWithConcurrency(items, BATCH_CONCURRENCY, ([ticker, range, interval]) =>
      fetchYahooChart(ticker, range, interval)
    )

항목	기존 코드	새 코드
평균 속도	빠를 수 있음	약간 느림
안정성	낮음	매우 높음
실패율	높음	낮음
대량 요청 대응	취약	안정적

해결 방법은 단순히 “코드를 고쳤다”가 아니라, 요청 처리 방식을 바꾼 것이다.

기존에는 모든 요청을 한 번에 보내고 전체가 끝날 때까지 기다리는 구조였다면,

이제는:

동시 요청 수를 제한하고 (concurrency control)
실패 요청은 재시도하고 (retry)
각 요청을 독립적으로 처리하도록 분리했다

return mapWithConcurrency(items, BATCH_CONCURRENCY, ([ticker, range, interval]) =>
  fetchYahooChart(ticker, range, interval)
)

이 변화로 인해 달라진 점은 명확하다:

일부 요청이 느려도 전체가 멈추지 않음
일시적인 실패는 자동으로 복구
외부 API 상태에 덜 민감해짐

결과적으로

“빠를 때는 빠르고, 느릴 때는 무너지는 구조”에서 “느려도 버티는 구조”로 바뀌었다.

5. 예전에 일하다 있었던 이야기

한 5년 전쯤, 갑자기 전새계에서 로그인이 먹통이 되는 사고가 터진 적이 있었다.

페이스북 인증서버에 문제가 생겨서 소셜 로그인이 안되었던 사건인데, '왜 게임 로그인이 안되요? 라며 문의가 빗발쳤던 기억이 난다. 기다려달라는 양해를 구하는 공지를 올려서 겨우겨우 여론을 진화했었더랬다.

서비스를 유지하다보면 보통 만나게 되는 건 이런 장애와 관련된 일이 되곤 한다.

내 문제인가? 하며 찾아봐도 문제가 없는 경우도 가끔 있다.

이번 이슈같은 경우에는 이런 일로 코드 개선이 되었으니 그나마 좀 전화위복인가 싶어졌다.

5. Take five

점심뭐먹지 — Sun, 12 Apr 2026 01:37:16 +0900

1. Intro

[장학] 2026. 1학기 한국방송통신대학교 교외(발전기금, 출판문화원,아시아발전재단)장학생 선발 안내

https://knou.ac.kr/knou/561/subview.do?enc=Zm5jdDF8QEB8JTJGYmJzJTJGa25vdSUyRjUxJTJGNzkyNzA0JTJGYXJ0Y2xWaWV3LmRvJTNGcGFnZSUzRDElMjZzcmNoQ29sdW1uJTNEc2olMjZzcmNoV3JkJTNEJUVBJUI1JTkwJUVDJTk5JUI4JTI2YmJzQ2xTZXElM0QlMjZiYnNPcGVuV3JkU2VxJTNEJTI2cmdzQmduZGVTdHIlM0QlMjZyZ3NFbmRkZVN0ciUzRCUyNmlzVmlld01pbmUlM0RmYWxzZSUyNnBhc3N3b3JkJTNEJTI2

한국방송통신대학교

고등교육의 기회 제공, 국민교육의 수준 향상, 사회교육의 확대 발전, 분야별 인재양성

www.knou.ac.kr

3학년 1학기는 교내 장학금을 못 받는다.

전 학기 성적이라는 게 없기 때문에, 일단 한학기는 버텨야 한다.

그래서 교외장학금 공고가 나왔길래 바로 테스트 해봤더니, 장학금 확인 목록이 뜨지 않는 것이었다.

버그인줄 알고 튜터 선생님에게 1:1 대화 걸었는데,

그냥 공고가 미리 올라왔던 것이었을 뿐, 교외장학금 신청은 6/8부터에요

그냥 내가 너무 빨랐던 거였다.

교외장학금 신청은 6월부터라고.

교외 장학금 해당이 되면 조금이라도 돈이 굳을 테니 관심 있으신 분들은 확인 한번 해보시는 게.

공지사항에 뭐가 많이 올라와서 그렇지, 생각보다 찾아보면 좋은 정보들도 올라오는 것 같긴 하다.

~~찾기 불편해서 그렇지~~

요새 뭐든 바로바로 처리하는 버릇이 있는데, 아무래도 좀 천천히 여유를 가질 필요를 느꼈달까.

그런 의미에서, 데이브 브루벡의 Take five가 이번 글의 제목이 되시겠다.

누구나 들어보면 '아, 이 노래?'하는 곡이다.

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

이 곡은 의외의 부분에서 의미를 갖는데, 트럼펫과 드럼 솔로가 분위기에 잘 맞춘다는 점이다.

실제로 이 곡의 드럼 솔로는 꽤 길고, 트럼펫 역시 다른 곡처럼 뻗어나가듯 강하게 연주하지 않는다.

다들 그냥 분위기에 맞춰서 조용조용히 둥글둥글하게 맞춰주고 있다.

뭐 물론 믹싱이 받쳐줘서 그런걸 수도 있지만, 제목에 맞추려 다시 들어보니 눈에 들어오던 부분이었다.

제목의 의미는 5/4박자라는 뜻과, 5분만 쉬자는 의미의 Take five 둘 다라고.

정작 5/4박자로 박자는 바쁘면서 5분만 쉬자니, 아이러니도 이런 아이러니가 없다.

더 찾아봤더니, 이 곡은 원래 라이브 공연 중 밴드가 쉬어가기 위한 숨 돌리기용으로 만들어졌다는 것.

제목 그대로 진짜로 쉬려고 만든 드럼 솔로 곡을 준비했더니, 결국은 히트곡이 되어버렸다.

쉬려고 만든 곡이 히트곡이 되서 연주하게 되는 건 어떤 기분일까.

2. 학교 수업

41% -> 41%

저번주에 이어서 기사 시험 문제 집중 풀이 기간이다. 수업은 잠시 전부 홀드.

3. 노션

과제 검토해서 제출 완료했고, 토이프로젝트만 중간중간 건드렸다

노션도 당장 건드리기에는 딱히 이렇다 싶은 건 없다. 홀드.

4. 토이프로젝트 - MarketRadar

소소하게 기능이 추가되었다

MarketRadar를 꾸준히 개선 중이다.

다크모드를 집어넣고, 다국어 기능을 추가했다. 소소한 버그들도 고쳤다.

~~줄이 비어있는데 쓸데없이 박스 크기가 크다거나, 외국어판으로 보는데 한글로 프롬프트가 돌아온다거나~~

다국어 기능은 막상 추가하고보니 이거 그래도 한국시장만 다루고 있는데 괜찮나... 싶어졌다.

리엑트로 i18n을 넣어본 건 처음인데, 아무래도 thymeleaf로 SSR로 내리는 것보다 더 번거로운 느낌이었다.

좀 더 자바스크립트 식으로 해석하면 기능 구현하는 방식이 이렇게나 달라지는구나... 싶어졌다.

서버 구조도 잡아뒀고, 슬슬 프론트는 여기까지 하고 서버를 vercel을 떼어내고 붙이려 한다.일단 지금 만들어둔 리액트로 잘 돌아가게끔 한 다음에, 어디까지 서버에 넘겨줄지는 좀 고민해봐야할 거 같다.i18n같은 건 그냥 프론트에 둬도 될 거 같은데.

5. 기사시험 준비

기출 푸는 건 그대로 반복중.

범위가 방대해서 그런지 기출 푸는거만으로 괜찮나...? 싶어지긴 한다.

꼭 킬러문제 하나씩 나와서 요새 꽤 술렁술렁하던데.

아무래도 시험이 다가오고 있어서 그런가.

6. Google Skills

시험 집중하느라 이것도 지금 멈춰있다. 어느정도 듣긴 했어야 했는데.지금 프로젝트에 분석용으로 RAG를 붙일까도 고민하고 있었는데, 역시 너무 과잉인가... 싶기도 하고.아무래도 프로젝트에 뭘 붙이냐 때문에 좀 모티베이션이 떨어진 것도 같다.

7. 일본 개발자 커뮤니티에 투고 해본 이야기

'전직 게임디자이너가 가족을 위해 웹사이트를 만들어본 이야기' 라는 타이틀로 여기서 쓰던걸 정리해서 일본 개발자 커뮤니티인 Quiita에 올려보았다.

토이프로젝트를 만들게 된 계기와, 스프레드시트로 프로토타이핑, 스태틱 페이지까지 만든 이야기를 간단하게 적어보았다.

사실 Zen 쪽이 더 맞지 않나 싶다가도, 그 쪽은 완전히 기술쪽의 이야기라 - useState는 어떨 때 써야 하나 같은 - 보통 내가 쓰는 수기 스타일로 아티클을 올리기에는 조금 부담스러웠다.

리액트로 전환한 이야기도 써서 올려야 하는데, 이건 또 언제 쓰나 싶어진다. (그 사이에도 계속 내 레포는 계속 바뀌고 있는데!)

링크는 여기.

https://qiita.com/RinRie_3R/items/af1aaee8d9d06ed3634f

元ゲームデザイナーが家族のためウェブサイトを作った話(1) - Qiita

0.まずはスプレッドシートで簡単にプロトタイピング本編では、このプロジェクトを始めたきっかけから、設計・実装・デプロイに至るまでの流れを順を追ってご紹介します。 1. きっかけ：

qiita.com

8. Outro

응모했던 OSS는 떨어졌던 거 같다.뭐 전국에서 모여드니 자리에 비해 사람이 많았겠거니 하고 있다.

자정이 지났으니 오늘로 봐도 되겠지, 데이터베이스 시스템 수업이 이따 아침 9시에 있고, 다음 주에는 기사 시험도 있고, 시험 다음 날에는 컴퓨터 보안 출석수업이 또 아침 9시에 있다. 아침에 약한 나로써는 아침 9시에 수업이라는 게 가장 힘들다.

주 중간에는 서류 넣었던 것의 결과가 아마 나올 거 같다.학교 공고 보니 지원해볼 곳이 하나 더 생긴 거 같아서, 이와중에 서류 쓸 게 또 생겼다.

이래저래 4월에는 뭔가 많이 걸려있는 느낌이라, 지난하다는 생각이 든다.

아참, 보나마나 출석수업 과제들이 또 있겠지...?

5. 기획이 엉성하면 몸이 고생한다.

점심뭐먹지 — Sun, 12 Apr 2026 00:36:20 +0900

최근(2026-04-07 ~ 2026-04-09)에는 Market Radar를 프로토타입에서 운영 가능한 서비스로 만드는 작업이 대부분이었다.

3/28~3/29에 했던 작업이 보안/성능/기능 추가(RSS, RateLimit, DOMPurify, CORS, 프롬프트 최적화 등)였다면, 이번 구간은

외부 의존성(RSS/Yahoo/Gemini) 때문에 생기는 데이터 계약(contract) 문제
React + Chart.js 경계에서 생기는 UI stale/리렌더링 문제
“내일 시장 주가”라는 제품 컨셉 때문에 생기는 시간대/거래일 계산 문제
i18n 확장으로 인해 생기는 상태 꼬임 / stale 결과 문제
CORS / RateLimit 같은 보안 정책을 실제 트래픽/환경에 맞게 튜닝하는 문제

패치노트 기반으로 정리하되, 실제로는 장애 대응 로그에 가까운 경험이었다.

1. 주로 확인했던 사항들 – 신뢰성, 보안, UX

1-1. 신뢰성(Reliability): 외부 데이터는 ‘항상 정상’이라는 가정이 깨진다

(1) RSS pubDate가 없을 때 “0으로 박아넣는” 게 더 큰 버그를 만든다

문제: RSS 뉴스 수신을 붙여놓고 보니, 모든 피드가 pubDate를 정상적으로 주는 게 아니었다. 파싱이 실패하거나 아예 없는 경우도 있었다.
처음에는 “없으면 0으로 두자” 같은 식으로 임시처리를 하게 되는데, 이게 나중에 UI/정렬 로직에서 오히려 더 큰 버그가 된다.

0은 “값이 없는 상태”가 아니라 “유효한 숫자”처럼 취급된다
정렬/표시에 개입하면서 “시간이 1970년으로 표시”되거나
“최신 뉴스” 정렬이 깨질 수도 있다

해결: pubDate를 억지로 0으로 채우는 걸 제거하고, “없는 값은 없는 값(옵셔널)”로 Contract를 명확히 했다.
UI는 “시간 모르면 표시하지 않는다”로 확정.

(2) “내일”은 날짜가 아니라 ‘다음 거래일(next trading day)’이었다

문제: 이 프로젝트는 '내일의 주가를 예상한다'가 포인트였는데, 새벽 시간대에 접속하면 접근하면 AI가 모레를 분석하는등, 날짜 컨텍스트가 꼬일 수 있었다.

원인은 단순했다.

today + 1 day는 캘린더 상 내일이지만,
“시장” 관점의 내일은 다음 거래일이다.
주말/휴장/시간대까지 섞이면, 단순한 날짜 계산은 제품 컨셉을 깨뜨린다.

해결: 거래일 컨텍스트를 명시적으로 계산하는 로직을 추가했고, Gemini 프롬프트에서도 “tomorrow”를 실질적으로는 nextTradingDay 라는 의미로 바꿨다.

이건 AI 정확도 문제처럼 보이지만, 사실은 도메인 정의(내일 = 거래일) 문제였고, 제품 컨셉을 코드에 정확히 반영한 케이스였다.

무엇보다도 도메인 지식이 명확히 없어서 생긴 문제.

이 문제는 무엇보다도 문제를 정의하며 데이터 처리할 때의 타임존 기준을 KST로 맞추는 계기가 되었다.

어차피 한국 시장 관련 웹사이트라, 한국 시장의 시간에 맞추는 게 더 타당하기 때문이었다.

(3) API/AI가 깨졌을 때를 대비한 “계약 기반 테스트”를 넣기 시작했다

문제: Yahoo / RSS / Gemini는 언제든 깨질 수 있다. 응답이 느려질 수도 있고, 일부 필드가 빠질 수도 있고, 사용자가 탭을 바꿔서 요청이 중간에 취소(abort)될 수도 있다.

운영 관점에서 진짜 중요한 건 “성공 케이스가 잘 되냐”가 아니라:

실패했을 때 UI 상태가 꼬이지 않는지
부분 실패가 전체 실패로 번지지 않는지
한 번 고친 계약이 다음 리팩터링에서 다시 깨지지 않는지

해결: 뉴스/야후/Gemini 경계에서 계약 테스트를 추가하고, abort 이후 상태 잔류를 줄이는 식으로 신뢰성 작업을 계속했다.

1-2. UX(Frontend): 차트/상태는 “가끔”이 제일 잡기 어렵다

(1) ticker/기간 전환 시 차트가 stale(이전 캔버스)로 남는 문제

문제: 대시보드에서 ticker나 기간을 바꾸면, Chart.js 캔버스가 가끔 이전 상태를 유지하는 현상이 있었다.
state는 바뀌었는데, Chart.js 내부 인스턴스가 재사용되면서 “정확히 다시 그려지지 않는” 상황.

이런 버그가 무서운 이유는:

100% 재현이 아니라 “가끔” 발생한다 -> 재현 불가 이슈. 어쩌다 한번 본 게 운이 좋은 것.
사용자는 “데이터가 틀렸다”고 느끼게 된다 (신뢰도 하락)

해결: 선택된 ticker/period 조합이 바뀔 때 차트 컴포넌트를 확실히 remount되게 만들고, 회귀 테스트도 추가했다.

state는 '다시 꺼내 쓰기 위해서는' 좋지만, 그 state가 잘 업데이트 되었는지도 체크해야

1-3. 보안/정책 튜닝(Security): CORS/RateLimit은 ‘정답’이 아니라 ‘운영에 맞춘 정책’이었다

(1) CORS 중앙화 이후에 생긴 “너무 엄격해서 정상적인 요청도 막는” 문제

문제: 3/29에 CORS allowlist를 손봤지만, 시간이 지나면서 엔드포인트가 늘고 정책이 복잡해지니 CORS 처리도 공통화가 필요해졌다.

다만 공통화는 편해지지만, “정책 튜닝 실패”의 영향 범위가 커진다.

ALLOWED_ORIGIN이 빠져있으면 어디까지 막아야 하는가?
Origin 헤더가 없는 요청은 무조건 막아야 하는가?
strict 정책을 모든 API에 적용하면, 정상 트래픽까지 같이 죽지 않는가?

해결 흐름:

CORS를 helper 코드를 작성해서 중앙화하고, 에러 응답도 sanitize
설정 누락 시 fail-closed 도입
어차피 뉴스나 API 정보는 서버에서 요청중. 때문에 범위를 Gemini 요청으로만 제한
Origin 없는 same-origin 스타일 트래픽 허용

한 줄로 요약하자면:

“보안 정책은 한 번 커밋하고 끝나는 게 아니라, 실제 요청 패턴과 충돌하면서 계속 다듬게 된다.”

(2) RateLimiter(KV)가 죽으면 fail-open이냐 fail-closed냐

문제: RateLimit은 “있다/없다”보다 “장애 시 어떻게 행동하냐”가 중요했다.
KV가 일시적으로 실패했을 때 fail-open으로 두면, 그 순간부터 API 비용이 그대로 터질 수 있다.

vercel 에서 제공하는 redis의 콜은 꽤 넉넉한 양이라 사실 어지간해서는 죽을 일이 없지만, 그게 죽을 정도로 과도한 요청이 '만약' 들어온다면, fail-open 해뒀다간 제미나이 요금폭탄으로 이어질 수도 있을 것이다.

해결: 운영 관점에서 비용/남용 리스크가 더 크다고 판단해서, RateLimiter가 불안정하면 요청을 막는 방향(fail-closed)으로 선회했다.

2. (추가) 기능 확장: i18n을 붙이면서 상태 관리가 더 어려워졌다

2-1. i18n(KO/EN/JP) 기능 추가

Added: 다국어(ko/en/ja) 기능 추가

UI 문구 사전화
언어 스위처 + 로컬스토리지 저장
Gemini 프롬프트도 선택 언어로 생성 (RSS 원문은 그대로 유지)

2-2. 언어 변경 시 Gemini 분석 결과가 남아있는(stale) 문제

문제: 언어를 바꾸면 UI만 바뀌는 게 아니라 Gemini 프롬프트 언어 자체가 바뀐다.
근데 그 순간에도 기존 요청이 진행중이면:

이전 언어 응답이 늦게 도착해서 UI를 덮어쓰거나
(일본어로 요청 날렸더니 4개 분석중 1개가 한국어로 되어있다던가)
loading/error 상태가 꼬이면서 UX가 무너질 수 있다

해결: 언어 변경 시 in-flight 요청 abort + 기존 결과/에러/로딩 초기화로 “언어 변경은 분석 결과 무효화”를 명시적으로 만들었다.

이 부분은 기능 추가가 아니라 state를 정리하는 작업에 가까웠다.

3. 회고

배포는 끝이 아니라 시작이라는 말이 흔한데, 이번에는 그 말이 좀 더 현실적으로 다가왔다.

외부 데이터는 형식이 뒤죽박죽이다. “이걸 어떻게 안전하게 실패할지”가 곧 품질이다.
보안은 기능이 아니라 정책이다. 정책은 운영 환경에서 계속 튜닝된다.
“가끔 발생하는 UI 버그”는 기능 결함이 아니라 신뢰도 결함이다.
i18n은 번역 문제가 아니라 상태/캐시/요청 무효화 문제까지 같이 온다.

혼자 개발하다보니 좀 엉성하기도 하고, 아무래도 프로토타이핑을 해가며 이것저것 추가하다보니 전체적으로 기획을 조망하기가 쉽지가 않았다. 금융이나 경제쪽 도메인 지식도 적었던 편이라, 아무래도 거기서 생기는 이슈도 있었고.

중간중간 생산해낸 문서들도 최신화 하고, 이슈 트래킹 해나가며 기능추가나 개선, 버그 수정을 하고 있다.

CLI로 개발할 때는 눈 앞에 있는 문제들을 바로바로 해치우기엔 좋지만, 간트차트 같은 게 아무래도 전체적으로 스프린트를 조망하기에는 더 좋은 느낌이라는 인상을 받고 있다.

다국어 기능은 일본쪽에 글을 하나 썼더니 '아무래도 외국 사람들이 와서 보는 건 좀 불편할 수도 있겠다' 싶어서 급하게 집어넣은 것이었다. Thymeleaf 환경에서 다국어화를 해본적도 있는데, 프론트에서 처리하는 건 좀 더 신경쓸 게 많다는 느낌이라, 이것저것 확인하고 수정하는 데에 오래 걸렸다.

개인적인 감상으로는 초단기 기획 이후 구현, 배포, 운영 순으로 이어지고 있는데,

배포 이전까지의 단계가 너무 짧았어서 (거의 이틀도 안되었으니) '이래도 되는 건가?' 싶을 정도였다.

프론트쪽 기능은 일단 안정화가 되었으니, 이젠 서버 붙여서 Vercel 걷어내고 클라우드 배포로 가야지.

4. Waiting fo(u)r Godot

점심뭐먹지 — Sat, 4 Apr 2026 13:22:18 +0900

0. Intro

올해 만우절은 파파존스가 가장 웃겼다 / 게임 속 패러디가 현실에 나타날 줄 누가 알았겠어

4월이 왔고, 민족의 대명절 April fool도 지나갔다!

아무 것도 없는 무대, 나무 하나만 꽂아둬도 황야으로 인식하게 하는 배경의 마법이 돋보이기도 한다. 이 사진에서는 흙도 좀 뿌려주는 걸로 인지를 더 강화시켰지만.

블라디미르와 에스트라공, 두 사람이 고도라는 인물을 황야에서 기다린다.

고도가 누군지도 모르고, 언제 오는지도 모른다. 그냥 기다린다.

'고도를 기다리며'는 사무엘 베케트의 희곡이다. 전통적인 연극과는 다른 부조리극으로 분류되며, 처음 읽으면 꽤 난해함을 느낄 것이다.

학부시절 읽고 나서 '교수님이 왜 나에게 이런 부조리를' 같은 생각부터 들었다. (지도 교수님이셨고, 알고보니 그 쪽 전공이셨다.)

희곡은 2막으로 구성되어 있는데, 1막과 2막의 구조가 거의 똑같다. 기다리고, 아무것도 안 오고, 내일 또 기다린다. 막이 바뀌어도 달라지는 건 별로 없다.

이번 주가 딱 그런 느낌이었다.

기사 기출은 매일 1회씩 풀고, 틀린 거 체크하고, 다시 보고, 다음날 또 푼다. 만화나 애니메이션에서 매일 수련장에서 칼 휘두르는 연습을 하는 느낌.

고도엔진 마스코트. 오른쪽의 고데트는 만우절에 나왔던 농담.

여담이지만 이 Godot에서 이름을 딴 게임 엔진이 있다.

유니티가 작년 이용정책으로 거하게 삽질을 한 덕분에 급부상했던 엔진.

Scene과 Node로 이어져있다는 점에서는 유니티와 흡사하고, GDScript는 파이썬과 비슷하고 - 그러나 C++과 C#도 지원하고 - 이용료도 무료라, 아직도 이래저래 유니티의 대안으로 손꼽히고 있다.

최근에 나온 Slay the Spire 2가 이 고도엔진으로 만들어졌다.

마침 일지 쓰려 이것저것 뉴스 검색하다보니 AI 개발에 대한 기사가 보였다.

https://www.inven.co.kr/webzine/news/?news=314280&site=loll

[기획] AI, 만능의 환상이 깨지고 있다: 게임 개발자의 비명

게임 개발의 만능 해결사로 기대된 AI가 'AI 쓰레기 코드'와 '조용한 실패' 등 부작용을 낳으며 개발자들의 고충이 커지고 있다. 실제 2025년 상반기 이후 AI 도구 사용률은 감소했으며, 품질 저하

www.inven.co.kr

관심이 있으신 분들은 한번 읽어보셔도 좋을 것 같은 내용.

특강 들으러 가기 전에 쓰던 거라, 특강과 꽤 내용이 비슷하지 않을까, 하는 생각을 하며 집을 나섰었다.

1. 그로스 프라임 특강 - AI, Coder, and Developer

학교에서 강지훈 교수님 특강을 듣고 왔고, 재미있었다.

1-1. 한 문장으로 강의 요약을 하자면

거칠고 간단하게 요약하자면

우리 시대에 변화가 찾아왔습니다.
이젠 적응하면서 기초를 단단히 하시고, ai 너무 믿지 마시고, ai를 어떻게 지휘할 지 생각하세요

~~교수님 작년 강연의 '우리 AI 그렇게 똑똑하지 않습니다'와 다른데요!~~

~~상황이 바뀌었습니다.~~

프로그램을 배우는 방법의 변화 (한 언어를 깊게 drilling 하고...)
개발하는 과정에서의 특징의 변화 (오타와의 전쟁)
개발이 변화하며 발맞춰 생긴 인프라에서의 변화
코드 중심에서 자연어로의 변화
스탠드 얼론의 대화형 ai에서 최근 이행되고 있는 에이전트같은 '역할 중심의 복합체'로의 변화
소프트웨어 개발 생명주기의 모든 과정에서 가속되고 있는 속도의 변화
높아진 생산성 vs 관리 복잡도의 증가
Local Minima 문제, AI는 과연 '정확'할까?
(찾아보니 Local Minima보다 Saddle Point가 더 문제라는데 옵티마이저로 해결한다는 이야기가)

기존의 구조가 어떻게 변화했는지 그리고 그 구조를 종과 횡으로 슬라이스해가며 강연하셨던 부분이 꽤 인상적이었다.

1-2. 중간중간의 감상들

강의 도중에 한 슬라이드의 서두에서

여러분들중에 브레이크 걸어가며 코드 검사해본 사람은 별로 없으실 겁니다

에서는 혼자 '크으윽...! 뭔지 알지 저거...!' 하고 있었는데, 2014년 즈음 모 팀에서 게임브리오 엔진에 디버깅 소프트웨어 따로 열고 notepad++ 열어서 Lua 코드 브레이크 찍어가며 테스트 했었던 기억이 있기 때문이다 -_-...

의외로 생각할 수도 있지만, 유니티 & 비주얼 스튜디오로 아직도 작업하는 게임 프로그래밍 쪽에서는 저게 아직도 동작하기는 한다. 유니티 모노 디밸롭에서부터의 전통.

저 때는 작업하다 안되면 에라 모르겠다 하고 svn에 커밋하고 다음 날 해야지 하고 퇴근하기도 했어요
(오... 교수님... 젠킨스나 팀시티로 자정쯤 되면 자동빌드 걸어서 빌드 깨지면 바로 메일이 안오는 행복한 시대셨군요...)

같은 감상도 좀 있었다.

게임 같은 경우 빌드 한번 걸면 완성까지 오래 걸리다보니, 사람들 퇴근하는 자정이나 새벽 즈음에 보통 빌드를 자동으로 묶어서 하루 동안의 업데이트를 반영하도록 자동으로 커밋해두는 경우가 있다.

요새는 어느정도 중견 기업들에도 꽤나 퍼진 문화로 기억중.

~~물론 패치 날 즈음이 되면 그런 거 없다. 필요하면 바로바로 빌드~~

~~으으 svn 극혐~~

1-3. AI와 윤리

여러분 AI는 책임져주지 않습니다. 여러분이 push를 했다면 그건 여러분 책임이에요

끝에 윤리와 책임에 대한 것도 꽤 언급을 할애하신 것이 이채로웠다.

개발자들이 FOMO 같은 것 때문에 속도에 신경을 쓰다보니 아무래도 일각에서는 'IT 쪽은 개발 윤리나 직업 윤리 같은 거 좀 떨어지는 거 아니야?' 같은 이야기가 도는 경우도 꽤 듣곤 하는데, 윤리 쪽은 좀 지면을 할애할 필요가 있었던 거 같기도.

1-4. 붉은 여왕의 역설에 대하여

붉은 여왕은 그녀가 그 자리에 있기 위해 빠르게, 더빠르게 달려야 해요. 그리고 그게 여러분이 지금 하고 있는 것이랍니다!

아무래도 공통적으로 느끼는 문제가 FOMO와 '붉은 여왕의 역설'이 아닌가 싶다.

여러 곳에서 소개가 되었던, 루이스 캐럴의 거울나라의 앨리스에서 등장하는 개념이다.

거울나라에서는 모두가 일정한 속도로 멀어지기에, '정상'적으로 있으려면 속도에 맞춰서 뛰어야 한다.

더 나아가려면 2배로 뛰어야 하고.

다른 개발자 커뮤니티에 가도 '언제까지 열심히 해야 할까?' 라던가, '난 한동안 노력이나 열심히 라는 말이 싫어서 SNS에서 그 단어들을 뮤트해버렸어' 같은 이야기는 꽤 듣곤 한다.

회사 일도 죽겠는데 집에 와서는 죽어라 컴퓨터 앞에 앉아서 트랜드도 습득하고, 새로운 걸 배워서 익히는 건 또 끝이 없어서 결국 사람이 번아웃이 오는데 그쯤 되면 되려 '열심히 했는데 왜 그대로인거 같지?' 같은 그런 고민.

제논의 역설을 가상 세계에서 더 가혹하게 구현해낸 게 붉은 여왕의 역설이 아닌가 같은 생각도 들지만, 거칠게 이야기하자면 '결국은 수많은 정보를 나에게 입력하고, 다시 출력할 수 있어야 한다'는 거라, 최대한 기술로 그런 스트레스를 줄이는 게 답이 아닐까 같은 생각을 요즘 하곤 한다. 모두 스마트폰에 뇌의 일부를 맡기고 있듯이...?

1-5. 트랜드에 대하여

Q. 책은 너무 느린데 뭘로 트랜드를 참고해야 할까요?
A. 전 논문으로 트랜드를 읽어서요

~~이게 그 힘의 차이가 느껴지십니까 인가 뭔가인가~~

웃기는 했지만 예전에 게임쪽 특허 찾고 기업들의 논문 위주로 어떻게 돌아가는지 챙기던 입장에서는 논문이나 특허로 보는 게 베스트긴 했다. 일단 이런 걸 구축해두면 어지간한 기사보다 더 빠르게 트랜드를 파악할 수 있다.

마치 게임 새로 출시되는 걸 빨리 알려면 한국 정부에서 무슨 심의 등급 받았는지 봇 돌려서 알림 받는게 더 빠른 거처럼.

요즘은 이것저것 다 챙기기는 좀 쉽지 않아서 안하고 있지만, 하다보면 '이 논문이 어디까지 의미가 있을까...' 같은 생각도 하고, 노이즈 같은 논문도 있어서 보다보면 좀 자체 필터링 하기가 쉽지 않다는 느낌이긴 한데...

차라리 노무라 연구소나 가트너 보고서 돈주고 사는 게 이래서 더 편하겠다 싶을 때도 있고.

요샌 AI가 있으니 이런 거 분석, 요약해서 한 눈에 보게 만드는 것도 꽤 편할 거 같은데...

어? 이거 다음 사이드 프로젝트로 만들어 볼까?

2. 학교 수업

41% -> 41%

앞으로 3주간은 기사 시험 문제 집중 풀이 기간이다. 수업은 잠시 전부 홀드.

딱히 드라마틱한 이야기는 없고, 그냥 잠시 멈춰두는 것에 가깝다. 시험 끝나면 다시 켜면 되니까.

과제 해둔 거나 마지막으로 한번 다시 손보고 있다. 일요일까지 손 보고 제출해야지.

3. 노션

딱히 픽스는 하지 않고 있다. 날 잡고 해야지, 를 반복 중.

지금은 기사시험에 집중중이니 당장 손댈 시기는 아닌 거 같다.

이게 2화부터 하는 말인 거 같은데... 언젠가는 손봐야지.

4. 토이프로젝트 - MarketRadar

리액트로 바꾸고 탭도 생겼다

MarketRadar를 꾸준히 개선 중이다. 작업 내용은 따로 블로그에 정리해두고 있다.

Static Page -> React app

이번 주 기준으로 보면 꽤 열심히 개선했다.

바닐라 JS로 만들다 CORS 벽을 만났고, Gemini 모델이 deprecated되는 걸 맞닥뜨렸고, 변수명 하나 때문에 뉴스가 조용히 안 오는 버그도 잡았다. 배포 후엔 Rate Limiting, XSS 방어, 병렬 처리로 제미나이 응답 속도를 1분대에서 5초대로 줄였고, 정적 페이지의 한계를 느껴서 리액트로 전환했다.

페이지가 궁금하시다면 Marketradar 여길 참고하시면 되실듯.

아직 블로그에 작성은 안했는데 라이트하우스 점수도 끌어올렸다.

다음 단계는 Vercel을 벗어나 클라우드에 자체 서버와 DB를 구축하는 것.

리액트쪽도 아직 문제가 보여서 고치느라, 아마 다음 주쯤 되야 겨우 손 볼 거 같지만.

5. 기사시험 준비

매일 기출 1회 풀고, 틀린 거 체크하고, 개념 다시 익히고, 다음날 또 풀고, 다음 기출로 넘어간다.

생각보다 디테일한 부분에서 틀리는 경우가 많았다. 오류검출이라던가, 미묘한 개념 차이라던가. '알고 있다'고 생각했던 것들이 막상 문제로 나오면 손이 멈추는 경우가 있다.

6. Google Skills

Google Study Jam이 시작되었다.

데브옵스는 커리어상 너무 멀어 보여서, 일단 AI와 클라우드에 집중하기로 했다.

강의도 영어, 워크북도 영어, 실행환경도 영어.

현재는 Google Cloud Engineer Associate 과정 수강 중 (2/6). 어소시에이트 자격증을 하나 따두고, AI 쪽도 하나 더 노려볼 생각이다. 가능하면 6월까지 자격증 과정을 따라가는 걸 목표로 하고 있다. 사이버시큐리티 쪽도 관심이 있긴 한데, 얼마나 할 수 있을지는 좀 더 봐야 할 것 같다.

최대한 여기서 배워서 그냥 GCP 쪽에 RAG 달아서 분석력을 좀 더 올려볼까, 같은 생각도.

7. 우연히 학교 시스템 버그 리포트한 이야기

학교 시스템이 MYKnou로 개편되면서 아직 이런저런 버그가 있는 모양이다.

뭔가 신청하려 학교에 등록을 하려 했더니, 나는 폼에 넣으라는 것에 잘 맞춰서 제출했는데 담당자 분의 관리자 페이지에서는 데이터가 중간에 딴 길로 샜는지, 정상적으로 노출이 안되는 상황이 발생했다.

초 간단 양식. 아무래도 내 쪽에서 재현이 불가능하니.

결국 안내받은 지역대학 메일로 해당 사항을 다시 보내고, 버그리포트도 간단하게 양식 만들어서 전산팀에 전달 부탁드린다는 문구와 함께 메일에 첨부해서 보냈다.

갑작스런 상황이긴 했지만 간만에 겪어보는 리포트라 신선했다.

쓰고보니 방송대는 장애학셍센터 공지가 따로 없이 학사 공지에서 전부 다 봐야해서 조금 불편한 거 같긴 하다.

전에 다니던 학교 장애학생센터 들어가서 보는 게 좀 더 편하다는 느낌마저 드니 (...)

8. Outro

커리어를 다시 시작하기 위해 인턴 자리에 지원서를 넣었다. 이력서 글자수 500자 제한이라 오히려 쓰기가 쉽지 않았다. 개발에서도 '늘리는 것보다 줄여라'라는 말이 있다. 뭐든 줄이는 건 늘리는 것보다 어렵더라 역시. 아무튼 잘 되면 좋겠는데!

꽃들로 천장이 만들어지는 이 모습이 석촌호수 벛꽃의 매력인 거 같다

이력서를 꽤 여러 번 수정했고, 중간에 제출용 서류 하나 스캔하러 킨코스에 들렀고, 마감 전에 제출했다.

나와보니 석촌호수에 벚꽃이 만발해있었다.

고도를 기다리는 두명마냥 올 때까지 마냥 기다리는 건 사실 인디언 기우제 메타지만,

적어도 나는 뭔가 하면서 기다리는 중이니까 어떻게든 되지 않을까.

4. RSS를 깎자

점심뭐먹지 — Thu, 2 Apr 2026 03:30:39 +0900

RSS를 깎자 - Vercel 타임아웃부터 제미나이 프롬프트 튜닝까지

Market Radar의 증시 분석 퀄리티를 높이기 위해, 기존 5개였던 미국 위주의 RSS 피드에 CNBC, BBC, ECB, 야후 파이낸스(JP) 등 글로벌 매체를 더해 총 9개로 확장하는 작업을 진행했다. (NHK world backstory는 이번에 삭제.)

단순한 배열 추가 작업인 줄 알았으나, 데이터 소스의 규모가 2배 가까이 커지면서 기존 아키텍처(파서, 서버리스 타임아웃, AI 프롬프트 전처리) 전반의 스케일업이 필요해짐. 백엔드 데이터 수집부터 프롬프트 주입까지, 확장 과정에서 만난 6가지 병목 현상과 해결 과정을 정리했다.

Phase 1. 데이터 수집의 늪 (API & 파싱 이슈)

가장 먼저 맞닥뜨린 문제는 새로 추가한 글로벌 피드들이 화면에 아예 뜨지 않거나 에러를 뱉는 현상.

1. 등잔 밑이 어둡다: "왜 배포가 안 됐지?"

로컬에서는 배열에 10개의 피드가 정상적으로 잡히는데, 프로덕션에서는 여전히 5개만 돌고 있었어서 더 이상했다. 원인은 허무하게도 커밋을 안하고 기다리고 있었음.

Lesson: "왜 안 되지?" 할 때는 제일 먼저 git status부터 쳐보자.

2. 가짜 RSS 링크 (ECB)

ECB(유럽중앙은행) 피드가 빈 배열([])만 반환하고 있었다. 확인해 보니 넣은 주소(.../rss.en.html)는 XML 피드가 아니라 RSS 목록을 안내하는 일반 웹페이지(HTML). 이것저것 찾아서 긁어오다 미처 확인을 못했다. 그러니 파서가 <item> 태그를 찾지 못해 조용히 돌다 빈 값을 리턴. 주소를 실제 XML 엔드포인트(press.xml)로 교체하여 해결.

3. BBC의 변칙: Atom 스타일 태그 파싱

BBC 뉴스 카드를 클릭하면 원문 기사로 가지 않고 href="# " (데드 링크)가 걸리는 버그가 발생. 기존 정규식은 <link>주소</link> 형태만 찾았는데, BBC는 <link href="주소"/> 형태의 Atom 스타일을 섞어 쓰고 있었음. 파서(lib/parseRSS.js)에 Fallback 정규식을 추가해 속성값을 안전하게 빼오도록 수정.

const linkHrefRegex = /<link[^>]+href=["'](.*?)["']/i;
const link = (lM ? lM[1] : content.match(linkHrefRegex)?.[1] ?? '').trim();

4. 깐깐한 야후와 Vercel의 시간제한

야후 파이낸스는 Mozilla/5.0 User-Agent를 봇으로 간주하고 403이나 리다이렉트 루프를 돌려버렸다. 때문에 헤더에 완전한 크롬 브라우저 정보를 넣어 우회하기로 결정. 거기에, 10개의 피드를 병렬로 당겨오다 보니 가끔 응답이 느린 서버 때문에 Vercel의 기본 함수 실행 제한 시간(10초)을 초과하는 상황도 발생. vercel.json에서 api/news.js의 maxDuration을 30초로 넉넉하게 늘려 타임아웃을 예방.

Phase 2. 조용한 데이터 누락 (프론트엔드 & 프롬프트 이슈)

API를 고쳐서 화면에는 글로벌 뉴스가 뜨기 시작. 그런데, 제미나이(Gemini)가 작성하는 '시황 요약'을 읽어보니 여전히 국내 뉴스만 가지고 분석을 하고 있었다. 그럼 이제 하드코딩해둔 프롬프트의 시간이다.

5. 프론트엔드의 숨은 하드코딩 (Cap 제한)

프롬프트를 조립하는 src/lib/buildDataBlock.ts 파일에 이런 코드가 있었다.

const newsBlock = news.slice(0, 10); // 문제의 코드

초기에 토큰 길이를 아끼겠다고 걸어둔 제한. 피드가 9개로 늘어나 후보군이 45개나 되는데, 최신순 상위 10개만 뚝 잘라 AI에게 보내면 당연히 모두 다 전달이 될리가 없었다. 발행 빈도가 높은 국내 통신사 뉴스가 10칸을 꽉 채워버리니, 서구권 뉴스는 제미나이에게 도달하기도 전에 버려지고 있었던 것. 전송할 양을 slice(0, 20)으로 늘려주는 것으로 일단 대처.

6. 프롬프트 헤더 불일치

마지막으로 템플릿의 조건문 트리거가 불일치하고 있었다. 프롬프트에서는 "[최신 뉴스 헤드라인]이 있으면 요약하라"고 지시해놓고, 정작 데이터를 넘기는 쪽에선 \n\n[Top News]\n라는 헤더를 달아서 보내고 있었으니. AI가 문맥상 눈치껏 처리하긴 했지만, 확실한 조건부 실행을 위해 양쪽의 텍스트를 하나로 통일.

결론 및 회고

단순한 피드 추가 작업이었지만, 이 과정을 통해 모듈 간의 결합도가 높을 때 단일 수정 사항이 전체 파이프라인에 어떤 파급 효과를 일으키는지 생생하게 경험했다.

데이터 소스가 늘어나면 전체 파이프라인의 Cap과 타임아웃을 재계산할 것. (maxDuration 연장, 배열 slice 범위 스케일업)
외부 데이터를 다룰 때는 항상 엣지 케이스를 의심할 것. (XML vs HTML, <link> 포맷 차이, 봇 차단 정책 등)
프롬프트와 데이터 블록의 텍스트는 강타입(Strong Type)처럼 정확히 일치시킬 것.

이제까지의 MarketRadar는 한국 뉴스와 미국 뉴스에 다소 의존하는 경향이 있었는데, 소스의 다양성을 늘렸다.

초기 기획에서 하드코딩(slice(0, 10))해둔 것이 확장을 어떻게 가로막는지 라던가, 시스템 설계 단계부터 유연성을 고려해야 한다는 경험을 얻었다. 이래서 사람들이 나중으로 가면 함수형 프로그래밍으로 가려고 하는 건가.

~~간단할 줄 알았는데 자기 전에 떠올라서, 막상 수정하다보니 이것저것 손 대게 되어서 이 시간.~~

3. 프론트엔드 고도화

점심뭐먹지 — Wed, 1 Apr 2026 03:32:15 +0900

0. 리액트로 이사가기

화면배치를 바꾸다보니 슬슬 리액트로 넘어가는 게 맞을 거 같아서 작업을 진행중.

1. 대시보드면 정적 페이지여도 충분할텐데?

크게 3가지 문제가 있었다.

시인성의 한계: 정보가 위아래로 너무 길게 나열되어 한 눈에 들어오지 않음.
정보의 파편화: 뉴스 데이터가 분석 프롬프트용으로만 소비되고 추가 활용이 안되고 있었음.
긴 스크롤: 핵심인 AI 분석 결과를 보려면 화면 맨 아래까지 내려가야 하는 불편함.

대시보드는 한 눈에 들어오는 시인성이 중요한데, 지금은 위 아래로 길게 정보를 뿌려주고 있었다.

AI 분석도 맨 밑에 있어서, 스크롤을 내려서 봐야하는 사소한 불편함이 있지 않나 싶어졌다.

지금 분석은 뉴스도 수집하고 있는데, 프롬프트 용으로 수집하는 게 아니라 '최근 뉴스'정도로 해서 주요 뉴스들을 뉴스 탭으로 따로 빼서 보게 하는 것도 괜찮을 것 같았다.

대시보드, AI분석, 최근 뉴스 정도로 탭을 늘여놓다 보니 이정도 탭 분량이면 화면 전환도 될 테니 리액트로 넘어가도 될 것 같아졌다.

2. 그러면 뭘 어떻게 바꾸는 거지?

3개 탭의 구성: 대시보드(Overview), 뉴스(News), 심층분석(Analysis).
Tailwind CSS + Radix UI: 직접 스타일을 짜던 시간은 줄이고, 디자인의 완성도와 접근성(Accessibility)은 높이고.
상태 관리 전략:
- 서버 상태(React Query): 비동기 데이터 관리의 복잡함을 줄이기 위해 도입. useState가 복잡해지기 시작해서 캐싱과 로딩 상태를 더 효율적으로 처리하도록 도입.
- 클라이언트 상태: 현재는 탭이나 필터 정도의 가벼운 상태만 필요해서 Zustand 도입은 보류.

탭은 3개, UI도 생짜 css로 짜던 걸 리액트 + 테일윈드로 바꾸고, 리액트 쿼리를 도입해보기로 했다.

주스탠드를 보류한 이유는 여러 컴포넌트들에서 상태를 공유해야 할 때 쓰는 게 맞을 텐데, 당장은 그렇게까지 할 상황이 아니기 때문.

useState로 각 컴포넌트마다 데이터를 관리하면서

로딩 / 에러 상태 처리 코드가 반복되고
탭 이동 시 데이터를 다시 불러오는 문제가 있었다

이를 해결하기 위해 React Query를 도입했다.

리액트 쿼리를 도입한 이유도 이 서비스는 어쨌든 서버에서 가져온 것들을 활용하는데, useState만으로는 관리해야할 게 많아지는 것 같아서 채택했다.

3. 탭을 3개로 늘렸다

3-1. 대시보드 탭

탭을 3개로 늘림

한 화면에서 길게 보는걸 아예 대시보드만 첫 화면에 남겨두고,

나머지 AI 분석이나 뉴스 관련 기능은 따로 탭을 팠다.

3-2. 심층분석 탭

AI 분석을 위한 탭을 따로 놓았다. 침고용 지표도 추가.

AI 기능만 있으면 또 애매하니 차트를 좀 더 넣었고

3-3. 뉴스 탭

RSS로 긁어오는 뉴스들도 한 눈에 볼 수 있게

RSS로 긁어오는 뉴스도 따로 참고할 수 있게 해뒀다.

받아오는 뉴스를 다양하게 하려고 NHK RSS도 챙겨봤는데 경제쪽이랑은 거리가 먼 뉴스여서 대체할 곳을 고민중이다.

3-4. footer

그리고 footer도 넣어뒀다.

누가 만들었고, 만약 의견을 주고 싶다면 연락할 곳을 만들어두는 게 좋으니까.

4. 그럼 다른 거는?

4-1. Yahoo api 요청 최적화

Before: 브라우저 → 야후 API (58회 요청)
After: 브라우저 → Vercel 서버 (1회 배치 요청) → 야후 API (58회 병렬 처리)

Yahoo 쪽으로 58개를 매번 요청할 때마다 보내게 되니 API 요청이 너무 잦다는 생각이 들었다.

사용자 수에 따라 IP 차단의 우려도 있을 수 있고, 매번 날리니 성능저하의 문제도 있었다.

그래서 Vercel 서버 api 함수를 추가로 제작.

return Promise.all(items.map(([ticker, range, interval]) => {
      const url = `https://query1.finance.yahoo.com/v8/finance/chart/${encodeURIComponent(ticker)}?interval=${interval}&range=${range}`;
      return fetch(url, { headers: { 'User-Agent': 'Mozilla/5.0' } })
        .then(upstream => {
          if (!upstream.ok) return { ticker, range, error: upstream.status };
          return upstream.json().then(json => {
            const result = json.chart.result[0];
            return {
              ticker,
              range,
              data: {
                quote: extractQuote(result),
                history: extractHistory(result),
              }
            };
          });

Vercel 서버에서 60여개의 요청을 병렬로 날리고, 리액트 쪽으로 브라우저가 정보를 줄 때는 묶어서 1회로 데이터를 받게 하도록 만들었다. 브라우저에서 보내는 건 최소화 하고, vercel 서버에서 대신 처리하도록 했다.

결과:

브라우저 요청: 58회 → 1회
초기 로딩 속도 체감 개선
API 호출 실패율 감소

4.2 TypeScript & Tailwind CSS

TypeScript: 프론트와 백엔드 사이의 데이터 규격을 명확히 하여, 향후 자바 서버로 전환할 때를 대비해 도입.
무엇보다도 요새 리액트 하면 타입스크립트 못쓰면 안된다는 이야길 들었었다.
Tailwind CSS: 유틸리티 우선(Utility-first) 방식으로 스타일링 생산성을 최대한으로. 덕분에 디자인에 신경을 덜 써도 되서 편했다.

4.3 Fail-Open 전략

속도 제한(Rate Limiting)을 담당하는 Vercel KV(Redis)에 장애가 발생할 수 있을 가능성이 있으니, 만약 VercelKV에 장애가 발생하더라도 전체 서비스를 차단하는 대신, 에러를 로그로 남기고 요청을 허용하도록 변경했다.

악의적인 요청을 방지하고자 만든 자물쇠인데, 이 자물쇠가 망가져서 서비스를 이용을 못하게 되는 건 말이 안된다고 생각했었다.

4.4 트라이 해본 것

응답이 10초 제한에 걸리며 504 발생

원인:

프롬프트 토큰 과다
모델 응답 시간

해결:

prompt 경량화 (키 축약, 뉴스 길이 제한)
gemini-2.5-flash → gemini-2.5-flash Lite로 롤백
서버 timeout 전략 조정

결과:

응답 속도 개선 (10초+ → 약 6초)
Vercel 함수 제한(10초) 내 안정적 처리
504 Gateway Timeout 및 분석 실패 문제 해결

Gemini 2.5 flash로 모델을 바꿔봤더니 응답 대기 시간이 너무 길어졌다.

1년치 지수들의 지표를 전부 프롬프트에 넣어서 보내다보니 계산하는 게 길어지기도 해서, Gemini 2.5 Flash Lite로 다시 롤백할 수 밖에 없었다.

빠르게 답변주는 간단한 모델이 필요했던 건 속도 문제도 있었지만, Vercel의 무료 요금제에서는 요청 응답 시간을 10초로 끊는다. 상황에 맞춰서 모델을 취사선택할 수밖에 없어서 Gemini 2.5 flash lite로 다시 롤백할 수밖에 없었다.

5. 이후의 계획

Vercel은 너무 편한 대신, 조금만 더 파고들려면 과금이 추가로 든다.

따라서 스프링부트로 서버를 직접 짜서 Vercel을 점차 대체하려 한다.

2. 배포 이후 수행했던 것들

점심뭐먹지 — Mon, 30 Mar 2026 04:27:40 +0900

0. 패치노트

2026-03-29

Added

- RSS 뉴스 수신 기능 추가 및 Vercel KV 기반 Rate Limiting 도입
- DOMPurify 기반 HTML sanitize 적용
- index.html에 DOMPurify 스크립트 추가
Changed

- 프롬프트 수정/정확도 개선
- AI 답변이 길어질 때 UI/CSS 표시 개선(긴 답변 대응)
- Gemini 호출 5분 타임아웃(shutdown) 문제 수정
- `/api/news` CORS allowlist 동작 수정
- CORS 처리 리팩터링 및 에러 응답 개선

- 프롬프트 요청 비동기 promise로 수정, 병렬 요청으로 요청응답 속도 개선

Security

- Gemini 출력 렌더링 시 XSS 위험 완화(DOMPurify sanitize)

2026-03-28

Added (Project setup)

- 초기 커밋 및 프로젝트 파일 추가

Added

- 2년 데이터 범위 지원(app.js) (60일 이동평균선 분석에서 필요했음)
- Microsoft Clarity analytics 스크립트 추가(index.html)

Changed

- 티커 표시 UI 개선(renderCards)
- 차트 제목 표시 포맷 개선(통화 포함)
- fetch 로직 변수명 정리(가독성)
- 프롬프트 조건/임계값 조정(KRW/USD 관련 조건 포함)
- Gemini 출력 토큰 상향(4096)
- Gemini 모델/버전 및 엔드포인트 관련 변경(엔드포인트 설정에서 헤멤)
- 에러 메시지 개선 및 CORS 지원 추가
- 뉴스 RSS 기능 초기 추가
- html 파일 구조 js, css 분리 및 리팩터링
- Node.js 엔진 버전 24.x로 변경 - vercel에서 강제. 18버전 지원을 종료
- README 개편 및 프로젝트명 오타 수정

최근 이틀간 Market Radar 프로젝트의 초기 배포 후 발견된 보안 취약점을 보완하고, AI 응답 속도 저하 문제를 해결하기 위한 작업들을 진행했다.

1. 주로 확인 했던 사항들 - 보안, 성능개선, UI

1-1. 보안(Security): 비용과 직결된 인프라 보호

AI API 모델(Gemini)은 호출당 비용이 발생하는 종량제 구조이기에, 악의적인 반복 요청이나 공격으로부터 서비스를 보호하는 것이 최우선 과제였다.

Vercel KV(Redis) 기반 Rate Limiting 도입
- 문제: 동일 사용자가 짧은 시간 내에 '분석 버튼'을 연타하여 API 비용을 급증시킬 수 있는 리스크 확인.
- 해결: Vercel KV(redis)를 활용하여 사용자당 요청 횟수를 제한하는 Rate Limit 로직을 구현했다. 이를 통해 무분별한 API 남용을 방지.
XSS 공격 방어 및 HTML Sanitization
- 문제: AI 답변에 리치 텍스트를 지원하기 위해 HTML을 렌더링하는 과정에서 스크립트 주입(XSS) 위험성 발견.
- 해결: DOMPurify 라이브러리를 도입하여 Gemini가 출력하는 모든 HTML 콘텐츠를 필터링(Sanitize). 보안을 위해 필요한 태그만 허용.
CORS 정책 강화
- 문제: API 엔드포인트가 외부에서 중계 서버처럼 악용될 소지 확인.
- 해결: /api/news 등 주요 엔드포인트에 Allowlist 방식의 CORS 처리를 적용하여 지정된 도메인에서만 접근 가능하도록 리팩터링.

1-2. 성능 개선(Performance): 사용자 경험과 안정성 확보

프롬프트가 길어짐에 따라 발생하는 타임아웃 문제와 느린 응답 속도를 비동기 처리 최적화로 해결했다.

비동기 Promise 기반 병렬 처리 전환
- 문제: 기존 순차적(Sequential) async/await 구조로 인해 전체 응답 시간이 지나치게 길어지는 병렬성 저하 문제 발생.
- 해결: 프롬프트 요청 로직을 병렬 Promise 구조로 개편. 다수의 요청을 동시에 처리함으로써 체감 응답 속도를 5분 이상 증가하던 걸 5초대로 개선.

길면 12초까지 나오던 요청응답을 4초로 줄여버렸다.

Gemini 셧다운(Timeout) 이슈 해결
- 문제: 긴 프롬프트와 복잡한 분석으로 인해 Gemini API 호출이 5분 타임아웃에 걸려 강제 종료되는 현상 발생.
- 해결: 요청 구조를 최적화하고 타임아웃 설정을 조정하여 긴 답변 생성 시에도 안정적으로 결과를 수신할 수 있도록 수정.

응답 텍스트 양에 상관 없이 프론트에서 안잘리도록 css 수정

UI/CSS 최적화
- AI 답변이 길어질 경우 레이아웃이 깨지는 문제를 방지하기 위해 긴 텍스트 대응 CSS를 적용하고, 60일 이동평균선 분석을 위한 데이터 범위(2년치)를 확보하여 분석의 정확도를 항샹.

1-3. 주요 기술 스택 업데이트

Runtime: Node.js 24.x (Vercel 환경 최신 기준 준수)
Analytics: Microsoft Clarity 도입을 통한 사용자 행동 패턴 분석 시작
Infrastructure: Vercel KV, RSS News Feed Integration

2. 회고

소프트웨어 생명 주기에서 배포는 마지막이지만, 제품 타임라인에서 차지하는 비중이 가장 많을 수도 있다.

회사 다니며 신규 개발도 진행했지만, 라이브 서비스 및 장애대응도 자주 맡았었다.

프로덕트에 따라 개발까지 이르는 과정이 배포보다 긴 회사들도 있었지만, 안정적으로 서비스가 운영되는 회사의 경우에는 보통 개발보다는 라이브 서비스와 장애대응의 기간이 더 길어지곤 했다.

안타깝게도 업계에서는 라이브 서비스와 장애대응을 그닥 잘 쳐주지는 않는 느낌이었지만, 어찌되었든 상황에 따라서는 배포 이후의 환경이 중요할 수 있다. 보통 잘 만드는 회사들은 이 배포 이후의 환경들을 더 오래 맞닥뜨리게 된다.

빠르게 웹페이지를 프로토타이핑 해서 배포까지 경험을 했으니, 이 뒤의 단계는 배포와 운영에 대한 조치와, 경험, 그리고 서비스 고도화가 될 것 같다.

3. 이후의 계획

3-1. Escape from Vercel

기능을 더 붙이는 것도 좋지만, 일단은 Vercel을 벗어나려 한다.

Vercel을 벗어나려는 이유는 편하긴 하지만, 해상도가 높은 운영 분석등을 하려 하면 '요금제를 올리세요!'라는 과금정책을 유지중이기 때문이다. - 그리고 기본적으로 엣지 컴퓨팅이고, '알아서 다 해드립니다'라는 구조라 서버 구축에는 그닥 좋은 경험이 안된다는 걸 깨달았다.

풀스택으로 기술을 배우기는 했지만, 방향은 하나로 정하는 게 나을 것 같고. 백엔드 쪽을 더 심화하는 게 나을 것이라는 판단이 섰다.

3-2. 백엔드 고도화

서버리스를 뜯어고치게 된다면 자연스레 방향은 서버와 DB 구축으로 이어진다.

현재의 제미나이 답변 품질이 아주 믿을만 한지는 물음표가 찍히고 있다.

한정된 데이터를 야후 파이낸스의 API 호출에 의지하고 있기 때문에, 아무래도 API calling 횟수도 신경쓰인다.

때문에 RSS용 워커 도입을 통한 오라클 클라우드에서의 DB 구축과 프롬프트 향상을 위한 서버 구축 , 클라우드 플레어의 인프라 적용등을 진행할 예정이다.

한국은 연합뉴스 같은 곳에서 아직 무료로 RSS를 발행중인데, 아무래도 다른 시간대의 뉴스들이 더 필요한 지라 그런 RSS를 무료로 발행하는 곳이 얼마나 있는지를 조사중이다. 시간대 차이도 있거니와, 아무래도 한국 주식은 미국 증시 영향을 많이 받다보니 새벽에 뉴스가 들어오는 경우도 꽤 있는 것 같아서.

최종적으로는 도커나 k8s까지 도입을 해볼까 하는데, 일단은 오라클로 이사를 간 뒤에 마저 고민을 좀 해봐야 할 거 같다.

이런 건 역시 처음부터 아키텍처를 그리고 작업하면 편하지만, 경험해보고 나면 좀 더 그런 걸 잘 그릴 수 있게 될 거 같다는 생각이 든다.