뒤늦은 2025년 하반기 회고록,,,

안녕하세요, 프론트엔드 개발자 송연지입니다.

…네, 하반기 회고도 또 늦었습니다. 하하 😇
상반기 쓸 때만 해도 “이번엔 제때 써야지!” 했는데
역시나 현실은 늘 예상보다 빠르고, 저는 늘 예상보다 바빴습니다.

2025년 하반기도 마찬가지로,,,
솔직히 말하면 너무 정신없어서
시간이 어떻게 지나갔는지도 잘 기억이 안 날 정도였어요.

지난 상반기 회고록을 보실 분들은 여기루 ㅎㅎ
상반기 회고록 보기

근데 신기하게도,
막상 돌아보려고 하니까
머릿속에 제일 먼저 떠오른 단어는 이거였습니다.

테스트. 사용자. 구조. 그리고 책임.

상반기가 ‘처음’을 많이 겪은 시기였다면,
하반기는 그 처음들의 결과를
끝까지 책임지면서 진짜로 부딪힌 시간이었어요.

코드는 잘 짰다고 생각했는데 무너졌고,
설계는 괜찮다고 믿었는데 사용자 앞에서 깨졌고,
문서는 미뤄둔 만큼 되돌아와서 저를 괴롭혔습니다.

그리고 저는 그 모든 걸
배포하고, 고치고, 다시 확인하고, 또 배포하는 반복 속에서
조금 더 단단해졌던 것 같아요.

웃으면서 시작했지만
내용은 전혀 웃을 수 없었던(?)
2025년 하반기 이야기를 이제 하나씩 꺼내보려고 합니다.

그럼, 본격적으로 시작해볼게요.

🧨 7월 — 통합 테스트를 시작한 순간, 평화도 같이 종료되었다

7월은 제가 단위 테스트를 했다는 사실에 괜히 뿌듯해하던 나 자신을
가장 세게 반성한 달이었습니다.

5월에 단위 테스트를 도입했을 때는 솔직히 이런 마음이었어요.

“이 정도면 꽤 단단하지 않나?”

“적어도 큰 건 다 잡았겠지?”

지금 와서 말하자면,

그건 정말 순진한 착각이었습니다.

단위 테스트와 통합 테스트는 전혀 다른 이야기였다

7월에 본격적으로 통합 테스트 시나리오를 작성하고, 실제로 테스트를 돌리기 시작했어요.

그리고 거의 바로 깨달았습니다.

“아… 이건 단위 테스트랑 차원이 다르네.”

단위 테스트는

• 함수가 잘 도는지
• API 응답을 잘 처리하는지
• 특정 조건에서 에러가 나는지

를 보는 개발자 중심의 테스트였다면,

통합 테스트는

• 사용자가 처음 이 화면을 봤을 때 뭘 할지
• 어떤 버튼을 누를지
• 실수했을 때 어디서 막히는지

를 전부 보는 사람 중심의 테스트였어요.

그리고 이 ‘사람’은 개발자가 아니었습니다.

개발자가 쓴 통합 테스트 시나리오의 문제

처음엔 당연하게도 통합 테스트 시나리오를 개발자들이 직접 작성했어요.

결과요?

• 내부 상태를 이미 알고 있다는 전제
• “정상 케이스 기준”의 흐름
• 전문 용어가 자연스럽게 섞인 문장들

딱 보자마자 이런 생각이 들었습니다.

“이거… 개발 안 한 사람은 못 하겠는데?”

통합 테스트는 개발을 전혀 모르는 사람도
문서만 보고 그대로 따라 하면 테스트가 가능해야 했어요.

• 여기서 뭘 클릭해야 하는지
• 이 화면이 뜨는 게 정상인지
• 잘못했을 땐 어떤 메시지가 보여야 하는지

모든 걸 ‘사용자 언어’로 다시 써야 했습니다.

이 과정에서 처음 느꼈어요.

“사용자 입장에서 쓴다는 게

이렇게까지 어려운 일이었구나.”

그리고… 버그가 미친 듯이 튀어나오기 시작했다

통합 테스트를 본격적으로 돌리자, 그동안 잠잠하던 시스템이

