heechann

4박 5일의 입원 기록 (in 본바움 병원)

chan_2 — Thu, 23 Jul 2026 23:30:30 +0900

스케이트보드를 타다 발목에 금이 갔다. MRI 결과를 기다리는 동안 나는 속으로 계속 빌었다. 제발, 인대 손상까지만.

하지만, 결과는 골절이었다. 다리를 전문으로 보시는 선생님은 화면을 보시며 담담하게 말씀하셨다. 수술은 월요일에 가능한데, 그때까지 절대 움직이면 안 되니 지금 당장 입원하라고. 토요일 아침이었다.

골절이라는 사실과 입원이라는 사실이 한꺼번에 밀려오니 잠깐 정신이 아득했다. 그래도 짧은 시간에 생각을 했을 때, 집에 가면 화장실이든 부엌이든 발을 디딜 일이 끝도 없을 테고, 그러다 뼈가 어긋나기라도 하면 더 큰일이었다.

따라서, 별다른 고민 없이 입원하겠다고 했다. 그런데 입원 상담을 받는데 비용이 생각보다 꽤 나왔다. 실비보험이 없었다면 다쳐도 그냥 자연치유가 정답인가 싶은 금액이었다. 다행히 회사에서 가입해 준 단체 실손보험으로 보장이 되는 부분이었다. 하마터면 생돈이 크게 나갈 뻔한 상황에서, 보험이라는 게 이렇게 중요하구나 하는 걸 처음으로 몸으로 느꼈다.

입원 수속을 밟고 수술 전 필요한 검사를 다 마치니 어느새 오후 12시였다. 병실 침대로 돌아와 앉아 있으니 첫 병원밥이 나왔다. 솔직히 맛있진 않았다. 그렇다고 식욕이 있었던 것도 아니라, 딱히 다른 게 먹고 싶다는 생각조차 들지 않았다. 그 뒤로 이어진 시간은 대부분 기다림이었고, 인내였다.

지금 돌이켜보면 굳이 토요일에 입원할 필요가 있었을까 싶기도 하다. 통원하면서 수술 준비를 하고 월요일에 들어와도 괜찮지 않았을까?

하지만 이건 겪어보지 않으면 알 수 없는 종류의 일이었다. 다음엔 이런 건 좀 더 알아보고 결정해야지, 하고 마음에 적어두는 정도로 넘기기로 했다.

MRI 사진

이 사진은 다시 봐도 너무 슬프다. 저렇게 심하게 금이갔다니...

링거를 달고 사는 삶

토요일 저녁, 링거를 맞기 위해 꽤 굵은 바늘이 왼쪽 팔에 깊이 들어왔다. 링거를 맞아본 게 처음이었는데, 5일 동안 가장 불편했던 걸 하나 꼽으라면 단연 이 링거였다. 어디를 가든 매달고 다녀야 하는 그 존재감이 삶의 질을 야금야금 갉아먹었다. 한 번은 줄로 피가 역류하는 걸 보고 깜짝 놀라 간호사를 호출했는데, 자연스러운 현상이라는 말에 괜히 부끄러웠다.

병원의 아침은 정말 빨랐다. 왜 굳이 5시에 깨워서 검사를 하는지는 지금도 잘 모르겠다. 5시에 한 번 깨고, 7시 반쯤 아침밥에 또 한 번 깨고. 밤 12시에 잠들었다면 피곤한 게 당연한 구조인데, 이상하게 몸은 피곤함을 잘 느끼지 못했다. 링거 때문인지 몸이 제정신이 아닌 것 같기도 했다. 대신 낮에 할 게 없어서 틈틈이 잤다. 밥을 먹고 가만히 누워 있으면 저절로 눈이 감기고, 감으면 그대로 잠드는 그런 매직. 그렇게 하루가 뭉근하게 흘러갔다.

머리 감는 것부터 얼굴을 닦는 것까지 전부 불편했고, 샤워는 아예 불가능했다. 그러니 온몸이 씻고 싶다고 아우성이었다. 머리도 기름지고, 얼굴도 기름지고. 결국 아빠 찬스를 써서 5일 동안 머리를 세 번 감을 수 있었다. 혼자서는 도저히 못 하겠던 일이었다. 그런데 옆자리 아저씨는 허리 수술에 무릎 수술까지 하시고도 혼자 머리를 감고 오셨다. 그 모습을 보면서 정말 대단하다는 생각이 절로 들었다.

정말이지 할 게 없어서, 나는 책을 읽고 블로그 글을 썼다. 다치면서 느낀 감정을 생각나는 대로 한 편 적었고, 빈 시간마다 『하마터면 열심히 살 뻔했다』를 펼쳤다. 완치되기 전까지는 내가 좋아하는 활동적인 것들을 한동안 못 할 텐데, 다음으로 좋아하는 독서와 글쓰기를 이참에 좀 파봐야겠다고 생각했다. 이 기간에 글도 많이 쓰고 책도 많이 읽어서 생각의 폭을 좀 넓혀봐야겠다.

소소한 선물

같은 파크에서 타는 친한 아저씨가 커피랑 쿠키를 사다 주셨다. 딸아이랑 같이 오셨는데, 인사하는게 너무 귀여웠다 ㅋㅋ.

나도 결혼하면 딸을 낳아야지... 아들은 나처럼 말썽이겠지?

창밖의 거리

내가 배정받은 자리는 창문에 딱 붙어 있는 자리였다. 8층이었고 주변에 높은 건물이 없어서 밖으로 보이는 풍경이 꽤 좋았다. 그런데 책을 읽고, 블로그 글을 쓰다가 문득 고개를 들어 밖을 볼 때마다 기분이 그리 좋지만은 않았다. 창밖으로는 내가 평소 자주 돌아다니던 거리가 보였고, 그 거리를 자유롭게 오가는 사람들이 보였다. 내가 할 수 있던 걸 지금은 못 한다는 사실이, 그 장면 앞에서는 유난히 받아들이기 어려웠다. 하필 날씨는 또 어찌나 좋던지. 지나다니는 사람들과 그 풍경을 보고 있으면 조금은 우울해졌다. 좋아하는 것들을 못 하니까.

그러다 문득, 병원에만 있어야 하는 모든 환자들이 어떤 기분일지 조금씩 공감이 되기 시작했다. 드라마에서 창밖을 하염없이 바라보던 환자들의 장면. 예전엔 그냥 지나쳤던 그 장면들이, 이제는 다시 본다면 공감이 될 것 같다. 같은 창인데 누군가에겐 풍경이고 누군가에겐 누리지 못하는 그림이라는 걸, 나는 그 8층 창가에서 처음 배웠다.

창밖 풍경

사소한 것의 즐거움

병원은 정말 재미가 없다. 할 게 없으니 누워서 휴대폰만 만지게 되는데, 그마저도 딱히 재미있지 않다. 일요일도 그렇게 무료하게 흘러갔다. 그래도 그날은 소소하게 웃긴 사건이 하나 있었다.

내 병실은 4인실이었는데, 나를 빼면 다들 이미 수술을 받으신 분들이었다. 나는 당연히 다들 걸어 다녀도 되는 줄 알았다. 워낙 잘 돌아다니셨으니까. 그래서 나도 아프지 않은 선에서 슬슬 돌아다녔다. 그런데 들어오신 간호사님의 말이 놀라웠다. 이 방 사람들 전부 움직이면 안 되는 상태라는 것이었다. 스물여덟에 잔소리를 듣고 있는데, 옆자리 분은 마흔다섯이셨다. 다 같이 한바탕 "걷지 마세요" 잔소리를 듣고, 그러고는 또 슬금슬금 걸어 다녔다. 남자들이란 참 말을 안 듣는다. 물론 나를 포함해서.

그렇게 한 번 더 돌아다니다가 간호사님께 딱 걸려서 곧장 휠체어로 끌려갔다. 여러 번 잔소리를 들어도 귀찮은 건 어쩔 수 없나 보다. 그래도 수술을 하고 나서는 확실히 달라졌다. 이제 정말로 발을 디디면 큰일 날 것 같다는 감각이 생겨서, 휠체어를 한번 자의로 타봤는데 이게 또 너무 불편했다. 결국 그 뒤로는 그냥 한 발로 콩콩 뛰어다녔다. 나도 참, 다친 것부터 이미 말썽꾸러기인 것 같다.

강제 휠체어

수술실 앞에서

일요일 저녁, 잠을 자려고 눈을 감아도 잠이 잘 오지 않았다. 다음 날이 수술이라는 사실이 생각보다 크게 다가왔던 것 같다. 그날 밤 잠을 설치고, 다음 날 아침 일어나 11시쯤 수술실로 들어갔다. 들어가자마자 이름과 어디를 수술하는지 물어보시는데, 내가 제정신인지 확인하려는 질문 같았다. 수술실 안에 들어서니 긴장이 훅 올라왔다. 잘못되면 어쩌지, 마취 주사가 아파서 내가 움직이면 어쩌지, 하는 쓸데없는 생각들이 머릿속을 가득 채웠다.

그런데 겁먹었던 것과 달리 마취 주사는 아프지 않았다. 주사와 거의 동시에 수면 마취가 진행되어서, 눈을 감았다 떴더니 이미 수술이 끝나 있었다. 끝나고도 이름을 한 번 더 물어봐 주셨고, 그렇게 원래 병실로 돌아왔다. 하반신에 감각이 하나도 없는 게 신기했다. 다리를 양옆으로 벌리고 있는 줄 알았는데 사진을 찍어보니 멀쩡한 정자세였다. 감각과 현실이 이렇게 다를 수 있다는 게 웃겼다.

살면서 수술이라는 걸 한번 언제 해보게 될까, 가끔 막연히 떠올리곤 했는데 이렇게 갑작스럽게 겪고 나니 신기하면서도 어딘가 씁쓸했다. 전날 밤부터 그렇게 걱정했는데, 막상 겪어보니 걱정할 정도는 아니었다. 아마 처음으로 마취를 하고 처음으로 수술대에 올랐기 때문에 그렇게 마음을 졸였던 것 같다. 그래서 처음 수술실에 들어가는 모든 사람에게 말해주고 싶다. 그렇게까지 걱정할 것 없다고. 눈을 한 번 감았다 뜨면 어느새 다 지나가 있을 거라고.

하반신 마취 후

병실에서 업무를 보다

월요일은 수술도 있고 마취도 해야 해서 아까운 휴가를 하루 썼다. 다행히 토요일에 미리 매니저님께 상황을 말씀드렸더니, 움직이기 편해질 때까지 재택을 허락해 주셨다. 그래서 화요일은 병실에 앉아 일을 했는데, 이게 여간 불편한 게 아니었다. 침대에 앉아 다리를 뻗고 일하다 보면 발과 다리가 저려오고, 그렇다고 수술한 발을 바닥에 내리면 피가 쏠려 열감이 올라왔다. 다시 다리를 올리고, 이 자세 저 자세 다 취해봤지만 끝내 편안한 자세는 찾지 못했다. 그날 해야 할 일은 그래도 다 잘 마무리했다. 다만 앞으로 병원에 있을 때는 그냥 마음 편히 휴가를 쓰기로 마음먹었다. 아무래도 병실은 일하기에 적합한 공간은 아닌 것 같다.

병원 후기

여기까지는 내가 느낀 것들에 대한 이야기였다. 그래도 병원에 대한 후기를 조금 남겨두면 나중에 누군가에게 도움이 되지 않을까 싶었다.

내가 입원한 본바움병원은 집에서 5분도 안 되는 거리에 있어서 골랐다. 최근에 개원한 정형외과 전문 병원이라, 가깝고 내게 필요한 곳이라는 이유만으로 별 고민 없이 선택했다. 지금 생각하면 조금 더 알아보고 갔다면 더 나은 조건으로 입원할 수 있었을지도 모른다. 다만 나는 번거로운 걸 싫어하고 단순하게 해결하고 싶은 사람이라, 이번엔 그 성향대로 움직였다.

좋았던 점부터 말하자면, 시설이 새것이라 전반적으로 쾌적했다. 건물도 침대도 선반도 다 새것이니 이용하는 데 거부감이 없었다. 그리고 첫 입원이라 다른 병원과 비교할 기준은 없지만, 병원밥이 생각보다 먹을 만했다. 이건 언제 또 바뀔지 모를 일이지만.

불편했던 점도 솔직히 있었다. 병실이 조금 좁게 느껴졌다. 옆 사람과 커튼을 쳐도 틈으로 서로가 보일 만큼 가까웠고, 두 침대에 보호자 의자를 다 놓으면 지나갈 길이 있을까 싶을 정도였다. 처음엔 몰랐는데 오래 지내다 보니 조금 답답하게 느껴지기도 했다. 물리치료도 그랬다. 10만 원짜리 비급여 치료를 안내받았을 때, 당시엔 그게 유일한 선택지인 줄로만 알았는데 나중에 알고 보니 다른 선택지도 있었던 모양이다. 이런 점들이 조금 아쉬웠다. 그래서 앞으로는 물리치료도 건강보험으로 처리되는 선에서 받아볼 생각이다. 물론 이건 어디까지나 내 개인적인 경험이고, 사람마다 느끼는 건 다를 수 있다.

마지막으로, 병원이 세로로 긴 구조라 검사를 받을 때마다 층을 옮겨 다녀야 했다. 환자가 적어서 다행이지, 많았다면 엘리베이터를 기다리느라 시간을 다 썼을 것 같다. CT, X-ray, MRI를 찍으러 5층에 갔다가 3층으로 내려와 진료를 보고 또 다른 층으로 이동하는 동선을 한 번 겪고 나면, 조금 번거롭다는 생각이 들긴 했다. 적다 보니 결국 대부분 개인적인 불편함이긴 하지만, 그래도 병원을 고르기 전에 이런 정보를 미리 알고 간다면 다른 곳과 비교하기엔 좋지 않을까 싶다.

다시, 창가에서

4박 5일. 짧다면 짧고 길다면 긴 시간이었다. 스케이트보드 위에서 즐거워 하던 나는 잠시 8층 창가에 묶여, 그동안 당연하게 여기던 것들을 하나씩 다시 바라봤다. 마음대로 걷는 일, 뜨거운 물로 개운하게 씻는 일, 창밖의 거리를 아무렇지 않게 걸어 다니는 일. 전부 대단할 것 없어 보였던 일상인데, 못 하게 되고 나서야 그게 얼마나 중요한 것들이었는지 알게 됐다.

발이 다 나으면 나는 아마 또 스케이트보드를 탈 것이다. 다만 그전까지는, 그다음으로 좋아하는 것들을 붙잡고 이 시간을 건너보려 한다. 책을 읽고, 글을 쓰고, 생각을 넓히면서. 이렇게 한 편의 글로 남겨두는 것도 그 시작이다. 언젠가 이 기록을 다시 읽을 때, 창밖만 바라보던 그 며칠이 그래도 꽤 괜찮은 시간이었다고 말하지 않을까?

천천히 배운 4년, 빠르게 배운 석 달

chan_2 — Sat, 18 Jul 2026 22:55:29 +0900

오늘 발목 골절 진단을 받았다.

어제 파크에서 드랍인 이후 단계에서 넘어졌다. 램프에서 내려가는 순간, 옆 기물에서 다른 사람이 출발하는 게 보였다. 동선이 겹치겠다는 생각이 스쳤고, 반사적으로 속도를 죽여야겠다는 판단이 몸보다 먼저 나갔다. 그 결과, 중심을 잃었고, 보드에서 발을 빼는 순간 발이 바닥에 끌렸다.

인대 부분 파열, 그리고 발목 뼈에 간 금. 어젯밤에는 '인대가 좀 다쳤겠네' 정도로 생각하고 잠들었는데, 아침에 병원에서 검사를 받아보니 뼈까지 금이 가 있었다.

입원실에 누워서 처음 든 생각은 '이제 2~3개월 동안 보드를 못 타는데 어떡하지'였다. 두 번째 생각은 '발이 나았을 때를 위해 코어 운동을 해둬야겠다'였다. 누가 보면 미쳤다고 할지도 모른다. 하지만 그만큼 4월부터 7월까지의 석 달이 즐거웠다. 24살의 나를 넘어서 계속 늘고 있다는 감각이, 시간 가는 줄 모르게 만들었다.

천천히, 안전하게 배우던 시절

스케이트보드는 대학교 때 시작했다. 지금보다 시간이 훨씬 많았던 2021년에는 정말 열심히 탔다. 다만 방식이 달랐다. 천천히, 안전하게. 넘어지지 않는 선 안에서만 연습했다.

