간단한 블로그

얼마 전 회사에서 공유했던 문서 중 하나를 가져와 블로그에도 적어둔다. 다른 글과 다르게 회사에 공유했던 주요 내용만 요약한 글이지만, 제대로 확인된 내용이 아니기도 하고 평소에 어떤 식으로 이야기를 풀어 공유 해왔는지를 남겨두는데 의미를 둔다. 개요신규 프로젝트 런칭 이후 성능 개선 작업 도중 문득 이상한 것을 발견했다. HTTP2를 지원하는 스테이지 서버임에도 때때로 굉장히 "느리게" 페이지의 JS가 실행되는 것이었다. 혹시나 하여 청크 개수 제한을 걸고 배포해보니 불규칙적인 로드 완료 지연이 크게 줄어든 것을 느꼈다. 이것을 제대로 확인해보진 않았지만 분명하게 빨라진 것을 느꼈고, 다른 성능 개선 작업에 더해(서비스에 아무런 영향이 없으니) 청크 제한을 건 상태로 라이브 배포를 진행했다. 다른 작업..

최근 여기저기에서 gRPC에 대한 이야기가 들린다. 회사에서 gRPC를 쓰겠다는 말이 있기도 했지만 이런 통신 계열에 재미있는 것이 자주 나와 관심을 가져봤다. 책을 읽고 이런저런 테스트를 해보니 당장 쓰진 않을 것 같지만, 관련 시스템을 한번쯤 만질 일은 있을 것 같다는 생각이 들어 이 글을 남겨둔다. 최소한 순식간에 없어질 정도는 아닐 것 같다는 뜻이다. gRPC gRPC는 구글에서 만든 원격 프로시저 호출(RPC) 시스템이다. CGI부터 이어져 온, 외부 시스템에 값을 전달해주기 위해 사용하는 연결 방식이다. 더 줄이자면 "RESTful API를 대체할 수 있는 무엇이다" 정도로 말할 수 있겠다. 물론 응답을 주고 받을 프로젝트가 웹 프로젝트로 한정되지 않았다는 점 때문에 약간 다르지만, 결국 서버..

연말 평가가 다가와 수행한 업무들을 정리하던 중 블로그에도 회고를 적는다. 11월이지만 늦게 적는 것보단 미리 적는 게 더 나을 것 같기도 하고, 하반기에 남은 업무가 많지 않아 한두 달 지나도 차이는 없을 것 같다. 올해 상반기까지는 계속 혼자 작업을 진행했었는데, 하반기부터 팀원이 한분 붙어 함께 작업하기 시작했다. 정/부 개념이 되어 부담은 덜해졌다. 다만 서로 코드 리뷰를 해도 놓치는 부분이 여전히 있었다. 주로 스타일이나 로그 등 상대적으로 중요하지 않은 부분이 그랬는데, 이건 리뷰하는 인원이 늘어난다고 해도 별 차이가 없을 것 같다. 주요 업무서비스 업무1. 국내 숙소 상세 사이트 개편 (07/20 ~ 11/08)개요 11월 8일에 런칭한 가장 최근 프로젝트이기도 하지만 중요도와 성과를 생각하..

개발자로서 업무를 진행하다 보면 별 생각 없이 섞어 쓰는 단어들이 있다. 정확한 뜻은 다르지만 모두 이해하고 있고 구분할 정도로 다르지는 않기에 다들 무시하는 그런 단어들이다. 섞어 쓰면 안된다거나 고쳐야 한다는 그런 것은 아니고, 단순히 재미삼아 떠오르는 대로 몇가지 적어본다. 1. Function과 Method최근 멀티 패러다임 언어가 많아지며 이 둘을 구분하는 것이 꽤 중요해지긴 했다. 자신이 어떤 것을 만들고자 하는지 알아야 방향을 잡을 수 있기 때문이다. 간단하게 요약하면 이렇게 쓸 수 있겠다.함수는 외부에 영향 없이 입력에 대한 출력을 반환하는 명령이다. 메소드는 요소(객체)의 상태를 변화시키는 행동이다. 함수형 언어를 공부했다면 이 두개 단어를 혼용하는 것에 미묘한 반감을 가지게 된다. 함수..

FE 개발자는 많은 Rest API(웹 개발에 대한 이야기이니 이하 API로 칭한다)를 사용한다. 대부분의 로직을 백엔드에서 처리하기 때문이다. 그러다 보니 많은 개발자가 만든 API를 사용해보게 된다. 나 역시도 정부 기관, 오픈 API나 사내 API 등 꽤 많은 수의 API들을 사용해보았다. 겉으로 보기에 큰 차이는 없어 보였지만 유독 쓰기 곤란한 것들도 있었고 오랜 기간 다양한 작업을 수행했음에도 아무런 수정이 필요하지 않았던 훌륭한 API들도 있었다. 물론 비즈니스 로직의 영향도 있고 변경 범위가 크지 않아서 그럴 수 있다. 하지만 API를 호출하는 입장에서 느껴지는 '무엇인가'가 있다. 그 차이가 무엇일까 궁금해 얼마 전부터 떠오르는 것들을 메모장에 적어두었다. 어느정도 내용이 쌓인 것 같아 블..

