미리보기

[스마트 제조 물류 서비스 관련 과제 수행]

• OCR을 통한 작업일지 기록 효율화

• MES의 KEY-IN 기반 기존 워크플로우 개선 방안 기획

• 노션 글로벌 엠버서더 선정

• 노션 API를 활용한 워크플로우 자동화 관련 아티클 작성 (진행중)

• 주제 : 위치 기반 역사 탐방 서비스

• 기간 : 2024.04.08 ~ 2024.05.20

• 인원 : 총 6명 (백엔드 3인, 프론트엔드 3인)

• github : https://github.com/seoulpop/seoulpop-be

• Role

  • 팀장

  • 백엔드 리더

  • 서버 및 CI/CD 구축

  • 회원 기능 API 구축

  • 역사 조회 기능 담당

    • 문화재 조회

    • 사적지 조회

• Language : Java 17

• Framework

  • SpringBoot 3.2.5

  • Spring Data JPA

  • Spring Security

  • QueryDSL

• Database

  • MySQL 8.0

  • Redis 7.2

  • AWS S3

• Server

  • AWS EC2 t2.xlarge

  • Nginx Proxy Manager

  • Docker

• CI / CD : Jenkins

• Tools : gitlab, IntelliJ, Jira, figma

어려웠던 점

1. 실시간 위치에 따른 거리 계산

• 유저 이동 시 수시로 바뀌는 위치에 따른 주변 좌표 계산을 어떻게 처리해야할지 고민했습니다.

• 최단 거리를 수시로 계산하기에는 비용이 지수시간으로 증가했습니다.

• 보다 효율적인 탐색을 하기 위해서는 단순 탐색 방식 보다 개선된 방식이 필요했습니다.

  • 실시간 유저 좌표 기반 부분 탐색 vs GeoHash vs Uber-H3

💡 이렇게 해결했습니다.

• 실시간 근접성 계산 및 정확성, 편의성을 고려하여 Uber H3를 도입했습니다.

• 다양한 스케일을 실험하여, 최종적으로 약 200미터 정도의 거리를 가정하고 최적화했습니다.

• 가장 효율적인 방식을 채택함으로써 생산성을 높일 수 있었습니다.

2. 효율적인 로그 추적

• 기존에는 Portainer를 통해서 컨테이너들의 로그를 추적해왔습니다.

• 그러나, 컨테이너 수가 많아질수록, 효율적인 방식의 추적이 어려워졌습니다.

• 추가적으로, Portainer의 고질적인 콘솔 스크롤 문제는 이전 로그 추적의 불편함을 주었습니다.

• 다양한 툴을 모색했고, 그 중에서도 가장 간편하면서 강력한 도구를 도입하고자 했습니다.

💡 이렇게 해결했습니다.

• Dozzle을 도입하여, 여러 컨테이너들의 로깅을 간편하게 진행할 수 있었습니다.

• 트랜잭션 별로 로그의 가시성이 높아졌고, 이를 통해 생산성을 높일 수 있었습니다.

• 이를 통해 팀원들에게 보다 직관적인 로그 추적 환경을 제공할 수 있었습니다.

• 주제 : 노래 가사 기반 게임 서비스

• 기간 : 2024.02.19 ~ 2024.04.05

• 인원 : 총 6명 (백엔드 2인, 프론트엔드 2인, 데이터 2인)

• github : https://github.com/lyricit/lyricit-be

• Role

  • 백엔드 리더

  • 서버 CI/CD 구축 및 인프라 총괄

  • 웹소켓 통신 구축

  • 회원 기능 API 구축

  • 채팅 기능

  • 방 생성 및 게임 참여 API 구축

  • 게임 플로우 전체 리팩토링

  • 게임 내 타이머 스케줄링

• Language : Java 17

• Framework

  • SpringBoot 3.2.1

  • Spring Data JPA

  • WebSocket

• Database

  • MySQL 8.0.35

  • Redis 7.2

  • ElasticSearch

• Server

  • AWS EC2 t2.xlarge

  • Nginx Proxy Manager

  • Docker

• CI / CD : Jenkins

• Tools : gitlab, IntelliJ, Jira, figma

어려웠던 점

1. pub / sub topic 설계

• 게임 내 존재하는 수많은 topic을 어떻게 관리하는게 유리할지 고민을 했습니다.

• 리소스를 효율적으로 활용하면서 동시에 채널 관리가 용이한 방식을 구상해야 했습니다.

• 개발 비용을 줄이기 위해서는 직관적인 방식을 선정해야 했습니다.

  • 클라이언트 컴포넌트 별로 topic 지정 vs 페이지 별 topic 지정 후 message type 설정

💡 이렇게 해결했습니다.

• 페이지 별로 topic을 싱글 채널로 관리하며 이에 대한 통일된 Response를 지정했습니다.

• 상황에 따른 다양한 message type을 활용하는 방식으로, 채널의 관리 복잡성을 줄였습니다.

• 이를 통해 리소스 부담을 줄일 수 있었고 동시에 기능 별 유연한 확장이 가능하도록 하였습니다.
  

