흔들리지 않고, 후회 없이
My path, my pace, no regrets.-
2026년 7월 생각 정리
이 글은 필자의 지극히 개인적인 생각을 정리한 내용임을 감안하여 읽어주시면 감사하겠습니다.
Prologue
지난 1월 이후로 매달 생각 정리를 블로그에 올리려고 했는데, 이런저런 이유로 6개월 만에 올린다.
상반기에 있었던 일들 중에 기억에 남는 것과, 지금 집중하고 있는 것, 앞으로 그려나가야 할 것들을 머릿속에만 두지 않고 글로 남겨두려고 이 글을 쓴다.
새로운 회사
지난 3월에 새로운 회사에 들어갔다.
이직하기 전에 세 곳에 합격했는데, 결론부터 말하면 콘텐츠 플랫폼 회사인 포스타입을 선택했다. 연봉이나 안정감보다는, 내가 앞으로 성장하고 싶은 방향과 가장 맞닿아 있는 곳이라고 봤다. 그동안 가고 싶었던 B2C 영역이었고, 콘텐츠 기반 플랫폼을 운영하면서 얻을 수 있는 경험들을 배우고 싶었다.
들어오고 나서 온보딩을 거쳐 작은 업무부터 맡았는데, 그 중 하나가 슬로우 쿼리 개선이었다. 쿼리 자체보다 이 쿼리가 왜 이렇게 짜였는지, 어떤 화면에서 어떻게 불리는지를 파악하는 데 시간이 더 걸렸다. 그때 든 생각은, 결국 차분하게 문제를 잘 정의하는 게 먼저라는 것이었다. 그래서 수습 3개월 동안에는 업무 외 시간에 그에 필요한 기술들을 조금씩 공부해나갔다. 여러 기술 중에서도 DB 쪽이 중요하다고 생각해서, 관련 서적을 읽고 정리하면서 실무에서는 어떻게 쓰이고 있는지 확인했다. 지금은 조금씩 기여도 해나가고 있다.
지금은 회사의 핵심 가치 중 하나인 ROI 관점으로 우선순위를 세워 일하는 과정에서, 백엔드뿐만 아니라 데이터 분석과 관련된 업무도 같이 하고 있다. 그 과정에서 리텐션, 퍼널 분석, A/B 테스트 같은 그로스 관점의 분석으로 비즈니스 인사이트를 뽑아내려면 관련 지식을 채워야겠다는 생각이 들었다. 그래서 그로스 관련 책들을 읽으면서, 지금 맡고 있는 도메인의 지표를 정의하고 발굴하는 작업도 병행하고 있다.
앞으로는 백엔드만이 아니라 데이터적인 사고와 그로스 기반의 업무 역량도 같이 길러나가고 싶다.
AI와 학습
이제는 코딩의 상당 부분을 AI가 맡을 만큼 품질이 좋아졌고, 나도 실제로 그렇게 일하고 있다. 다만 조심해야 할 부분이 있다. 코딩을 많이 해봤고 실무 경험이 많은 개발자라면 AI로 생산성을 극대화할 수 있을 것이다. 여기서 말하는 ‘경험이 많은 실무자’를 백엔드 기준으로 내 나름대로 정의해보면 이렇다.
- 유지보수하기 좋은 코드를 넘어 사람이 읽고 바꾸기 쉬운 코드를 만들어본 사람
- 규모가 큰 시스템에서 좋은 설계와 복잡도를 다루며 개선해나가는 사람
- 배포하기 쉬운 구조, 운영하기 쉬운 구조, 안정성과 성능을 위한 구조를 고민하고 실행에 옮겨본 사람
- 실시간 대용량 트래픽과 지연이 짧은 이벤트 처리를 겪어보고, 까다로운 문제를 끝까지 넘어본 사람
이 기준으로 보면 나는 아직 부족하다. 그래서 AI에게 코딩을 통째로 맡기기보다는, 내 경험을 객관적으로 보고 AI에 기댈 부분과 직접 할 부분을 나눠서 잡으려고 한다. 이미 해본 일이라면 AI를 적극적으로 쓰지만, 처음 해보는 일이라면 직접 코딩하면서 배운다. 그래야 다음에 비슷한 일이 왔을 때 유연하게, 때로는 간단하게 처리할 수 있다고 생각하기 때문이다. AI가 알려준 답이 늘 정답인 것도 아니고 실제로 틀린 적도 있으니, 새로운 경험일수록 직접 타이핑하면서 익혀야 한다고 본다.
AI가 일하는 방식에 이만큼 들어왔어도, 학습만큼은 깊게 파서 내 것으로 만들어야 한다. 안 그러면 AI가 요약해준 것만 보고 공부했다고 착각하게 되고, 나중에 비슷한 문제를 만나도 남에게 설명하지 못할 정도의 지식만 남은 채 계속 AI에 기대게 되더라. 무엇을 공부할지 정하고 찾아보는 속도는 AI의 도움을 받되, 설명해보는 연습과 근거를 검증하는 일은 직접 해야 하지 않을까 싶다. 먼저 묻지 말고, 내가 아는 것을 먼저 적고 검증하고 보완하는 식으로 의도적인 수련을 해야 한다고 본다. 이걸 반복하다 보면 AI가 없던 시절보다 오히려 학습 속도가 빨라질 것 같다.
AI 이후의 개발자
AI로 제품을 만들어내는 속도도 이전보다 많이 빨라졌다. 그런데 만드는 속도가 빨라졌다고 내 일이 줄어든 느낌은 아니다. 오히려 빨리 만든 만큼, 놓친 게 없는지 확인하는 데 시간이 더 든다. 그래서 이제는 속도보다 ‘디테일’이 중요해지는 게 아닐까 싶다.
- 구현이 쉬워지고 출시가 빨라진 만큼, 에러가 날 확률도 같이 줄어야 한다. 그러려면 검증하는 부분을 더 꼼꼼하게 손봐야 한다.
- 같은 기능이라도 앱을 터치했을 때 미세하게 반응하는 애니메이션처럼 인터랙션이 더 자연스러워야 하고, 쿼리 개선으로 성능이 눈에 띄게 빨라져야 하고, 엣지 케이스까지 세심하게 처리되어야 한다.
- 사용자에게 더 가치 있는 제품이 나오도록 실험하는 횟수도 늘어야 한다.
예전에는 기능 요청을 받으면 일정부터 계산했다. 요즘은 그 전에 이 기능이 사용자에게 어떤 가치를 주는지를 먼저 생각하게 된다. 만드는 일이 쉬워진 만큼, 무엇을 왜 만들지 판단하는 힘, 즉 비즈니스 전략을 보는 눈을 길러야 하지 않을까 싶다. 개발자가 비즈니스에 관여한다는 말도 거창한 게 아니라, 이 정도의 변화를 뜻한다고 본다.
외부 활동
2022년부터 지금까지 개발과 관련된 외부 활동을 꾸준히 조금씩 해왔다. 그런데 2025년 어느 순간부터 이 활동의 중요도가 내 안에서 점점 옅어지고 있다.
초반에는 실무 경험이 없다 보니 어딘가에는 속해 있어야 한다는 조바심이 컸다. 그러다 실무 경험이 쌓이고 외부 활동 경험도 쌓이면서, ‘효율’이라는 기준이 자꾸 마음에 걸렸다. 평일 저녁이나 주말에 쏟은 시간만큼 나에게 돌아오는 게 큰가 생각해보면, 그렇지 않은 경우가 더 많았다. 특히 동아리는 고연차보다 저연차 위주로 모이다 보니, 나와 비슷한 경험을 가진 사람이 많아 배움의 크기도 줄어들었다.
물론 외부 활동을 하며 여러 사람을 만나고, 그중에 좋은 사람을 만나는 가치는 크다고 본다. 다만 어느 시점 이후부터는 그동안 알게 된 사람들만으로도 충분하다고 느꼈다. 그리고 외부 활동에서 얻기 어려운 정보는 오히려 링크드인이나 X에서 영향력 있는 분들이 가끔 올리는 글 하나하나가 더 인상 깊고 배울 점이 많기도 했다.
예전에는 개발자라는 직무에 한정된 기술을 배우려고 참여했다면, 이제는 좀 더 넓은 관점에서 커리어를 설계하려는 목적으로 참여하지 않을까 싶다. 지금 참여하고 있는 우아한유스방도 그런 이유로 들어왔고, 지금은 만족감과 감사함을 느끼고 있다.
커리어 밖의 것들
올해 상반기까지는 평일 주말 가리지 않고 커리어와 관련된 기술과 지식을 1순위에 두고 공부했다. 그런데 이제는 대학생 때, 혹은 그 이전에 해왔던 취미나 해보고 싶었던 취미를 하면서 나를 조금 넓게 가져가야 행복하다는 걸 느꼈다.
그래서 요즘은 업무와 상관없는 독서를 하고 있다. 지금은 ‘안녕은 작은 목소리로’와 ‘마음으로 경영하기’ 두 권을 읽는 중이고, 한 달에 한두 권 정도는 보는 것 같다. 그리고 일본어를 공부하고 있다. 작년 하반기에 제이팝에 빠지면서 원래 관심 있던 일본어에 더 마음이 갔고 이참에 시작했다.
마무리
돌아보면 상반기의 변화는 하나로 이어져 있었다. 회사를 옮긴 것도, 공부하는 방식을 바꾼 것도, 외부 활동을 줄인 것도, 결국 어디에 시간을 쓸지 다시 정한 일이었다.
예전에는 매일 무엇을 어떻게 하겠다는 계획을 세세하게 세웠는데, 이제는 조금 러프하고 유연하고 단순하게 사는 게 더 편하고 나에게 맞는 방식인 것 같다.
커리어 안팎으로 다양하게 삶을 채워나가고 있지만, 어디에 휘둘리지 않고 적당함을 유지한 채 ‘나’를 지키면서 이어가지 않을까 싶다. 하반기에도 크게 다르지 않을 것 같다. 다만 그때 가서 이 글을 다시 읽어보고 싶다.
-
2026년 1월 생각 정리
이 글은 필자의 지극히 개인적인 생각을 정리한 내용임을 감안하여 읽어주시면 감사하겠습니다.
Prologue
나는 개발뿐 아니라 다양한 분야에 호기심이 많고, 배우는 것을 즐긴다. 그래서인지 주변 친구들과 비교했을 때 유독 생각이 많고 하고 싶은 일도 많은 편인 것 같다. 이런저런 생각의 조각들을 흘려보내지 않고 정돈하기 위해, 2026년부터는 매달 기록의 장을 마련해보려 한다.
-
시스템 장애를 처리하기 위해 재처리 및 DLQ 적용하기
모든 기술 선택에는 트레이드오프가 존재합니다.
이 글에서 소개하는 방식이 유일한 정답은 아니며, 각자의 비즈니스 환경에 맞는 최선의 선택을 고민하는 데 작은 참고가 되길 바랍니다.
Prologue
대규모 트래픽을 처리하는 비즈니스 로직에서 가장 두려운 상황 중 하나는 비동기 처리 중 발생하는 데이터 유실입니다. 특히 쿠폰 발급과 같이 유저에게 민감한 보상이 주어지는 시스템에서, API 응답은 성공했지만 내부 장애로 실제 발급이 누락된다면 서비스 신뢰도에 치명적인 타격을 입게 됩니다.
이번 글에서는 쿠폰 발급 시스템을 예시로, Consumer 서버에서 처리 도중 DB 장애 등의 시스템 예외가 발생했을 때 어떻게 메시지를 유실 없이 보호하고 재처리하는지, 그 설계와 구현 과정을 공유합니다.
예상 독자
-
시스템 장애(DB) 발생 시 재처리에 대한 로직에 대해 해결 과정이 궁금하신 분
-
SpringBoot 환경에서 재처리 방식 및 DLQ 처리 과정이 궁금하신 분
(이 글은 재처리/DLQ에 대한 기본 개념과 경험이 있는 독자를 대상으로 작성했습니다.)
-
-
'삶을 재구성하는 관계의 법칙, 사람을 남기는 사람' 책 리뷰
이 글은 ‘삶을 재구성하는 관계의 법칙, 사람을 남기는 사람‘이라는 책을 읽고, 책의 내용과 함께 필자의 개인적인 생각을 정리한 글입니다.
시작하며
나이가 들수록 인간관계의 중요성을 더 많이 체감한다. 스스로 바쁘게 살아가며 노력한 것에 비해 성과가 나지 않아 지친 부분도 있었고, 그 과정에서 가족이나 친구 등 주변 관계에 소홀했던 것은 아닌가 싶어 생각을 정리하고 싶었다.
마침 생일날 합정동의 한 서점에 들렀다. 사장님께 현재의 고민을 말씀드리니 이 책을 추천해 주셨고, 시간 날 때마다 조금씩 읽으며 마음에 남는 문장들을 기록하기 시작했다.
이 책의 저자는 프롤로그에서 ‘관계의 안정기’에 접어들며 이 글을 쓰게 되었다고 고백한다. 관계의 어려움을 어떻게 극복해 왔는지에 대한 그의 이야기가, 관계에 대해 고민하는 이들에게 한 줌의 도움이 되길 바라는 마음을 담았다고 한다.
-
2026 Dev History
2026 Dev History
- 2025 Dev History에 이어 2026년에도 내가 공부하면서 배운 내용을 꾸준히 기록해두자.
- DevHistory 4
- Essay 2
- Java 10
- Spring 15
- SpringBoot 17
- JPA 13
- MySQL 3
- Flyway 1
- Kafka 8
- Technology 22
- GoodCode 7
- Side_Project 20
- Retrospective 4
- AlgorithmSkill 3
- LeetCode 2
- Algorithm 70
- SQL 9
- OS 14
- Database 8
- Network 7
- HTTP 7
- DataStructure 5
- Linux 4
- Woowacourse 4
- Git 9
- AssertJ 1
- IntelliJ 5
- Probability-Statistics 5
- Electronic-Finance 13
- Business-Statistics 13
- Competition 1
- Book 6
- Workout 7
- E.T.C 8