기록하는 개발자

우테코 슬랙에서 리더쉽에 관심이 있는 사람들에게 추천하는 책이라고 해서 읽어볼 책 리스트에 넣어뒀다가 이번에 꺼내서 읽어봤다.스타트업에서 주니어이지만 수평적인 관계를 지향하다 보니 자연스럽게 리더쉽 역량에 대해서도 생각하게 된다. 이 과정을 어떻게 헤쳐나가야 할지, 어떤 유형의 사람을 인재상으로 봐야 할지, 효과적인 커뮤니케이션은 무엇이고 또 어떻게 해야 하는지 등 평소에 막연하게만 가지고 있던 고민들을 책을 통해 조금씩 정리해볼 수 있는 기회였다. 특히 팀의 성과를 위해 개인의 성과를 양보하는 일의 어려움이나, 의사결정을 미루는 것이 잘못된 의사결정만큼이나 피해가 크다는 부분은 요즘 내가 직접 겪고 있는 고민들과 맞닿아 있어서 더 와닿았다. 결국 함께 일하는 사람들과 감정적으로 교류하면서 본질에 집중하..

'바깥은 여름'을 읽고 문학 작품을 더 읽어보고 싶다는 생각이 들어서 교보문고 베스트셀러에 올라와있던 이 책을 선택했다. 간략하게 줄거리를 설명해 보면, 주인공인 스무 살 나희는 종합병원 내 편의점에서 야간 아르바이트를 시작한다. 나희는 다른 사람과는 다르게 '죽은 사람의 영혼을 보는' 특별한 능력을 지니고 있다. 종합병원 편의점에서 아르바이트를 하면서 특별한 손님을 마주하는데 바로 세상을 떠나기 직전 혹은 이미 떠난 그림자가 없는 사람들이다. 이 사람들은 각기 다른 목적을 가지고 있고, 나희는 이 사람들과 함께 이야기를 풀어간다. 내가 느낀 이 책에서 하고자 하는 이야기는 죽음이라는 것을 두려움의 대상으로 보지 않고, 자연스러운 존재로 받아들이면서 오히려 현재의 삶을 더 소중히 여기자라는 것이다. 죽음..

'바깥은 여름' 유튜브에서 책 추천 쇼츠를 보다가 책을 소개하는 키워드들이 끌려서 바로 읽어봤다.원래 문학 작품이랑은 철저히 담을 쌓아왔는데, 요즘 쉴 새 없이 돌아가는 내 머리속을 진정 시키기에는 문학이 좋아보였다.자기계발서는 정말 좋지만 읽으면서도 쉴새없이 머리를 돌려야 해서 요즘에는 손이 잘 안간다. 이 책은 챕터별로 전달하고 싶은 키워드들이 분명하다.그래서 챕터별로 기록으로 남겨보면 좋을 것 같아서 각 장 마다 느꼈던 감정과 생각을 적어본다. 1장. 입동“그랬다. 잠이 안 올 정도로 좋았다. 어딘가 가까스로 도착한 느낌. 중심은 아니지만 그렇다고 원 바깥으로 튕겨진 것도 아니라는 거대한 안도가 밀려왔다. 그런데 영우가 떠난 뒤 결국 그렇게 도착한 곳이 '여기였나?' 하는 의문이 들었다. 비로소 정..