2. 세션 Disconnect 문제

• 회원은 로그아웃의 개념이 아닌, 소켓 세션이 끊어지는 것을 기준으로 오프라인 처리를 했습니다.

• 이 때, Redis에서 관리하는 방과 게임에 대한 세부적인 업데이트 로직이 필요했습니다.

• 뿐만 아니라, 타임아웃 메커니즘으로 인해 연결이 끊어지는 문제도 해결해야 했습니다.

💡 이렇게 해결했습니다.

• 인터셉터를 통해 STOMP의 command를 확인하여 다양한 분기 처리를 하였습니다.

• 게임 중 단일 유저가 disconnect 되면, 해당 게임과 방의 데이터를 삭제 후 업데이트 하였습니다.

  • 채널 인터셉터에서 이벤트 리스너를 활용하여 순환참조를 예방할 수 있었습니다.

• 나아가 HeartBeat를 활용하여 세션 끊김 현상을 해결할 수 있었습니다.

  • ping, pong 프레임을 일정 시간마다 주고 받으며 연결성을 보장할 수 있었습니다.

• 주제 : 명절 기간 중 잔소리 및 대처 경험 공유 서비스

• 기간 : 2024.01.02 ~ 2024.02.16

• 인원 : 총 6명 (백엔드 3인, 프론트엔드 3인)

• github : https://github.com/jansorry/jansorry-be

• Role

  • 팀장

  • 백엔드 리더

  • 인프라 및 기술 총괄

  • 서버 및 CI/CD 구축

  • 메인 서비스 API 구축

    • 잔소리 관련 기능 전체

    • 좋아요 및 팔로우 기능

    • 영수증 생성 및 공유 기능

    • 배치 스케줄링 기능

• Language : Java 17

• Framework

  • SpringBoot 3.2.1

  • Spring Data JPA

  • Spring Security

  • Spring Batch

• Database

  • MySQL 8.0.35

  • Redis 7.2

• Server

  • AWS EC2 t2.xlarge

  • Nginx Proxy Manager

  • Docker

• CI / CD : gitlab-runner

• Tools : gitlab, IntelliJ, Jira, figma

어려웠던 점

1. Redis 내에서의 팔로우 양방향 관계 지정

• 비관계형 데이터 베이스에서 팔로우 관계를 어떻게 처리할 것인지 긴 고민을 했습니다.

• 단방향 관계인 좋아요 기능과는 달리 팔로우의 N:M 관계를 어떻게 풀어나갈 지 초점을 맞췄습니다.

• 기회비용을 고려해야 했습니다.

  • 양방향 저장 시 데이터 적재량 증가 vs 단방향 데이터 저장 시 탐색 효율 저하

💡 이렇게 해결했습니다.

• 와일드카드를 최대한 지양하는 방향이 올바르다고 판단하여 양방향 저장을 선택했습니다.

• "following", "follower" 접두사를 붙이는 key 네이밍 전략을 활용하여 양방향으로 저장했습니다.

• 최종적으로, 유저의 팔로워 및 팔로잉 리스트 조회 시 탐색 시간을 크게 줄일 수 있었습니다.

2. Spring Batch를 통한 데이터 동기화 시 전체 탐색 문제

• 배치 작업에서 Redis의 데이터를 MySQL로 동기화하는 작업은 매일 새벽 3시에 진행됐습니다.

• 이 때, Redis에서 업데이트 된 데이터만을 배치 작업에 태우기 위한 다양한 시도를 했습니다.

💡 이렇게 해결했습니다.

• Redis의 ZSET 자료형을 활용하여, 스코어를 데이터 업데이트 시간으로 지정했습니다.

• 데이터가 업데이트 될 때마다, 해당 데이터의 key값을 update ZSET에도 반영했습니다.

• 이를 통해, 이전 배치 시간 이후 발생한 업데이트의 키 값만을 동기화 할 수 있었습니다.

• 배치 마무리 시점에는, ZSET을 초기화함으로써 새로운 업데이트 set만을 담을 수 있게 했습니다.

  • 나아가, 좋아요나 팔로우 취소로 인해 Value의 자료형이 Empty일 경우,

    이를 테이블에서 제거하여 추가적인 공간 확보 작업도 진행했습니다.

3. 최종 통계 도출 시 Top 5 가격의 영수증 파악

• 최종 데이터 통계를 구할 때, 가격 순으로 가장 비싼 5개의 영수증을 파악해야했습니다.

• 모든 유저의, 모든 영수증을 한 번에 파악하기에는 너무 많은 비용이 발생한다고 생각했습니다.

💡 이렇게 해결했습니다.

• 데이터 업데이트 시 ZSET을 활용했던 방법을 응용하였습니다.

• 어느 한 시점에 발생하는 탐색 효율 저하를, 유저에게 실시간으로 분산시키는 전략을 선택했습니다.

• 유저가 영수증을 저장할 때, Top5 영수증 ZSET에도 가격을 score로 지정하여 반영했습니다.

  • 우선순위에 따라 6위로 지정된 영수증은 자동적으로 삭제하여 5위권을 갱신했습니다.