오래 탔고 시간도 많이 썼지만, 실력이 느는 속도는 더뎠다. 그 시절 영상을 지금 다시 봐도 '엄청나다'는 느낌은 들지 않는다. 2023년까지 그렇게 타다가 2024년부터는 한 달에 한두 번으로 줄었고, 취업 준비를 시작하면서 2년 가까이 보드를 놓았다.

빠르게, 과감하게 배우기로 한 올해

2026년, 취업을 하고 나서 보드를 다시 타기 시작했다. 이번에는 방식을 바꿨다. 대학생 때와 달리 이제는 시간이 부족했고, 20대가 가기 전에 더 화려하고 위험한 기술을 배워두고 싶었다. 그래서 대학교 때도 안 하던 것들을 28살에 하기 시작했다. 좀 더 빠르게, 좀 더 과감하게. 개인 강습도 두 번 받았고, 그 덕에 오랫동안 두려워하던 드랍인도 해낼 수 있었다.

파크에서 만난 어글 스케이터(묘기용 인라인 스케이트)분들이 내가 타는 모습을 따라오며 영상으로 찍어주신 적이 있다. 영상 속의 나는 생각보다 훨씬 볼품없었다. 그런데 그 영상이 오히려 불을 붙였다. 더 빠르게, 덜 겁내면서 타야겠다고. 더 멋지게 찍히고 싶다는 욕심은 어느새 '넘어지고 다쳐도 괜찮다'는 마음으로 이어졌고, 그 끝에 골절이라는 결과로 이어졌다.

다치고 나서 보이는 것

다치고 나니 보이는 게 있다.

예전처럼 안전하게 탔다면 다치지 않았을 것이다. 그건 분명하다. 하지만 그렇게 탔다면 실력도 그 자리에 머물러 있었을 것이다. 2021년의 나는 훨씬 많은 시간을 쓰고도 천천히 늘었고, 올해의 나는 석 달 만에 4년 치를 따라잡고 넘어섰다. 빠른 속도에는 처음부터 대가가 붙어 있었고, 오늘 그 대가를 받았을 뿐이다.

그래서 후회하냐고 묻는다면, 후회는 하지 않는다. '안전하게 탔다면 안 다쳤을 텐데'라는 생각은 분명 스쳐 지나가고 있다. 하지만 그 뒤에 곧바로 따라온 생각은 이거였다. 예전 처럼 탔다면, 나는 아직도 두려워하던 것들 앞에 그대로 서 있었겠지.

그래서, 앞으로

결론은 정해져 있는 것 같다. 30대가 되기 전까지는 젊음이라는 무기를 쓰기로 했다. 골절이 다 낫고, 다음에는 더 크게 다칠 수도 있다. 그래도 28년을 살아오며 배운 게 하나 있다면, 결국 오래 남는 후회는 다친 기억이 아니라 그 시절에 시도하지 않은 기억이라는 것이다.

다만 당분간은 장난감을 압수당한 아이의 기분으로 석 달을 버텨야 한다. 그게 지금은 제일 슬프다. 그러니 발이 붙는 동안 코어 운동을 하며 더 높은 알리를 뛸 준비를 해 놓을 생각이다.

다시 램프에서 알리 하이를 하고싶다.

『시시한 사람이면 어때서』를 읽고

chan_2 — Tue, 14 Jul 2026 22:43:11 +0900

시시한 사람이면 어때서 - 교보문고

상처받기 싫어서 아무것도 하고 싶지 않은 날들, 나누고 싶은 공감의 한마디 모든 날이 어둡고 축축하고 긴 터널처럼 느껴졌을 때, 남들은 다 잘나가는데 나만 제자리인 것 같아 조바심이 날 때,

product.kyobobook.co.kr

책을 만난 계기

최근에 링크드인 계정을 만들어 가끔 앱에 들어가 피드를 읽는다. 어느 날 누군가 읽은 책 하나가 눈에 밟혔다.

『시시한 사람이면 어때서』

평소 책을 즐겨 읽는 편은 아니지만, 이상하게 읽어보고 싶다는 생각이 들었다. 순간의 이끌림이었고, 그 자리에서 e-book으로 바로 샀다. 이렇게 책을 충동적으로 산 것도, 다 읽고 블로그에 독후감을 남기고 싶어진 것도 이 책이 처음이다.

뜻밖의 발견 — 나는 에세이를 좋아했다

다 읽고 놀란 사실은, 내가 에세이를 좋아한다는 것이었다. 군대에서는 소설이나 자기계발서를 주로 읽어서 '내가 에세이를 읽을 날이 올까?' 싶었는데, 이 책은 마지막 장이 다가오는 게 싫어질 만큼 아쉬웠다. 예전에 『지적 대화를 위한 넓고 얕은 지식』을 읽을 때도 재밌었지만 이 정도는 아니었다. 글마다 밑줄을 긋고 싶었고, 한 챕터를 넘길 때마다 공감되는 이야기가 많아 내가 어떻게 살아왔는지 되돌아볼 수 있는 시간이었다.

가장 깊이 남은 생각 — 하지 않은 선택의 가치

직장을 다니며 동료나 친구와 이야기하다 보면 '그때 내가 이렇게 했다면' 하는 가정을 자주 한다. 이 책의 저자도 비슷한 상상을 한다. 하지만, 비슷한 생각에서 저자는 다른 지점에 도달한다.

그토록 소심한 아이가 아니었다면 결코 알 수 없었을 것들이 있다. 자기가 좋아하는 걸 말하는 일에도 큰 용기가 필요한 사람이 있다는 것. 겪어본 사람만 알고, 겪지 않은 사람은 존재조차 모르는 두려움.
그 앎이 또 다른 방향에서 삶을 떠받쳐왔다.

이 대목에서 머리를 망치로 한 대 맞은 기분이었다.

나도 과거의 나에 대해 후회도 해보고, 그 때 했던 선택들에 대해 인정까지도 해봤다. 하지만 그 과정에서 내가 느낀 감정까지 들여다보고 거기서 얻었던 관점에 대해서는 깊이 생각해 본적은 없었다. 이번에 처음으로 그 감정들을 떠올려봤는데, 어쩌면 그 때 느꼈던 감정들이야말로 지금의 나를 만든 필수 요소가 아니었을까 싶다.

후기

이런 소재가 한두 챕터뿐이었다면 추천하지 않았을 것이다. 하지만 거의 모든 챕터가 공감됐다. 출퇴근길 지하철에서 e-book으로 읽어가다 마지막 페이지를 넘길 때, 책이 끝나는 게 이렇게 아쉬웠던 건 처음이다. 기록을 하다 보니 다시 한번 읽고 싶어졌다.

내일 아침 출근길, 첫 페이지부터 다시 읽어야겠다.

무신사 AI Rookie 전형 지원 회고

chan_2 — Sun, 15 Mar 2026 13:14:28 +0900

1월 말부터 2월 말까지 서류 포함 총 4단계에 걸친 과정이 끝났다. 각 전형마다 결과가 바로바로 나와 되게 빠르게 지나갔던 것 같다. 결과는 운이 좋게도 합격이었고, 좋은 기억이었던 만큼 이전처럼 준비했던 내용 위주로 기록하기보다 생각이나 느꼈던 감정 위주의 일기 형식으로 기록해보려고 한다. AI는 절대 이렇게 쓰지 않겠지? 싶은 날것의 글을 한번 남겨봐야지.

아래는 내가 지원했던 공고다. (언제 사라질지 모른다. 안 사라질 수도?)

무신사 채용홈페이지

musinsacareers

www.musinsacareers.com

서류 전형

서류 전형까지만 해도 정말 후회하고 싶지 않다는 생각으로 지원했다. 내가 될 것이다라고 생각은 하지 않았다. 그냥 늘 그랬던 것처럼 지원했다. 지원하며 느낀 건 일단 자기소개서 작성이 없어서 좋았고, AI를 1월 동안 적극적으로 사용하려고 했는데 이런 부분이 평가 요소에 있어서 좋았다. 지원하고 며칠 후 서류 통과 이메일이 날아왔다. 찾아보니 적부라는 소문을 들었고, 그냥 열심히 코테나 준비해야지라는 생각을 했다.

1차 코딩테스트 : 60분 구현 2문제

2026-musinsa-rookie/1차 문제 at main · musinsatech/2026-musinsa-rookie

2026 무신사 AI Native 개발자 채용 2차 시험 안내. Contribute to musinsatech/2026-musinsa-rookie development by creating an account on GitHub.

github.com

일단 한 줄 평을 말하자면 물리적인 코드량이 너무 많았다. 한 번 실수하게 되면 절대 두 문제를 모두 풀지 못하는 유형의 코딩테스트였다. 난 불행히도 1번 문제에서 실수를 남발했고 2번 문제를 보았을 때 20분이라는 시간이 남게 되었다. 열심히 풀어보려 했지만 입력하는 부분을 다 작성하고 조건문을 작성하려 시간을 봤는데 1분이 남아있었고, 그렇게 코딩테스트가 끝났다. 끝나고 뭔가 준비를 많이 안 한 것이 후회스러웠지만 다 내 선택이었던 터라 그렇게 크게 마음을 쓰진 않았다.

3일 후, 그리팅 카카오 채널에서 무신사 결과가 나왔다고 알림이 왔다. 생각보다 속도가 빠른데? 싶었고 반쯤 기대하고 봤는데 다행히 합격했다. 생각보다 커트라인이 널널해서 다행이라는 생각이 들었다.

2차 코딩테스트 : AI 사용 가능한 3시간 코딩테스트

2026-musinsa-rookie/PROBLEM.md at main · musinsatech/2026-musinsa-rookie

2026 무신사 AI Native 개발자 채용 2차 시험 안내. Contribute to musinsatech/2026-musinsa-rookie development by creating an account on GitHub.

github.com

이건 1차보다는 자신이 있었다. 1월부터 진행했던 프로젝트에서 AI를 적극적으로 활용하고 있었고, 어떤 문제가 나올지는 모르지만 대충 Spec 기반으로 문제를 풀어나가야지라는 생각을 가지고 미리 Skills 2개를 만들어 놓았다. 실제로 내가 만들어 놓은 Skills를 적용할 수 있는 문제가 나왔고, 3시간 동안 목표로 했던 구현을 모두 진행하진 못했지만, 문제에서 제시했던 기본 조건들은 모두 충족하게 만들었다고 생각했다.

확실히 1차 코테보다 아쉬웠던 것은 내가 그만큼 더 자신 있어 하던 영역이라 그랬던 것일까? 끝나고 테스트 코드를 제대로 다 작성하지 못한 것, 문서 작성도 너무 급하게 한 것들이 머릿속에 맴돌았다. 뭐든 내가 열심히 한 것에는 역시 마음이 쓰이나 보다.

5일 뒤, 밥 먹고 공부하러 가는 엘리베이터 안에서 그리팅 카카오톡 채팅을 보게 되었고 바로 확인했는데.. 나이스...! 또 면접까지 왔다. 뭔가 너무 빠르게 지나가서 그런지 내가 했던 노력들은 잊어버리고 조금은 쉽게 왔다는 생각이 들었다. 그래도 참 다행이다. 내가 작년과는 다르게 성장했다는 사실을 이렇게 결과로라도 계속 볼 수 있다는 사실이.

3차 면접 : 면접관 1명과 1시간의 인터뷰 (with 나를 강하게 만들어준 채널톡)

12월 한 달 동안 채널톡이 나를 강하게 만들어줬기 때문에 자신감이 있었다. 아마 채널톡에 지원하지 않았거나 혹은 과정 중에 열심히 준비하지 않았다면 이런 자신감이 존재하지 않았을 것이다. 면접 준비는 생각보다 수월했다. 한 번 진행해 보았던 힘들었던 기술면접이 아마도 똑같이 무신사에서 진행되지 않을까?라는 생각이 들었고, 그래서 그냥 그대로 준비했다. 이때 했던 생각은 이거보다 어렵게 나오면 거기서 또 배워서 상반기에 무조건 취업할 수 있다는 생각을 가졌다.

그렇게 면접 당일이 되었고 긴장 반 기대 반으로 일대일 면접에 들어갔고, 면접이 끝났을 땐 생각보다 내가 경험 정리를 잘해놔서 길게 말하는데도 말을 정말 잘했다는 느낌이 들었고, 질문 대비를 정말 잘해왔다는 생각이 들었다. 예상을 벗어난 질문은 2개 정도 왔는데 모두 그 자리에서 임기응변으로 대처할 수 있는 수준이었고, 집에 돌아가며 내가 잘 말했는지 AI에게 질문을 그대로 물어봤을 때 내가 말했던 그대로 답변을 돌려주어서 기분 좋게 집으로 갔다.

근데 웃기게도 면접은 잘 보거나 못 보거나 사실 결과는 항상 잘 모르겠다. 이번에도 정말 잘 봤다고 생각이 들었는데 결과가 나오기까지 마음을 졸이며 기다렸던 것 같다. 실제로 꿈도 2번 정도 꿨는데 한 번은 광탈하는 꿈이었고, 한 번은 예비 번호를 받는 꿈을 꾸었다. 그만큼 나에게 절박했던 것 같고, 꼭 가고 싶다는 마음을 갖고 있었나 보다.

최종 결과 : 무신사 AI Rookie 합격

3월 3일 휴일이 지난 다음 날 5시, 침대에 누워서 유튜브를 보고 있었다. 토요일에 진행하던 팀 프로젝트 최종 발표를 마친 뒤부터 결과가 나오기까지 조금만 휴식을 취하자는 생각으로 3일 정도 힐링을 하고 있었다. 그때, 역시 그리팅에서 무신사 이메일이 발송되었다는 알림이 왔고, 그대로 바로 Gmail을 켜서 메일 제목을 보는데..

"[MUSINSA] 안희찬님, 3차 인터뷰 합격 및 입사 관련 안내드립니다."

지금 이 글을 쓰다가도 저 순간의 그 기쁜 감정이 떠오르고 또, 1년간의 취준이 머릿속에 스쳐 지나가며 눈에 눈물이 맺히는 기분?

취업은 정말 아이러니한 것 같다. 취준을 시작하며 무신사는 신입을 안 뽑기로 유명해 가고 싶은 기업 리스트에서 지워놓고 준비하고 있었는데... 이렇게 무신사에 입사하는 것이, 뭔가 세상일은 참 알다가도 모르겠다는 생각이 들었다.

1년이라는 취준 기간 동안 가장 변한 관점이 있다면 실패와 운에 대해 내가 갖는 생각이다. 감사합니다 무신사. 나를 데려가 줘서.

채널톡 Software Engineer 전형 지원 회고

chan_2 — Mon, 2 Mar 2026 21:51:33 +0900

2025년 11월, 같이 CS 스터디를 하던 스터디원이 채널톡 면접을 보고 왔다는 얘기를 듣고 공고를 찾아봤다. 코딩 테스트 화면 우하단에 매번 보이던 회사라이름은 익숙했는데, 마침 지원 자격도 맞아서 갖고 있던 이력서를 그냥 넣었다. 이전까지 계속 서류에서 떨어지던 경험이 있어서, 이번에도 비슷하게 끝나겠지 싶었다. 그런데 운 좋게 서류를 통과했고, 전형은 서류부터 3차 인터뷰까지 총 5단계였는데 2차에서 탈락했다. 이 글에서는 각 단계를 어떻게 준비했고, 실제로 어떻게 느꼈는지를 정리해두려 한다.

채용 방식

1. 서류

25년 4월에 써뒀던 이력서와 포트폴리오를 그냥 제출했다. 4월 이후로 추가한 거라고는 오픈소스 기여 내용과 간단한 데스크톱 애플리케이션 개인 프로젝트 정도라 서류 자신감이 크진 않았다. 지금 돌아보면 기술적 깊이가 한참 부족한 서류였다. 그럼에도 2차까지 올라간 건 순전히 코딩 덕분이 아닐까라는 생각을 한다. 그렇다고 코딩을 그렇게 잘하는 것도 아니다...

2. 사전 인터뷰 : 긴장 속 라이브 코딩

11월 20일쯤 지원서를 넣었는데, 넣었다는 사실을 까먹을 즈음 모르는 010 번호로 전화가 왔다. 채널톡 측에서 사전 인터뷰 일정을 조율하는 전화였고, 이후 확정된 날짜로 메일이 도착했다. 이후 본격적으로 면접 준비를 시작했다.

2.1 준비

잡플래닛으로 미리 조사했더니 25분 구현 + 질의응답 형식이라는 후기들이 있었다. 그래서 연결리스트, 스택, 큐를 직접 구현해 보는 연습을 했고, 혹시 더 어려운 게 나오면 어쩌지 싶어 LRU 캐시까지 `LinkedHashMap`으로 구현해 봤다. 일반적인 라이브 코테 문제도 몇 개 풀어보고 갔다.