마치 기다렸다는 듯이 무너지기 시작했습니다.

• 단위 테스트에선 한 번도 안 났던 버그
• 특정 순서에서만 터지는 문제
• 상태가 살짝만 어긋나도 바로 깨지는 흐름

그제야 깨달았어요.

“단위 테스트 때 수월했던 게 아니라,

그냥 그때는 안 보였던 거였구나.”

7월의 제 하루는 거의 이랬습니다.

배포한다

테스트한다

어, 또 터진다

고친다

다시 배포한다

다시 테스트한다

그리고 이 루틴을

하루에도 몇 번씩 반복했습니다.

퇴근하고 나면 아무것도 하고 싶지 않았고,

“오늘은 뭘 배웠지?”보다는

“오늘은 그래도 큰 사고는 없었다.”

이 문장으로 하루를 정리하던 날들이었어요.

배포–테스트–배포–테스트, 그리고 지연의 시작

이 반복이 계속되다 보니 자연스럽게 일정이 밀리기 시작했습니다.

처음엔 “오늘만 좀 더 보자”였고,

그 다음엔 “이번 주까지만 마무리하자”였고,

어느새 지연이 지연을 낳는 구조가 되어버렸어요.

이때 처음으로 통합 테스트의 진짜 무서움을 느꼈습니다.

통합 테스트는
문제를 ‘만들어내는’ 테스트가 아니라
문제를 ‘숨길 수 없게 만드는’ 테스트구나.

그리고 이 여파는 7월로 끝나지 않았습니다.

이 통합 테스트의 후폭풍은 8월까지 고스란히 이어지게 됩니다.

🧩 8월 — 통합 테스트의 후폭풍, 그리고 “이건 코드 문제가 아니었다”

7월이 통합 테스트의 시작이었다면,

8월은그 테스트가 남긴 후폭풍을 전부 떠안은 달이었습니다.

7월 말쯤에는 이런 희망 섞인 생각을 했어요.

“그래도 큰 건 다 나왔겠지…?”

“이제 좀 안정되겠지…?”

네.

역시나 틀렸습니다.

통합 테스트는 끝났지만, 문제는 이제 시작이었다

8월이 되자 통합 테스트에서 발견된 문제들이

하나씩 정리되는 게 아니라,

서로 엮이기 시작했습니다.

• 이 버그를 고치면 저쪽이 깨지고
• 이 흐름을 맞추면 다른 시나리오가 어긋나고
• 한 화면을 고치면 전체 동작이 미묘하게 변하고

이쯤 되니 머릿속에 계속 맴돌던 생각이 하나 있었어요.

“이거… 뭔가 이상한데?”

코드가 아니라, 구조가 문제라는 걸 깨닫다

처음엔 당연히

“로직을 더 꼼꼼히 보자” , “예외 처리를 추가하자”

이렇게 접근했습니다.

근데 아무리 봐도 문제는 코드 몇 줄이 아니었어요.

그때 처음으로 명확하게 느꼈습니다.

“이건 구조 문제다.”

• 흐름이 한눈에 안 보이고
• 상태가 여기저기 흩어져 있고
• 책임이 애매하게 나뉘어 있고
• 테스트 기준도 흔들리고 있고

결국

“왜 이런 문제가 반복되지?”라는 질문의 답은

“전체 구조를 제대로 그린 적이 없어서”

였습니다.

결국 시퀀스 다이어그램을 꺼내 들었다

사실 시퀀스 다이어그램은 원래 문서 설계 단계에서 했어야 하는 작업이었어요.

하지만 우리는 늘 그렇듯,

• “일단 개발부터”
• “시간 없으니까 나중에”
• “지금은 돌아가잖아”

이런 이유로 미뤄두고 있었죠.

그리고 8월이 되어서야 그 ‘나중에’가 찾아왔습니다.

시퀀스를 그리기 시작하자 비로소 보이기 시작했어요.

• 이 요청이 왜 여기로 가는지
• 이 상태가 왜 여기서 바뀌는지
• 이 타이밍에 이 로직이 왜 호출되는지

그리고 동시에 이런 생각도 들었습니다.

“아… 이걸 처음에 했으면

덜 고생했겠구나.”

