일년이 어떻게 흘러간지 한해가 지날수록 더 기억이 안 나서 정리의 필요성을 느껴, 올해부터는 회고를 진행해볼까 합니다.

💼 회사

01월~02월

서버리스 아키텍쳐 구현 마무리

12월부터 설계 및 개발을 진행하였던 서버리스 아키텍처를 12월 중순쯤 배포하였으나, 이슈 사항들이 많아 마무리 짓는데 생각보다 오래 걸렸습니다.

외부 싱크 여부를 판단하기 위한 데이터들을 Insert 또는 Update 하다 보니, RDS 콘솔 상에서 IOPS 쓰기가 1000 이상이 되는 경우가 발생했습니다.

해당 데이터를 레디스(Elastic Cache)나 noSQL(DynamoDB)에 쌓은 후, 다시 RDS로 옮기는 것도 검토해보았지만, 실제 구현할 경우 관리 포인트가 너무 많이 발생하게 되어 연동 속도를 줄이더라도 Lambda의 동시성을 조절하는 것으로 처리하였습니다.

02월~03월

On-The-Fly 동적 이미지 리사이징 구현

기존 서비스에서는 이미지 파일을 올릴 때 도메인별로 고정된 크기로 이미지를 리사이징하고 있었습니다.

다양한 해상도에 대한 대응이 어려웠고, 서버에서 동기식으로 이미지를 리사이징 하다 보니 파일 업로드의 응답 시간이 느려지는 문제가 있었습니다.

위 문제의 해결책으로 AWS Lambda를 이용한 이미지 리사이징을 검토하게 되었고, [VCNC] 온디맨드 이미지 리사이징 발표 자료와 [당근마켓] 온디맨드 이미지 리사이징 포스팅을 보았습니다. 해당 방식은 원본 이미지와 변환된 이미지를 모두 가지고 있을 수 있다는 이점이 있으나, 다양한 해상도를 모두 제공하는 데에는 비용적 문제가 있다고 판단하여, CloudFront Cache를 이용한 On-The-Fly를 도입하기로 하였습니다.

[당근마켓]AWS Lambda@Edge에서 실시간 이미지 리사이즈 & WebP 형식으로 변환 포스팅과 [후이서울]Lambda 한개로 만드는 On-demand Image Resizing 포스팅을 참고하여, Lambda@Edge 서비스를 이용하였습니다.

최초 이미지 생성에 Latency가 발생하나, 캐시 될 경우 빠르게 리사이징 된 이미지를 제공 할 수 있었습니다.

이와 같은 도입으로 이미지 최적화를 통해 모바일 사이트에서 이미지 용량을 최대 1/3까지 줄일 수 있었습니다.

03월~05월

해외 업체 예약 API 연동

작년부터 회사에서 서비스를 모놀리식 아키텍처(PHP)에서 마이크로서비스 아키텍쳐(Java Spring Boot)로 마이그레이션중이였습니다.

자바는 학부생때 배웠지만, 스프링을 해 본적이 없어서 개인 시간에 Spring Boot 책도 읽고, 정말 간단하게 회원 관리 시스템을 구성하여 AWS Elastic Beanstalk에 배포하는 등 API 연동 작업을 하기 위해 미리 준비를 좀 해두었습니다.

기존에 다른분들이 작성한 코드를 참고하여 작업을 하려했는데, 다른분들은 REST API로 작성하였으나, 제가 맡게 된 API는 XML SOAP으로 제공되고 있었습니다….

기존에 PHP에서는 SOAP을 설치해서 사용해서, 자바 서비스가 실행중인 서버에도 SOAP을 서버에 설치해야하나 고민했습니다만 다행히도 XML 포맷으로만 보내면 HTTP로 요청이 가능했습니다.

JAXB를 이용하여 Java 객체 <-> XML 을 처리하였는데, 해당 API가 SOAP Body의 특정 스키마부터는 htmlEsacpe를 해서 보내야하거나, 받아야하는 특이한 API 였습니다.

이 연동을 하며, 말로만 듣던 Retrofit 라이브러리도 사용해 보았고, 실제 서비스에서 JPA도 다루어 볼 수 있는 기회가 되었습니다. 또한 PHP에서는 클래스의 멤버변수에 값을 주입해서 쓰는 경우가 많았는데, Spring Application Context에서 관리되는 Bean들이 싱글톤으로 관리 되어 발생하였던 문제도 경험도 할 수 있던 좋은 기회였습니다.

Webhook 서비스 구축

