제로베이스 개인프로젝트 진행록3 - 기능고려/readme/성능최적화 초안 구상

bsh6226 2024. 9. 20. 15:52

지난 피드백과 회신

안녕하세요 밍밍멘토님 상세한 피드백 감사드립니다. 피드백 주신부분에 대해서 답변드립니다.

• 우선 일차적으로는 주제의 현실성에 대해서 제가 피드백을 드리긴 했습니다. 다만 제가 상화님의 실력이나 해당 스터디에 투자할 수 있는 시간등을 정확히 알지 못하기 때문에 이전에 드린 피드백 이외에 더 나아가서 피드백을 드리긴 어려울 것 같습니다. 제가 처음에 드린 피드백을 바탕으로 고민해보신 뒤 현재와 같이 범위를 설정하신 것이라면 문제 없을 것이라고 생각됩니다.

-> 네, 1~4순위 우선순위대로 구현 진행해보도록 하겠습니다.

• 다만 추가적으로 드릴 수 있는 피드백으로는, 현재 알고리즘 학습을 한뒤 학습하신 알고리즘을 서버개발에 녹여내고자 하신것 같은데요, 저는 해당 부분이 서버개발자로서 크게 메리트가 있는 경험이라고는 판단하지 않습니다. 실무에서는 더 복잡한 알고리즘을 사용하기 때문이에요. 그리고 서버 개발자가 알고 있어야할 기본적인 알고리즘에 대한 이해도는 코딩테스트를 통해서 테스트합니다. 따라서 알고리즘을 서버 개발 기능에 이용하는 것을 서비스의 메리트로 삼기에는 조금 돌아가는 느낌이 드네요. 그보다는 쿼리 최적화나 캐싱전략등에 집중하는것이 좀더 좋다고 개인적으로는 생각하긴합니다. 다만, 해당 기능을 한번 구현해보고 싶으시다면 해당 측면에서 기능을 넣는 것은 좋다고 생각합니다.

-> 네 객관적인 피드백 감사드립니다. 이번 프로젝트는 우선적으로 제가 관심사가 높은 주제(문화재, 야외활동), 관심사가 높은 기술(탐색문제)를 프로젝트로 구현해보면 어떤 느낌일까 체험을 해보고싶어서 선정하게 되었습니다. 실무에서는 알고리즘만 전문적으로 공부하신 석학분이 설계를 하고 계시지 않을까 싶네요.

-> 우려해주신 대로 알고리즘 학습에 과도하게 집중하지 않고 나름대로 쓰레드, 캐싱, 쿼리 등 균형을 잡아보도록 하겠습니다. 어떤 알고리즘을 써야하는지 이번주에 조금 고민+써치를 해보았는데, 잠정적인 결론은 Greedy 탐색방식으로 밖에는 구현이 안될것 같다는 것입니다. 제가 정의한 최적화문제가 부분최적이 전체최적을 보증하는 것이 아니라서 완전 탐색을 해야만 가장 최적화된 루트를 찾아낼 수 있는 문제더라구요. 그러면 탐색 경우의수가 (V-1)!이라 20개의 Node만해도 계산불가한 경우의 수가 되어서 서비스가 불가능하다는 생각이 들었습니다. 부분 최적으로 결정하는 Greedy 탐색방식으로 실제로도 그렇게 많이하는 것같더라구요. 이상으로 알고리즘 관련 조사/고민은 마무리하고 구현의 관점에서 집중하고 캐슁과 스레드, 쿼리에 집중하도록 하겠습니다.

• GPT 프롬프트 엔지니어링을 이용한 기능은 어떻게 개발하실 계획이신가요? 어떤 api를 이용하실 계획이신지 궁금합니다.

-> 본 기능은 제가 지식도 계획도 아직 없는 상태입니다. [5. 확장고려기능 : 구현은 안하되 확장가능성 고려하여 설계] 항목이라 구현할 계획도 없고 1~4순위까지의 기능만 구현할 생각입니다. 문서에서 제거하지 않은 것은 해당 기능이 추가될 수도 있다는 가능성 고려하에 데이터 모델링에 참고하고 싶어서입니다. 나중에 취준시기에 좀 심심하면(?) 찾아보고 구현해볼 예정입니다. 혼선을 발생시킨다면 문서내용에서 삭제하겠습니다.