참고

Blind 75 - LeetCode

Level up your coding skills and quickly land a job. This is the best place to expand your knowledge and get prepared for your next interview.

leetcode.com

2.2 당일 체감

분명 여러 번 구현해봤던 코드인데, 누군가 보고 있다는 사실 하나로 뇌가 멈췄다. 그래도 일단 주석으로 구조를 쭉 그려놓고 그걸 보면서 코드를 채워나갔더니, 어느 순간 손이 따라오기 시작했다.

요구사항은 전부 만족했는데, 면접관분께서 테스트 코드를 돌려보니 버그가 2개 나왔다. 둘 다 그 자리에서 바로 잡을 수 있는 수준이었다. 마지막에 설계 의도 질문이 하나 나왔는데, 급하게 구현하다 보니 제대로 답을 못 했다. 면접이 끝나고도 그 부분이 계속 걸렸다.

되게 걱정하고 있었는데, 다음날 오후에 합격 연락이 왔다. 사전인터뷰 때처럼 비슷하게 1차 면접 일정을 잡았다. 이미 반쯤은 떨어졌다고 생각하고 있었는데, 그래도 내가 학교를 놀러 다니지는 않았구나 싶었다 ㅋㅋ.

3. 1차 인터뷰 : 예상 밖의 문제

사전인터뷰와 달리 1차는 사전 정보가 거의 없었다. 잡플래닛 후기도 추상적인 것들뿐이라 결국 이메일에 나온 내용을 기반으로 준비 방향을 잡았다. 나름 열심히 준비했다고 생각했는데, 실제 면접에서는 전혀 예상하지 못한 문제가 나왔다.

3.1 준비

PS 위주라는 얘기를 듣고 리트코드 문제를 20개 정도 풀었고, LRU, LFU 캐시도 풀어봤다. CS도 살짝 복습했는데, 솔직히 이렇게 준비한 게 실전에서 크게 도움이 되진 않았다. CS는 아래 링크정도만 몇 번 읽어보았다.

CS 참고:

https://dev-coco.tistory.com/158

https://github.com/4z7l/tech_interview.zip/tree/main

https://gyoogle.dev/blog

3.2 당일 체감

문제를 처음 봤을 때 눈앞이 깜깜했다. 특정 기능을 직접 구현하는 문제였는데, 한 번도 해본 적이 없었다. 일단 그때를 다시 생각해 보면 급하게 머릿속에 떠오르는 방법으로 구현 계획을 간단히 이야기하고 시작했던 것 같다.

첫 구현이 끝났을 때 면접관이 개선점을 찾아보라고 했다. 처음엔 가독성 위주로 리팩토링을 시작했는데, 급하게 짠 코드라 꽤 지저분했다. 메서드를 나누고 불필요한 코드를 걷어내니 그나마 읽을 수 있는 수준이 됐다.

이후 면접관이 다른 관점에서도 개선할 부분이 없는지 물었다. 좀 더 생각해보니 현재 구현이 특정 입력 케이스를 처리하지 못한다는 걸 발견했다. 어떻게 해결할지 답했더니 그 방향으로 다시 구현해 보라고 했다. 지금까지 짠 코드를 거의 버려야 할 수준의 변화였고, 결국 개선된 방향으로의 구현은 완성하지 못한 채로 끝났다. 시간 압박에 마지막엔 내가 면접관님께 이상한 질문도 한 것 같았다. 끝나고 나니 후회만 남았다.

구현 이후 몇 가지 질의응답이 있었는데, 합격한 건 아마 이 부분에서 그래도 나쁘지 않게 답했고 틀린 부분을 인지하고 개선하려 했던 방향성 덕분이 아닐까 싶다.

면접 스타일을 복기해보면 CS도 중요하지만 구현 자체에 더 무게가 실려 있었고, 내가 주로 쓰는 언어에 대한 지식과 문제에 접근하는 과정을 중요하게 보는 느낌이었다.

합격하고도 의아했지만, 그래도 나름 잘 해냈다는 생각이 들어 기분이 좋았다.

4. 2차 인터뷰 : 처음 받아본 제대로 된 기술 면접

2차는 커뮤니티에서도 정보를 찾을 수 없었다. 그래서 그냥 모든 걸 준비해 가자는 생각으로 사전인터뷰, 1차보다 훨씬 많은 시간을 투자했다. 면접 당일에는 긴장이 크게 없었는데, 질문이 날카로웠고, 그만큼 내 밑천이 탈탈 털리는 느낌이었다. 지금 당장 내가 뭐가 부족한지 돌아볼 수 있었던 면접이었다.

4.1 준비

이메일로 CS, 이력서, 컬처핏을 전반적으로 다 볼 거라는 안내를 받았다. 마침 크리스마스 주간이 껴있어서 준비 시간이 제법 있었고, 셋 다 최대한 챙기려고 했다.

CS는 시중에 있는 자료를 거의 다 찾아봤다. 유명한 질문 리스트들을 쭉 훑으며 예상 답변을 정리했고, 친구에게 부탁해서 CS 모의면접도 진행했다.

CS 관련 자료
- https://mangkyu.tistory.com/88)
- https://incheol-jung.gitbook.io/docs/q-and-a/spring
- https://dev-coco.tistory.com/163
- https://github.com/gyoogle/tech-interview-for-developer
- https://github.com/ksundong/backend-interview-question
- https://github.com/jbee37142/Interview_Question_for_Beginner
- https://jojoldu.tistory.com/784

이력서 기반 질문도 친구에게 부탁해 모의면접을 한 번 했다. 다만 CS에 비해 깊게 준비하진 못했다. 이력서 기반으로 깊은 질문을 받아본 적이 없어서, 내가 했던 작업에 대해 어떤 질문이 들어올지 예측하고 답변을 정리하는 정도로만 진행했다. 이 부분에서 좀 후회하는 것은 꼬리에 꼬리를 무는 질문들 까지도 준비했다면 더 좋았을 텐데 생각한다. 그만큼 경험이 부족했던 것 같다.

컬처핏은 채널톡 기술 블로그를 전부 읽고 유튜브 테크 컨퍼런스 영상까지 챙겨봤다. 그중 Redis Pub/Sub을 도입해 성능을 개선한 글이 가장 기억에 남았는데, 나중에 이 내용을 바탕으로 내 프로젝트를 고도화해 볼 수 있었다.

4.2 당일 체감

총 80분, 1시간 기술 + 20분 컬처핏이었다. CS는 아는 선에서는 잘 답했지만 몇 번 질문의 의도를 파악하지 못하고 답변을 했다. 이력서 프로젝트 질문은 더 힘들었다. 이력서 기반 질문은 "내가 했던 내용 정리하면 되겠지"라고 가볍게 봤는데, 내가 개선했던 작업들에 대해 깊게 질문이 들어왔고 고려하지 않았던 부분이 나오자 말이 흐트러졌다.

결론적으로 2차 면접에서 탈락했다. 3차를 앞두고 2차에서 떨어진 거라 정말 기분이 안 좋았지만, 또 이 면접 경험에서 내가 어떤 방향으로 나아가야할 지 많이 배울 수 있는 시간이었다.

5. 마무리

처음으로 제대로 된 기술 면접을 경험하며 내 수준을 객관적으로 돌아볼 수 있는 시간이었다. 이력서를 다시 쓰는 방향성을 잡게 된 계기가 됐고, CS를 각 잡고 다시 공부하지 않아도 되겠다는 자신감도 생겼다. 채널톡 블로그에서 읽은 내용이 이후 프로젝트 고도화로 이어진 것도 나름 수확이었다. 결국 실패했지만, 지금까지 본 면접 중 가장 많이 배운 전형이었다. 좋은 면접은 내 부족한 점을 보여주고 방향을 잡아주는 나침반 같다는 생각이 들었다.

진행한 프로젝트 메인 페이지 조회 구조 및 성능 개선하기

chan_2 — Fri, 20 Feb 2026 01:44:32 +0900

2024년부터 진행해온 축제 SaaS 서비스 프로젝트는 고객(축제 운영팀)마다 하나의 축제를 등록하고, 각 축제의 메인페이지를 위젯 단위로 구성해 축제 분위기에 맞는 사이트를 만들어주는 서비스입니다.

2024년 상반기, 메트릭 모니터링을 통해 `/home/{festivalId}` API의 응답 시간이 다른 API들보다 눈에 띄게 높다는 것을 발견했습니다. 이를 단일 테이블 상속 전략으로 개선했었는데, 이 글에서는 그 당시 왜 그런 선택을 했고, 그 선택이 어떤 새로운 문제를 낳았으며, 이를 어떻게 해결했는지를 다룰려고 합니다. 나아가 2025년 한 해 동안의 Google Analytics 통계를 기반으로 메인페이지 조회 성능을 한 단계 더 개선한 과정까지 함께 정리해 보겠습니다.

1. 단일 테이블 상속 전략 도입 배경

초기에는 메인페이지에 보여지는 여러 위젯들을 타입별로 테이블을 분리하고 있었다. 문제는 메인페이지 API였다. 메인페이지를 한 번 조회하면 Festival과 함께 5종류 위젯을 모두 가져와야 하는데, 각 위젯 테이블이 Festival과 일대다 관계로 연결되어 있으니 N+1 문제가 발생했다.

자연스럽게 Fetch JOIN으로 해결하려 했지만, 여기서 또 다른 벽에 부딪혔다. 여러 일대다 관계를 동시에 Fetch JOIN하면 카테시안 곱(Cartesian Product) 이 발생한다. Hibernate는 이를 `MultipleBagFetchException`으로 차단하고, 설령 `Set`으로 우회하더라도 결과 행이 폭발적으로 늘어나 성능이 오히려 악화된다.

결국 다른 접근이 필요했고, 5개 타입이 공통 필드(`name`, `url`, `festival_id`)를 공유한다는 점에 착안하여 단일 테이블 상속 전략을 도입했다. 하나의 테이블로 합치면 Fetch JOIN 하나로 모든 위젯을 가져올 수 있기 때문이다.

Widget 통합 및 메인페이지 조회로직 개선 by HeeChanN · Pull Request #101 · festimap-org/waba-backend

#️⃣연관된 이슈 ex) #100 작업 내용 문제 상황 2024년 10월 경희대 대학 축제에서는 축제 기간에 메인 페이지 접속 시 페이지 로딩이 느려지는 것을 경험했으며, 이를 모니터링하기위해 prometheus

github.com

돌이켜 보면, 당시에는 단일 테이블 상속 전략의 장단점을 충분히 따져보지 않았다. 솔직히 그때는 개발 경험이 부족했고, 문제를 바라보는 시야가 단편적이었다. "N+1이 발생한다 → 테이블을 합치면 된다 → STI가 있네 → 적용하자" 식의 일직선적인 사고 흐름이었다. 당장 눈앞의 문제(N+1)가 해결되니까 또 테스트를 해봤을 때 성능적으로도 개선됬으니까 그걸로 충분하다고 생각했다.

하지만 역시, 초기에는 잘 동작했지만, 서비스가 새로운 축제에 도입되며 단일 테이블 상속 전략의 구조적 한계가 하나둘 드러나기 시작했다.

2. 단일 테이블 상속 전략의 문제점

2-1. NULL 문제

첫 번째 문제는 도입하면서부터 알 수 있는 NULL 컬럼 폭발문제이다. 하나의 테이블에 여러 type의 위젯이 존재하기 때문에 각 위젯마다 필요한 컬럼이 존재했고 그에따라 아래와 같이 null을 갖게 되는 경우가 발생했다.

모든 행에서 자기 타입과 무관한 컬럼들이 NULL로 채워진다. 위젯 타입이 5개뿐인 지금도 이 정도인데, 타입이 늘어날수록 NULL 비율은 가속도로 증가한다는 문제가 존재했다.

2-2. 스키마 경직성

두 번째 문제는 스키마 경직성이다. 이 문제는 프로젝트가 추구하는 SaaS 서비스에서 가장 치명적인 문제이다. 축제마다 필요한 위젯이 다르다. 어떤 축제는 상단 위젯이 필요하고, 어떤 축제는 중간 배너가 필요할 수 있다. 단일 테이블 상속 전략에서 새 위젯 타입을 추가하면 어떻게 될까?

-- 타이머 위젯 추가
ALTER TABLE base_widget ADD COLUMN timer_duration INT;
ALTER TABLE base_widget ADD COLUMN timer_label VARCHAR(255);

-- 투표 위젯 추가
ALTER TABLE base_widget ADD COLUMN vote_options TEXT;
ALTER TABLE base_widget ADD COLUMN vote_deadline DATETIME;

새 타입 하나를 추가할 때마다 `ALTER TABLE`이 필요하다. 운영 중인 테이블에 DDL을 실행하는 것 자체가 리스크이며, 추가된 컬럼은 기존의 모든 위젯 행에 NULL로 들어간다. 위젯 타입이 10개, 20개로 늘어난다면? 테이블은 거대한 NULL 매트릭스가 된다.

2-3. 도메인 제약 불가능

타입별로 필수인 컬럼이 달라도 DB 레벨에서 NOT NULL 제약을 걸 수 없다.

-- SquareWidget은 description이 필수지만...
ALTER TABLE base_widget ALTER COLUMN description SET NOT NULL;
-- → MainWidget도 description을 쓰지만, UpWidget/DownWidget은 쓰지 않으므로 불가!

결국 모든 제약은 애플리케이션 레벨로 올라가야 한다. DB가 데이터 무결성을 보장해주지 못하면 어떻게 될까?

서비스 코드 곳곳에 유효성 검증 로직이 흩어진다. SquareWidget을 생성하는 Service에서 `description`이 비어 있는지 직접 검사해야 하고, MainWidget을 생성하는 Service에서도 또 검사해야 한다. 타입이 늘어날수록 "이 타입에서 이 필드는 필수인가?"를 코드로 일일이 관리해야 하며, 이 검증을 누락하면 NULL이 그대로 저장되어도 DB는 아무런 경고를 주지 않는다. 버그가 발생해도 데이터가 조용히 저장되어 버리기 때문에, 문제를 인지하는 시점은 사용자가 깨진 화면을 보고 나서야 비로소다. DB가 마지막 방어선 역할을 하지 못하는 구조인 셈이다.

3. 메인 페이지 조회 구조 변경 : JSON 컬럼 도입

3-1. 왜 JSON 컬럼이 SaaS 메인페이지에 적합한가?

단일 테이블 상속 전략의 문제를 인식한 뒤 여러 대안을 검토했다. 결론은 MySQL의 JSON 컬럼이었다. 그중 가장 큰 이유는 스키마 유연성이었다.

축제 SaaS 서비스에서는 고객별로 필요한 위젯이 다르다. JSON 컬럼을 사용하면 타입별 속성을 스키마 변경 없이 자유롭게 정의할 수 있다는 점이 가장 큰 이유였다. 메인페이지를 구성할 때 DDL 변경이 없어지고, 코드 배포만으로 새 타입을 추가할 수 있다.

두 번째는 위젯 속성이 조회 위주라는 점이었다. 위젯의 타입별 속성(`image`, `description`, `periodStart` 등)은 생성 시 저장하고, 이후에는 읽기만 한다. 복잡한 업데이트 쿼리가 필요 없으므로 JSON의 쓰기 성능 단점이 거의 드러나지 않는다.

마지막으로 JSON 컬럼의 단점이 드러나지 않는 구조라는 점이었다. 타입별 속성으로 복잡한 쿼리(`JOIN`, `GROUP BY`, 정렬 등)가 필요하면 `JSON_EXTRACT`를 사용해야 하는데, 성능이 일반 컬럼보다 떨어진다. 하지만 현재 동작에서 위젯 속성으로 복잡한 WHERE/JOIN이 불필요했다. 위젯 조회는 `festival_id`와 `widget_type`으로 필터링하면 끝이다. 타입별 속성을 기준으로 `JOIN`하거나 `GROUP BY`할 일이 없으므로, JSON의 쿼리 약점이 부각되지 않는다.

물론 데이터 무결성 검증을 DB가 아닌 애플리케이션에서 해야 한다는 것은 여전히 남겨진 문제다. 이 부분은 Properties 클래스의 생성자에서 필수 필드 검증을 수행하고, 잘못된 값이 들어오면 객체 생성 자체를 차단하는 방식으로 보완할 수 있다. DB 제약만큼 강력하지는 않지만, JSON의 타입별 속성이 반드시 Properties 객체를 거쳐야만 저장되는 구조이므로 검증 누락 가능성을 최소화할 수 있다.

