마로의 개발일지

23년 7월 7일부로 퇴사를 하게 되었다. 모두들 퇴사보단 이직이 나을 거라고 했다. 하지만 고민한 끝에 퇴사를 결심하게 되었다. 퇴사를 하게 된 이유들을 정리하고 다음 글에는 앞으로의 방향에 대해 적어보고자 한다. 팀장님이 퇴사했다 팀장님은 나에겐 어떻게보면 개발자로서 1인분을 할 수 있게 만들어준 사람이라고 해도 무방한 분이었다. 많은 걸 배우고 느꼈고, 보답하고 싶었다. 하지만 여러 사정으로 인해 저번 글에서 언급했던 것과 같이 팀장님이 퇴사하셨다. 좋은 동료와 팀장님이 가장 큰 장점이라고 생각하던 나에게 팀장님과 동료들의 퇴사는 내가 퇴사를 고민하게 되는 트리거가 되었다. 개인적으로 느끼는 부족한 점이 많다 회사에서 업무를 하면서 기능을 구현하는 능력은 많이 성장했다. 자료를 찾아 적용하고 문제를..

이번 글은 결론부터 말하자면 Lambda Function내에 DB 커넥션이 요청이 들어올 때마다 생성이 되게 되어있어 발생한 에러였다. 해당 문제는 이전에 vertical-api에서 redis 커넥션을 요청마다 생성해서 발생한 에러와 유사한 에러였으며 Lambda에서 DB 커넥션의 관리가 얼마나 중요한지 또 한 번 깨닫는 좋은 경험이었다. 이번 글에서는 해당 문제를 해결하기 위해 진행했던 테스트 방법과 결과들을 소개할 예정이며 결과적으로 해당 테스트들이 큰 유의미한 결과를 가져오진 못했지만 이런 방법들을 통해 이런 결과들이 나왔다 정도만 참고하면 좋을 것 같다. 배경 커넥션 증가로 인한 장애가 발생하고 장애 보고서가 작성된 뒤 작업한 담당자가 휴가라 휴가 동안 내가 해당 장애를 분석하는 일을 맡게 되었다..

com.mongodb.MongoException: org.springframework.dao.DuplicateKeyException: E11000 duplicate key error collection 어느 날 모니터링 채널에 해당 에러가 올라왔다. 이전까지 본 적이 없는 에러였는데 찾아보니 key 값이 중복으로 Insert 되어 발생한 에러라고 했다. 다음과 같이 서비스를 구현하고 테스트했을 땐 잘 되던 로직이 간헐적으로 해당 에러를 반환하고 있었다. 대상 데이터를 찾고 상태를 변경한 후 다시 저장할 때 Update가 아닌 Insert가 되어 발생한 것 같았다. 분명 @Transactional로 인해 하나의 트랜젝션 안에서 찾은 데이터기 때문에 당연히 Update로만 실행이 될 줄 알았는데 내가 모르는..

5월 3일 AWS Summit Seoul 2023 Day1에 다녀왔다. Day2에 기술적인 부분이 많아 가서 듣고 싶은 내용이 꽤 있었지만 사다리 타기에서 패배했기 때문에 Day1을 가게 되었다. 하지만 Day1도 꽤나 흥미로운 주제들이 많아서 가기 전에 어떤 주제들을 들을지 고르는 게 꽤 힘들었다. 내가 고른 세션별 주제는 다음과 같다. 천만 사용자를 위한 카카오의 AWS Native 글로벌 채팅 서비스 - 카카오 마이크로서비스로 이커머스 성장을 이끈 AWS 매니지드 서비스와 마켓플레이스의 활용 사례 - 29cm 당신의 Application Modernization, 안전하십니까? - AhnLab 투자를 모두에게, 토스증권의 MTS 구축 사례 - 토스 이후의 주제들도 흥미로웠지만 Expo에 참여하는게 ..

픽업 서비스 현재 내 경력에서 가장 많은 비중을 차지하고 우여곡절도 많았던 프로젝트인 픽업 서비스에 대한 회고이다. 픽업 서비스는 편의점에 물건을 맡기고 찾아갈 수 있도록 하는 서비스로 22년 7월부터 시작해 23년 1월에 끝난 질긴 프로젝트였다. 계획대로라면 22년 8월에 작업을 시작하여 22년 11월에 오픈 예정이었지만 여러 사정으로 인해 연기되었다. 여러 협력사들이 함께 진행하는 프로젝트다보니 서로간의 의사소통이나 일정 산출에 좀 더 많은 영향을 받았던 것 같다. 다른 회사와 협업을 한다는 자체가 역시 쉽지 않았다. 이번 회고는 개발 과정에 좀 더 중점을 둬서 작성할 예정이다. 테이블 설계나 구체적인 코드가 있으면 좋겠지만 개인적인 목적으로 사용하기엔 부담스러운 점이 있어 제외하고 기록하기로 했다...

팀원의 퇴사 며칠 전 팀장님과 시니어분이 퇴사소식을 알렸다. 우리 팀은 팀장님 포함 시니어 셋 주니어 넷으로 구성이 되어 있었는데 이젠 시니어 하나 주니어 넷이 되었다. 분위기상 누가 언제 나가도 이상하지 않다고 생각하고 있었기에 마음의 준비를 하고 있었지만 한 번에 둘이나 가게 되는 건 생각지 못해 조금 당황스러웠다. 두 분도 어쩌다 보니 함께 나가게 되어 미안하게 생각하고 있는 것 같았다. 사실 퇴사가 미안할 일은 아니고 자신의 의지로 퇴사를 하는 일은 언제나 축하할 일이라고 생각해서 좀 더 아무렇지 않은척 하려고 애썼다. 두 분은 일에 지쳐 쉬러 가는 것이라고 했다. 팀장님은 이번이 첫 팀장이라 약 1년 반정도 많은 고생을 하셨고 시니어 분도 오랜 시간 동안 쉬지 않고 달려오셔서 충분히 그럴만하다고..

이전 포스팅에서 Java에서 Aws AppConfig 사용하기를 소개했다. 하지만 리프레시 토큰으로 계속 갱신해서 사용하지 않으면 호출에 상당한 시간이 걸려 다른 방법을 찾게 되었고 그 방법으로 배포된 AppConfig 항목을 Redis 캐시에 저장해서 사용하기로 했다. 사실 AppConfig를 이렇게 쓰는 건 비효율적인 것 같지만 당장은 AppConfig에 저장해서 사용하는 항목이 거의 없어 이렇게 사용하기로 했다. 아무튼 그렇게 하기 위해선 AppConfig가 배포될 때 자동으로 Redis 캐시의 항목을 갱신하는 로직이 필요한데, AppConfig에는 Extension을 통해 배포 상태에 따라 호출하는 항목들을 설정할 수 있다. 새로운 Extension을 생성하기 위해 Create extenstion..

편의점 택배사들의 점검이나 에러 시 배송신청을 막기 위해 배송 신청 여부를 Flag 값으로 설정한 뒤, AppConfig를 통해 조절하도록 하는 작업을 진행했었다. api 호출 시 AppConfig를 직접 조회에서 쓰도록 하기 위해 Java Application에 직접 AppConfig를 조회하는 로직을 추가했었다. 이전에 아무도 해본 적이 없어 공식문서를 보면서 진행했고 그 과정을 기록했다. 공식 문서 읽어보기 Step 6: Retrieving the configuration - AWS AppConfig 해당 문서를 살펴보면 Your application retrieves configuration data by first establishing a configuration session using th..