개발과 일상

개요매년 스프링캠프를 지원했지만 올해 처음으로 당첨됐다. 최근 안좋은 일도 있었지만 안좋은 일만 있는 건 아닌 것 같다. 올해는 스프링 캠프 10주년이라 힘을 주고 준비했다는데... 제법 기대를 하고 들으러 왔다. 세션은 다음과 같았다. 첫 세션이 제일 고민됐다. 다양한 종류의 세미나를 들으러다니는 이유가 가능한 많은 사례들을 보고 싶어서인데, 첫세션을 ML이 아니라 SaaS를 개발하는데 있었던 일들을 듣는 것도 충분히 재밌어보였기 때문이다. 하지만 ML쪽도 재밌어보였고 HR이란 분야가 너무 핏한 분야 같아서, 일단은 리젠시홀로 스타트를 끊었다. 후기를 작성할 때마다 내 생각도 주석을 조금씩 남기는데, 파란색이 내가 한 생각들이다. 1. 난 spring에서 ml 서빙을 해봤어요오랫동안 ml에서 주로 ..

어느 날 유튜브 알고리즘에 떠밀려 보게 된 영상 하나."총자산이 금리보다 +2% 이상 성과를 내줘야 노후 준비가 된다." 이 한마디가 나에게 꽤나 큰 충격으로 다가왔다. 작년 초부터 한국은행이 금리를 내리기 시작했고, 은행 예금 금리는 순식간에 하락했다.5.7% → 4.5% → 3.5%딱 2년 만에 일어난 변화다. 적금도 실질 금리를 이해하고 나선 더 이상 좋은 상품이 아니었다. 이제는 정말 ‘투자’를 고민할 수밖에 없었다. ☝️ 첫 걸음: 채권 펀드 첫 시작은 작년 말, 만기된 적금 돈으로 은행 PB가 추천해준 채권 펀드에 투자했다. 연 4.5~5% 정도 수익률이었고, 마침 당시 달러 환율은 1480원. "이 타이밍엔 원화를 들고 있는 게 낫겠다"는 판단을 했고, 꽤 큰 비중을 넣었다. 결과적으론 ..

개요난 꽤 오랫동안 "서비스 로그를 어떻게 남겨야 할까?"라는 고민을 해왔고, 이 고민은 다음의 블로그 글들로 이어져 왔다.스프링부트 서비스에 LOG 남기기 (with. Logback)스프링부트 AOP를 이용해 로깅 처리하기스프링부트에서 Multipart/form-data 요청의 MultipartFile 정보 로그 남기기Terraform으로 EKS 배포하기 11. Grafana Loki와 로그 모니터링 로그를 남길 때 가장 많이 고민한 건 다음과 같은 질문들이었다. API마다 어떤 로그를 남겨야 하는가?예외 발생 시 어떤 정보를 남겨야 대응하기 좋을까?known 에러는 어떻게 표기할까?서버 에러는 어떻게, 또 알람은 어떤 기준으로 발생시킬까?이번 서비스 개발을 계기로, 어느 정도 최종안을 정리할 수 있었..

개요별로 좋은 기억은 아니어서 작성하지 않으려고 했는데, 이전 글이 반응이 좋아서 작성해본다. 토스 뱅크에 떨어진 직후 토스페이먼츠에서도 면접 연락이 왔다. 토스 페이먼츠는 4년차 이상 - 백엔드 개발자 모집 직군이었고, 사전과제를 이미 푼 후였다. 사전과제는 그렇게 어렵지 않아서 큰 문제가 없으면 면접까지는 갈 수 있겠다 싶었다. 그런데 면접을 준비하면서 정말 여러 실수를 했다... 들어가기 전에 변명을 좀 하자면, 면접 날짜가 AWS summit 참가 날짜로 지정됐다. 올해 유난히 재미있어보이는 세션이 많았어서 보고 싶은 것들을 다 보고 나서 면접을 보기로 결정했다. 그래서 근처 코엑스 주변 스터디룸을 잡고 면접을 봤다. 이게 첫번째 실수였다. 면접시간이 6시여서 AWS summit 세션들을 다 보..