• grid의 크기는 어떻게 결정되나요? 또한 그냥 회원이 방문한 유적지의 위도경도를 내려주면 화면을 그려주는 측에서 grid를 그려도 될것 같은데 이 부분을 서버에서 구현하시기로 결정하신 배경이 있나요?

-> Grid크기는 동적으로 결정하지 않고 전역상수로 정의하고 Grid 분리기준도 일정하게 해서 동적으로 생성하되 일관성을 유지하려고 합니다. 좌우 2km정도면 적당하지 않을까 생각중입니다.

-> 화면을 그려주는 측이면 FE를 말씀하시는 것일까요? 해당 질문은 제가 미처 고민못했던 부분이라 기획시 특별한 배경은 없었습니다. 지금 질문을 듣고 생각나는 부분은 (FE 측을 의미한다고 하시면), 1. 데이터 처리니깐 데이터 처리 관련은 가능하면 백엔드에서 처리하고 넘겨주는게 맞지 않나하는 생각이 들고 2. x,y좌표라는 외부API의 데이터(DB에 저장할것이지만, 출처는 외부니깐)를 내부적 기준에 따라서 Grid로 변환하는 과정이니 서비스 Layer에 해당하는 부분이 아닌가 하는 생각이 우선 듭니다. 제가 놓치고 있는 부분이 있으면 말씀부탁드려요.

• 사용자 위치를 기반으로 Nkm 주변에 존재하는 문화유산을 조회한다. // (Input : 사용자위치, 거리 Nkm, Output : 문화재ID리스트) 이 기능에 대해서는 Nkm 주변에 존재하는 문화유산 조회 자체를 API로 대체하나요? 아니면 내부 DB에서 query를 통해서 구하게 되나요?

-> 내부 DB 쿼리로 구현예정입니다.

리뷰를 통해 배울점

- 결국에 Backend 개발자에게 요구되는 우선적인 역량은 Computer Resource Optimization이다는 점 (쿼리, 캐슁, 스레드 등)

멘토리뷰

기획의 수정은 이정도면 충분한 것으로 멘토의 확인을 받았으니 다음 단계로 넘어가면 된다.

Prototype 기능고민

기획의 다음단계를 readme 작성이다. 이전 기획안의 내용을 바탕으로 작성하면 내용은 금방 작성할텐데, 문제는 ERD 작성이다. 데이터 모델링은 효율적인 모델을 구현하기 위해서는 데이터의 CRUD에 대해서 정확하게 알고 있어야하는데, 기획서의 내용은 나에게 생소한 내용들이라 CRUD를 알기가 어렵다. 때문에 데이터 모델링에 들어가기전 간단한 기능구현을 고민해보아 프로그램의 뼈대를 정리해보고자한다.

Prototype 기능고려(1) : 외부API 다루기

외부 API조회기능 구현을 통해서 유적에 대한 어떤 정보를 어떻게 가져올 수 있을지, 어떤 정보를 DB에 저장하면 좋을지 알아보고자 한다. 외부API는 WebClient를 통해서 데이터를 받고, Parsing을 통해서 DB에 쌓아나가면 될 것이라 1회성이고 DB설계단계에서는 크게 고려할 것이 없다. 필요한 데이터에 대해서 골라서 담는 부분만 고려하자.

국가유산API파악하기

- 국가유산 현황 : 등급표로 활용

https://www.khs.go.kr/html/HtmlPage.dopg=/cultural_info/cultureTotal_ccrebasi_kor.jsp&mn=NS_03_07_03

- 국가유산API 문서 :

https://www.cha.go.kr/html/HtmlPage.do?pg=/publicinfo/pbinfo3_0202.jsp&mn=NS_04_04_03

- 국가유산분류체계에대한 설명, 문화유산고유코드는 ‘문화재연계번호'(ccbaCpno)을 사용하는게 좋을 것.