PHP와 Java를 같이 가져가는 구조에서 백오피스는 기존 그대로 PHP를 유지하고 있는데, 외부 업체들에 상품 변경 내역을 실시간으로 웹훅과 같이 전달하는 기능이 요구사항이 생겼습니다.

AWS Lambda로 서버리스 아키텍처로 구현하였던 경험을 바탕으로 이번에는 Typescript 템플릿을 사용하여 해당 기능을 빠르게 구현 할 수 있었습니다.

06월

모놀리식 서비스 마이그레이션 시작

작년에 PHP에서 쿠폰 서비스를 고도화 작업을 진행하여, 어느정도 도메인에 대한 이해가 있다 생각하여 쿠폰 서비스를 자바로 마이그레이션 하는 작업을 진행했습니다.

우선적으로 개발 해야 했던 기능이 상품 전용 쿠폰을 사용 했을때 할인될 가격을 가져오는 부분인데, 제가 개발한 이후로 다국어 서비스 및 다중 통화 지원 서비스가 생겨서 예상치 못했던 변수들이 너무 많았습니다. 해당 부분을 작업 하셨던분들께 여쭤보며 해당 작업을 진행하였습니다.

현재 스프링으로 개발한 서비스들의 인프라 구성이 모두 동일하기 때문에, 인프라 구성은 기존에 서비스를 만들고 계시는 다른 자바 개발자 분들의 도움을 받아 동일하게 구성하였습니다.

사내 인프라 구성에 대해 배울 수 있는 좋은 기회였습니다.

신규 기능 개발

상품에 접근하는 방식을 개선하고자 상품을 새롭게 그룹핑하여 노출하는 신규 서비스가 요구 되었습니다.

프론트와 백엔드 서비스를 분리하는 시작으로 생각하여, 프론트 개발자분과 프론트 서비스 인프라를 어떻게 구성하는게 좋을지 같이 논의하여, 다양한 아이디어를 주고 받아 최종적으로는 SEO 지원을 고려하여 Next.js를 이용해 서버사이드 렌더링을하고 기존 서비스에는 영향이 없도록 하기 위해 AWS ELB를 활용하는 방향으로 설계하였습니다.

주요 도메인 설계는 다른분이 진행하여 주시고, 저는 서브로 퍼블릭 서비스에서 해당 데이터를 받아 조합하는 작업을 진행 하였는데, 기존에 도메인간 의존 관계가 너무 커서 퍼블릭 서비스보다 프라이빗 서비스가 모든 처리를 하는 방향으로 개발하게 되어 일정상 특정 기능을 제가 구현해야 하는 상황이 되었습니다.

해당 서비스의 도메인 설계와 구현 해야할 것에 대해 인수인계 받아 작업을 진행 하였고, 우여곡절 끝에 7월이 되어서야 빠른검색(가제) 서비스 릴리즈를 완료했습니다.

📒 블로그

어썸데브 블로그

국내 개발자들 블로그를 구독하고 있었는데, 내 포스팅도 많이 노출되어서 많은 피드백을 받았으면 좋겠다 싶어서, 해당 서비스가 어썸데브블로그의 피드를 사용하기때문에 국내 개발자로 등록을 하였습니다.

등록하고 바로 포스팅을 올렸는데 어날리틱스 기준으로 처음으로 블로그 1일 방문자수가 20을 넘었습니다. 해당 그래프를 보는게 재밌어서 포스팅을 계속해서 올렸었고, 아래와 같은 그래프를 그릴 수 있었습니다.

노출 수가 많아질수록 더 읽고 싶은글, 읽기 좋은 글 또는 관심가질만한 글들을 써야겠다고 생각하게 되었습니다.

블로그 배포 방식 변경

기존에 hexo-cli를 이용해서 배포를 하다가 매번 커맨드를 치는것도 귀찮다 생각하여, package.json에 스크립트를 작성해두었습니다.

팀원에게 Codeship 서비스로 깃허브 블로그 배포 자동화 하는 방법을 소개해주어 팀원분은 이걸 적용했는데, 저는 드롭박스로 코드를 관리하고 있었고 소스 전용 레포지토리도 따로 관리하고 있었기 때문에 큰 필요성을 못 느꼈습니다.

하지만 hexo deploy 와 소스 전용 브랜치에 커밋&푸시를 별도로 하는게 딱히 메리트가 있다고 생각이 들어 바로 작업을 진행하게 되었습니다.

Codeship으로 배포할까 하다가 이번에는 플러그인처럼 프라이빗 repo에서도 깃허브와 연동시 무료로 제공되는 Travis CI를 이용하기로 하였습니다.