구조 변경이라는 지옥문이 열리다

시퀀스를 정리하고 나니

선택지는 딱 두 개였습니다.

1. 지금 구조를 유지한 채 계속 땜질하면서 버틴다
2. 지금 아프더라도 구조를 다시 잡는다

결국 선택한 건 두 번째였습니다.

그리고 솔직히 말해서요.

구조 변경은 정말 미친 경험이었습니다.

• 어디까지 고쳐야 하는지 감이 안 오고
• 하나 고치면 다 고친 것 같고
• 근데 또 하나 안 고치면 전체가 흔들리고

이때는 진짜로

“다시는 구조 변경 안 하고 싶다…”

라는 말이 입 밖으로 몇 번이나 나왔어요.

---

문서를 미룬 대가를 몸으로 치르다

8월의 가장 큰 교훈은 기술적인 것보다 이거였습니다.

“문서는 귀찮아서 미루는 게 아니라,
나중에 나를 살리기 위해 쓰는 거다.”

문서를 제대로 정리하지 않은 상태에서의 개발은

• 기억에 의존하고
• 감에 의존하고
• “아마 이랬던 것 같아”로 움직이는 개발

이게 얼마나 위험한지 8월에 제대로 배웠습니다.

이때부터는 코드를 고치기 전에

• 흐름을 적고
• 조건을 정리하고
• 상태 변화를 글로 써보고

그 다음에야

코드를 손대기 시작했어요.

8월의 체감 난이도는 ‘멘탈’

7월이 체력 싸움이었다면, 8월은 멘탈 싸움이었습니다.

“이게 맞나?”
“지금 방향이 맞는 걸까?”
“괜히 더 망치고 있는 건 아닐까?”

이런 생각이 하루에도 몇 번씩 들었어요.

근데 아이러니하게도 그 와중에 느낀 게 하나 있었습니다.

“아… 나 지금

진짜 실무 개발하고 있구나.”

편한 선택이 아니라 맞는 선택을 하려고 고민하는 시간이었으니까요.

8월을 지나고 나서

제 개발 태도는 확실히 바뀌었습니다.

• “일단 고치자”보다 “왜 이렇게 됐지?” 를 먼저 묻게 됐고
  
• 코드보다 흐름을 먼저 보게 됐고
  
• 문서를 귀찮은 게 아니라 필수 장비로 보게 됐어요.
  

그리고 무엇보다,

“통합 테스트는 끝이 아니라,
진짜 개발의 시작이다.”

라는 걸 이 달에 확실히 배웠습니다.

🧯 9월 — 사용자성이라는 벽, 그리고 “우리는 아무것도 몰랐다”

9월은 제가 개발자로 일하면서

가장 큰 충격을 받은 달이었습니다.

7–8월이 테스트와 구조의 지옥이었다면,

9월은 그 모든 걸 통과한 뒤에 만난

현실 사용자라는 보스 스테이지였어요.

시험성적서와 납품, 그리고 동시에 시작된 사용자성 개발

9월에 들어서자

일정표에 새로운 단어가 추가됐습니다.

시험성적서.
그리고 납품.

이 두 단어가 등장한 순간, 개발의 기준이 완전히 바뀌었어요.

이전까진 “기능이 된다”가 기준이었다면,

이제는

• 이걸 처음 보는 사람이 이해할 수 있는가
• 실수했을 때 당황하지 않는가
• 다시 시도할 수 있는가

이 질문들이 모든 기능 위에 올라탔습니다.

“개발자들끼리는 다 알잖아요?”

솔직히 말하면 저희는 이런 착각을 하고 있었어요.

“이 정도면 설명 안 해도 알겠지.”

“이건 개발자면 바로 이해하지 않나?”

근데 사용자 테스트를 돌리는 순간 그 착각은 바로 깨졌습니다.

사용자들은

• 어디서 시작해야 하는지 모르고
• 다음 단계가 뭔지 모르고
• 잘못 눌렀는지조차 몰랐어요

그걸 보면서 진짜로 멍해졌습니다.

“어… 이게 그렇게 어려워?”

사용자성은 ‘조금 다듬는 문제’가 아니었다

