개발과 일상

나는 항해 코스를 듣지 않았지만, 주변에 들은 분들이 꽤 있다. 내가 이런 세션을 들으러 다니는걸 좋아한다는건 그분들도 다 아시기 때문에.. 항해 DEV LAB에 같이 가자고 추천 받았다. 참석이 확정되고 스케줄을 받았는데, 다음과 같았다.  세션보단 네트워킹에 초점을 맞춘 스케줄이었다. 그러나 막상 세션 장소에 도착해보니 너무 덥고, 시끄러워서 의사소통이 썩 원활하진 않았다. 세션도... 다 좋지는 않았는데, 일단 정리는 해봤다. 1. AI와 자동화로 주니어 개발자 키우기 인프랩은 개발자가 33명으로 구성되어 있다. 그중에 첫 직장 11명이고, 대부분 주니어로 구성되어 있다.그러나 처음 채용을 할 때는, 좋은 시니어를 뽑자가 목표 - 어떤 사람을 뽑아야 할까?1. 셀프모티베이션2. 제품과 조직의 ali..

문제 상황 정리작년 9월쯤부터 비용절감을 위해 dev 서버를 spot 인스턴스로 변경했다. 약 30% 정도 비용절감이 효과가 있어서 당시에는 꽤 괜찮은 선택이었는데, 운영하면서 문제가 발생했다. dev 서버가 spot 인스턴스를 너무 자주 뺏기고, 다시 할당 받는데 시간이 오래 걸리는 현상이 반복됐다. 한두번이면 상관 없는데 하루에도 몇 번씩 뺏기고 다시뜨는데 10분씩 걸리니까, 개발에 차질이 생기는 경우가 생겼다. 이 문제를 해결하고 싶었다. 문제 정의spot instance란?스팟 인스턴스는 실행 중인 동안에는 온디맨드 인스턴스와 정확히 동일합니다. 그러나 스팟은 실행 중인 인스턴스를 워크로드를 완료할 수 있을 만큼 충분히 오래 유지할 수 있다고 보장하지 않습니다. 또한 스팟은 찾고 있는 인스턴스의 ..

5월 초에 인제님이 주최하는 오픈소스에 참석하고 석달 반이 지났다.2024.05.13 - [일상] - 오픈소스 멘토링 후기 최근에는 많은 기여활동을 못하고 있지만, 오픈소스 멘토링 당시 작업했던 게 머지된 김에 오픈소스 멘토링 외에도 몇 가지 이슈를 더 다룬 것들이 기억에서 사라지기전에 정리해보려고 한다. 1. Spring Cloud AWS 기여(2머지)2. JTokkit 기여(머지)3.Azure SDK for Java 기여(실패)  총 3가지 프로젝트에 기여하려고 시도했었고 사실상 3번은 실패나 다름없었다... 하나씩 정리해보자  1. Spring Cloud AWS 기여 오픈소스 멘토링 지원 당시에는 Spring Data JPA, Spring Cloud OpenFeign을 전달드렸었다. 이리저리 생각해..

2024.07.19 - [개발/SPRING] - Kotlin + SpringBoot 서버에 테스트 도입기. Kotest와 MockK 이전 포스팅에서 테스트는 왜 필요하고, 어떤 것들이 있는지에 대해 정리해봤다. 그리고 현재 프로젝트에서 어떻게 쓰면 좋을지도 결정했었다. 이 후 한동안 실제로 테스트를 구현하면서, 어떻게 테스트를 서비스에 잘 녹일 수 있을지 고민하면서 구현했다. 테스트가 있긴 있었지만, 레거시의 레거시를 테스트하는 용도라 싹 들어내고 다시 구현했다. 1. 테스트는 기능을 테스트하는 용도도 크지만 히스토리 용도도 크다테스트는 사이드 이펙트를 잡는 용도도 크지만 이 코드가 왜 만들어졌는가를 남기는 요소도 포함하고 있다. 주석도 서비스 로직에 남겨져 있는 것보다, 테스트에 남기는게 최신화 하기 ..

