마로의 개발일지

오픈소스를 알게 된 계기 오픈소스 컨트리뷰트라는 말을 처음 알게 된 건 생활코딩 유튜브 페이지를 통해서였다. 해당 페이지를 구독 중이었는데 공지사항으로 OSS에서 오픈소스 컨트리뷰톤을 진행한다고 하길래 '이게 뭐지?' 하고 찾아봤었다. 그 땐 SSAFY를 하기 전이었고 의욕만 앞서고 실력은 없었기에 신청했지만 떨어졌다. 오픈소스 나도 해보자 이후 취업을 하고 바쁘게 살다 퇴사한 지금 다시 생각이 났다. 물론 채용 공고에 적혀있는 오픈소스 컨트리뷰트 경험자 우대가 눈에 밟힌 것도 있었다. 그래서 다시 한번 OSS의 오픈소스 컨트리뷰톤에 지원했는데 떨어졌다. 여러 이유가 있겠지만 무튼 나보다 뛰어난 사람들이 많았나 보다. 그런데 생각해 보니 '굳이 저걸 해야 오픈소스 컨트리뷰트를 할 수 있는 건가?'라는 생..

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

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

22년 3월 아무 문제 없이 잘 돌아가던 Vertical-api에 장애가 발생했다. 새로운 버티컬 페이지가 배포된 다음날이었다. 처음엔 테스트도 문제없이 잘 돌아가고 로직을 수정한 게 아니라 단순히 페이지만 추가했을 뿐인데 에러가 나는 게 이상했다. 상대적으로 이전과 차이 나는 건 트래픽이 좀 더 늘었다는 것이었고, 들어갈 때마다 발생하는 게 아니라 간헐적으로 발생했기에 AWS Lambda 자체의 오류라고 생각했다. 지금 생각하면 정말 멍청한 생각이었다. 겨우 그 정도 트래픽이 늘어난 것 때문에 장애가 발생할 서비스가 아닌데 말이다. 당시 상황 하필 장애가 났을 땐 팀장님이 휴가를 간 상태였고 오랫동안 기다리던 휴가였기 때문에 방해하고 싶지 않았다. 팀장님을 제외한 다른 팀원분들은 serverless f..

관심 카테고리 앱 메인 화면에 관심 카테고리에 따른 관심 상품 목록이 추가되었다. 따라서 관심 카테고리를 등록 및 수정 할 수 있는 기능을 만들게 되었는데 해당 기능은 단순 CRUD였기에 구현에 별다른 어려움은 없었다. 하지만 지금 생각해보면 DB 설계에 살짝의 아쉬움이 남는다. 자세한 내용은 하단에서 설명하겠다. 테이블 설계 아래의 ERD는 실제 운영 DB의 ERD가 아닌 이해를 돕기 위해 임의로 작성한 테이블이다. column의 이름이 이상하거나, 없거나 실제 테이블의 데이터 형식과 차이가 있다. ERD 작성은 quickDBD를 이용했다.(https://app.quickdatabasediagrams.com/) user와 category 테이블은 예상할 수 있듯이 사용자와 기존의 카테고리 정보들을 저장..

퀵메뉴 개편 기존의 퀵메뉴는 하드코딩된 값들과 사용자별로 인기 카테고리들을 내려주고 있었다. 해당 항목을 수정하고, 유동적으로 내려주기 위해선 일단 먼저 DB 테이블에 저장하고 불러오는 기능이 필요했다. 이전엔 퀵메뉴 테이블이 존재하지 않았기에 테이블 설계부터 진행했다. 테이블 설계 아래의 ERD는 실제 운영 DB의 ERD가 아닌 이해를 돕기 위해 임의로 작성한 테이블이다. column의 이름이 이상하거나, 없거나 실제 테이블의 데이터 형식과 차이가 있다. ERD 작성은 quickDBD를 이용했다.(https://app.quickdatabasediagrams.com/) menu 퀵메뉴 정보를 저장하기 위한 테이블이다. menu_seq 기본키로 사용할 값이다. order 퀵메뉴에 나타낼 순서를 뜻한다. n..

2022년이 되어 맡은 첫 프로젝트였다. 이전까지는 운영 건들을 해결하거나 간단한 작업만 했었는데 꽤 사이즈가 큰 업무가 처음으로 할당되었다. 당시 생각에는 '재밌을 거 같지만 겨우 7개월 차 신입이 하기에는 부담스러운 거 같은데?'라고 생각했었다. 개발이 아닌 개편인데 뭘 그렇게 생각하냐고 할 수도 있다. 하지만 메인페이지 호출 api를 새로 만들게 되면서 기존에 호출하던 api들도 새로운 api로 바뀌었고, 새로운 기능들이 추가되었다. 거기에 이전에 있던 로직들이 필요한 기능인지 아닌지를 판단해서 제거해야 했기 때문에 작업량이 꽤 많았다. 개발 내용 작업했던 내용을 모두 적을 순 없겠지만 대략적으로 적어보자면 메인 배너 추가, 기존의 호출 api들 교체 및 스펙 변경, 불필요한 로직 제거, 이전까지 ..

당시엔 시간도 없고 정신도 없어서 못썼지만 지금에서라도 21년 회고를 작성하고자 한다. 3월에 쓰는 회고는 뭔가 많이 어색하지만 까먹기 전에 미리 써놓는 게 좋을 것 같아 지금이라도 쓰기로 했다. 첫 직장 첫 회사에 입사를 했다. 개인적으로는 많이 부족하다고 생각했는데 운이 좋았던 것 같다. 코딩 테스트날 컨디션도 좋았고 운도 좋아서 문제를 모두 맞혔다. 면접 때도 좋은 동기와 함께 면접을 봐서 편하게 볼 수 있었다. 언제나 하고 있던 생각이 '붙여만 주면 진짜 일 잘할 수 있는데...'였고 붙여줬기에 정말 열심히 일했다. 열심히 말고 잘하기 위해 늦게까지 남아 야근하며 부족한 공부를 했고 당시엔 야근의 아이콘이 되어 있었다. 저녁 먹고 돌아와서 공부한 뒤 퇴근하면 평균 퇴근시간이 9시쯤이었던 것 같다...