airbnb 프로젝트 회고

airbnb 프로젝트 회고

에어비엔비 프로젝트를 마스터가 선정한 이유는 무엇일까

에어비앤비는 GPS로 인식되거나 사용자가 작성한 검색어 기반으로 검색 위치에서 가까운 숙소를 찾아준다.
공간 데이터를 다루게 되는데 일반적인 도메인과 다른 것은 카테고리 안에 속한 데이터를 보여주는 것이 아닌 위치 기반으로 반경을 설정하여 데이터를 추출한다.

반경 내에 있는 데이터는 어떻게 추출할 수 있을까?
이것이 이번 프로젝트의 업무 도메인이다.

예전에는 공간 데이터 추출을 위해 CLOB등의 데이터형태로 저장된 지도 데이터를 사용하였다고 한다.
이번 프로젝트를 통해서 데이터베이스에 공간정보를 저장하는 데이터 타입이 있다는 것을 알게 되었다.

새로운 도메인을 접하면서 내가 공부했던 과정과 겪은 어려움을 적어보려고 한다.

---

데이터베이스에서 제공하는 공간 데이터 관련 지식 알아가기

1. 먼저 아래 유튜브를 통해서 대략적인 것을 파악했다. 설명도 자세하면서 재생시간도 적당했다.
   한빛미디어 출판사에서 나온 우재남저 "이것이 MySQL이다(8.0)" 라는 책 내용의 유튜브 강의이다.

14장에서 다루는 "GIS 개념과 MySQL의 공간데이터"

2. 그리고 나서 블로그를 찾아보았다.
   공간데이터는 처음이니깐 자세하면서도 너무 길지 않은 내용이 필요했다.

대략적인 내용을 파악하면서도 튜토리얼로 간단하게 해볼 블로그를 찾았는데 링크에 걸려있는 해당 블로그가 딱 좋았다.

생소한 정보를 익힐 때 모니터로 보는 것이 집중이 되지 않아 인쇄해서 보면서
DB에 테스트 테이블을 생성해서 익혀갔다.
어렵지 않게 진행되면서 새로운 것을 배우니 재미 있었다.

3. 이렇게 대략적인 것을 파악하고 에어비앤비 프로젝트에 적용해보았다.
   팀과 공동으로 사용하는 프로젝트에 연습용 git 브랜치를 생성해서 숙소 엔티티에 point 타입을 적용해보았다.

alter table add column으로 point 타입의 컬럼을 추가하고,
기존에 숫자타입으로 저장한 위도, 경도 데이터를 활용해 concat으로 update문을 sql로 추출해 해당 sql을 실행했다.

mysql 제공함수를 사용하는 것이다보니 먼저 native sql을 JPA에서 사용하는 방법을 찾고, 파라미터를 생성하지 않고 DB에서 실행되는 구문 전부를 JPA Repository에 넣어 실행해보았다.
데이터가 잘 나온다.
당연히 잘 나오겠지만 개발할 때 이럴 때 제일 뿌듯하다. 처음하는 것이 돌아갔을 때! ㅎㅎ

개발하면서 가장 힘든 부분

준비를 마치고 조건이 되는 위/경도 값을 파라미터로 받아서 반경 내 숙소를 찾아주어야 하는데 파라미터가 잘 적용되지 않았다.

이럴 때 힘들더라.
개념도 대략적으로 파악이 됐고, 일반적 사용법도 알겠는데
프로젝트에 적용할 때 이런 파라미터를 어떤 형식으로 줘야 하는지 알아가는 것.

기존에 :id 이런 것처럼 파라미터를 넣어주는 것인데 그게 잘 안됐다.
너무 작고 별 것 아닌 부분처럼 느껴질 수 있지만 이 부분이 해결되지 않으면 진행이 되지 않는다.

지금부터 시작이다.
구글링과 프로젝트에 적용 무한 반복.

삽질도 의미있게 하라고 했는데 이런 부분은 어떻게 삽질을 의미있게 해야 하는지 어려웠다.
근본을 알아야 한다는 말도 있던데 그 당시 이 부분은 무엇이 근본인지 파악되지 않았으며 가장 중요한 것은 프로젝트는 기한이 있다.

시간을 더 투자하면 될 것 같았지만 그룹으로 하는 프로젝트이니 산제된 다른 과제를 맡아본다.

OAuth 와 JWT를 이용한 인증

