개발과 일상

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

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

개요 현재 담당하고 있는 제품이 해외 결제 시스템을 추가하게 됐다. 이에 따라 고려해야할게 몇 가지 있었다. 1. 어느 지역 까지 커버할 것인가? 2. 구독이 정상적으로 동작할 것인가?3. 데이터 유실 없이 안정성은 보장할 수 있을 것인가?4. 개발하기 간편한가?5. 환불이나 CS 운영적인 부분도 커버가 가능한가? 이리저리 알아볼 것도 없이 Stripe가 가장 강력한 후보가 됐다. Twilio 때도 그랬지만 북미에서 제공하는 SaaS 형식의 제품들은 사용하기는 편하지만 생각보다 비싸다. 그래도 자체 인프라 없이, 월간 결제 형식이 아니라 on-demand + 수수료로 책정되는 모델이라 초기 모델로는 더할 나위 없을 것 같았다. 이번 글에서는 완전히 도입까진 아니고 developer 사이트에서 결제 세션..

한참 전에 읽은 책인데 이제서야 정리한다. 한줄로 정리하면 이제 개발자를 시작하는 사람에게 반드시 추천해주고 싶은 책이다. 학습용 서적은 아니어서 개발을 공부하는 단계에서 읽는 것 보다 입사 후 온보딩 과정에서 읽으면 좋을 것 같다. 단순 개발만 아니라 어떻게 일하면 좋을까? 에 대한 방법론이 많아서 재밌게 읽었다. 인상 깊었던 부분이 참 많다. 평소에 내가 생각하던 것들을 재미있는 표현으로 잘 정리해준게 신기했다. 고무오리마치 욕조안에서 고개를 끄덕이듯 고무오리가 아래위로 까닥이듯 말이다 정답을 말해주지 않더라도 누군가에게 문제를 설명해보라는 의미. 뭘해야하는지 문제가 뭔지 찾아가기 위해서 차근차근 처음부터 끝까지 설명해보라는 것이다. 이 방법은 나도 자주 쓰는 방법인데, 보통 말하다가 뭐가 문젠지 어..

작년에도 AWS Summit을 참석했었다.2024.05.18 - [일상] - [컨퍼런스] AWS Summit Seoul 2024 - 1일 차 후기2024.05.19 - [일상] - [컨퍼런스] AWS Summit Seoul 2024 - 2일 차 후기 다만 이번에는 작년과는 차이가 있었는데, 작년에는 플랫폼 엔지니어링이란게 뭘까라는 뚜렷한 목적이 있었다. 이번에는 성장이 막혀있단 느낌이 있어서 이걸 뚫어보고 싶어서 다양한 개발 사례를 보고 싶었다. 그런데 막상 가니까 너무 AI 쪽에 쏠려 있었다. 들어가기 전에 잠깐 정리하자면 사람이 너무너무너무 많았다... 기업 부스도 돌아봤는데 대부분 LLM을 이용한 챗봇과 업무 효율화 관련 내용이었다. 그렇게 재밌진 않아서 바로 세션을 들으러 갔다. 세션은 아래와 같..

개요 올해부터는 이직을 위해 움직여보려고 생각은 하고 있었는데, 바쁘다보니 지원을 할 생각을 못하고 있었다. 마침 지인 토스가 이번에 대규모 채용을 한다해서 지원서를 넣어봤다. 프로젝트가 바쁘게 돌아가고 있어서 시간을 내기 어려운 상황이라 있던 이력서를 그대로 냈는데 운좋게 서류를 통과했다. 그래서 면접을 시작하게 됐는데, 요약하면 어렵지만 재밌는 시간이었다. 어디서든 이야기하지만 토스 면접은 준비하는게 딱히 의미가 없다. 일단 떨어졌기 때문에, 아쉬움이 앞서지만 피드백은 해야겠지.... 토스 면접과 과제는 보안서약서를 꼭 작성시키기 때문에, 면접과 과제에 대한 상세 내용은 명시할 수 없으니 양해 부탁드립니다. 면접에서 아쉬웠던 부분들1. 예시가 잘못됐나?이 부분이 사실 특히 아쉽다. 선택권이 둘중 하..

개요앞선 글(언제나 복잡한 이름 순 정렬 구현하기)에 이어서 파일 드라이브의 정책 관련 이야기들 중 하나다. 별로 재미없는 이야기인데, 내가 했던 고민들을 정리해보려고 한다. 현재 개발 중인 서비스에 파일을 관리할 때 파일들이 고유한 id를 갖게끔 구성했다. 그래서 순도 100% 백엔드 개발자 마인드로 어차피 id로 구분되니까 파일 이름이 중복되도 문제가 없지 않을까...? 란 생각을 했지만... 다른 팀원들의 생각은 달랐다. 그 결과 나는 반대했지만 결국 중복된 이름 생성을 방지하기 위한 다양한 정책이 나오기 시작했다... 어떤 문제가 있었고 이에 따른 어떤 정책들이 있었으며 어떻게 처리했는지 하나씩 알아보자. 1. 생성 시 동일한 이름이 있다면 어떻게 해야하나?이건 정책적으로 그냥 막기로 했다. ..