테스트를 도입하면서 다양한 정보를 얻고 싶어서 들은 강의 중 하나인데... 개인적으로는 솔직히 실망스럽다. 정확히는 제목 값한다는 표현이 맞다. 가장 강조되야할 부분은 "하루만에" 다. 다양한 사례나 테스트에 대한 본인의 철학이나 엣지 포인트들을 짚어주는 그런 강의를 기대하면 안된다. 테스트에서 가장 중요한 부분은 어떻게도 중요하지만, 무엇을, 왜, 언제라고 생각하는데 이게 딱 빠져있다. 무엇을 : 프로젝트에서 어떤 부분을 테스트해야 하는가? 테스트에는 어떤 방식이 있는가?왜 : 이 테스트가 왜 필요한가? 테스트를 안할 경우 어떤 문제가 생길 수 있는가?언제 : 언제부터 테스트가 필요한 상황일까? 이런 상황에서는 어떤 테스트를 적용해야하는가? 사실 어떻게도 부족한 것 같다. 정해진 시간에 많은 걸 담으려..

행사 주최자분이 광고도 많이하시고 주변에서 많이 간다고해서 참여한 컨퍼런스였는데 여느 컨퍼런스가 그렇듯 좋은 세션이 있는가 하면 애매한 세션도 있었다. 세션은 다음과 같다.  나는 백엔드 개발자라 거의 서버 세션에 쭉 있었다. 한번만 개발자의 공허함 Part2 를 들었는데, 이 세션은 참여자가 유난히 적었다. 총 6개의 세션을 들었는데, 세션을 들으며 내용을 정리하고 짧게 후기를 써봤다.. 에어프레미아는 왜 재개발을 하는가?별로 특별하지 않았던 세션... 재개발의 이유는 너무 보편적인 이유였고 재개발 방식은 딱히 새롭지 않았다.가장 궁금한 부분인 FE/BE를 나누면서 어떤 아키텍처를 선정했고 k8s가 들어갔는지 운영을 위해 어떤 모니터링을 구축했고, 어떤 기준을 갖고 분리했는지에 대한 이야기가 너무 짧거..

서버 to 서버로 데이터를 전송할 일이 생겼는데.... 문제가 생겼다. 문제 상황은 다음과 같다. 1. A 서버에서 B서버로 요청을 보낼 계획2. A 서버는 S3에서 파일정보를 가져와서 ByteArray 형태로 들고 있음3. B 서버에는 MultipartFile을 파라미터로 받는 API(ex. /api/file)가 존재함 - 수정 불가(FE에서 사용 중)  4. A 서버에서 B 서버로 /api/file을 요청해야 함 - 데이터만 삽입하고 끝내기엔 이력이나 업데이트해야할 정보가 많음5. A 서버에서는 FeginClient를 사용 중(HTTP 통신을 위해서 사용 중, 굳이 고집하지 않아도 됨) 요약하면, 요청을 보내기 위해서 스프링부트 서버에서 MultipartFile을 어떻게 만들 것인가? 와  Feign..

서비스의 규모가 커짐에 따라 수정 사항도 늘어나고, 서로 간의 의존성도 커지면서 다른 한쪽의 문제를 예상하지 못하고 수정해버려서 발생하는 이슈가 늘어났다. 그래서 개발을 할 때나 수정할 때 점점 부담이 많이 생기게 되서, 제대로된 테스트의 도입 방식을 검토했다. 이전에 강의를 하나보고 여기에 감명을 받았다. 2024.04.15 - [일상] - [인프런 강의] Java/Spring 테스트를 추가하고 싶은 개발자들의 오답노트를 듣고위 그래프처럼 개발 양은 많아지는데, 이게 잘 동작할까? 에 대한 부담감이 점점 커지는 상황이라 조치가 필요해졌다. 그러나 테스트 도입에는 정말 많은 애로 사항들이 있었는데... 다음과 같은 의사결정이 필요했다. 1. 테스트의 종류 선정: 몇 종류의 테스트를 실행할 것인가?2. 어..