처음엔 라벨을 바꾸고, 툴팁을 달고,

설명을 한 줄 추가하면 될 줄 알았어요.

근데 아니었습니다.

문제는 훨씬 깊었습니다.

• 시작 지점이 모호했고
• 중간 단계가 많았고
• 실패했을 때의 길이 없었어요

그래서 결국 프로세스를 다시 만들기 시작했습니다.

한 번 만들고

돌려보고

다시 부수고

또 만들고…

이걸 거의

10번 가까이 반복했습니다ㅜㅜㅜㅜ

---

개발자에게 당연한 흐름은, 사용자에게 공포였다

9월에 가장 충격이었던 건 이거였어요.

개발자 기준으로는 “자연스러운 흐름”이,

사용자 기준에서는 “이거 잘못하면 큰일 나는 거 아냐?” 로 느껴진다는 사실.

보안 제품이라는 특성까지 겹치니

사용자 입장에서는

• 한 번의 실수가
• 시스템 전체에 영향을 줄 것처럼 느껴졌고
• 그래서 더 아무것도 못 하게 되더라구요

그때 처음으로 이해했습니다.

사용자성은 편의성이 아니라,
심리적 안전감이다.

구현보다 어려웠던 것: ‘안심시키는 설계’

이 시점에서

개발보다 더 어려웠던 건

• 어디까지 막아야 할지
• 어디까지 자유를 줄지
• 어디서 “괜찮아요”라고 말해줘야 할지

이 판단들이었습니다.

그래서 9월엔

• 한 단계씩 진행 상황을 보여주고
• 되돌릴 수 있다는 걸 명확히 하고
• 잘못된 선택은 미리 막고

사용자가 불안해하지 않게 만드는 것에

집중하게 됐어요.

야근과 주말 출근, 그리고 웃픈 현실

이 과정은 시간이 정말 많이 들었습니다.

9월에서 끝날 줄 알았던 작업은 10월까지 이어졌고,

야근은 자연스러워졌고 주말 출근도 생겼어요.

월급날 야근수당과 주말수당이 찍힌 금액을 보고

잠깐이나마 아 이게 내 진짜 월급이면 좋겠다....

라는 생각이 들었다는 겁니다.ㅎㅎ,,,,야근수당 최고,,,

(+ 웃픈 토스 보이스피싱,,,)

이렇게 사용자성 때문에 정신이 혼미해지던 와중에

갑자기 토스에서 문자가 하나 왔습니다.

순간 심장이 철렁해서

“혹시 상반기에 지원했던게,,,?” 했다가 확인해보니

그냥 보이스피싱이었습니다.

토스가 나한테 직접 연락할 리가 없잖아요…

잠깐 설렜던 나 자신 매우 반성합니다.

그리고 다시 현실로 복귀했습니다.

🏸 현실 도피가 아니라, 현실 불편 해결용 사이드

9월에 회사 프로젝트 때문에 머리가 계속 터지고 있던 와중에

웃기게도(?) 하나의 사이드 프로젝트를 만들게 됐습니다.

남자친구가 배드민턴 점수랑 득실차를

매번 수기로 계산하면서 너무 힘들어하길래

“아 그냥 내가 만들어줄게…” 하고

급하게 점수 계산 사이트를 하나 만들었어요.(사실 클로드 코드 썼어요,,,잘하더라고요,,)

솔직히 UI는 엉망이었고 사용자성도 좋다고 말하기는 어려웠지만,

적어도 이제 계산이 틀릴 일은 없다는 것 하나로

그 사이트는 존재 이유가 충분했습니다.

프로젝트 구경은,,,,,여기 클릭
나만보는 배드민턴 점수집계
+혹시 사용자성이나 의견 좀 주세여,,,,,ㅠ 인덱스 db만 썼습니다...

회사에선 사용자성을 고민하느라 미치고 있었는데

사이드에서도 결국 똑같이 “사람이 덜 힘들게 하는 게 개발이구나”를

또 한 번 느끼게 된 순간이었어요.

9월을 지나고 나서 저는 확실히 알게 됐어요.

• 사용자는 우리가 생각한 대로 행동하지 않는다
• 설명 없는 자유는 오히려 독이다
• 제품은 기능이 아니라, 신뢰로 평가된다