이러한 단점에도 불구하고, 메인페이지 구성 정보를 축제별로 유연하게 관리하는 용도라면 스키마 유연성의 이점이 훨씬 크다고 판단하여 JSON 컬럼 도입을 결정하게 되었다.

3-2. 왜 NoSQL(MongoDB)이 아닌 JSON 컬럼인가?

"스키마 유연성이 필요하다면 MongoDB를 쓰는 게 낫지 않나?" 라는 질문이 나올 수 있다. 처음에는 당연히 NoSQL 데이터베이스를 도입해야하나 고민했지만, 아래와 같은 이유로 선택을 하지 않았다.

또한 WidgetItem과의 FK 관계도 한목 하였다. 위젯은 하위에 `WidgetItem`이라는 자식 엔티티를 갖고 있고, 이 관계는 FK로 참조 무결성을 보장한다. MongoDB로 위젯을 옮기면 이 FK가 깨지고, 두 데이터스토어 사이의 정합성을 직접 관리해야 한다. 분산 트랜잭션이라는 거대한 복잡도를 떠안을 이유가 없었다.

따라서 결론은 유연해야 할 부분(타입별 속성)만 JSON으로 빼고, 나머지(공통 필드, 관계)는 RDB의 강점을 그대로 유지하는 것이 이 상황에서 가장 합리적인 선택이었다고 생각한다.

4. 캐시 도입 배경 : GA 통계가 보여준 것

2025년 PV

JSON 컬럼 도입으로 스키마 유연성 문제는 해결했다. 새 위젯 타입을 추가할 때 더 이상 운영 DB를 건드릴 필요가 없고, NULL 컬럼 폭발도 사라졌다. 그렇다면 메인페이지 API 성능은 어떨까?

2025년 한 해 동안의 Google Analytics 통계를 확인해보니, 총 51만 PV 중 메인 홈(`/`)이 31.7만(62%)을 차지하고 있었다. 메인페이지는 모든 사용자가 처음 접근하는 페이지이므로, 응답 속도가 곧 사용자 경험이다.

메인 홈 데이터의 특성을 정리하면 이렇다:

극단적인 Read-Heavy: 관리자가 위젯을 수정할 때만 데이터가 변경된다. 하루 수 회 수준 (거의 없음)
스파이크 트래픽: 축제 기간에 동일 데이터에 DB 쿼리 수천 건/분이 반복된다.
이미 쿼리 최적화 완료: JSON 마이그레이션 + JOIN FETCH + 복합 인덱스로 단건 쿼리 자체는 최적화된 상태. 병목은 쿼리 자체가 아니라 쿼리 횟수다.

극단적인 Read:Write 비율 + 짧은 지연 허용(관리자 수정 후 수 초 내 반영이면 충분) → 캐시 도입의 최적 조건

메인 홈 데이터의 경우 변경 빈도가 낮아 데이터 최신성 부담이 거의 없고, 수 초 수준의 지연만 허용되면 되므로 캐시 무효화 전략도 단순하게 가져갈 수 있다고 생각했다.

초기 인프라 구조 (No Redis)

현재 구조는 위와 같다. 클라이언트의 모든 요청이 ALB를 거쳐 EC2 인스턴스에 도달하고, 인스턴스는 매 요청마다 MySQL에 직접 쿼리를 날린다.

5. 첫 번째 시도 : 글로벌 캐시 도입 (Redis, ElastiCache Valkey)

Festimap은 다중 인스턴스 구조로 운영되고 있다. ALB 뒤에 Auto Scaling 그룹이 구성되어 있어, 축제 기간에 트래픽이 몰리면 인스턴스가 자동으로 늘어난다.

이 때, 각 인스턴스가 독립적으로 로컬 캐시를 들고 있으면, 인스턴스 간 데이터 정합성을 보장할 수 없다. 인스턴스 A에서 관리자가 위젯을 수정해도 인스턴스 B의 캐시에는 여전히 이전 데이터가 남아 있기 때문이다. 따라서 첫 번째 단계로는 모든 인스턴스가

하나의 외부 캐시를 공유하는 글로벌 캐시 방식을 선택했다.

5-1. Self-hosted vs AWS Managed Service

Redis를 직접 EC2에 올려 운영하는 방법도 있지만, 현재 프로젝트에서 Redis 서버의 모니터링, 보안 패치, 장애 대응까지 직접 관리하는 것은 현실적이지 않았다. 따라서, AWS ElastiCache를 선택하면 이런 관리 오버헤드를 제거하고 개발에 집중할 수 있다고 판단했다. 또한 직접 Redis 환경을 구축했을 때 운영 비용은 월 $12의 ElastiCache 요금보다 훨씬 크다고 생각했다.

5-2. Redis vs Valkey

2024년 3월, Redis Labs가 라이선스를 SSPL에서 RSAL로 변경하면서 클라우드 벤더들의 Redis 호스팅이 제한되었다. 이에 AWS는 Redis의 오픈소스 포크인 Valkey를 ElastiCache의 기본 엔진으로 권장하기 시작했다.

동일 스펙에서 Valkey가 Redis보다 약 20% 저렴하다. 가장 저렴한 조합은 Graviton 기반 `cache.t4g.micro` + Valkey로,

월 $14.02다. 여기에 1년 예약 인스턴스를 적용하면 시간당 $0.013까지 내려가 월 ~$9.5 수준이 된다. 참고로 AWS 프리 티어를 활용하면 `cache.t3.micro` 기준 첫 12개월은 무료다 (말도 안돼~ 프리티어 최고!).

최종적으로 `cache.t3.micro`를 선택해 시작했다. 현재로서는 프리티어 사양으로도 충분히 동작한다고 생각하였다.

5-3. 적용방식

Spring의 `@Cacheable`을 활용하면 기존 서비스 코드를 거의 건드리지 않고 캐시를 적용할 수 있다.

@Cacheable(value = "home", key = "#festivalId")
public HomeDto getMainPage(Long festivalId) {
    // Festival + Widget JOIN FETCH + 공지 + 실종자 조회
}

캐시 무효화는 도메인 이벤트 기반으로 설계했다. 위젯, 공지, 실종자 서비스의 mutation 메서드에서 `HomeCacheEvictEvent`를 발행하고, `@TransactionalEventListener(phase = AFTER_COMMIT)`으로 트랜잭션 커밋 후에만 evict를 수행한다. 트랜잭션이 롤백되면 캐시를 무효화할 필요가 없기 때문이다.

TTL은 5분으로 설정했다. 이 값은 다음 두 가지 기준에서 도출했다.

Cache Validity - Database Caching Strategies Using Redis

This whitepaper is for historical reference only. Some content might be outdated and some links might not be available. Cache Validity You can control the freshness of your cached data by applying a time to live (TTL) or expiration to your cached keys. Aft

docs.aws.amazon.com

Cache optimization: Strategies to cut latency and cloud cost

A practical guide to cache optimization: TTLs, eviction, cache-aside, write-through, edge caching, and AI/semantic caching to cut latency and cost.

redis.io

TTL을 결정할 때 두 가지 질문을 던지라고 권장한다: 데이터가 얼마나 자주 변하는가, 그리고 오래된 데이터를 반환했을 때의 위험은 무엇인가. Redis 공식 블로그에서도 데이터 변경 빈도에 따라 TTL 범위를 제시하는데, 거의 변하지 않는 데이터(참조 데이터, 설정값 등)는 수 시간~수 일, 가끔 변하는 데이터(사용자 프로필, API 응답)는 5~60분을 권장한다.

메인홈 데이터의 변경 빈도는 하루 수 회 수준이다. 관리자가 데이터를 수정하면 도메인 이벤트가 즉시 캐시를 무효화하므로, TTL은 이벤트가 누락되었을 때를 대비한 안전망 역할이다. Redis 공식 블로그의 기준에서 가끔 변하는 데이터에 해당하는 5~60분 범위의 상한인 TTL 5분으로 설정했다. 대부분의 갱신은 도메인 이벤트가 처리하고, TTL은 혹시 모를 상황에서 최대 5분 안에 자동 만료되는 보험이다.

글로벌 캐시 구조

5-4. 글로벌 캐시의 구조적 한계

k6를 사용해 같은 VPC 내 EC2 Spot에서 1,000 VU 부하 테스트를 수행했다(ramping-vus, 0 → 200 → 1,000 → 0, 약 5.5분).

글로벌 캐시 도입 효과

Redis 캐시 도입만으로 p95가 434ms로 떨어졌다. Throughput도 2배 이상 증가했다. DB 직접 쿼리 대비 확실한 개선이라고 볼 수 있다.

기존 인프라 테스트

글로벌 캐시 도입

하지만 CloudWatch 메트릭을 확인해보니, 이 구조가 갖는 한계도 함께 드러났다.

CloudWatch 로그

캐시 히트여도 매 요청마다 Redis로 네트워크 왕복이 발생하고, 응답 JSON을 매번 역직렬화해야 한다. 인스턴스가 늘어나면 그만큼 네트워크 트래픽이 증가해 글로벌 캐시 자체가 병목으로 전환될 수 있는 수치였다.

6. Caffeine 로컬 캐시 + Redis Pub/Sub

6-1. 채널톡 기술 블로그에서 얻은 인사이트

글로벌 캐시의 한계를 확인한 시점에서, 채널 톡의 로컬 캐시 도입기https://channel.io/ko/team/blog/articles/tech-distributed-cache-1-67a392c5를 읽게 되었다.

이 블로그의 핵심 아이디어는 Redis를 캐시 저장소가 아닌 무효화 메시징 채널로만 사용하는 것이었다. 읽기 경로에서 네트워크

비용을 완전히 제거하고, 캐시 무효화 신호만 Redis Pub/Sub으로 전파하는 구조다.

당연하게도 이 구조가 유리하다. 글로벌 캐시는 캐시 히트여도 네트워크 왕복 + JSON 역직렬화가 매 요청마다 발생한다.

반면 로컬 캐시는 같은 JVM 힙에 객체 참조로 들고 있으므로 조회 비용이 사실상 0이다. 대신 다중 인스턴스 환경에서 캐시 정합성이라는 새로운 문제가 생기는데, 이것을 Redis Pub/Sub이 해결한다. 읽기는 네트워크를 타지 않고, 쓰기(무효화)만 네트워크를 타는 구조로 메인홈처럼 읽기가 압도적으로 많은 워크로드에서는 이상적인 분리라고 생각이 들었다.

6-2. 설계 과정에서 고민한 것들

채널톡 블로그에서 배운 점과 Festimap 상황에 맞게 주의해서 결정한 것들이 있다.

키 무효화 vs 키+값 동기화 : 무효화 시 키만 날리고, 다음 조회에서 DB 로드하는 방식을 선택했다. 새 값을 함께 전파하면 직렬화 비용이 추가되고, 두 인스턴스가 거의 동시에 수정하면 race condition이 발생할 수 있다. 키만 무효화하면 항상 DB에서 최신 데이터를 로드하므로 정합성이 보장된다. 관리자 변경이 하루 수 회 수준이니 이 DB 히트 비용은 무시할 수 있다.
메시지 유실 대비 두 가지 안전망 : Redis Pub/Sub은 At-most-once(최대 한번) 전달이라 메시지가 유실될 수 있다. 이를 보완하기 위해 두 가지 안전망을 설계했다.
- Caffeine TTL 1분: 메시지가 유실되어도 최대 1분 후 자동 만료된다. 캐시 무효화를 포함한 부하 테스트에서 분당 12회 무효화를 수행해도 성능 차이가 거의 없었으므로 TTL을 짧게 잡아도 안전하다고 판단했다. 다만 5초 수준까지 줄이면 캐시 재생성이 너무 빈번해지므로, 메시지 유실 시에도 메인홈 데이터가 1분 정도 지연되는 것은 사용자 경험에 큰 영향이 없다는 점을 고려해 1분으로 설정했다.
- 재연결 시 전체 캐시 클리어: Redis 연결이 끊겼다가 복구되면, 끊긴 동안 놓친 메시지가 있을 수 있으므로 전체 캐시를 비운다.

Pub/Sub + Caffeine 캐시 구조

이 구조에서 변한 핵심 코드는 `DistributedCacheManager`다. Caffeine 캐시를 내부에 두고 다음과 같이 동작한다.

읽기 경로 (get)

Caffeine 히트 → 바로 반환
Caffeine 미스 → DB 조회 → Caffeine에 저장 → 반환
Redis Pub/Sub은 관여하지 않음

무효화 경로 (invalidate)

관리자가 데이터를 수정하면 도메인 이벤트 발생
로컬 Caffeine 무효화 + Redis Pub/Sub으로 다른 인스턴스에 무효화 신호 전파

7. 부하테스트 비교 : 최종 결과

테스트 환경

도구: k6 (ramping-vus, 0 → 200 → 1,000 → 0, 약 5.5분)
실행 위치: 같은 VPC 내 EC2 Spot
대상: ALB → EC2 2대 → MySQL + ElastiCache Valkey

Read-Only 테스트

Caffeine + Pub/Sub 도입

Read/Write : 캐시 무효화 발생 테스트

1,000 VU 읽기 트래픽과 분당 12회 관리자 캐시 무효화를 동시에 수행했다.

캐시 무효화 테스트

eviction 횟수가 거의 동일한 조건에서, Throughput은 29% 증가하고 p95는 39% 감소했다. 무효화가 발생해도 성능 영향이 미미한 이유는, eviction 직후 첫 요청만 DB로 가고 나머지는 곧바로 Caffeine 히트를 이어가기 때문이다.

CloudWatch Valkey 메트릭 비교 (캐시 무효화 테스트)

글로벌 캐시 메트릭

Caffeine + Pub/Sub

8. 마무리

이 개선 작업을 진행하면서 두 가지 종류의 배움이 있었다.

JSON 컬럼 도입은 직접 부딪혀야 알 수 있는 배움이었다. 단일 테이블 상속 전략의 한계를 글로만 읽었을 때는 와닿지 않았다. 실제로 NULL 컬럼이 늘어나는 것을 보고, 새 위젯 타입을 추가할 때마다 ALTER TABLE을 써야 하는 상황을 겪고 나서야 이 구조는 SaaS에 맞지 않는다는 판단이 섰다.

반면 Caffeine + Pub/Sub 도입은 남의 경험에서 배운 것이었다. 글로벌 캐시의 CloudWatch 지표를 보며 "읽기 경로에서 네트워크를 제거해야 한다"는 문제 인식까지는 도달했지만, 구체적으로 어떻게 해결할지는 채널톡 기술 블로그를 읽고 나서야 그림이 그려졌다. Redis를 캐시 저장소가 아닌 무효화 채널로만 쓴다는 발상, 키 무효화 vs 값 동기화의 트레이드오프, TTL과 Pub/Sub의 역할 분담같은 설계 판단들을 처음부터 혼자 도출하기는 어려웠을 것이다.

직접 부딪혀야 배우는 것과, 남의 경험에서 배울 수 있는 것. 둘 다 필요하다. 기술 블로그를 꾸준히 읽는 습관이 실제 프로젝트의 의사결정 품질에 영향을 준다는 것을 경험한 시간이었다.

프로젝트 티켓 예매 시스템 개선하기

chan_2 — Thu, 19 Feb 2026 01:13:23 +0900

축제 SaaS 서비스 프로젝트는 고객마다 하나의 축제를 등록하고, 각 축제의 메인페이지를 위젯 단위로 구성해 축제 분위기에 맞는 사이트를 만들어주는 서비스입니다. 그러던 중 고객사로부터 티켓 예매 기능 요청이 들어왔고, 빠른 일정 안에 비관적 락 기반의 예매 시스템을 구현하여 실제 목포 W쇼 티켓팅에 도입했습니다.

다행히 초과 발급은 발생하지 않았지만, 운영 과정에서 응답 지연과 커넥션 풀 고갈 문제가 드러났습니다. 이 글에서는 비관적 락을 선택한 배경부터, 기존 코드의 문제 분석, 그리고 두 번의 걸친 개선 과정을 정리해 보겠습니다.

1. 비관적 락 도입 배경

축제 티켓 예매는 평소에는 트래픽이 거의 없다가, 오픈 시점에 수백 명이 동시에 같은 잔여 티켓을 두고 경쟁하는 구조다. 동시성 제어 없이는 잔여 수량이 0인데도 예매가 성공하는 초과 판매가 발생할 수 있으므로, 락을 통한 동시성 제어가 필수적이었다.

JPA 환경에서 DB 레벨의 동시성 제어 방법은 크게 두 가지다. `@Version`을 사용하는 낙관적 락과, `@Lock(PESSIMISTIC_WRITE)`를 사용하는 비관적 락(Pessimistic Lock). 이 두 가지를 비교했다.