• 주제 : 부동산 모의 투자 서비스

• 기간 : 2023.11.01 ~ 2023.11.24

• 인원 : 총 2명 (백엔드 1인, 프론트엔드 1인)

• github : https://github.com/NewJibs/newjibs-be

• Role

  • 팀장

  • 백엔드 총괄 (1인)

  • 서버 및 CI/CD 구축

  • 회원 기능

  • 랭킹 조회 기능

  • 부동산 모의투자 기능

  • 공지사항 기능

  • 뉴스 기능

• Language : Java 8

• Framework

  • SpringBoot 2.7.16

  • Spring Data JPA

  • Spring Security

• Database

  • MariaDB 2.7.4

  • Redis

  • S3

• Server

  • AWS EC2 t2.micro

  • Docker

• CI / CD

  • CloudType

  • github-action

• Tools : github, IntelliJ, figma

어려웠던 점

1. 400만 개의 데이터 축소작업

• "부동산 모의 투자"라는 주제에는 400만개가 넘는 데이터가 전부 필요하지는 않았습니다.

  • 2016 이후 발생한 모든 매매 데이터가 있는 상황이었고 이는 렌더링 성능저하로 이어졌습니다.

• 이를 해결하기 위해 데이터를 임의의 기준에 맞추어 축소시켜야했습니다.

• 코로나19의 시작인 2020년을 기점으로 부동산 가격이 많이 오른 점을 감안했습니다.

💡 이렇게 해결했습니다.

• 2020년과 2022년에 동일한 층수와 평수를 가진 데이터를 1:1 매핑 시키는 작업을 진행했습니다.

• 동일 가구의 매매 데이터를 기반으로 하여 보다 신뢰도 높은 투자 결과를 파악하려고 했습니다.

• 최종적으로 400만 개 이상의 데이터를 6만 개 정도로 줄였고, 렌더링 성능 또한 크게 개선했습니다.

2. 뉴스 크롤링 시 발생하는 bot 인식 문제

• Jsoup을 활용하여 매 정각마다 최신 부동산 뉴스 데이터를 크롤링했습니다.

• 기계적 호출로 인해 bot으로 인식이 되었고, 매번 서버 ip가 차단당하는 문제가 있었습니다.

  • 셀레니움을 활용하기 보다는 크롤러 내부적으로 해결을 하고자 했습니다.

💡 이렇게 해결했습니다.

• 정각마다 데이터를 호출하는 문제 + 헤더값 때문에 bot으로 인식한다는 점을 파악했습니다.

• 헤더를 교체하고, 데이터 호출 시점에 임의의 랜덤 딜레이를 부여하였습니다.

• 이를 통해 안티 크롤링 매커니즘을 우회화여 스케줄링 패턴의 명확성을 낮출 수 있었습니다.

• 주제 : 여행 금융 다이어리 서비스

• 기간 : 2023.09.01 ~ 2023.09.17

• 인원 : 총 4명 (백엔드 3인, 프론트엔드 1인)

• github : https://github.com/Triplet-Shinhan/Triplet

• Role

  • 백엔드 메인 서비스 API 구축

    • 회원 기능

    • 여행 관리 기능

    • 데일리 관리 기능

    • 이미지 업로드 기능

  • 서버 및 CI/CD 구축

• Language : Java 11

• Framework

  • SpringBoot 2.7.10

  • Spring Data JPA

• Database

  • MySQL 8.0.31

  • S3

• Server

  • AWS EC2 t2.micro

  • Docker

• CI / CD

  • github-action

• Tools : github, IntelliJ, figma

어려웠던 점

1. 현실과는 달랐던 API

• 실제 은행의 API에는 수 많은 보안, 기술적 이슈가 따랐기에 동작하는 API를 제공받지 못했습니다.

  • 그래서 해커톤은 더미 데이터로 이루어진 API를 제공 받은 상태로 진행됐습니다.

• 거래 로직부터 환율 정보 등을 직접 파악하여 프로젝트를 진행해야 했습니다.

💡 이렇게 해결했습니다.

• 지출부터 환율 정보 등등, 다양한 상황을 가정하여 추가적인 API 및 더미데이터를 만들었습니다.

• 이를 통해 유저 시나리오에 맞춘 다양한 상황을 연출할 수 있었습니다.

2. EC2 인스턴스 사양 문제

• AWS를 무과금으로 돌리기 위해 프리티어 계정의 인스턴스에 모든 컨테이너를 올려야 했습니다.

• 지속적으로 사용량이 치솟으면서 인스턴스가 종료되는 이슈가 있었습니다.

• 이를 해결하기 위해 사양을 과금 모델로 올리는 방법도 생각했었습니다.

💡 이렇게 해결했습니다.

• 프리티어의 1기가 램은 너무나도 작았기에 메모리 스왑을 통해 해결해야했습니다.

• 첫 배포 작업이었기에 문제 원인을 파악하기까지 오래걸렸습니다.

• 최종적으로 한정된 자원을 최대한 효율적으로 쓰는 방법의 중요성을 깨달았습니다.