개요기존 서비스가 지속적인 개발 단계에서 완전한 유지보수 단계로 전환되면서, 새로운 기능이나 콘텐츠가 더 이상 추가되지 않아 MAU/DAU가 크게 감소했다. 반면, 기능 추가가 활발하던 시절에 확장한 서버와 DB 스펙은 그대로 유지되어 인프라 비용은 오히려 증가했다. 결과적으로 월 비용은 약 2천 달러에서 3천 달러로 40~50% 가까이 상승했다. 사용량은 줄었는데 비용은 오르는 상황이 반복되자, 실장님께서 회의 때마다 시간이 날 때 비용 구조를 한번 점검해보자고 언급하셨고, 마침 맡고 있던 MVP 개발이 마무리되면서 본격적으로 비용 절감 작업을 시작할 수 있었다. 우선 하이퍼빌링 계정을 전달받아 전체 AWS 리소스를 분석하기 시작했는데, 큰 문제는 두 가지였다. 첫째, 리소스에 태깅이 제대로 되어 있지..

인제님이 운영하시는 오픈소스 모임 오프라인 밋업에 참석했다. 나는 이번 기수에도 저번에 했던 것과 동일하게 spring-cloud-aws에 기여했다. 저번에는 오류 픽스와 간단한 파라미터 추가였다면 이번엔 조금 난이도가 있는 피쳐 개발로 넘어왔다. 이 소개는 다음에 하고 이번 모임에는 이미 각자가 기여한 오픈소스에 PR을 하고, 머지까지 하신 분들이 발표를 진행해 주셨다. 스무명 남짓 모여서 아담하게 한 밋업이라 꽤 재밌게 진행됐다.첫 발표 스프링 카프카와 아파치 카프카에 기여하신 분이 발표를 해주셨다. 5월에만 7건 PR 처리를 하셨는데, 피쳐랑 버그 픽스를 다양하게 진행하셨다. 특이한 건 이슈를 만들기도 하고, 이슈를 진행하다 별도의 버그를 찾아 기여하기도 하셨다. 현재 spring-cloud-aws..

개요사실 로그 파이프라인은 인프라 초기 설계 단계에서 함께 고민했어야 했지만, ECS 기반 인프라를 구성할 당시에는 방법을 몰라 한동안 손대지 못하고 있었다. 그 대신 임시 방편으로 로그를 데이터베이스에 저장하고, 단순히 스택 트레이스를 확인할 수 있게만 만들어둔 상태였다. 하지만 로그를 DB에 저장하는 방식은 여러모로 바람직하지 않다.첫째, 서비스 로직에 필요한 DB 커넥션 풀을 로그 기록 때문에 점유하게 된다.둘째, 불필요한 DB I/O가 발생해 비용 낭비로 이어진다.셋째, 로그는 개발자나 운영자를 위한 정보인데, 이를 위해 운영 데이터 저장소의 용량을 소모하게 된다.그리고 마지막으로, 검색과 필터링도 DB 쿼리로 해야 하기 때문에, 로그 시스템 고유의 장점인 빠른 탐색/집계 기능을 기대하기 어렵다...

개요서비스에 파일 다운로드 시나리오가 추가되었다. 과부하에 대응하기 위해 파일을 인메모리에 저장하지 않고 스트림을 통해 클라이언트에 전달하는 방식을 사용했다. 이에따라 응답에 파일 이름을 전달할 수 없게 됐고, 파일명을 다른 방식으로 전달할 수 밖에 없었다. 어떻게 처리할까 고민하다가 Content-Disposition 헤더를 알게되서 이번에 사용해봤다. 동작 자체는 잘 됐지만, 다기종과 연동하면서 생긴 문제를 함께 정리해보려고 한다. Content-Disposition란?일반적인 HTTP 응답에서 Content-Disposition 헤더는 컨텐츠가 브라우저에 inline 되어야 하는 웹페이지 자체이거나 웹페이지의 일부인지, 아니면 attachment 로써 다운로드 되거나 로컬에 저장될 용도록 쓰이는 것..