프로젝트 중 처음 인증을 구현하게 되었다.
OAuth는 강의에서 흐름은 파악했지만 개발하려면 그 흐름을 기억하고 코드로 작성해야 한다.

그 흐름을 외우고 있는 것은 아니니깐 다시 흐름을 찾아보고 코드로 작성하려는 시도를 해야 한다.

https://velog.io/@max9106/OAuth4

클래스 메이트의 자료제공으로 알게 된 블로그이다.
OAuth 인증의 흐름도를 알고 이 블로그를 보면 코드로 무엇이 진행되는지 파악할 수 있도록 자세히 적어놓은 블로그이다.

이 블로그를 이용해서 OAuth를 파악하면서 코드를 작성했고 JWT 토큰까지 생성했다.

이제는 다시 앞단의 헤더를 통해 들어온 토큰을 검증하는 과정이 남아있다.
이 부분은 과정 하나하나를 검색해가면서 파악했다.

일련의 프로세스 중 제일 처음은 어디서 토큰을 받아 검증하느냐였다.
여러 검색어로 찾아보니 필터로 해당 방법들을 시도해나간 글들이 보였다.

이 부분은 어떤 하나의 자료를 튜토리얼 형식으로 따라하지 않고 다른 사람들이 작성하여 블로그에 올린 코드의 흐름을 파악해서 알아갔다.
먼저 주로 필터로 검증하는 자료들이 나왔으며 Spring Security가 하는 형식을 찍먹정도로 따라하는 느낌이었다.

그런 과정으로 필터를 이용해 헤더를 확인하고 검증하는 것을 선택하게 되었다.

필터는 키워드만 들어봤지 잘 모르는 영역이였다. 이 부분에 대해서 단기 프로젝트가 아니였다면 난 필터를 깊게 공부하거나 스프링 시큐리티를 확인해봤을 것이다.
그런데 함께 하는 프로젝트로 백엔드로서 기능을 개발해서 제공하고 싶은 목표가 있었다.
앞단과 작업할 수 있는 기회를 활용하고 싶었다.

그래서 조금 빠르게 구현해보았다.
헤더에 들어온 문자열을 파싱하는 부분을 확인하여 가져왔다.
그런 후에 JWT 토큰을 파싱하는 부분을 보는데 jjwt라는 라이브러리로 JWT를 생성한 상태였다.
JWT 생성까지는 블로그를 통해서 어렵지 않게 했는데, 토큰 파싱하여 검증하는 부분은 블로그 내용들이 시원치 않았다.
명확한 것이 없었고, 그냥 코드만 나열되어 있었다. 코드만 봐서는 그 부분이 뭘 어떻게 검증하는 것이고 익셉션 처리는 어떻게 해야 하는지 나와있지 않았다.

결국 공식문서 라이브러리 사용방법을 찾아볼 수 밖에 없게 되었다.
jjwt library 또는 jjwt api 검색어를 통해 발견한 공식문서URL 링크를 발견했다.

다행히 사용법이 꽤 친절하게 적혀 있었으며 가려운 부분들이 모두 나열되어 있었다.
이걸 다시 프로젝트에 적용하려니 기존에 JWT 토큰 내용도 마음에 안들어서 다시 작성하고,
파싱 로직도 새로 짜게 되었다.

그러면서 필터 내에서는 catch 구문 실행이후에도 코드가 계속 진행된다는 것을 알았고, 핸들러가 작동하지 않아 Resolver를 통해서 익셥션을 처리해야 한다는 것을 알게 되었다.
그래서 대의적인 부분을 먼저 처리하고, resolver등을 통해 코드를 간결하고 깔끔하게 작성하는 부분들은 메모만 해두고 넘어갔다.

실질적으로 구현을 하게 되면서 알게 되는 이론들과 라이브러리를 잘 사용했다는 성취감이 들었다.
스프링에 대해서 자세히 알아야 되는 부분을 발견하고 그것을 탐구하고 싶어진 마음이 들었다는 것이 큰 소득이었다.

남은 과제들

이후에 해결해보고 싶다는 마음을 잊지 않기를 기억하고 마무리한다.

---

이후, 더해서

해당 글을 공유하고 감사한 키워드를 피드백 받았다.

• PreparedStatement 를 왜 사용하는지 알아보기 (':id' 와 같은 방식)
• SQL Injection 키워드