https://kwusaih.wordpress.com/2024/02/17/6217/

- (1) 페이지별 간단 조회 ; 1차적으로 본 데이터를 통해서 DB에 저장

https://www.khs.go.kr/cha/SearchKindOpenapiList.do?pageUnit=20&pageIndex=600&ccbaCncl=N

- (2) 유물별 상세조회 ; 유물별 상세내용이 필요할때 (1)의 데이터를 사용하여 추가조회 (유물별 필수파라미터가 있기때문)

https://www.khs.go.kr/cha/SearchKindOpenapiDt.do?ccbaKdcd=11&ccbaAsno=00030000&ccbaCtcd=11

Prototype 기능구현(2) : 좌표를 통한 조회

geolocation이라고 좌표를 별도로 저장하는 DB자료구조가 있다고 한다. 이를 사용해보고 DB를 어떻게 설계할지 좋을지 알아 보고자한다. DB에 Point라는 데이터구조가 존재하고 (x,y)처럼 좌표체계로 데이터타입이 존재한다. 별도로 설계를 특별히 할 것은 없고 spatial index를 설정해주면 공간적 탐색을 용이하게할 수 있으며 이는 DB에서 제공하는 기능이다. 때문에 좌표조회에 대한 고민은 안해도될듯.

Prototype 기능구현(3) : 좌표간 경로탐색

좌표간 경로탐색이 본 서비스의 핵심로직인데 이를 위해서 어떤 데이터가 필요한지, 효율성을 높이기 위해서는 어떤 캐슁전략이 필요한지 확인해본다. API호출의 빈도 그리고 API호출로 인한 Latency가 문제인데 이는 아래와 같이 고민해볼것.

성능최적화

기능고민을 하면서 어떤 부분이 성능측면에서 문제가 될 수 있는 여지가 있고 어떻게 처리해야할지를 고민해본다. 해당 내용은 BrainStroming이고 필요내용은 별도 페이지로 빼야할 것.

(1) Grid동적생성

최초의 구상에서는 Grid를 객체로 만들고, 고객이 방문한 Grid는 DB에 저장하여 MAP조회시에 호출하는 방식으로 구상하였음

-> 조회하는데 logN으로 비교적 짧기는 하나, Grid를 조회하는 행위와 방문문화재를 조회하는 행위가 반복되어 Latency를 두번 불러오는 꼴이라고 생각하였음. 때문에 방문문화재 조회를 통해서 Grid를 서버에서 동적으로 처리하는 것은 충분히 가능하다고 생각하여 Grid를 DB에 저장하지 않기로 결정함

(2) 경로탐색시 비동기화 및 멀티스레딩

경로탐색시에 복수의 API 호출이 필요할 것으로 보인다. 복수의 호출이기때문에 하나의 스레드로 호출하기보다는 여러가지의 스레드가 동시에 호출작업을 해주었으면 어떨까 하는 생각이 들고, 또, 스레드들이 호출을 대기하는 동안 비동기적으로 다른 작업들도 동시에 진행했으면 한다.

(3) 고객 방문문화재 캐싱

고객이 로그인을 하는 시점에 고객의 정보를 캐쉬로 미리 꺼내어와서 호출시에 바로 전달할 수 있도록 하면 좋다고 생각한다. 특히 지도의 조회같은 경우에는 손가락으로 위치를 옮기거나할때 위치가 refresh되는 것이라고 생각하기때문에 다회 조회가 필요할 것. 그러므로 1회에 한해서 방문문화재를 캐싱해두면 다양한 곳에서 사용가능하리라고 생각한다

(4) 지역별 문화재 캐싱

관광을 위해서 자주 모이는 지역이 있고 문화재가 밀집되어있는 경우가 있다. 주로 내 주변에 있는 문화재를 찾기때문에 사람들이 주변문화재를 자주 탐색할만한 곳을 캐싱해두어서 request를 주면 어떨까싶음. 특히, range를 설정해서 해당 range안에 들어가는 request면 미리 캐싱해둔 값을 전달하면 어떨까 싶음

Readme 완성본

https://github.com/shbyeon20/zerobase-heritage