기록

5월 딱 한달. 제주도에서 한달동안 살아보았다. 짧다면 짧고 길다면 긴 시간 동안 그 안에서 느꼈던 순간들과 생각들을 하나씩 정리해보려고 한다. 1. 왜 제주도 한달살이를 하게 됐는지❓한 달 살이의 시작은 여자친구의 교생 실습이었다. 선생님이 되기 위해 한 달 동안 교생 실습을 해야 했는데, 서울에서도 할 수 있었지만 여자친구의 로망이었던 “조금 더 특별하게, 제주도에서 해보고 싶다”는 마음에서 제주 한 달 살이가 시작됐다.나 역시 마침 반복되는 일상에서 잠시 벗어나고 싶었던 시기였고, 제주도에서의 생활이 어떤 느낌일지 궁금하기도 했다. 평소와는 다른 환경에서 지내보는 경험 자체가 꽤 의미 있을 것 같다는 생각이 들었다.제주 한 달 살이를 5월에 계획하면서, 그 전에 프리랜서 계약 종료 시점을 맞춰두었..

이번에 세금계산서 자동화를 기능을 맡으면서, 어떤 데이터 기반으로 자동화를 하고 어떻게 설계를 하고 어떻게 자동화를 했는지 그리고 중간에 발생했던 문제를 어떻게 해결했는지 등 경험을 하고자 하여 글을 작성합니다. 1. 왜 세금계산서 자동화하게 됐는지? 📚세금계산서는 정기 과금, B2B 상품 판매, 외주 거래, 월세, 광고/마케팅 비용 등 다양한 비즈니스 상황에서 필수적으로 발행됩니다. 초기에는 발행 건수가 많지 않기 때문에 수기로 처리해도 큰 문제가 없습니다.하지만 발행 건수가 수십, 수백, 수천 건으로 늘어나면 상황이 완전히 달라집니다.사람이 직접 처리하다 보면 금액 입력 실수, 중복 발행, 발행 대상 누락 등의 문제가 발생하기 쉽고, “누가 누구에게 발행했는지”를 일일이 추적하는 것도 점점 어려워집..

올해는 드디어 나이 앞자리가 2에서 3으로 바뀌는 해다. 이제 30살이다.귀여웠던 29살을 지나 30살이 되면서 느꼈던 것들을 정리해보며, 2025년 회고를 써보려고 한다. 내향인의 커뮤니케이션 생존기나의 MBTI는 ISTJ이다. 내향적이면서 계획적인 성격이 장점이기도 하지만, 동시에 단점이 되기도 한다. 내향적인 성격이라 그런지, 말을 꺼내기 전에 자꾸 상대방의 기분이나 생각부터 신경 쓰다 보니 정작 내가 하고 싶은 말을 못할 때가 많았다.예를 들면친하지 않은 동료들과 함께 있을 때,나이 차이가 많이 나는 상사에게 피드백을 요청해야 할 때,옆자리에 앉아 있어도 하루 종일 한마디도 못 하고 내 모니터만 바라보고 있을 때가 있었다.돌아보면, 남에게 큰 관심이 없고 말을 걸 때 고민이 너무 많은 성격이 ..

이 책은 2025년 4월 28일에 출간된 따끈따끈한 신간이다. 배드민턴에서 땀을 나눈 파트너에게 추천을 받기도 했고, 팀장님의 블로그에서 이 책에 대한 언급을 보며 자연스럽게 관심을 갖게 되었다.내용은 주니어 개발자가 반드시 알아야 할 핵심 주제들을 여러 카테고리로 나누어 정리한 구성이다. 만약 내가 신입 개발자였더라면, 아는 것보다 모르는 게 훨씬 많았을 것이고, 책을 이해하는 데도 훨씬 더 많은 시간이 걸렸을 것 같다.만 3년 차가 된 지금 읽어보니, 알고 있던 내용은 복습처럼 다시 머릿속에 정리되었고, 몰랐던 부분은 새롭게 배울 수 있었다. 실제로 읽다가 “이건 처음 듣는 개념인데?” 싶었던 부분도 몇 군데 있었다.아래에는 내가 읽으며 도움이 되었던 내용, 이전에는 몰랐던 내용, 나중에 다시 꺼내 ..

1. 문제 배경📚마케팅 프로젝트를 진행하던 중 외부 서비스인 Shopline API를 사용해야 했습니다. 하지만 이 API에는 요청 제한(Rate Limit)이 걸려 있었고, 이 제한은 클라이언트의 요금제 플랜에 따라 달라졌습니다. 기업 요금제에서는 제한이 없지만, 문제는 해당 클라이언트의 요금제 플랜 업그레이드를 우리가 직접 제어할 수 없고 클라이언트 측에서 진행해야 하는 상황이었습니다.Shopline API는 토큰 요청, 리프레시 요청, 기프트 카드 생성, 웹 훅 구독 등 여러 가지 작업에 사용되는데, 이 모든 요청은 1초에 4회라는 제한이 있었고, 특히 토큰/리프레시 요청은 공용 제한이라 여러 작업에서 동시에 요청이 몰릴 경우 HTTP 429 Too Many Requests 오류가 빈번하게 발생했..

이번 글에서는 동기 방식 통신의 한계를 해결하기 위해 메시지 큐를 도입 + 메세지 유실이 없는 이야기를 소개하겠습니다 🚀 1. 문제 배경📚프로젝트 구조상 통계 서버와 API 서버가 분리되어 있었고, 처음에는 이 두 서버 간의 통신을 동기 방식의 API 호출로 처리하고 있었습니다. 그러나 이 방식은 여러 가지 문제를 야기했습니다.가장 큰 문제는 한쪽 서버에 장애나 지연이 발생하면 다른 쪽 서버도 그 영향을 직접적으로 받는다는 점이었습니다. 예를 들어, 통계 서버에 문제가 생기면 API 서버의 요청도 지연되거나 실패하게 되어 시스템 전체의 안정성이 떨어질 수밖에 없었습니다.또한, 속도 측면에서도 비효율적이었습니다. API 서버가 통계 처리 결과를 기다리는 동안 스레드가 블로킹되고, 이는 곧 리소스 낭비..