티켓 예매는 오픈 시점에 충돌이 거의 100% 발생하는 시나리오다. 낙관적 락을 적용하면 대부분의 요청이 버전 충돌로 실패하고, 클라이언트가 재시도해야 한다. 재시도가 몰리면 충돌은 더 심해지고, 사용자 경험은 최악이 된다고 생각했다.

반면 비관적 락은 DB 레벨에서 순서를 보장하므로, 한 번 대기하면 반드시 처리된다는 확실성이 있다. 빠른 일정 안에서 정합성을 확실히 보장하는 선택이 필요했기 때문에 비관적 락을 채택했다.

실제로 목포 W쇼 티켓팅에서 초과 판매는 발생하지 않았고, 비관적 락의 정합성은 검증되었다. 하지만 운영 중 다음 두 가지 문제가 드러났다.

응답 지연: 락 경합이 심해지면서 사용자 응답 시간이 수 초~수십 초로 늘어났다. 락을 잡은 채로 불필요한 쿼리를 실행하고 있었기 때문이다.
커넥션 풀 고갈: 트랜잭션 내부에서 SMS 외부 API를 호출하고 있었고, SMS 응답을 기다리는 동안 DB 커넥션이 묶여 전체 서비스가 느려졌다.

돌이켜보면 이 문제들은 처음 코드를 작성할 때 트랜잭션 경계와 락 범위에 대한 이해가 부족해서 발생한 것이었다. 이렇게라도 실제 운영을 통해 문제점을 직접 파악하고 개선할 수 있었다는 점에서 좋은 경험이었다고 생각한다.

이 문제들의 원인을 실제 코드 레벨에서 분석해 보자.

2. 기존 코드의 문제 분석

먼저 간단하게 이 예매 시스템에 대해 설명해보면, SMS 인증 후 게스트 JWT 토큰을 발급하는 방식으로 동작한다. 토큰에는 유효기간이 존재하는데, 미리 발급받은 토큰으로 오픈 전에 API 요청을 보내는 것을 막기 위해 예매 시점에 인증 상태를 다시 검증해야 했다. 그래서 당시에는 검증을 최대한 철저하게 하는 방향으로 코드를 작성했다.

문제 1: 불필요하게 긴 락 홀딩 시간

기존 `LockBasedTicketService.reserve()` 메서드를 보자.

// BEFORE: LockBasedTicketService.java
@Override
@Transactional
public void reserve(TicketRequest request) {
    validateVerification(request);                              // ① DB 조회 (인증 확인)
    Event event = loadEventWithLockOrThrow(request.getEventId()); // ② 락 획득 (FOR UPDATE)
    event.validateIsOpenAt();                                    // ③ 오픈 시간 검증
    isExistTicketBy(request.getEventId(), request.getPhoneNumber()); // ④ 중복 예매 조회
    event.decreaseRemainingTickets(request.getTicketCount());    // ⑤ 재고 차감
    ticketRepository.save(Ticket.of(request, event));            // ⑥ 티켓 저장
}

의도 자체는 틀리지 않았지만, 문제는 검증과 락의 순서에 있었다. ②에서 락을 획득한 뒤, ④에서 중복 예매 여부를 조회하고 있다. `isExistTicketBy()`는 단순 읽기 쿼리임에도 락을 잡은 채로 실행되므로, 다른 모든 스레드가 이 쿼리가 끝날 때까지 대기해야 한다.

트래픽이 폭주하는 시점에 이 차이는 크게 벌어진다. 100명이 동시에 예매를 시도하면, 99명은 한 명의 검증 쿼리가 끝나기를 기다려야 하고, 이 대기 시간이 누적되어 전체 처리량(throughput)이 급격히 떨어진다.

문제 2: 트랜잭션 내부에서 SMS 발송

@Transactional
public void sendVerificationCode(VerificationReqDto verificationReqDto) {
    validateEventIsActive(verificationReqDto.getEventId());

    Verification verification = verificationRepository.findByPhoneNumber(...)
            .map(existing -> {
                existing.updateVerificationCode();
                return existing;
            })
            .orElseGet(() -> verificationRepository.save(Verification.from(verificationReqDto)));

    smsClient.send(SmsSendRequest.from(verification)); // 외부 API 호출이 트랜잭션 안에!
}

이 코드에는 두 가지 심각한 문제가 있다.

첫째, 커넥션 풀 고갈 위험

`@Transactional` 메서드가 시작되면 DB 커넥션을 하나 점유한다. SMS 발송은 외부 네트워크 I/O로, 통상 1~5초가 걸린다. 이 시간 동안 DB 커넥션이 묶여 있으므로, 동시 요청이 쏟아지면 커넥션 풀이 빠르게 고갈된다.

[요청 1] ── DB 저장(10ms) ── SMS 발송(3000ms) ── 커밋 ──→  총 3010ms 커넥션 점유
[요청 2] ── DB 저장(10ms) ── SMS 발송(2500ms) ── 커밋 ──→  총 2510ms 커넥션 점유
[요청 3] ── 커넥션 대기... ─────────────────────────→  HikariCP timeout!

둘째, 불필요한 롤백

SMS 발송이 실패하면 `smsClient.send()`에서 예외가 발생하고, `@Transactional`에 의해 인증코드 저장까지 롤백된다. 하지만 인증코드는 이미 생성되었으므로, SMS만 재시도하면 되는 상황이다. DB까지 롤백하면 사용자는 처음부터 다시 요청해야 한다.

문제 3: DB 비관적 락의 커넥션 풀 고갈 위험

모든 동시성 제어가 `@Lock(PESSIMISTIC_WRITE)`, 즉 `SELECT ... FOR UPDATE` 하나에 의존하고 있다.

// EventRepository.java
@Lock(LockModeType.PESSIMISTIC_WRITE)
@Query("SELECT e FROM Event e WHERE e.id = :id")
Optional<Event> findByIdWithLock(@Param("id") Long id);

DB 비관적 락은 정합성을 확실히 보장하지만, 구조적으로 락 대기가 곧 커넥션 점유라는 문제가 다. `SELECT FOR UPDATE`는 DB 커넥션을 잡은 상태에서 락 획득을 대기한다. 즉, 100명이 동시에 예매를 시도하면 100개의 DB 커넥션이 동시에 점유되고, 그 중 99개는 락이 풀릴 때까지 아무 일도 하지 않으면서 커넥션만 잡고 있는 셈이다.

[스레드 1] ── 커넥션 획득 ── FOR UPDATE (락 획득) ── 처리 ── 커밋 ── 커넥션 반환
[스레드 2] ── 커넥션 획득 ── FOR UPDATE (대기중...) ─────────────── 커넥션 점유 중
[스레드 3] ── 커넥션 획득 ── FOR UPDATE (대기중...) ─────────────── 커넥션 점유 중
   ...
[스레드 N] ── 커넥션 획득 실패 → HikariCP timeout!

HikariCP의 기본 커넥션 풀 크기는 10개다. 동시 요청이 10개를 넘는 순간 나머지 요청은 커넥션 자체를 획득하지 못해 락 경합과는 별개로 타임아웃이 발생한다. 이전까지는 쿼리 타임아웃으로 커넥션을 반납하도록 코드를 작성했지만, 트래픽이 더 증가하면 근본적인 해결이 필요하다.

3. 첫 번째 개선 : 트랜잭션 및 동시성 최적화

기존 코드를 구조적으로 변경하지 않으면서 동시성과 트랜잭션 문제를 해결해보려 했다.

개선 1: 락 홀딩 시간 최소화

// AFTER: LockBasedTicketService.java
@Override
@Transactional
public void reserve(TicketRequest request) {
    // ── 검증 구간 (락 없이 수행) ──
    validateVerification(request);                              // ① 인증 확인
    isExistTicketBy(request.getEventId(), request.getPhoneNumber()); // ② 중복 예매 확인

    // ── 임계 구간 (락 획득 후 변경) ──
    Event event = loadEventWithLockOrThrow(request.getEventId()); // ③ 락 획득
    event.validateIsOpenAt();                                    // ④ 오픈 시간 (빠른 체크)
    event.decreaseRemainingTickets(request.getTicketCount());    // ⑤ 재고 차감
    ticketRepository.save(Ticket.of(request, event));            // ⑥ 저장
}

변경한 점 : `isExistTicketBy()`를 락 획득 전(②)으로 이동했다.

이렇게 결정하게 된 근거는 다음과 같다.

중복 예매 확인은 읽기 작업이다. 락 밖에서 사전 필터링하면, 이미 예매한 사용자는 락을 잡지도 않고 빠르게 탈락시킬 수 있다.
단, 중복 체크를 락 밖으로 빼면 동시 요청 시 두 건 모두 통과할 수 있으므로, Ticket 테이블에 `(event_id, phone_number)` 유니크 제약조건을 추가하여 DB 레벨에서 중복을 최종 방어했다.
검증을 락 밖으로 빼면 락 홀딩 시간이 검증 쿼리 시간만큼 줄어든다. 검증 쿼리가 50ms라면 100건 기준 총 5초의 대기 시간이 절약된다.

BEFORE: ──[락 획득]──[검증 쿼리 50ms]──[재고 차감 5ms]──[저장 10ms]──[락 해제]──
          └──────────── 락 홀딩: 65ms ────────────────┘

AFTER:  ──[검증 쿼리 50ms]──[락 획득]──[재고 차감 5ms]──[저장 10ms]──[락 해제]──
                              └─────── 락 홀딩: 15ms ──────────┘

개선 2: 트랜잭션 경계 재설계

앞서 문제 분석에서 살펴봤듯이, 기존 `sendVerificationCode()`는 `@Transactional` 안에서 SMS 외부 API를 호출하고 있었다. SMS 응답을 기다리는 수 초 동안 DB 커넥션이 묶여 커넥션 풀이 고갈되고, SMS 실패 시 인증코드까지 롤백되는 문제가 있었다. 해결 방향은 단순하다. DB 작업과 외부 I/O를 분리하면 된다.

초기에는 `private` 메서드에 `@Transactional`을 붙여서 DB 저장과 SMS 발송을 분리하는 방식을 시도했다. 하지만 여기에는 근본적인 문제가 있다. Spring AOP는 프록시 기반으로 동작하기 때문에, `private` 메서드에 `@Transactional`을 붙여도 실제로는 트랜잭션이 적용되지 않는다. 같은 클래스 내부에서 `this.saveVerificationCode()`를 호출하면 프록시를 거치지 않고 직접 호출되기 때문이다.

이 문제를 근본적으로 해결하기 위해 Spring의 `@TransactionalEventListener`를 도입했다. 트랜잭션이 커밋된 후에 SMS가 발송되는 것을 프레임워크 레벨에서 보장한다.

// 이벤트 클래스
@Getter
@RequiredArgsConstructor
public class VerificationCodeSavedEvent {
    private final String phoneNumber;
    private final String code;
}

// AFTER: VerificationService.java
@Transactional
public void sendVerificationCode(VerificationReqDto verificationReqDto) {
    validateEventIsActive(verificationReqDto.getEventId());

    Verification verification = verificationRepository.findByPhoneNumber(verificationReqDto.getPhoneNumber())
            .map(existing -> {
                existing.updateVerificationCode();
                return existing;
            })
            .orElseGet(() -> verificationRepository.save(Verification.from(verificationReqDto)));

    eventPublisher.publishEvent(
            new VerificationCodeSavedEvent(verification.getPhoneNumber(), verification.getCode()));
}

// 이벤트 리스너 — 커밋 후 SMS 발송
@Component
@RequiredArgsConstructor
public class VerificationEventListener {
    private final SmsClient smsClient;

    @TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
    public void handleVerificationCodeSaved(VerificationCodeSavedEvent event) {
        try {
            smsClient.send(SmsSendRequest.ofVerification(event.getPhoneNumber(), event.getCode()));
        } catch (Exception e) {
            log.error("SMS send failed for phone: {}", event.getPhoneNumber(), e);
        }
    }
}

이렇게 결정한 근거를 정리하면 다음과 같다.

핵심 원칙은 외부 I/O는 트랜잭션 커밋 후에, DB 작업만 트랜잭션 안에서다.

`@TransactionalEventListener(phase = AFTER_COMMIT)`를 사용하면 SMS 발송이 트랜잭션 커밋 이후에 실행되는 것을 Spring이 보장하므로, 호출 순서나 프록시 동작 여부에 의존하지 않는 안정적인 구조가 된다.

4. 두 번째 개선 : 비관적 락 -> 메모리 락으로 전환 및 락 추상화

첫 번째 개선이 기존 구조 안에서의 최적화였다면, 두 번째 개선은 락 메커니즘 자체를 전환하는 작업이다.

첫 번째 개선으로 락 홀딩 시간과 트랜잭션 경계 문제는 해결했지만, 앞서 문제 분석(섹션 3)에서 짚었던 근본적인 한계는 그대로 남아 있었다. DB 비관적 락은 `SELECT FOR UPDATE`로 락을 대기하는 동안 DB 커넥션을 점유하기 때문에, 동시 요청이 커넥션 풀 크기를 넘는 순간 커넥션 고갈이 발생한다. 락 홀딩 시간을 아무리 줄여도, 락 대기 = 커넥션 점유라는 구조 자체가 바뀌지 않는 한 트래픽 증가에 취약할 수밖에 없다.

처음에는 Redis 기반 분산 락(Redisson)을 도입하려고 했다. 분산 락은 DB 커넥션 없이 락을 대기할 수 있고, 멀티 인스턴스 환경에서도 동작하니 가장 확실한 해결책이었다. 하지만 한 발 물러서 생각해보니, 현재 Festimap의 티켓팅 서버는 단일 인스턴스로 운영되고 있었다. Redis를 도입하면 인프라 비용이 증가하고 운영 복잡도도 올라간다. 단일 인스턴스에서 분산 락은 명백한 오버 엔지니어링이었다.

그래서 방향을 전환했다. 지금 당장은 JVM의 `ReentrantLock`을 사용하는 메모리 락으로 커넥션 고갈 문제를 해결하고, 나중에 트래픽이 커져 서버를 스케일 아웃할 때를 대비해 락 메커니즘을 인터페이스로 추상화하기로 했다. 이렇게 하면 지금은 추가 인프라 없이 문제를 해결하면서도, 분산 락이 필요한 시점에 서비스 코드 변경 없이 구현체만 교체할 수 있다.

개선 : 락 추상화 with 전략 패턴

먼저 락의 획득과 해제를 `LockManager` 인터페이스로 정의했다. 서비스 계층은 이 인터페이스에만 의존하고, 실제 락 구현이 메모리인지 Redis인지는 알 필요가 없다.

// LockManager.java — 락 추상화 인터페이스
public interface LockManager {
    boolean tryLock(String key, long waitTime, long leaseTime, TimeUnit timeUnit)
            throws InterruptedException;
    void unlock(String key);
}

현재 사용하는 구현체는 JVM의 `ReentrantLock`을 활용한 `LocalLockManager`다. `ConcurrentHashMap`으로 key별 락을 관리하며, DB 커넥션 없이 메모리에서 락 대기가 이루어진다.

@Component
public class LocalLockManager implements LockManager {
    private final ConcurrentHashMap<String, ReentrantLock> locks = new ConcurrentHashMap<>();

    @Override
    public boolean tryLock(String key, long waitTime, long leaseTime, TimeUnit timeUnit)
            throws InterruptedException {
        ReentrantLock lock = locks.computeIfAbsent(key, k -> new ReentrantLock());
        boolean acquired = lock.tryLock(waitTime, timeUnit);
        if (acquired) log.debug("Lock acquired for key: {}", key);
        return acquired;
    }

    @Override
    public void unlock(String key) {
        ReentrantLock lock = locks.get(key);
        if (lock != null && lock.isHeldByCurrentThread()) {
            lock.unlock();
            // 대기 중인 스레드가 없으면 메모리에서 제거
            if (!lock.hasQueuedThreads()) {
                locks.remove(key);
            }
        }
    }
}

그리고 나중에 분산 환경으로 전환할 때를 대비해 `RedisLockManager` 스켈레톤도 준비해두었다.

// @Component
// @Profile("prod")
public class RedisLockManager implements LockManager {
    // TODO: Redisson 라이브러리 추가 후 구현
    //   RLock lock = redissonClient.getLock(key);
    //   return lock.tryLock(waitTime, leaseTime, timeUnit);
}

정리하면, `LockManager` 인터페이스를 두고 `LocalLockManager`(메모리 락)와 `RedisLockManager`(분산 락) 두 구현체를