라는 걸요

10월 — 시험성적서, 구조 개편, 그리고 “그래도 내가 잘 가고 있구나”

10월은 제가 개발자로서

도망치던 것들과, 동시에 처음으로 보상받은 것들이
한꺼번에 밀려온 달이었습니다.

9월이 사용자성으로 멘탈을 흔들었다면,

10월은 기술적으로도, 감정적으로도

꽤 복합적인 달이었어요.

---

시험성적서가 등장한 순간, 개발의 기준이 바뀌었다

10월에 들어서자 일정표에 본격적으로 등장한 단어가 하나 있었습니다.

시험성적서.

이 네 글자가 등장하자마자

그동안 “괜찮겠지”로 넘어가던 모든 것들이

전부 질문으로 바뀌었어요.

• 이 기능은 정말 안정적인가?
• 에러가 나면 얼마나 빨리 캐치할 수 있는가?
• 성능 저하는 없는가?
• 이 동작을 문서로 설명할 수 있는가?

이제는 “개발자의 감”이 아니라

완성도와 근거로 증명해야 하는 단계였습니다.

완성도를 요구받는 순간, 구조의 민낯이 드러났다

시험성적서를 기준으로 하나하나 점검하다 보니 확실히 보였습니다.

폴더 구조가 너무 비효율적이었다는 것.

그동안은

• “여기서도 쓰고”
• “저기서도 쓰고”
• “이 파일이 이 역할도 하고, 저 역할도 하는”

상태였는데,

시험성적서 기준으로 보니까

• 수정 범위가 너무 넓고
• 에러 추적이 어렵고
• 테스트 기준도 모호해지고

결국 결론은 하나였습니다.

“역할 기반 구조로는 한계다.”

그래서 10월에

역할 기반 → 기능 기반 폴더 구조로
프론트엔드 구조를 아예 갈아엎었습니다.

이미 일정이 촉박한 상황에서

이 결정을 내린 건

솔직히 말해서 도박에 가까웠어요.

근데 동시에 이런 생각도 들었습니다.

“지금 안 바꾸면

이건 평생 고통이다.”

그래서 시간내서 빠르게 바뀌버렸습니다..

그리고 회의 중, 나를 찌른 한 순간

10월 즈음, 에러 원인을 찾기 위한 회의 중에

이야기가 자연스럽게

• 프로세스
• 스레드
• 내부 동작 구조

이쪽으로 흘러갔습니다.

그런데 그때 제가 이 흐름을

명확하게 설명하지 못하겠더라구요.

순간 머릿속이 하얘졌어요.

“나는 프론트엔드 개발자인데…”

“이건 나중에 공부해도 되지 않나?”

그동안 프론트엔드라는 이유로

OS, 프로세스, 스레드 같은 영역을

은근슬쩍 피해왔던 게

그 순간 그대로 드러났습니다.

부끄러웠어요. 진짜로.

“프론트엔드라서”라는 변명을 버리기로 했다

회의가 끝나고 혼자 앉아서 이런 생각이 들었습니다.

“이건 프론트 범위를 벗어난 문제가 아니라,

지금 내가 다루는 시스템의 일부잖아.”

그래서 그때부터 마음속에서 이 말을 지웠어요.

“나는 프론트엔드 개발자니까.”

대신 이렇게 바꿨습니다.

“나는 이 시스템을 만드는 개발자니까.”

완벽하진 않지만,

프로세스와 스레드, OS 기본 구조를 다시 공부하기 시작했고,

적어도

“왜 이런 문제가 터질 수 있는지”는

설명할 수 있어야겠다고 다짐했습니다.

그런데, 이 모든 와중에 찾아온 작은 보상

정신없이 구조를 바꾸고,

시험성적서를 준비하던 10월에

뜻밖의 연락 하나를 받았습니다.

코드잇 스프린트 커리어 프로그램 우수수료자 선정.

이력서 공개와 함께

짧은 인터뷰를 진행하게 됐고,

우수수료자로 뽑혔다는 이야기를 들었을 때

솔직히 기분이 정말 좋았습니다.