이 책은 PM-PO 직군, 그러니까 기획 계열의 업무 관련 도서다. 어떻게 해야 프로젝트를 성공적으로 이끌어 나갈 수 있을지에 대한 책으로 일종의 자기계발 서적이다. 자기계발 서적들이 흔히 그렇지만 250장이 넘는 책의 내용 중 얻을 것이 극소수라 부정적인 시선으로 보게 된다. 최근들어 PM-PO 직군으로 운영하는 회사가 많아져서인지 이 책을 추천 도서로 넣는 경우가 있는데 개인적으로는 PM-PO 직군 밥그릇 내구도 강화 재료라고 보인다. 한동안 개발쪽에서도 유행했던 그런 책이란 느낌이다. 제목이기도 한 '개발 함정'에 관한 골자는 한줄로 요약할 수 있다. "필요없는 기능을 개발하는데 쓸데없는 시간과 인력을 소모하지 말라" 이것이다. 하지만 실무를 경험해본 사람들은 의아할 수 밖에 없다. 어떻게 "필요없..

하반기 회고라기에는 상반기 회고를 너무 늦게 작성하는 바람에 뭔가 꼬인 느낌이 있다. 내용 중 하반기에 한 작업이 많았고(8~9월 작업이니) 그 이후로는 대부분 서스테이닝 작업을 진행했기에 기록하기 애매한 내용들이 많다. 이 유지보수성 작업들은 뭔가 하는건 많은데 포트폴리오로 남길만한 내용이(뭔가 있어보이는 내용이) 없는 편이다. 그런데도 오히려 서비스 운영을 위한 근본적인 실력 자체는 늘어난다는게 참 아이러니하다. 어쨌든 사내 평가 시스템에 내용을 작성하며 정리한 김에 블로그에도 정리해두려고 한다. 1. 클라이언트 로그 라이브러리 개발이곳의 서비스들은 클라이언트 로그(통계 정보) 수집을 위해 aws kinesis를, 사용자의 인증 정보를 획득하기 위해 cognito를 사용하고 있다. 문제는 이 클라이언..

이 책은 크게 두 파트로 나누어져 있다. 딱딱하지만 도움되는, 문장이나 어휘, 맞춤법등을 예시와 함께 설명하는 파트와 '함인주'라는 가상의 인물을 내세운 일종의 소설 부분이다. 문장에 대한 부분은 글쓰기에도 도움되며 아무 생각 없이 사용하던 어휘에 대해 되돌아보는 좋은 파트였다. 본래 글을 자주 쓰는 직업을 가지지는 않았지만, 코로나 이후 정착된 재택 근무로 다양한 사람들과 메신저로 소통하며 생기는 크고 작은 오해를 해결할 수 있는 작은 단서가 될 지도 모른다. 특히 저자가 말하는 '깔끔하게 읽히는 문장'이 된다면 업무 자체에도 큰 도움이 될 것이라는 생각이 든다. 특히 그 문제에 대해 나도 책임이 있다 -> 그 문제에 나도 책임이 있다. 서로에 대해 깊은 신뢰를 느낀다 -> 서로 깊은 신뢰를 느낀다. ..

아래에 적어두는 방식은 평상시 운영하고 있는 서비스가 특정 이벤트로 인해 더 많은 요청이 들어올 것을 대비하기 위한 계산 방식이다. 단순히 요청량과 CPU 사용률만으로 계산하는 방식으로 신뢰도가 굉장히 낮지만, 기본적인 지표로 삼고 메모리 혹은 로드 밸런서의 부하 등을 감안하여 인스턴스의 수를 조정할 수 있다. 평상시 인스턴스당 요청 처리량 먼저 이벤트 중이 아닌, 평상시 운영중인 서비스의 인스턴스당 요청량을 계산한다. 평상시 피크 타임의 Request 횟수를 획득한 후, 그 값을 인스턴스 개수로 나눠 피크 타임에 인스턴스 하나당 처리되는 요청의 양을 구한다. 평상시 피크 타임(23시 ~ 00시) 총 250,000 Request, 16개의 인스턴스를 사용 중일 때 250,000 req / 16 insta..

내가 2022년 상반기에 진행했던 프로젝트는 사내에서 PDP라고 불리던(이곳에서는 호텔,모텔,펜션,게스트하우스 등 국내 숙소의 상세 정보 페이지를 통칭한다) 상세 페이지를 완전히 새롭게 개발하여 기존 페이지를 대체하는 작업이었다. 개발하기로 하여 사전 회의에 모두 참여했던 담당자가 퇴사하는 바람에 갑자기 맡게 된 프로젝트로, 2명이 약 5개월간 개발을 진행했다. 나는 페이지에 노출되는 숙소의 위치, 정책 등 상세 정보, 후기, 그리고 쿠폰 정보 등을 주로 담당하여 개발했다. 이 프로젝트는 기존 하나의 프로젝트에서 노출하던 영역을 새로운 도메인이자 서비스로 분리하여 개발하는 마이크로 프론트엔드 개발이었다. Next.js를 이용하여 개발하고 AWS Beanstalk를 이용해 배포되었기에 새로운 도메인이 추가..