전략 패턴으로 구성했다. 현재는 `LocalLockManager`가 활성화되어 있고, 분산 환경이 필요한 시점에 `@Profile`만 전환하면

서비스 코드 변경 없이 분산 락으로 교체할 수 있다.

6. 최종 정리 : 무엇이 바뀌었는가?

두 번의 개선에 걸쳐 세 가지 문제를 해결했다. 각 문제가 어떻게 변했는지 정리해보자.

문제 1: 불필요하게 긴 락 홀딩 시간 → 검증을 락 밖으로 이동
읽기 전용 검증(`isExistTicketBy`)을 락 획득 전으로 이동하여, 락은 재고 차감과 저장에만 사용하도록 변경했다. 동시
요청 시 대기열에서 기다리는 시간이 검증 쿼리 수만큼 줄어든다.
문제 2: 트랜잭션 내부 SMS 발송 → @TransactionalEventListener로 커밋 후 분리
DB 저장과 SMS 발송을 이벤트 기반으로 분리했다. `@TransactionalEventListener(phase = AFTER_COMMIT)`로
트랜잭션 커밋 후에 SMS가 발송되는 것을 Spring이 보장한다. DB 커넥션 점유 시간이 3~5초에서 10~50ms로
줄었고, SMS 실패 시에도 인증코드가 롤백되지 않는다.
문제 3: DB 비관적 락의 커넥션 고갈 → 메모리 락 전환 + 락 추상화
DB `SELECT FOR UPDATE`에서 JVM `ReentrantLock` 기반 메모리 락으로 전환했다. 락 대기가 DB 커넥션 없이 메모리에서 이루어지므로, 동시 요청이 아무리 많아도 커넥션 사용량은 락을 획득한 스레드 수로 제한된다. `LockManager`
인터페이스로 추상화하여 분산 환경 전환 시 구현체만 교체하면 된다.

7. 마무리 : 이 과정에서 배운 것

처음 티켓 예매 시스템을 구현할 때는 동시성 제어를 낙관적 락 vs 비관적 락 중 하나를 고르는 문제로만 바라봤다. 비관적 락을 선택하면 정합성이 보장되고, 그걸로 끝이라고 생각했다.

하지만 실제 운영을 겪으면서 시야가 넓어졌다. 락 자체보다 락을 잡고 있는 동안 무엇이 일어나는지가 더 중요했다. 락 안에서 불필요한 쿼리를 실행하면 대기 시간이 누적되고, 트랜잭션 안에서 외부 API를 호출하면 커넥션이 묶인다. 더 나아가 DB 비관적 락은

락을 기다리는 것 자체가 커넥션을 점유하기 때문에, 동시 요청이 커넥션 풀 크기를 넘는 순간 락 경합과는 별개로 시스템이 멈출 수 있다는 것도 알게 되었다.

결국 이번 개선 과정은 트랜잭션 경계, 락 범위, 커넥션 풀이라는 세 가지가 서로 밀접하게 연결되어 있다는 것을 체감한 경험이었다. 락의 종류를 고르는 것은 시작일 뿐이고, 그 락이 트랜잭션과 커넥션에 미치는 영향까지 함께 설계해야 한다.

여기서 한 발 더 나아가 생각해보면, 현재 구조는 메모리 락으로 커넥션 고갈을 해결했지만 여전히 동기 처리 방식이다. 100명이 동시에 요청하면 99명은 메모리에서 락이 풀릴 때까지 대기해야 한다. 만약 트래픽 규모가 지금보다 훨씬 커진다면, 메시지 큐를 도입해 예매 요청을 비동기로 처리하는 방식도 고려해볼 수 있을 것이다. 요청을 큐에 넣고 순차 처리하면 락 자체가 필요 없어지고, 사용자에게는 즉시 응답을 돌려줄 수 있다.

코딩 테스트에서 잘못 사용했던 Object.clone()

chan_2 — Tue, 4 Nov 2025 16:01:40 +0900

Java로 코딩테스트 문제를 풀던 중, 2차원 배열을 clone() 메서드로 복제한 후 수정하는 로직에서 원본 배열까지 함께 변경되는 문제를 경험했다. 당시에는 "clone이 얕은 복사를 수행하기 때문"이라는 표면적인 이해만으로 넘어갔고, 2차원 배열은 무조건 2중 반복문으로 복사해야겠다는 생각만 가진 채 문제를 마무리했다.

최근 『이펙티브 자바』와 『이것이 자바다』를 읽으며 배열의 메모리 구조와 clone()의 동작 원리를 깊이 있게 학습할 기회가 있었다. 힙 메모리에서 1차원 배열과 2차원 배열이 각각 어떻게 관리되는지, 그에 따라 clone()이 어떻게 동작하는지를 이해하면서 가변 객체, 불변 객체, 깊은 복사, 얕은 복사의 개념을 명확히 정리할 수 있었다.

이 글에서는 학습한 내용을 바탕으로 clone() 메서드의 동작 방식을 정리하고, 코딩테스트에서 clone을 안전하게 사용하는 방법을 명확히 정리하고자 한다.

1. 오버라이딩이 필요한 Object 메서드들

모든 Java 클래스에서 기본적으로 상속받는 클래스가 없다면 Object를 상속받는다. 이때, 커스텀 클래스의 경우 equals(), hashCode(), toString() 등과 같은 메서드가 정상적으로 동작하도록 보장하기 위해서는 오버라이딩이 필수다. toString()을 정의하지 않고 썼을 때 아래 사진과 같이 출력되는 경우를 본 적이 있을 것이다.

기본 toString()

따라서, 커스텀 클래스에서 만약 이런 Object가 제공하는 메서드를 사용할 상황이 있다면 정상적으로 동작하도록 규약에 맞게 재정의 해줘야 한다. clone 메서드도 이런 오버라이드를 해줘야 하는 메서드 중 하나이다.

2. Object.clone() 메서드

다른 메서드들과는 다르게 특이하게도 clone()의 경우는 오버라이딩해서 사용하려면 커스텀 클래스에 Clonable이라는 인터페이스를 implements 해야 한다. Cloneable 인터페이스를 살펴보면 아래와 같이 아무 메서드도 갖고 있지 않다.

실제로 Object의 clone()에 적혀있는 문서 내용에는 아래와 같이 적혀있다. 해석해 보면 Cloneable 인터페이스를 지원하지 않는다면 CloneNotSupportedException을 던진다고 나와있다.

실제 동작도 궁금해 아래와 같이 코드를 작성해 실험해 보았는데 문서대로 동작하는 것을 확인할 수 있었다.

public class Food {
    private String name;

    @Override
    protected Object clone() throws CloneNotSupportedException {
        return super.clone();
    }
}

// 실행 코드
Food food = new Food();
food.clone();

이펙티브 자바에서는 이런 clone()을 강제할 수 없고, 허술하게 기술된 프로토콜이라고 말한다.

`a. 강제할 수 없는 규약`

Cloneable는 메서드가 하나도 없는 마커 인터페이스다. 즉 clone() 메서드를 구현하도록 강제할 수 없다. 인터페이스를 사용하는 이유는 추상화, 다형성도 있지만 컴파일러 입장에서는 구현해야 할 메서드를 강제한다는 관점을 갖고 있다. 이런 관점에서 잘못되었다고 비판한다.

`b. 허술하게 기술된 프로토콜`

clone을 오버라이딩할 때 super.clone()과 new로 생성하는 것이 동작상 차이가 없기 때문에 컴파일 타임에 이를 감지할 수 없으며 런타임에 실제로 잘못 구현된 clone이 있으면 문제가 발생한다.

class Parent implements Cloneable {
    String name;
    
    @Override
    public Parent clone() {
        //super.clone()을 호출하지 않고 생성자로 반환
        Parent p = new Parent();
        p.name = this.name;
        return p;
    }
}

class Child extends Parent {
    int age;
    
    @Override
    public Child clone() {
        // super.clone()을 호출
        Child c = (Child) super.clone();
        c.age = this.age;
        return c;
    }
}

// 실행 코드
Child child = new Child();
child.name = "Alice";
child.age = 10;
Child cloned = child.clone();

이 코드를 실제로 실행시켜 보면 아래와 같이 동작한다.

왜 이런 문제가 발생하는 걸까?

핵심은 인스턴스로 메서드 호출 시 저장되는 this에 있었다. child.clone()을 호출하면 스택프레임에 this는 child를 참조한다.

이후 child의 clone에서 super.clone()을 호출할 때에도, parent.clone()의 스택 프레임에 this는 child이다. Object.clone()은 네이티브 메서드로, 내부적으로 this.getClass()를 통해 실제 객체의 타입을 확인하고 B 타입의 새로운 인스턴스를 생성한다. (반환 타입은 Object)

이를 간단하게나마 확인할 수 있는 코드를 아래처럼 작성해 보았다.

class A implements Cloneable{
    int a;

    @Override
    public A clone() throws CloneNotSupportedException {
        System.out.println("A method call : "+this.getClass());
        A a =(A)super.clone();
        System.out.println("Object.clone() return instance : "+a.getClass());
        return a;
    }
}

class B extends A implements Cloneable{
    int b;

    @Override
    public B clone() throws CloneNotSupportedException {
        System.out.println("B method call : "+ this.getClass());
        return (B)super.clone();
    }
}


//실행 코드
B b = new B();
b.clone();

이때, 만약 A의 clone에서 super.clone()을 호출하지 않고 A 인스턴스를 new 생성자를 통해 생성하고 이를 return 하도록 구현했다면? return 받은 A 객체를 (B)로 형변환이 불가능하기 때문에 ClassCastException이 발생하게 된다.

이처럼 실제로 이펙티브 자바에서 말한 내용에 대해 코드를 작성해 보며 느낀 점은 clone은 정말 잘못 사용하면 끝도 없이 문제가 발생할 수 있겠다는 생각이 들었다.

3. 불변 객체와 가변 객체, 그리고 clone()

clone() 메서드는 가변 객체를 다룰 때 특히 주의가 필요하다. 이를 이해하기 위해 먼저 불변 객체와 가변 객체의 차이를 살펴보자.

먼저 불변 객체란?

말 그대로 불변 객체는 생성 후 상태가 변경되지 않는 객체를 말한다. 대표적인 예가 String이다.

String a = "Hello";
a = "Bye";  // 기존 객체를 수정하는 것이 아니라 새로운 객체를 생성

위 코드에서 a = "Bye"는 기존 "Hello" 객체를 수정하는 것이 아니라, 내부적으로 new String("Bye") 객체를 생성하고 그 참조를 a에 할당한다. 불변 객체는 모든 필드가 final로 선언되어 있으며, String의 경우 문자열 상수 풀을 통해 동일한 문자열을 재사용한다.

가변 객체는 반대로 생성 후에도 상태가 변경 가능한 객체를 말한다. 대표적으로 아래와 같이 작성된 클래스에서 List 객체가 있다.

class Person implements Cloneable {
    private String name;
    private List<String> hobbies = new ArrayList<>();
	
    ...
    
}

Person 객체를 생성하고 해당 객체를 이용해 clone()을 호출하면 String의 경우 불변객체라 새로운 person 객체의 name을 생성할 때 같은 ref를 사용해도 문제가 되지 않는다. 실제로 문자열 상수풀을 이용하여 String의 경우 한번 사용된 문자열의 경우 새로 생성하지 않고 재사용한다.

하지만, hobbies의 경우 같은 ref를 복사해 생성할 경우, element를 하나 추가할 때, 그것이 원본 Person 객체에도 영향이 가기 때문에 문제가 된다. 이는 clone을 아래와 같이 사용할 때 얕은 복사로 동작하기 때문에 발생하는 문제이다(hobbies 객체의 ref만 복사하고 내부의 element는 신경 쓰지 않음).

아래와 같이 코드를 작성하고 확인해 보면 명확하다.

class Person implements Cloneable {
    private String name;
    private List<String> hobbies = new ArrayList<>();

	...

    @Override
    public Person clone() {
        try {
            return (Person) super.clone();
        } catch (CloneNotSupportedException e) {
            throw new AssertionError();
        }
    }
    
    ...
    
}

// 실행 코드
public static void mutableObjectClone(){
    Person person = new Person("Lee");
    person.addHobby("Game");
    person.addHobby("Book");
    Person clonePerson = person.clone();

    // 1. 동일성 검사시 같은 레퍼런스를 참조하고 있을 것이기 때문에 true여야 한다.
    System.out.println("name reference same : "+(person.getName() == clonePerson.getName()));
    person.setName("Kim");

    //2. String은 불변객체 따라서, reference값이 변경되어서 동일성은 더이상 같지 않다.
    System.out.println("name reference same : "+ (person.getName() == clonePerson.getName()));

    //3. 가변 객체(List)의 경우 해당 객체의 레퍼런스를 복사한다.
    System.out.println("person hobbies reference : "+(person.getHobbies() == clonePerson.getHobbies()));
}

이 문제를 해결하려면 clone을 재정의할 때 hobbies에 대해 새로 ArrayList를 생성하고 내부의 값들도 새로 생성해서 넣어줘야 한다. 이를 보통 깊은 복사라고 말한다.

cloned.addresses = new ArrayList<>();
for (Address addr : this.addresses) {
    cloned.addresses.add(new Address(addr.city));  // 각 요소도 복사
}

이를 통해 clone 메서드를 사용할 때, 불변 객체와 가변객체인지에 따라 얕은 복사만으로 충분한지 판단할 수 있고, 왜 불변 객체를 사용할 수 있다면 사용해야 하는지 알 수 있었다.

4. 문제의 상황 : 원시형 2차원 배열 clone()

코딩 테스트 문제를 풀며 경험했던 상황은 2차원 원시형 배열을 clone()할 때였다. 이펙티브 자바에서 배열은 clone 기능을 제대로 사용하는 유일한 예라고 말한다. 아래와 같이 1차원 원시형 배열일 경우 clone()을 호출하면 새로운 배열 객체가 생성되고 모든 값이 복사되는 깊은 복사로 동작한다.

public class Music implements Cloneable{
    public int [] arr = {1,2,3,4,5};
    public int [][] arr2 = {
            {1,2,3},
            {4,5,6}
    };
}

// 실행 코드
Music music = new Music();
Music clone = music.clone();
System.out.println("arr:       " + System.identityHashCode(music.arr));
System.out.println("cloned:    " + System.identityHashCode(clone.arr));

clone.arr[0] = 100;
System.out.println(clone.arr[0] + " " + music.arr[0]);

실제 내부 스택과 힙 구조를 간략하게 보면 아래와 같다. 1차원 배열은 새로운 배열 객체가 생성되고 모든 값이 복사되므로, clone 배열을 수정해도 원본 music 배열에 영향을 주지 않는다.

하지만, 2차원 원시형 배열에서는 어떻게 동작할까?

int[][] original = {{10, 20}, {30, 40}};
int[][] cloned = original.clone();

2차원 배열의 메모리 구조를 이해하면 답을 알 수 있다:

2차원 배열 변수는 실제로 "1차원 배열들의 배열"이다
최상위 배열의 각 요소는 내부 1차원 배열에 대한 참조값을 저장한다

clone()을 호출하면:

최상위 1차원 배열은 새로 생성된다
하지만 내부 배열들은 복사되지 않고 참조만 복사된다 (얕은 복사)

결과적으로 cloned와 original의 최상위 배열은 다르지만, 내부 배열들은 동일한 객체를 가리키게 된다.

위와 같이 동작하기 때문에, 코딩 테스트 문제 풀이에서 cloned를 변경할 때 original에도 영향이 가는 상황이 발생했던 것이다. 이를 해결하려면 위에서 가변객체를 위한 clone을 재정의했던 방식처럼 동일하게 복사 로직을 작성해줘야 한다. 배열 변수가 가리키는 1차원 배열의 경우 새로 생성된다는 점을 이용해 복사를 아래처럼 작성하면 서로 영향을 주는 상황을 해결할 수 있다.

int [][] original = {{10, 20}, {30, 40}};
int [][] clone  = new int[2][];

for(int i = 0; i<2;i++){
    clone[i] = original[i].clone();
}

5. 마무리

정리하면, clone()을 안전하게 사용하려면 다음을 확인해야 한다:

객체의 타입 확인: 복사하려는 객체가 가변 객체인가?
복사 깊이 결정: 내부 요소까지 복사가 필요한가?
적절한 구현: 필요하다면 내부 요소를 직접 복사하는 로직 작성

특히 원시형 2차원 배열이나 ArrayList 같은 가변 객체는 clone()만으로는 내부 요소의 참조만 복사된다. 원본을 보존해야 하는 경우, 반드시 내부 요소까지 값을 복사하는 로직을 구현해야 한다.