네이버 포인트 5만 원도 받았고요. (이건 중요합니다 😄)

하지만 그보다 더 좋았던 건,

현직 대기업 개발자분이
제 포트폴리오와 이력서를 보고
“잘했다”고 평가해줬다는 사실이었어요.

---

“아… 나, 방향은 맞구나”

10월은 계속해서 부족함을 느끼고,

자존심도 많이 흔들렸던 달이었는데,

이 작은 인정 하나가 제 마음을 꽤 단단하게 잡아줬습니다.

“아, 내가 완벽하진 않아도

헛되게 가고 있는 건 아니구나.”

그래서 그때 처음으로

이런 생각이 들었어요.

“앞으로도 그냥, 꾸준히만 하자.”

조급해하지 말고,

비교하지 말고,

지금처럼 계속 쌓아가면 된다고.

10월은

힘들고, 아프고, 많이 반성했던 달이었지만

동시에 처음으로 ‘외부에서의 인정’을 받은 달이기도 했습니다.

• 구조의 중요성을 몸으로 배웠고
• “프론트엔드라서”라는 변명을 내려놓았고
• 그리고, 내가 잘 가고 있다는 신호도 받았습니다.

그래서 10월을 한 문장으로 정리하자면 이거예요.

“아직 부족하지만,
그래도 계속 가도 되겠다고 느낀 달.”

🧪11월 — 시제품 이후, 그리고 “제품은 개발자 뜻대로 쓰이지 않는다”

11월은 제가 처음으로

‘이제 이건 팔만한 제품용이 아니다.’라는 말을

몸으로 실감한 달이었습니다.

10월까지는 “그래도 아직 내부용이지” “시연 단계니까 괜찮겠지”

라는 마음이 아주 조금은 남아 있었는데,

11월에 들어서면서 그 여지는 완전히 사라졌어요.

시제품 다음 단계는, 생각보다 훨씬 어려웠다

11월부터는 명확하게 기준이 바뀌었습니다.

“이건 나중에 시장에 나가도 되는 기능인가?”

이 질문이 모든 개발의 출발점이 됐어요.

그리고 솔직히 말하면,

시제품보다 이 단계가 훨씬 더 어려웠습니다.

시제품 단계에서는 조금 불편해도, 조금 투박해도,

“컨셉은 보여줬잖아”로 넘어갈 수 있었거든요.

근데 제품은 아니었습니다.

• 한 번 더 눌러야 하는 버튼
• 헷갈리는 용어 하나
• 설명 없는 화면 전환

이 모든 게

바로 ‘문제’가 됐어요.

기술 시연, 그리고 예상 못 한 장면들

11월에는 인천으로 기술 시연도 진행했습니다.

이 시연에서 제가 가장 크게 충격받은 장면이 하나 있어요.

그냥, 정말 그냥

‘닫기 버튼’을 하나 추가해준 기능이 있었거든요.

개발자 입장에서는 “있으면 편하겠지” 정도의 버튼이었는데,

사용자는 그 버튼을 눌러서

아예 다음 단계를 진행하지 않고 그대로 종료해버렸습니다.

그 장면을 보는 순간

머릿속이 잠깐 멈췄어요.

“어… 아니… 그게 그 용도가 아닌데…”

사용자는 항상 ‘가장 쉬운 탈출구’를 찾는다

그 시연을 계기로 확실히 깨달은 게 있습니다.

사용자는
우리가 의도한 흐름을 따르지 않는다.사용자는
가장 쉬운 길을 선택한다.

개발자 입장에서는 “이건 중간에 나가면 안 되는 단계”였지만,

사용자 입장에서는 “지금 안 해도 되는 것”이었던 거죠.

이걸 보고 나서

선택지에 대한 기준이 완전히 바뀌었습니다.

• 정말 필요한 선택인가?
• 사용자가 도망가도 괜찮은 지점인가?
• 아니면 반드시 안내하고 붙잡아야 하는 단계인가?

이걸 하나하나 다시 정의하기 시작했어요.

자유는 안내 없이는 독이 된다

11월에 가장 크게 바뀐 제 생각은 이거였습니다.

“사용자에게 선택지를 많이 주는 게
항상 좋은 건 아니다.”