최근 프로젝트에서 에러 로깅을 진행하면서 동시성 이슈를 겪었다.이전에 취준 스터디를 할 때 동시성 공부를 하면서 접했던 내용인데 잊고 살았던 것 같아서 기록으로 남기려고 한다.단순히 기록을 위한 내용이고, 사내 이슈를 명확히 쓸 수 없다보니 정확한 내용과 예시가 아닐 수도 있다. 트랜잭션 커밋 시점과 락 해제 시점에 따른 동시성 이슈 해결기팀 내에서는 레디스 분산 락을 적용해서 일반적으로 동시성을 제어하고 있고, 해당 이슈가 발생한 부분 역시도 동일한 흐름으로 진행되고 있다고 생각했다.그래서 처음 이슈를 접했을 때 분산락으로 잘 제어하고 있는데 동시성 이슈가 발생했다고? 라고 생각을 하면서 다른 부분을 집중적으로 찾아보고 있었다.(redis lock 구현체, 이벤트 리스너, 비즈니스 코드 흐름 등등.....

(이 글은 외로운 우테코 5기 취준생 “김동욱”, “이건회” aka “그레이”, “하마드”가 작성했습니다.) 현재 비동기 호출과 FCM의 sendAsync를 통해 FCM 알림 호출까지 비동기로 처리하고 있다. 하지만… String response = FirebaseMessaging.getInstance().sendAsync(message).get(); 여기서 get() 메서드가 자꾸 눈에 걸렸다. 자바 5에서 비동기 함수의 리턴 값을 받을 수 있도록 Future 객체가 등장했고 Future 객체에 값을 꺼내기 위해 get 메서드를 사용한다. FirebaseMessaging의 sendAsync의 반환 타입인 ApiFuture에서 get 꺼내는 동작을 찾아보니 블록킹 방식으로 동작하고 있었다. 추가적으로 자..

문제 발생 비동기 처리와 스레드 풀 튜닝을 통해 알림 기능을 개선하며 성능 테스트 하던 중, 문제가 발생했다. ?????????????? 갑자기 CPU 수치가 급등해 99.9%를 찍게 되는 현상을 발견했다. 알림을 처리하는 중 간헐적으로 발생하는 것이 아닌, 배포를 완료한 직후 요청(초반)에만 발생한 후 천천히 내려가는 것을 파악했다. 가용 중인 애플리케이션에서 CPU 수치가 99%를 찍는다는 것은 굉장히 위험한 징후다. 누가 CPU를 좀먹고 있었을까? 해당 현상을 확인하기 위해 다양한 시도를 했다. * 배포 직후 스레드 덤프 → 총 32개 스레드 먼저 스레드 덤프를 통해 확인해보니 알림 요청이 오기 전에는 비동기 스레드가 생성되지 않다가, 알림 요청이 온 이후에야 스레드가 생성 후 RUNNABLE 상태..

(이 글은 외로운 우테코 5기 취준생 “김동욱”, “이건회” aka “그레이”, “하마드”가 작성했습니다.) 동기적 알림 처리를 비동기로 수정 @Component @RequiredArgsConstructor public class NotificationEventListener { private final NotificationService notificationService; @EventListener @Async public void handleNotificationEvents(NotificationEvents notificationEvents) { for (NotificationEvent event : notificationEvents.getNotificationEvents()) { notificat..

(이 글은 외로운 우테코 5기 취준생 “김동욱”, “이건회” aka “그레이”, “하마드”가 작성했습니다.) 사건의 발단 때는 23년 12월 말...하반기 공채에 무참히 실패한 우테코 5기 수료생 두 남자가 만났다. 서울대입구 라멘집에서 늘 그렇듯 일상적인 개발 얘기를 하던 와중 말을 꺼냈다. "피움(23년에 진행한 식물 관리 서비스 프로젝트)의 알림 기능이 문제가 많아 보인다. 프로젝트 막판이라 생각없이 짠 코드가 너무 많다." 처음에 그 말을 꺼냈을 때는 별 관심이 없어 보였다. "이미 끝난 프로젝트이기도 하고...알림? 그거 내가 짠 기능 아닌데? 굳이 신경써야 하나? 그냥 다른 프로젝트 하면 안돼?ㅎㅎ" 하마드는 대충 이런 생각이었다. 하지만 식사 후 서울대입구역 집무실에서 내가 그에게 이 프로젝..

피움 서비스의 런칭 페스티벌을 무사히 마쳤습니다. 런칭 일정에 맞춰 빠르게 개발을 진행하다 보니 꼼꼼하지 못한 부분이 존재했고, 다음 개발에 착수하기 전 부족한 부분을 개선하고 넘어가기로 했습니다. 먼저 서비스 내에서 발생하는 모든 쿼리를 정리해보았습니다. 현재 서비스의 모든 기능을 인수 테스트로 작성했기 때문에 인수 테스트를 하나씩 돌려보며 발생하는 쿼리를 추적했습니다. JPA를 사용하는 환경에서 스프링 properties 설정 중 아래 옵션을 설정하면 쿼리를 확인할 수 있습니다. spring.jpa.show-sql=true spring.jpa.properties.hibernate.format_sql=true 현재 서비스에서 사용하고 있는 API에서 발생하는 쿼리를 위와 같이 정리하였고 개선이 필요한 ..

8주차 회고에 앞서 마지막 8주 차에서는 로그인, 로깅 전략 수립, 모니터링 환경 구축을 진행했고 첫 배포인 1.0 버전을 출시했다. 마지막으로 4차 데모데이를 진행했다. 훌륭한 팀원들 덕분에 무사히 레벨 3 프로젝트를 마칠 수 있었다. 로그인 마지막 4차 스프린트에서 구현하기로 했던 로그인 기능을 구현했다. 서비스 특성 상 일반 로그인은 불필요하다고 생각했고, 소셜 로그인 방식을 선택했다. 네이버, 구글, 카카오, 깃허브 등 많은 소셜 로그인을 활용할 수 있지만, 서비스 주 타켓층인 30대 ~ 50대를 고려해 가장 범용성이 높은 카카오 로그인을 사용하기로 했다. 인증을 구현할 방식으로 토큰을 이용한 인증과 세션을 이용한 인증 방식 중 세션 인증 방식을 선택했다. 우선 현재 프로젝트 규모에서 토큰 방식과..