이펙티브 자바에서는 복사 생성자와 복사 팩토리라는 더 나은 객체 방식을 제공하는 것이 Best Practice라고 소개한다. 따라서, 이미 Cloneable을 구현한 게 아니라면 복사 생성자를 고려해 보자.

`코딩테스트에서 적용`

코딩테스트에서는 원시형 2차원 배열과 ArrayList를 자주 사용한다. 원본 데이터를 유지하면서 변경을 가해야 하는 상황에서는 아래와 같이 사용하자.

// 2차원 배열 - 각 행을 개별적으로 복사
int[][] cloned = new int[original.length][];
for (int i = 0; i < original.length; i++) {
    cloned[i] = original[i].clone();
}

// ArrayList - 새 객체 생성 후 깊은 복사
List<List<Integer>> cloned = new ArrayList<>();
for (List<Integer> list : original) {
    cloned.add(new ArrayList<>(list));
}

`배운 점`

clone() 메서드를 깊이 있게 공부하면서 그동안 명확히 설명하지 못했던 개념들을 정리할 수 있는 시간이었다.

불변 객체 vs 가변 객체의 차이와 clone() 시 주의사항
Java에서 얕은 복사 vs 깊은 복사의 개념
메모리 구조를 통한 배열 복사의 동작 원리

디자인 패턴 : 빌더 & 싱글톤 패턴 구현해보기 (with. 이펙티브 자바)

chan_2 — Tue, 28 Oct 2025 15:59:06 +0900

Spring Boot로 개발하다 보면 @Builder, @Service같은 어노테이션을 너무나 자연스럽게 사용하게 됩니다. 하지만 문득 이런 생각이 들었습니다.

Builder 사용 사진

"만약 Lombok이나 Spring이 없다면 어떻게 구현해야 할까?"

그래서 이번에는 빌더 패턴과 싱글톤 패턴을 직접 구현하면서 이전까지 이론적으로만 학습해왔던 디자인 패턴들에 대해 자세하게 공부해 보며 직접 적용할 때는 어떤 점을 주의해야하는지 학습해 보았습니다.

1. 빌더 패턴

왜 필요할까?

객체를 생성할 때 이런 코드를 본 적 있으신가요?

Pizza pizza = new Pizza(12, "thin", "mozzarella", "tomato", "olive", "pepperoni", true, false);

Pizza 사진

매개변수가 8개나 되는데, 순서도 헷갈리고 어떤 값이 무엇을 의미하는지 전혀 알 수 없습니다. (물론 인텔리제이 IDE가 친절하게 매개변수 명을 보여주긴 합니다.) 게다가 일부 매개변수는 선택적이어서 필요 없는 값까지 null이나 false로 채워야 하는 상황이 발생합니다.

빌더 패턴은 바로 이런 문제를 해결합니다.

Pizza pizza = Pizza.builder()
    .size(12)
    .crust("thin")
    .cheese("mozzarella")
    .build();

훨씬 읽기 쉽고, 필요한 옵션만 선택할 수 있습니다. 이것이 바로 클라이언트 코드의 가독성을 보호하는 빌더 패턴의 핵심입니다.

직접 구현해보기

항상 빌더 패턴을 Lombok을 사용해 작성해왔기 때문에 어떤점을 고려해서 작성해야하는지 이펙티브 자바의 item 2을 참고했습니다.

`1. 정적 멤버 클래스로 구현하기`

처음에는 "왜 굳이 static을 붙여야 하지?"라는 의문이 들었습니다. 하지만 일반 내부 클래스로 구현하면 아래와 같은 상황이 발생합니다

// 일반 내부 클래스의 문제점
PizzaV2 pizza = new PizzaV2(12, "thin"); // 먼저 Pizza를 생성해야 함
PizzaV2.Builder builder = pizza.new Builder(12, "thin"); // Builder를 사용하기 위해 Pizza가 필요한 상황

Pizza를 만들려고 Builder를 쓰는데, Builder를 쓰려면 Pizza가 필요한 순환 논리에 빠지게 됩니다.

이를 정적 멤버 클래스를 사용하면 외부 클래스의 인스턴스 없이도 Builder에 접근할 수 있고 이를 통해 아래와 같이 Pizza를 생성할 수 있습니다.

Builder 사용 사진

`2. 필수 필드와 선택 필드 구분하기`

직접 Builder를 구현하게 되는 경우 해당 클래스에서 필수적으로 전달받아야하는 필드가 있고 선택사항이 되는 필드가 존재합니다. 아래는 제가 직접 실습을 진행할 때 작성해보았던 간단한 예제 클래스입니다.

public class Pizza {
    private final int size;
    private final String dough;
    private final boolean cheese;
    private final boolean peperoni;
    private final boolean mushroom;
    private final boolean onion;
    private final boolean olive;

    private Pizza(int size, String dough, boolean cheese, boolean peperoni, boolean mushroom, boolean onion, boolean olive) {
        this.size = size;
        this.dough = dough;
        this.cheese = cheese;
        this.peperoni = peperoni;
        this.mushroom = mushroom;
        this.onion = onion;
        this.olive = olive;
    }

    @Override
    public String toString() {
        return "practice_builder.Pizza{" +
                "size=" + size +
                ", dough='" + dough + '\'' +
                ", cheese=" + cheese +
                ", peperoni=" + peperoni +
                ", mushroom=" + mushroom +
                ", onion=" + onion +
                ", olive=" + olive +
                '}';
    }

    public static class Builder{
        private final int size;
        private final String dough;
        private boolean cheese = false;
        private boolean peperoni = false;
        private boolean mushroom = false;
        private boolean onion = false;
        private boolean olive = false;

        public Builder(int size, String dough) {
            this.size = size;
            this.dough = dough;
        }

        public Builder cheese() {
            this.cheese = true;
            return this;
        }

        public Builder peperoni() {
            this.peperoni = true;
            return this;
        }

        public Builder mushroom() {
            this.mushroom = true;
            return this;
        }

        public Builder onion() {
            this.onion = true;
            return this;
        }

        public Builder olive() {
            this.olive = true;
            return this;
        }

        public Pizza build() {
            return new Pizza(size, dough, cheese, peperoni, mushroom, onion, olive);
        }
    }
}

필수 필드의 경우 Builder의 생성자에서 매개변수로 받아 final로 선언하며, 선택필드의 경우 메서드 체이닝으로 기본값을 수정하는 방식으로 진행합니다. 이를 통해 실제 Client에서는 메서드 체이닝을 통해 가독성있게 Pizza 객체를 생성해 사용할 수 있습니다.

느낀점

직접 구현해보니... 빌더 패턴의 경우 보일러 플레이트 코드의 끝판왕이라고 느꼈습니다. Lombok의 `@Builder`가 얼마나 고마운 존재인지 깨달을 수 있는 시간이었습니다. 또, 이렇게 내부 구조를 이해하고 나니 빌더 패턴을 언제 사용해야 하는지, 어떤 방식으로 설계해야 하는지 명확히 알게 되었습니다.

Lombok 최고

2. 싱글턴 패턴

왜 필요할까?

Spring Boot를 사용하다 보면 Service나 Repository를 주입받아 사용합니다. 이때 Spring은 기본적으로 싱글턴 방식으로 빈(Bean)을 관리합니다. 이때, 만약 매번 새로운 객체를 생성한다면?

// 비효율적인 방식
@GetMapping("/users")
public List<User> getUsers() {
    UserService userService = new UserService(); // 매번 생성
    return userService.findAll();
}

인스턴스 N개 생성

API 호출마다 새로운 Service 객체를 생성하고, Service는 또 새로운 Repository를 생성하고... 자원 낭비가 발생합니다. 각각의 Service들은 모두 동일한 로직을 갖고 있어 이렇게 매번 새로 생성해서 사용하는 것은 아무리 봐도 비효율적이라고 생각합니다.

싱글턴 패턴은 애플리케이션 전체에서 단 하나의 인스턴스만 생성하여 자원을 효율적으로 관리합니다. (자원을 보호해주는 디자인 패턴)

직접 구현해보기

싱글톤의 경우에도 이펙티브 자바의 item 3를 참고해 구현을 진행해보았습니다.

`1.public static final 방식`

첫 번째 방식은 매우 간단한 방식입니다. 그냥 private으로 생성자를 막고 `Ingredient.INSTANCE`를 이용해 사용하는 방법입니다.

public class Ingredient {
    public static final Ingredient INSTANCE = new Ingredient();
    
    private Ingredient() {
        // private 생성자로 외부 생성 차단
    }
}

// 사용
Ingredient ingredient = Ingredient.INSTANCE;

매우 간단하고 실제 API를 통해 싱글턴임을 명확히 드러낼 수 있다는 장점이 있습니다. 하지만, 기획의 변경에 따라 더 이상 싱글턴을 유지하지 않아도 되는 상황이 발생하면 Ingredient 코드 뿐만 아니라 `Ingredient.INSTANCE`를 사용하는 클라이언트 코드도 변경해야 한다는 단점이 존재합니다.

아래 처럼 여러 클래스에서 싱글턴 인스턴스를 사용하고 있는 상황이었다면, 해당 클래스 모두 코드 수정을 해야한다는 단점이 존재합니다.

변경에 취약

`2. 정적 팩토리 메서드 방식`

두 번째 방식은 인스턴스 필드를 private으로 감추고 정적 팩토리 메서드로 해당 인스턴스에 대한 접근 API를 제공해주는 방식입니다.

public class IngredientV2 {
    private static final IngredientV2 INSTANCE = new IngredientV2();
    
    private IngredientV2() {}
    
    public static IngredientV2 getInstance() {
        return INSTANCE;
    }
}

// 사용
IngredientV2 ingredient = IngredientV2.getInstance();

이 방식의 장점은 API 변경 없이 싱글턴이 아니게 변경 가능하다는 점입니다. 필드를 그대로 가져다 사용하는 경우와 비교해보면 아래와 같이 코드를 작성해 정적 메서드를 가져다 사용하는 다른 클래스 코드에는 영향을 주지않고 변경 가능합니다.

변경에 유연

이 장점 이외에도 제네릭 싱글턴 팩터리, Supplier로 사용 가능하다는데... 저는 아직 한번도 이렇게 사용해 본적이 없어 잘 와닿지 않았습니다. 그래서 일단은 다른 객체와 결합도를 낮출 수 있다는 장점만 챙겨가려고 합니다.

`3. Enum 방식`

마지막 방법은 Enum을 사용하는 방식입니다.

public enum IngredientV3 {
    INSTANCE;
    
    public void doSomething() {
        System.out.println("Doing something...");
    }
}

// 사용
IngredientV3.INSTANCE.doSomething();

이펙티브 자바에서도 Enum을 이용해 싱글턴을 구현하는 것을 적극 추천하는데 그 이유는 다음과 같습니다.

가장 간결하고 추가 코드 없이 싱글톤이 보장됩니다.
직렬화 자동처리로 직렬화 -> 역직렬화 이후에도 싱글톤이 보장됩니다.

한가지 단점이 존재하는데, 바로 상속이 필요한 경우 사용할 수 없다는 점입니다. 하지만 엄청 간단하고 역직렬화시에도 싱글턴을 자동으로 보장해준다는 점에서 확실히 매력적인 방법이라고 생각이 들었습니다.

직렬화와 싱글턴

그럼 1,2번 방식은 직렬화 시에 어떻게 동작할까요?

객체를 직렬화했다가 역직렬화를 진행한다면 역직렬화를 진행하는 실제 동작에서는 이 객체가 싱글턴으로 사용되고 있다는 사실을 모릅니다.

따라서, 아래와 같이 코드를 작성해 비교하면 싱글턴이 깨지는 상황을 확인해 볼 수 있습니다.

Elvis elvis1 = Elvis.getInstance()
System.out.println("elvis1: " + elvis1);
        
// 직렬화 (객체를 바이트로 변환)
ByteArrayOutputStream baos = new ByteArrayOutputStream();
ObjectOutputStream oos = new ObjectOutputStream(baos);
oos.writeObject(elvis1);
oos.close();

byte[] serializedData = baos.toByteArray();


// 역직렬화 (바이트를 객체로 복원)
ByteArrayInputStream bais = new ByteArrayInputStream(serializedData);
ObjectInputStream ois = new ObjectInputStream(bais);
Elvis elvis2 = (Elvis) ois.readObject();
ois.close();


System.out.println("같은 인스턴스? " + (elvis1 == elvis2));  // false!

역직렬화 문제

이를 해결하는 방법은 readResolve 메서드를 구현하는 것입니다.

public class Ingredient implements Serializable {
    public static final Ingredient INSTANCE = new Ingredient();
    
    private Ingredient() {}
    
    // 역직렬화 시 호출되어 싱글톤 보장
    private Object readResolve() {
        return INSTANCE;
    }
}

그럼, 역직렬화의 동작과정중 아래와 같이 메서드를 불러와 실행시키는 부분이 존재하고 이를 통해 싱글턴 객체를 보장할 수 있게됩니다.

Method readResolve = Elvis.class.getDeclaredMethod("readResolve");
if (readResolve != null) {
    readResolve.setAccessible(true);

    // readResolve() 호출
    Object result = readResolve.invoke(tempInstance);  // INSTANCE 반환

    return (Elvis) result;
}

싱글턴 정리

싱글턴의 경우 직접 구현할 일이 있다면 최우선적으로 Enum을 고려하고, 만약 해당 클래스를 상속해야하는 일이 생긴다면 public 필드나 정적 팩토리 메서드를 사용해야겠다. 결합도를 생각한다면 코드 몇줄만 추가하면 되는 정적 팩토리 메서드를 아마 선택하는게 현명하지 않을까?

그리고 1번과 2번 방법을 사용하기로 결정하였다면 역직렬화시 발생할 수 있는 싱글턴이 깨지는 상황을 고려해 readResolve() 메서드를 작성해 놓아야 겠다.

3. 마치며..

Enum 싱글턴은 아직 실제로 사용해본 적이 없어 조금 낯설게 느껴지긴 했는데, 나중에 직접 사용할 일이 생긴다면 무조건 Enum을 이용해 싱글턴 패턴을 사용해봐야겠다.

매번 개념 학습에만 초점을 두었던 디자인 패턴 공부였고, 이번에 처음으로 직접 구현하며 주의해야할 문제점들을 다루어보았는데, 생각보다 유익한 시간이었습니다. 다른 디자인 패턴들도 한번 이렇게 직접 구현해보며 학습하고, 최종적으로는 진행하는 프로젝트에 적용해볼 수 있으면 좋을 것 같습니다.

파일 업로드가 귀찮아서 만든 북마크 데스크톱 애플리케이션 회고

chan_2 — Tue, 21 Oct 2025 20:55:51 +0900

1. 기획 동기

상반기 입사 지원을 하면서 자주 사용하는 파일이나 사진을 크롬 브라우저에서 업로드할 때마다 불편함을 느꼈다. 파일을 찾아가는 과정이 생각보다 귀찮고 번거로웠기 때문이다.

위 화면은 내 노트북에서 파일 업로드 버튼을 클릭했을 때 나오는 파일 탐색기다. 여기서 원하는 파일을 찾아가는 시간을 줄일 수 있지 않을까? 이런 생각에서 '파일 경로 북마크' 프로젝트가 시작되었다.
크롬 우측 상단의 북마크 탭처럼, 내 노트북의 파일 경로를 북마크로 저장하면 파일 업로드 시 찾아가는 시간을 획기적으로 줄일 수 있을 것 같았다.

2. 요구사항 정리

애플리케이션 개발에 앞서 가장 고민했던 지점은 "북마크를 정말 필요한 순간에 바로 사용할 수 있어야 한다"는 것이었다. 이상적인 시나리오를 그려보니, 크롬에서 파일 업로드 버튼을 클릭하는 순간 내가 만든 북마크 서비스가 자연스럽게 나타나면 좋겠다는 생각이 들었다. 이를 구현하려면 크롬 확장 프로그램을 활용하는 것이 가장 효과적일 것 같았다.

`파일 업로드 프로세스 분석`

먼저 파일 업로드 프로세스를 분석했다. 대부분의 웹사이트에서 파일 업로드 버튼을 클릭하면 <input type="file"> 태그가 동작한다는 것을 확인할 수 있었고 이를 바탕으로 크롬 확장 프로그램으로 사용자의 파일 업로드 클릭을 감지하고, 이를 트리거로 내 애플리케이션에 메시지를 전달하는 방식으로 구현 방향을 잡았다.

`기술 스택 선택`