우리는 “선택이 많으면 좋겠지”라고 생각했지만,

실제 사용자는 선택이 많을수록 더 불안해했습니다.

특히 보안 제품이라는 특성 때문에

사용자 입장에서는

• 한 번의 실수가
• 큰 문제로 이어질 것처럼 느껴졌고
• 그래서 아예 아무것도 안 하게 되는 경우도 많았어요.

그때 깨달았습니다.

사용자성은 편의성이 아니라,
‘안심시키는 설계’라는 걸요.

11월이 남긴 가장 큰 깨달음

11월을 지나고 나서 제 머릿속에 남은 문장은 이거였습니다.

“제품은 개발자가 만드는 게 아니라,
사용자가 완성한다.”

아무리 구조가 좋아도, 아무리 코드가 깔끔해도,

사용자가 이해하지 못하면 그건 아직 제품이 아니었습니다.

11월은 이 사실을 가장 정직하게 마주한 달이었어요.

🔐 12월 — 안정성, 로그, 그리고 “사용자보다 먼저 고치는 사람”

12월은 화려하지 않았고, 눈에 띄는 새 기능도 많지 않았지만,

지금 돌이켜보면

하반기에서 가장 중요한 걸 만든 달이었습니다.

11월까지 사용자성과 제품의 무게를 배웠다면,

12월은 그걸 ‘지속 가능한 상태’로 만드는 달이었어요.

보안기능 인증시험, 그리고 현실의 시작

12월의 시작은 보안기능 인증시험 준비였습니다.

이건 단순히 “기능이 있다”를 증명하는 시험이 아니었어요.

• 실제 환경에서도 안정적인지
• 예상 못 한 상황에서도 버티는지
• 문제가 생기면 추적 가능한지

이걸 전부 보여줘야 했습니다.

그리고 이 과정에서 그동안 모르고 지나쳤던 사실 하나를 뒤늦게 알게 됐어요.

OS가 다르면, 에러도 다르다

이미 나간 기능들에서 OS별로 전혀 다른 에러가 발생하고 있다는 걸

12월에 와서야 명확하게 인지했습니다.

그게 정말 무서웠던 이유는 이거였어요.

에러는 있었는데,
우리는 그걸 모르고 있었다.

사용자는 그냥 “뭔가 이상한데?” 하고 넘어가거나,

아예 말을 안 했을 수도 있고,

우리는 “잘 돌아가겠지”라고 생각하고 있었던 거죠.

이걸 깨달은 순간, 등골이 살짝 서늘해졌습니다.

로그가 없으면, 아무것도 아니다

그래서 방향을 완전히 바꿨습니다.

12월의 키워드는 로그였습니다.

• 모든 에러를 파일로 남기고
• 그 로그를 자동으로 서버로 수집하고
• 원격에서 바로 확인할 수 있도록

에러를 ‘기록되지 않는 사고’가 아니라

‘관리 가능한 이벤트’로 바꾸는 작업이었어요.

Redis를 도입해서

에러 상태를 빠르게 확인할 수 있게 만들었고,

이제는

• 언제
• 어떤 환경에서
• 어떤 에러가
• 어떤 흐름에서 났는지

를 한 번에 볼 수 있는 구조를 만들었습니다.

안정성이란, 에러가 없는 상태가 아니었다

12월을 지나며 제가 완전히 바뀐 생각이 하나 있습니다.

이전엔 “안정적이다”라는 말을

에러가 없는 상태라고 생각했어요.

근데 아니었습니다.

안정성이란
에러를 빨리 알아차리고,
빨리 고칠 수 있는 상태였습니다.

이미 자동 업데이트 기능을 넣어둔 덕분에,

• 에러를 발견하고
• 수정하고
• 사용자 개입 없이 배포하는 흐름을

꽤 빠르게 만들 수 있었어요.

그때 처음으로 이런 생각이 들었습니다.

“아… 이 정도면

그래도 사용자한테 미안하지는 않다.”

그리고, 정말 오랜만에 나를 위한 개발

12월 내내 회사 일에 치여 살다 보니

사이드 프로젝트는 거의 손도 못 댔는데,

