미리보기

“개발자를 시작한 이유”’

개발자를 시작해보자고 마음 먹은 건 아버지와의 우연한 대화 때문이었습니다. 코로나로 인해 아버지가 하시는 사업의 일거리가 많이 줄게 되어 경제적으로 걱정이 많다는 내용이었습니다. ‘아버지가 하는 일을 개인과 매칭 해줄 수 있는 웹 페이지가 있으면 좋겠다.’라는 생각을 하게 되었고, 가벼운 마음으로 개발 공부를 시작했었습니다. 개발 공부를 하다 보니, 기존 전공인 생명과학 보다 훨씬 큰 재미를 느끼게 되어 소프트웨어 학과를 복수 전공 하게 되었습니다.

“되고 싶은 개발자”

개발자는 언어, 프레임워크, 기술 등에 제한을 받지 않아야 된다고 생각합니다. 문제를 해결하는 능력이 있으면 어떤 곳에서든 충분히 영향력을 줄 수 있다고 생각하고 있습니다. 저는 주어진 좋은 기회들을 기술 스택 때문에 포기하지 않는 개발자가 되고 싶습니다.

“기초가 탄탄한 개발자”

저는 어떤 일이든 기초가 가장 중요하다고 생각합니다. 기초로부터 더 어려운 문제도 해결할 수 있는 능력이 생긴다고 생각합니다. 저는 학교 수업들 중 C언어, Java, Python 기초를 다루는 수업들에서 모두 A+이라는 성적을 받았으며, 학교에서 배우는 CS들을 개인 기술 블로그에 정리하면서 기초를 쌓기 위해 노력하였습니다.

“책임감으로 성격조차 극복”

저는 내성적인 사람입니다. 앞에 나서는 것을 싫어하고 부끄러워 합니다. 하지만, 제가 해야 하는 일에 대해서는 무조건 책임지고 해낼 만큼 책임감이 강합니다. 저는 교회에서 교육 부서 봉사를 하면서 총괄을 맡고 있습니다. 평소 나서는 것을 부끄러워 하지만 총괄이라는 역할이 가진 책임이 있기 때문에, 각종 행사, 회의 등을 진행하는데 주저 없이 나서서 합니다.

“팀 플레이어”

저는 팀이 더 좋은 방향으로 나아가기 위해 제가 할 수 있는 일을 끊임없이 생각 하며 팀의 좋은 분위기를 위해 노력합니다. 팀 프로젝트로 진행했던 맛집 랭킹 서비스에서 백엔드와 팀장 역할을 맡았었습니다. 백엔드가 일정의 차질 없이 API 개발이 잘 진행되고 있던 반면에, 프론트엔드 개발은 진행 속도가 많이 더디게 되었습니다. 같이 개발하던 백엔드 개발자의 불만은 쌓여갔고, 저에게 불만을 털어놨습니다. 상황에 대해 고민을 하고 나서 저는 프론트 개발자들에게 오류 상황을 공유 해 달라고 요청하였습니다. 저는 이미 개발이 많이 진행되었던 상황이었기 때문에, 프론트에서 공유한 오류 사항들을 수정해 나가는 것을 도와주었습니다. 덕분에 프론트의 개발 속도도 빨라질 수 있게 되었고 백엔드 팀원의 불만도 줄어들게 되어 마감 시간까지 수월하게 프로젝트를 마무리 할 수 있었습니다.

“기술적 역량”

Java 기본 문법과 함께 Collection, Stream, Optional, 람다 등을 공부하며, 더 가독성 있는 코드를 프로젝트에 적용 하기 위해 노력하였고, SOLID 원칙을 고민하며 프로젝트를 진행 해 왔습니다. 또한, Springboot를 공부하며 객체 간 의존성 결합도를 낮추기 위한 방안들을 고민하였습니다. JPA를 사용하면서 테이블을 주로 다대일 관계로 풀어내려고 노력하였으며, 테이블 간의 일대다 관계에서 발생할 수 있는 N+1 문제, 영속성 컨텍스트, 더티 체킹과 트랜잭션 내에서 발생할 수 있는 에러 등에 대해 고민해왔습니다. 프로젝트 내에서 검색 API를 구현 하면서 동적 쿼리의 필요성을 느껴, QueryDSL을 학습하고 적용하였습니다.