사용할 언어와 라이브러리는 고민 없이 결정했다. Java로 프로젝트를 만들고 싶었고, Java에서 UI를 구현하는 대표적인 라이브러리인 Swing UI를 선택했다. 따라서 메인 기술 스택은 Java + Swing UI로 확정되었다.

`핵심 요구사항`

대략적인 방향성과 사용할 도구를 정한 후, 고객의 요구사항을 뽑아보았다. (물론 여기서 고객은 나 자신이었다. ㅋㅋ)

1. 사용자는 파일, 폴더의 경로를 북마크에 저장한다.
a. 북마크를 저장할 때 이름을 설정할 수 있다.
b. 북마크는 사용용도에 따라 그룹으로 분류할 수 있다.
c. 그룹 내에 경로들은 카테고리로 분류할 수 있다.
2. 사용자는 저장한 북마크들을 볼 수 있으며 잘못 저장한 북마크는 수정하거나 삭제할 수 있다.
a. 그룹과 그룹 사이에 북마크를 옮길 수 있다.
3. 사용자는 저장한 북마크에 대한 파일경로를 복사해갈 수 있다.
4. 사용자는 북마크 리스트에 보여지는 그룹, 카테고리, 북마크 순서를 원하는 순서로 조정할 수 있다.
5. 그룹과 관련해서 CRUD를 진행할 수 있다.
6. 카테고리와 관련해서 CRUD를 진행할 수 있다.

애플리케이션에 필요한 기능을 정리한 결과, 6가지 핵심 요구사항을 도출했다. 이를 바탕으로 프로젝트의 방향성을 다음과 같이 설정했다.

크롬 확장 프로그램을 만들어 애플리케이션과 연결한다
Java와 Swing UI 라이브러리를 이용해 데스크톱 애플리케이션을 만든다
애플리케이션은 정의한 요구사항을 만족하도록 구현한다

3. 구현

`POC 검증 : 크롬 확장 프로그램과 애플리케이션 연동 가능성`

가장 먼저 검증한 것은 "크롬 확장 프로그램과 내 애플리케이션을 연결할 수 있는가?"였다. 한 가지 문제가 있었다면, 크롬 확장 프로그램을 한 번도 만들어본 적이 없다는 점이었다.

하지만 우리에게는 생성형 AI라는 든든한 도구가 있었기에 주저하지 않고 개발에 들어갔다. AI로부터 크롬 확장 프로그램 코드를 받아 구현하되, manifest.json의 각 키 값은 Chrome 공식 문서를 참고하며 필요한 기능만 빠르게 학습했다.

Chrome 확장 프로그램 | Chrome Extensions | Chrome for Developers

Chrome 확장 프로그램 개발 방법을 알아보세요.

developer.chrome.com

이 과정에서 크롬 확장 프로그램은 JavaScript에 익숙하다면 생각보다 어렵지 않게 구현할 수 있다는 것을 알게 되었다. 학습 후 GPT가 생성한 간단한 Swing UI 프로그램과 확장 프로그램의 연동을 테스트한 결과, 파일 업로드 버튼 클릭 동작이 실제로 내 애플리케이션까지 전달되는 것을 확인했다.

이 과정에서 핵심은 Native Messaging Host 등록이었다. 내가 만든 애플리케이션을 크롬 브라우저와 통신할 수 있는 메시지 호스트로 등록하면, 크롬 확장 프로그램에서 발생한 이벤트(파일 업로드 버튼 클릭)를 감지하고 네이티브 애플리케이션으로 메시지를 전달할 수 있다.

`Java 객체지향 프로그래밍과 디자인 패턴`

연결이 가능하다는 것을 확인한 후에는 정리한 요구사항을 토대로 코드를 구현했다. 아래 다이어그램은 최종 결과물의 도메인 모델이다.

코드를 작성할 때 2가지를 중점적으로 고려했다.

1. 도메인 모델 단순화 및 설계 개선

초기 기획에는 그룹, 북마크, 카테고리 세 가지 객체가 필요하다고 생각했다. 하지만 카테고리까지 도입하면 사용자 입장에서 "카테고리와 그룹의 차이가 뭐지?"라는 혼란을 야기할 수 있다는 생각이 들었다.
단순한 애플리케이션일수록 명확한 구조가 중요하다는 판단하에, 최종적으로 그룹과 북마크 두 가지 핵심 객체만으로 도메인 모델을 구성했다.

객체 간 협력 구조를 분석하던 중, "그룹 생성" 기능에서 "그룹 객체 생성"과 "생성된 그룹을 파일에 저장"이라는 두 가지 책임을 발견했다. 이 두 책임을 그룹 객체 하나가 담당하는 구조는 단일 책임 원칙에 위배된다고 판단했고, 서비스 계층을 도입하여 도메인 로직과 저장 로직을 조율하는 역할을 분리했다.

2. 어댑터 패턴을 통한 유연한 저장소 설계

그룹 저장소 구현에는 MicroStream이라는 라이브러리를 처음 도입했다. 새로운 라이브러리를 사용하는 만큼 예상치 못한 이슈가 발생할 가능성을 고려했고, 이러한 리스크에 대비하기 위해 어댑터 패턴을 적용했다.
저장소 인터페이스를 추상화하고 MicroStream을 어댑터로 감싸는 구조로 설계함으로써, 향후 다른 저장소 라이브러리로 교체가 필요한 상황에서도 기존 코드의 수정 없이 어댑터만 교체하면 되도록 유연성을 확보했다.

이 과정을 통해 8월부터 9월까지 학습했던 객체지향과 디자인 패턴을 직접 적용해볼 수 있었다. 앞으로 코드를 작성하고 설계할 때 이런 지식을 활용하면 보다 확장 가능한 개발을 진행할 수 있겠다는 확신이 들었다.

`파일 입출력과 MicroStream 라이브러리`

1. 데이터 영속화 전략: 데이터베이스 vs 파일 시스템

대부분의 프로그램은 데이터를 영속화해야 프로세스를 종료하고 다시 실행해도 저장한 데이터를 불러와 서비스를 제공할 수 있다.
기존 웹 서비스를 개발할 때는 데이터베이스를 활용했지만, 이 애플리케이션에도 데이터베이스가 필요한가? 고민한 결과 대답은 No였다. 그 이유는 다음과 같다. 가벼운 소프트웨어를 만드는 것이 목적인데, 데이터베이스를 포함하는 것 자체가 무거워진다는 생각이 들었다.또, 데이터베이스를 이용한다고 쳤을 때, 로컬 DB를 사용한다는 것은 나중에 배포를 생각해보면 있을 수 없는 일이었다.

따라서 간단하게 파일 입출력을 이용해 데이터를 영속화하는 것으로 결정했다.
처음에는 Java에서 제공하는 기본 파일 입출력 기능을 사용하려고 했다. 하지만 파일 저장 및 조회 시 필요한 직렬화/역직렬화 코드, 데이터 저장 및 수정 시 필요한 영속성 관리 코드를 작성하는 데 드는 비용이 4일 안에 해결하기 어렵다고 판단했다. MVP를 빠르게 완성하기 위해 기존 라이브러리를 활용하기로 결정하고 파일 입출력 라이브러리를 찾아보았다.

2. MicroStream 선택 이유

그 과정에서 MicroStream을 선택하게 되었다.

MicroStream은 JVM 메모리상에 존재하는 객체들의 참조 구조를 그대로 파일 시스템에 영속화하는 라이브러리다. 예를 들어, Group 객체가 Bookmark 리스트를 관리하는 경우, Group은 각 Bookmark에 대한 참조를 보유한다. MicroStream은 이러한 객체 그래프 구조를 있는 그대로 저장하고 복원할 수 있다.

이러한 MicroStream을 선택한 이유는 크게 2가지다.

1) 단순한 도메인 모델과의 최적 호환성
이번 프로젝트의 데이터 구조는 그룹과 북마크, 두 가지 엔티티만 존재하는 매우 단순한 형태다. 그룹 리스트를 루트(Root) 노드로 설정하면, 그룹과 북마크 간의 관계를 객체 그래프로 자연스럽게 표현할 수 있다. 별도의 매핑 작업 없이 도메인 모델을 그대로 영속화할 수 있다는 점에서 MicroStream과 궁합이 완벽했다.

2) 단일 언어로 통합된 데이터 처리
Java Stream API만으로 정렬, 필터링, 조회 등 모든 데이터 처리 로직을 구현할 수 있다는 점이 큰 장점이었다. SQL 기반 파일 저장 방식을 사용했다면 Java 코드 외에 SQL 쿼리까지 관리해야 하는 복잡도가 추가된다. 만약 MicroStream을 활용한다면? 데이터 저장부터 조회까지 순수 Java 코드만으로 일관되게 처리할 수 있다.

물론 처음 사용하는 라이브러리인 만큼 동시성 문제나 메모리 관리 이슈가 발생할 가능성도 생각했다. 하지만 앞서 적용한 어댑터 패턴 덕분에 실제 사용 중 문제가 발견되더라도 저장소 구현체만 교체하면 되는 구조이기 때문에, 리스크를 충분히 관리 가능한 수준으로 판단했다.

`Swing UI를 영리하게 작성하기 (With AI Agent)`

처음에는 GPT를 이용해 단순하게 내가 작성한 서비스 로직과 연결하는 방식으로 UI를 구현했다.
아래와 같은 프롬프트를 활용해 Swing 프로그램 코드 작성을 요청했는데, 이 과정에서 메서드뿐만 아니라 해당 메서드 내부의 구현을 어떻게 진행했는지도 간단하게 전달해야 2~3번 반복 요청하지 않을 수 있다는 사실을 배웠다.

- 다음 내부 기능들을 구현했는데 Swing UI 연결을 부탁할게. MainFrame 코드는 전달해 줄게.
- 북마크 리스트를 보여줄 때 BookmarkType을 보고 파일 아이콘, 폴더 아이콘 붙여서 보여주기 bookmark.getType()으로 타입 확인 가능
- 북마크 그룹 삭제 연결 → 이 메서드 활용: bookmarkGroupService.deleteBookmarkGroup(long id);
- 북마크 그룹 이름 변경 연결 → 이 메서드 활용: bookmarkGroupService.renameBookmarkGroup(long id, String name);
- 북마크 순서 변경 연결(북마크 그룹과 동일하게 드래그 앤 드롭 방식) → 이 메서드 활용: reorderBookmark(long groupId, long prevId, int toIndex)
- 북마크 정보 수정 연결 → 이 메서드 활용: updateBookmark(long bookmarkId, String displayName, String path)

그 결과, 위 사진의 UI가 탄생했다. (아직 좀 볼품없습니다~)

1. AI Agent로 UI 개선 자동화 시도

이후 UI 개선 작업을 진행하면서 GPT에게 "분석 요청 → 수정 요청"을 반복적으로 진행했다. 이 과정에서 "내가 매번 이 루틴을 조율해야 할 필요가 있을까?"라는 의문이 들었고, 이를 AI로 자동화할 수 있지 않을까 하는 아이디어가 떠올랐다.

그래서 이번 기회에 AI Agent를 실제로 구현해보기로 결심하고 바로 Claude Code 구독을 결제했다. 반복적인 UI 개선 프로세스를 자동으로 수행할 수 있는 Agent를 쉘 스크립트로 구현하는 것을 목표로 삼았다.

위와 같은 구조로 동작하는 Agent를 만들었지만, 아쉽게도 직접 사용해볼 수는 없었다. 내가 만든 Agent는 Claude Code가 아니라 Claude API를 사용할 때만 작동했고, API 비용 문제로 Claude Code를 구독한 상황이었기 때문에 다른 방법을 찾아야 했다.

2. 반자동화 워크플로우 구축

완전한 자동화는 아니지만, 대안으로 장기 작업용 프롬프트를 설계하는 방식을 선택했다. Agent에서 설계했던 작업 순서를 프롬프트로 그대로 옮기고, 마지막에 "이 과정을 N번 반복해줘"라는 지시를 추가했다.
이를 통해 완전 자동화는 아니지만, 한 번의 프롬프트 입력으로 여러 차례의 개선 사이클을 연속적으로 수행하는 반자동화 워크플로우를 구축할 수 있었다.

물론 이 반자동화 방식도 완벽하지는 않았다. 프롬프트에 세세한 디자인 지침까지 모두 담지 못했기 때문에, 처음부터 만족하는 수준의 UI가 완성되지는 않았다.

하지만 UI의 핵심 구조와 뼈대는 효과적으로 구축할 수 있었고, 세부적인 스타일링과 레이아웃 조정은 추가 프롬프팅을 통해 점진적으로 개선해 나갔다. 이러한 반복 과정을 거쳐 최종적으로 아래와 같은 UI를 완성했다

이 과정에서 앞으로 Swing UI를 이용하여 애플리케이션을 만들 일이 생긴다면 내가 직접 Swing 을 자세하게 공부하고 코드를 짜기보다 Swing UI로 만들 수 있는 UI 명칭을 공부하고 AI에게 명칭을 통해 내가 원하는 구조를 명확하게 표현하는게 더 좋은 UI를 탄생시킬 수 있을 것 같다는 생각이 들었다.

4. 시연 영상

UI 단은 정말 걱정을 많이했는데 이번 기회에 생성형 AI의 위대함을 한번 더 경험해볼 수 있었던 것 같다. 아래 영상은 20초 정도 되는 영상인데 앞으로 내가 파일 관리나 URL 관리를 할 때 애용할 것 같다.

시나리오는 다음과 같다.

이 글의 동영상을 업로드할 때 동영상 업로드 버튼을 클릭하는 시점에 내가 만든 파일 경로 북마크가 뜬다.
원하는 북마크를 클릭하면 파일 경로를 복사할 수 있다.
파일 탐색기에 해당 경로를 붙여넣기 후 확인을 누른다.

동영상 서비스가 종료되어 해당 콘텐츠를 재생할 수 없습니다.

영상에서는 너무 빠르게 지나가 뭔 차이지 싶을 수도 있는데 파일 탐색기가 켜지면서 내 애플리케이션 우상단에 같이 올라오는 것이 차이점이다. 해당 북마크를 통해 자주 쓰거나 원하는 파일을 바로 찾아 업로드 할 수 있는 것이 가장 큰 장점이다.

5. 개선해야 될 점들..

위 과정을 거쳐 최종적으로 동작하는 소프트웨어를 완성했다. 하지만 4일이라는 시간 안에 구현했기 때문에 부족한 부분도 있고 추가하지 못한 기능도 생겼다.

그 내용을 정리해본 결과 크게 3가지 범주로 분류할 수 있었다. 직접 사용해보며 겪은 경험을 바탕으로 뽑아낸 것이라 이것 외에도 더 존재한다고 생각한다. 따라서 이후에는 아래 작업을 진행하며 애플리케이션 고도화를 진행할 예정이다.

개선작업

- Swing UI 코드 분리 및 각 컴포넌트의 이름 정리하기 (ex. 트레이, 팝업 메뉴, 툴바 등)
- 애플리케이션 z-index 수정하기 → 현재는 가장 앞에만 표시됨
- Swing UI에서 보여주는 메시지가 애플리케이션 하단에 표시되는데 가독성이 떨어짐
- Main 코드 수정 및 설정 관련 코드 분리하기
- 북마크 ↔ 크롬 확장 프로그램 통신 설계하기

추가기능 작업

- 검색 기능
- lnk로 바로가기 만들어 유저가 파일/폴더 위치를 이동시켜도 문제없이 동작하도록 구현 (JNA)
- 그룹, 북마크 순서 변경 UI 추가하기

추가 인프라 작업

웹 스토어 개발자 등록 후 크롬 확장 프로그램 등록하기

6. 최종 목표

완성된 파일 경로 북마크 v1은 지금 실제로 사용하고 있다. 사용해보니 크롬에서 자주 사용하는 파일을 업로드하는 과정이 정말 빨라진 것을 체감할 수 있었다.
아직 내가 만든 소프트웨어를 직접 사용해본 경험이 많지 않아 어색하긴 하지만, 계속 불편한 점을 다듬어 최종적으로는 소프트웨어를 다운로드받을 수 있는 사이트에 업로드하는 것이 목표다. 그렇게 하려면 크롬 확장 프로그램까지 등록해야 하기 때문에 그 과정이 매우 험난할 수 있다고 생각되지만, 그만큼 도전적이기 때문에 더 재미있을 것 같다.

내가 불편했던 것을 해결하려고 만든 소프트웨어는 처음인데, 이 소프트웨어를 사용감 좋게 개선해 최종적으로 다른 사람들도 사용하기 좋은 소프트웨어로 만드는 것이 최종 목표다.