연말에 딱 하나 꺼낸 게 있었습니다.

3D 크리스마스 트리.

three.js로 만들었고, GPU를 살살 녹이면서

불빛이 반짝이는 트리를 만들었어요.

이 프로젝트는 완성도를 따지기보단,

“아, 나 아직 개발 좋아하네.”

이 감정을

다시 확인하기 위한 작업이었습니다.

사실 이 시점엔 체력도, 멘탈도 꽤 바닥이었어요.

그래도 전구가 반짝이는 걸 보면서

• 내가 만든 게 눈앞에서 움직이고
• 코드가 실제 화면이 되고
• ‘재밌다’는 감정이 다시 올라오는 순간

그게 참 좋았습니다.

개발을 좋아해서 시작했는데,

중간에 그 이유를 잠깐 잊고 있었구나 싶었어요.

크리스마스 트리 구경하러가기
3D 크리스 마스 트리 회고록 보러가기

🌙 2025년 하반기를 닫으며

2025년 하반기는

솔직히 말해서 정말 많이 무너지고, 많이 지치고, 많이 배웠던 시간이었습니다.

단위 테스트로 안심했던 코드들은 통합 테스트에서 깨졌고,

구조를 미뤄둔 대가는 일정과 멘탈로 돌아왔고,

“개발자끼리는 알겠지”라고 만든 기능들은 사용자 앞에서 전부 멈췄습니다.

그 과정 속에서 저는

코드를 잘 짜는 개발자가 아니라

끝까지 책임지는 개발자가 되어가고 있었다는 걸

뒤늦게 깨닫게 된 것 같아요.

혼자 야근하면서 좌절하던 순간도 많았지만,

회사 분들의 응원과 믿음,

특히 상사분들이 늘 이뻐해주시고 격려해주신 덕분에

끝까지 버틸 수 있었습니다.

그래서 이 하반기는

힘들었던 기억보다도

“그래도 나는 계속 가고 있구나”라는 감정으로 남아 있습니다.

Electron을 통해

웹 밖의 세계를 처음 경험했고,

솔루션과 시스템을 만드는 재미를 알게 되었고,

그래서 더 넓은 개발 영역에도 욕심이 생겼습니다.

2026년에는

three.js를 제대로 공부해보고 싶고,

vue.js도 깊게 다뤄보고 싶고,

언젠가는 로봇과 같은 하드웨어와 맞닿은 개발에도 도전해보고 싶습니다.

아직은 부족한 게 너무 많지만,

올해를 지나며 확실히 느낀 건 하나예요.

개발자는 무너지면서 자라고,

버틴 만큼 결국 다음 단계로 나아간다.

그래서 저는 내년에도

겁먹지 않고, 미루지 않고,

계속 배우고 실험하면서 나아가 보려고 합니다.

프론트엔드 개발자 송연지,

2026년에도 성장 중으로 살아가겠습니다. 🚀💙

---

마지막으로 이 긴 하반기 회고를

여기까지 읽어주신 분들께 진심으로 감사드립니다.

저는 여전히 느리고, 부족하고,

남들보다 돌아가고 있다는 느낌을 받을 때도 많지만

그래도 올해를 지나면서 한 가지는 확실히 믿게 됐어요.

속도는 늦을 수 있어도

방향만큼은 맞는 개발자로 가고 싶다.

빠르게 성장하는 개발자도 멋있지만,

저는 실수하더라도 배우고,

무너지더라도 기록하고,

결국엔 단단해지는 개발자가 되고 싶습니다.

혹시 이 글을 읽고 있는 누군가도

지금 느리다고 느껴지거나, 비교 때문에 힘들다면

우리 그냥 이렇게 말했으면 좋겠어요.

“늦어도 괜찮다. 멈추지만 않으면 된다.”

개발자는 결국

계속 배우는 사람이 이긴다고 저는 믿습니다.

그래서 저는 내년에도 계속 배우고, 도전하고, 버틸 거고

이 글을 읽는 모든 개발자 분들도

각자의 자리에서 원하는 방향으로 끝까지 나아가시길

진심으로 응원합니다.

우리 모두 2026년도 화이팅입니다. 🚀💙!