“프로젝트 경험”

‘맛집 랭킹 서비스’를 주제로 한 팀 프로젝트를 진행하면서, RestAPI로 구현하였으며, 배포 후 발생하는 CORS 문제를 Spring Security를 통해 해결하는 방법과 프론트에서 Proxy를 통해 해결하는 방법 모두 사용하면서 해결한 경험이 있습니다. 더 원활한 개발 환경을 조성하기 위해 AWS EC2에서 배포한 상태로 개발을 진행하여, 프론트에서 개발하며 API를 바로 테스트 해볼 수 있도록 하였습니다. 또한, AWS RDS를 배포하여 프론트에서 실제와 같은 환경의 DB를 통해 테스트 할 수 있도록 하였습니다. 리뷰를 작성하게 되면 이미지를 저장해야 하는데, 서버 내에 이미지를 저장했을 경우에는, 새롭게 저장된 이미지는 조회가 되지 않으므로 AWS S3에 이미지를 저장함으로써 실시간으로 조회할 수 있도록 하였습니다. 백엔드간의 협업을 위해서 Git 컨벤션을 공부하였고, commit과 branch 생성 규칙을 정하여 작성할 수 있도록 하였습니다.

‘SNS’를 주제로 한 개인 프로젝트에서는 모놀리스 구조로 구현했던 프로젝트를 요즘 많이 사용하는 MSA 구조로 마이그레이션하는 작업을 해보았습니다. 각 비즈니스 모델에 맞는 서버로 나눠야 하기 때문에 다른 서버들로 흩어지게 된 클래스들 간의 매핑 관계가 문제가 되었습니다. 이 문제를 해결하기 위해, 직접 Long 타입 FK를 엔티티 필드에 추가해 주었습니다. 처음 엔티티 코드를 작성할 때, 같은 생명 주기 안에 있지 않은 엔티티들의 관계는 JPA로 매핑 해주기 보다는 직접 FK를 엔티티 필드에 추가해 주는 것이 유지 보수에서 더 깔끔한 코드가 나올 것 같다는 생각이 들었습니다.

‘예약 구매’를 주제로 한 개인 프로젝트에서는 특정 상황에서 이용자가 몰리는 상황을 가상으로 시뮬레이션 하여, 동시성 문제를 해결하는 경험을 해보고자 하였습니다. 실제 대용량 트래픽을 직접 경험해 보기는 힘들기 때문에, Jmeter를 사용하여 동시에 10000개의 쓰레드가 결제 API를 호출 할 수 있도록 하였습니다. 동시성 문제가 발생했던 경우는 재고를 조회하고 수정하는 과정에서 발생하였습니다. 결제 프로세스에 들어갔을 때, 주문한 수량 만큼 재고가 감소 되고 나서 다음 사람이 재고 수량을 조회할 수 있어야 했지만, 먼저 들어간 사람의 재고 처리가 완료되기 전에 다음 사람이 재고를 조회하여 문제가 발생했습니다. 이를 해결하기 위해서 결제 API 자체에 Synchronized를 사용하여 동기화를 해주었고, 한번에 하나의 쓰레드만 결제가 진행 되었기 때문에 동시성 문제는 발생하지 않았습니다. 하지만, 한 쓰레드가 결제 중일 때, 나머지 쓰레드는 모두 기다려야 하므로 성능이 매우 낮은 문제가 있었습니다. 이를 해결하기 위해, 재고 DB에서 베타적 락을 걸어주었습니다. 베타적 락이 걸려 있는 상태에서는 다른 트랜잭션에서 DB에 접근할 수 없으므로 동시성 문제가 해결되었고 처리 속도가 84%가 향상된 결과를 얻을 수 있었습니다. 또한, 재고 처리 속도를 향상 시키고자 고민을 하였고, redis를 캐시로 사용하였습니다. 조회와 수정이 DB에서 계속해서 일어나는 경우 속도가 매우 느려지는 것이 문제였기 때문에 write-back-through 캐싱 전략을 사용하여, 캐시에서 재고의 조회와 수정이 일어나고 일정 시간마다 DB에 업데이트 해주도록 하였습니다. 결과적으로 처리 속도가 25.42% 향상된 결과를 얻을 수 있었습니다.