2023 11월 회고록

되게 오랜만에 회고록을 작성하는데, 글을 어떻게 써야 할지 감이 안 오네요..

그래도 이번달에는 이사 예정도 있고, 학우들과 진행하고 있는 캡스톤 프로젝트도 마무리 지어야 될 거 같아서 미리 앞당겨서 글을 작성하려고 합니다.

 

벌써 올해가 끝나가네요. 믿기지가 않을 정도로 빨리 지나갔던 것 같습니다. 

이제 서울 상경(?) 한 지 3달이 다 되어가는데, 아직까지도 생활적인 면에서는 불편함이 있네요. 더불어 지하철 파업 이슈로 2호선은 엄청 지옥인 거 같습니다 진짜로.. 하지만, 원래 계획이었던 캡스톤 프로젝트와 회사 업무를 병행하는 데는 크게 지장이 없기에 매우 흡족스러운 상황입니다. 

 

아직 수습기간이 끝나지 않아, Git 계정을 최근에 받았기에 기본적인 Legacy 코드 분석과 개인 Local PC 환경에서 Application을 구동하기 위해  application.properties 설정파일을 수정하고, 회사 프로그램이 어떻게 돌아가는지 파악하는데 급급했던 것 같습니다. Switch 장비 연동도 해보면서 새로운 경험을 했던 거 같아 뿌듯하네요. Docker-compose 파일이 있었기에 Elasticsearch, MariaDB 세팅에는 크게 번거로움이 없었던 것 같습니다.

 

저는 항상 JPA 기반으로 개발을 진행해 왔지만, 회사에서는 JPA, Spring Batch, Elasticsearch 등 다양한 기술들을 사용하고 있기에 다방면으로 공부의 폭을 넓혀가야 할 것 같습니다. 현재는 Elasticsearch의 Indexing, Searching을 하기 위한 Query(termQuery, matchQuery, boolQuery...)에 대해서 학습하고 있습니다. 아직 부족한 게 많아 끊임없이 공부해 보면서 지식을 습득해야 할 것 같습니다. 

추가적으로, 저희 프로젝트에서는 DB Replication 및 Clustering 기술로 Garela Cluster를 활용하고 있는데, 갈레라 클러스터는 동시성 문제를 해결해 준다는 측면이 가장 큰 메리트지만, DeadLock 문제는 완벽하게 해결할 수 없기에 이러한 문제점에 대한 고찰과 개선방향에 대해서도 고민해봐야 할 것 같습니다. 

 

이번에 우테코 쓴 친구들이 진짜 너무 많아서, 친구들의 코드를 보면서 서로 관점도 공유하고 피드백을 주고받는 시간도 가졌던 거 같습니다. 친한 친구들이 다 합격했으면 좋겠다는 생각에 리팩토링할 때마다 코드를 봤던 것 같고, 이러한 부분들에서 저도 배운 게 많았기에 만족스럽습니다. 제발 다 붙어서 웃는 얼굴로 봤으면 좋겠네요.! 하지만, 다들 저보다 훨씬 잘하는 친구들이라서 크게 걱정은 안 되네요.

 

리뷰 과정

 

캡스톤 디자인 프로젝트는 사전에 미리 팀원을 구해놨기에 진짜 수월하게 진행되고 있는 것 같습니다. 같이 동아리하는 바쁜 친구가 도와줬기에 담에 밥이라도 한 끼 사야 할 것 같네요..! 대략적으로 프로젝트의 핵심 기능을 소개드리자면, 크롤링을 통해 수집된 알러지 유발 재료 정와 OpenAPI를 통해 얻은 레시피 재료 정보를 결합하여 사용자에게 해당 메뉴의 안전성을 판별해 주는 기능입니다. Entity가 복잡하지 않지만 도메인형 패키지로 설계하였고, DDD(Domain-Driven Design)로 개발을 진행하였습니다. 친구와 함께 서로 Peer Review 해주는 방식으로 진행 중입니다.

[Github: https://github.com/2023ICE/backend]

 

[메인 기능 개발 진행 상황 및 직면하고 있는 문제]

 

음식 재료 범위 확정

• RecipeName(레시피)에 해당하는 Allergy를 찾기 위한 시간 복잡도 최적화에 대한 고민
• Map<String, Allergy>, Map<Allergy, String> 이것 둘 중에 우리 요구사항에 더 효율적인 것은 Map<String, Allergy>
  • 알러지 정보를 Key로 사용한다면, 알러지 정보를 키로 사용하여 해당 알러지에 연관된 재료를 순회해야 합니다. 더불어, 알러지 정보를 순회하면서 해당 알러지와 관련된 재료를 찾아야 합니다. 재료가 5개이면, 각 재료에 대해 모든 알러지 정보를 순회하고, 그 안에서 해당 알러지와 관련된 모든 재료를 순회해야 합니다 O(n^3)
  • 재료 이름을 Key로 사용하면 재료에 해당하는 알러지(Value)를 즉시 조회할 수 있습니다. O(n)

Member.class 

• Member Entity에 본인의 알러지 정보를 담기 위한 필드인 allergies를 EnumSet<T> 타입으로 선언
• 하지만, Spring Data JPA의 기본 직렬화 메커니즘은 EnumSet<T> 타입의 직렬화를 지원하지 않습니다.
• 따라서, Member Entity class가 RDB(Mysql)에 저장되기 위해서는 EnumSet<T> 타입의 allergies Field와 DB Column 사이의 직렬화(Java → Json), 역직렬화(Json → Java) 과정을 직접 구현해줘야 합니다.

이러한 문제를 해결하기 위해 따로 Enumset의 직렬화, 역직렬화의 기능을 담당하는 Converter 클래스를 만들어주었습니다.

 

이제 Allergy 관련 CRUD와 AWS EC2 배포만 해주면 프로젝트는 잘 마무리될 것 같습니다.

 

 

 

3달 만에 작성한 포스팅이라 두서가 없고 지저분하더라도 양해 부탁드립니다. 글이 잘 안 써지네요...