ChangJoo Park님의 포스팅 Travis CI를 이용한 Github Pages + Hexo 블로그 자동 배포하기을 참조하여 작업을 진행하였고, 빈 파일이 올라가는 문제도 겪었지만 블로그 소스 코드 관리 및 배포를 조금 더 간결하게 할 수 있어서 의미있는 작업이였다고 생각합니다.

Github Actions 서비스가 현재 베타 서비스중이여서 나중에는 이걸로 갈아타지 않을까 생각합니다

도메인 연결과 깃허브 아이디 변경

기존에 Github Page를 이용하여 github.io 도메인을 사용했는데, 지인의 추천을 받아 그날 바로 dev 도메인(hodory.dev)을 구매한 후 엄청난 삽질을 진행하였습니다.

원래는 서브 도메인(blog.hodory.dev)으로 블로그임을 더 확실히 하고 싶어서 서브도메인만 쓰려 했는데, 구글 애드센스때문에 루트도메인도 리디렉션 처리를 했습니다.

도메인을 여기저기 잘 활용하고 있어서, 도메인을 구입한거에 대해서는 전혀 후회하지 않습니다.

아쉬운점이라면 구글 서치 콘솔에 쌓인 2년간의 데이터를 잃어버린점이지만 크게 의미 있는 데이터는 아니였다고 생각합니다.(기존의 구글 검색에 노출되는 포스팅은 전부 현재 도메인으로 리디렉션 시켰습니다.)

🏃 일상

💪 운동

앉아서만 일을 하다보니 활동량이 줄어들어 계속해서 체중이 증가하고 있었습니다.

체력적으로도 문제가 될 수 있겠다 싶어, 4월부터 회사 근처에서 운동을 다니기 시작하였는데, 운동을 안하는 날에도 열심히 먹었지만 오히려 보상 심리로 운동이 끝난 후 더 많이 먹어서 체중이 늘어난거 같습니다…

꾸준히 다녀야지 하고 시작했던 운동인데, 간간히 운동 빠지는 재미가 쏠쏠합니다…

🔧 프로젝트

인스타그램으로 맛집을 많이 찾아 돌아 다녔는데 광고가 많아져서 몇번 데이고 나니, 제가 필요해서 프라이빗한 SNS를 만들어볼까? 생각하고 대학 동기들과 프로젝트를 진행하였습니다.

당시 스프링을 공부하고 있어서 스프링 부트로 서비스를 만들고, 기획도 진행하고, PM 역할까지 같이 했는데 중간에 슬럼프도 오고 각자의 사정으로 잠시 중단한 상태입니다.

하반기에는

위에 작성한 SNS 프로젝트를 다시 진행하고 싶은데, 같이 프로젝트를 진행하던 팀원들이 다들 바빠져서 가능할지 모르겠습니다.

면접에서 좋은 면접관님을 만나 평소에 생각하지 않았던 것들에 대한 좋은 질문을 받을 수 있는 기회가 있었는데, 굉장히 긍정적인 경험이였습니다. 하반기에는 이러한것들을 함께 고민해 볼 수 있는 자리를 찾아 볼까 합니다.

이직을 하게 되었는데, 우선적으로 새로운 회사에 빠르게 적응 해야 할 것 같습니다.

경력이 이제 3년이 되어 가는데, 아직까진 주위에서 "잘하고 있다." "잘한다."라는 좋은 이야기들을 들으며 일해 왔는데, 주관적으로 보았을때에도 아직 경력에 비해서도 모자른게 많이 느껴집니다. 3년이면 프레임워크정도는 혼자서 만들 수 있고, 사이드 프로젝트로 서비스 하나 정도는 릴리즈 하거나, 오픈 소스에 기여할 수 있을줄 알았는데 이정도 년차에 잘 하시는 분들은 이미 위의 세개중 하나에서 두개정도는 하시는것 같아서 더 분발해야할 것 같습니다.

알고리즘과 자료구조, 네트워크 지식 등 기본 지식들을 공부해야지... 공부해야지... 라고 말만 3년째 하고 있는것 같습니다. 물론 실무를 경험하며, 면접을 준비 하며, 블로그를 보다가 배우는 것들도 있긴한데 하나를 알아도 제대로 알아야 할 것 같습니다.

최근에 블로그를 찾아서 아는것만으로는 공부가 아니다라는 말씀을 들어 저처럼 본인이 아는걸 작성하고 공유한 글인데, 무분별하게 받아 들이던 제 자신을 반성하게 되었습니다. 출판 서적으로 공부하는게 정석이라고는 생각은 하면서 실천하지 못해, 하반기에는 노력해야 할 것 같습니다.