[회고록] Spring 프로젝트 : 시티 캣 타로 / 2주차

github.com/CodeSoom/city-cat-tarot-developerOlive

CodeSoom/city-cat-tarot-developerOlive

 

 

 

프로젝트 2주차 기간 내 완료한 내용은 다음과 같다.

 

 

1. 한 것

[ '오늘의 운세 타로' 채팅창 구현 + 선택한 카드 결과 보기 ]

 

 

 

---

2. 느낀 것

 

이번주에 구현한 기능의 핵심은 '오늘의 운세 타로 채팅창 구현 + 사용자가 선택한 카드 결과물 보여주기'였다.

 

먼저 로컬에서 스프링 코드 작성 + mariadDB 연결까지 테스트해본 후

테스트가 통과되면 AWS EC2 서버에 올렸다.

프론트엔드와 REST API로 타로카드 관련 JSON 데이터를 주고받으면서 화면을 구현해 나갔다.

 

타로카드 결과 내용은 내가 가지고 있는 타로카드 자료를 조합하여 만들었다. (타로카드 강의를 들은 보람이 있구만.)

22개 카드 결과 내용을 정리하는데 약간 시간이 소요되긴 했지만 은근히 재미가 있었다. 

 

 

 

그리고 이번 주에는 디자이너를 담당해 준 친구와 디자인에 대한 의견을 주고받으며 수정을 요청하는 시간도 꽤 필요했다. 

먼저 디자이너에게 내가 전반적으로 생각한 디자인의 느낌을 전달하고,

어떤 화면과 그림이 필요한지 정리하여 보냈다.

 

 

 

그럼 이렇게 디자인을 해서 보내주는데,

단독으로 보면 예뻐도 합치면 too much한 부분이 있었다.

디자인만 보면 A가 이쁜데, 막상 적용해보면 B가 훨씬 나은 경우도 있었다.

그래서 꼭 살리고 싶은 부분만 디자인을 적용하고 나머지는 심플하게 하는 등 톤 앤 매너를 맞추려고 해 봤다.

 

여기서 "서버 담당인데 왜 앞단까지 이렇게 관여를 많이 함?"이라는 생각이 들 수도 있겠다.

처음에 프로젝트 기획을 내가 했는데

프론트까지 내가 원하는 대로 구현하기에는 4주라는 기간이 너무 짧을 것 같아서 아는 친구에게 프론트엔드 협업을 요청했고

디자인도 내가 하는 것보다는 디자인을 할 줄 아는 친구가 담당하는 게 좋을 것 같아 도움을 요청했다.

 

전반적인 프로젝트 기획을 내가 했다 보니 서버임에도 디자인이나 프론트엔드를 이렇게 구성했으면 좋겠다..등 관여를 하게 됐다.

그래서 프론트엔드 담당하는 친구와 프론트를 어떻게 구성하거나 수정하면 좋을지에 대한 대화도 많이 나누면서 진행했다.

 

 

이번에 JPQL을 처음 사용해보는데, 익숙하지 않아서 이에 대한 공부도 같이 병행하면서 프로젝트 진행을 하고 있다.

 

채팅창 구현을 얼추 마치고 회원가입, 수정 기능을 시작하긴 했는데 

다음 주에 JWT 토큰 + Spring Security + 패스워드 암호화까지 이용한 로그인 기능을 만들어야 할 것을 생각하니....😱😭 아득해진다.

 

 

 

---

3. 배운 것

📚 JPQL

• JPA를 사용하면 검색을 할 때도 테이블이 아닌 엔티티 객체를 대상으로 검색을 해야 한다.
• 하지만 모든 DB 데이터를 객체로 변환해서 검색하는 것은 불가능하다.
• 애플리케이션이 필요한 데이터만 DB에서 불러오려면 결국 검색 조건이 포함된 SQL이 필요하다.
• JPA는 SQL을 추상화한 JPQL이라는 객체 지향 쿼리 언어를 제공한다.
• SQL과 문법이 유사하고, SELECT, FROM, WHERE, JOIN 등을 지원한다.
• JPQL은 엔티티 객체를 대상으로 쿼리를 질의하고 SQL은 데이터베이스 테이블을 대상으로 쿼리를 질의한다.
• 테이블이 아닌 객체를 대상으로 검색하는 객체지향 쿼리이다.

 

 

📚 어떻게 db 암호를 숨길 것인가?

 

 

그렇다면 이미 커밋한 application.yml 파일을 더 이상 추적되지 않게 하고

.gitIgnore 처리해야겠다.

 

 

---

📚 내가 진짜 REST API를 제대로 아는게 맞나?

 

REST API에 관한 질문을 트레이너님께 드리는 상황이 있었다.

다음 대화 내용을 통해서 난 REST API에 대해 정확히 정리가 되지 않았음을 깨달았다.

자세한 예시를 들어서 설명해 주신 내용을 계속 복습해야 할 것 같아서 회고록에도 옮겨 둔다.

---

종립 트레이너님 : REST의 뜻은 무엇인가요? 약어인가요? 아니면 단어인가요?

 

나 : Representational State Transfer - 자원을 이름으로 구분하여, 그 정보를 주고받는 것이라고 하면 어떨까요!

 

종립 트레이너님 : 어느 정도는 맞지만 그렇지 않은 면도 있어요. Representational State 가 무엇인지를 알아야 합니다.

representation의 뜻이 무엇인가요? 표현입니다.

 

나 : 그럼 “자원을 표현으로 구분하여 상태를 주고 받는 것”이라고 정리하면 어떨까요?

 

종립 트레이너님 :

"표현적 상태 전송 방법"이라고 하는 쪽이 더 좋을 거예요

자 이제 생각해 봅시다. 자원의 표현이란 무엇인지를 생각해볼 좋은 기회에요.

예를 들어 소연님이 저에게 전화를 겁니다. 그리고 저에게 소설책을 보내달라고 했다고 합시다.

그렇다면 저는 소연님에게 소설책을 보내줘야 할 거에요.

일반적으로는 제가 소연님께 소설책을 택배로 보내는 방법이 있을 거에요. 그게 상식이죠.

그런데 택배로 보내는 것이 불가능하다고 생각해 보기로 해요.

그렇다면 저는 소설책을 소연님께 어떻게 보낼 수 있을까요?

예를 들어서 제가 전화기를 들고 있는 상태 그대로 책을 처음부터 끝까지 읽어주는 방법이 있겠죠.

이 방법은 소설책을 표현하는 방법 중 하나입니다.

소연님이 전부 받아적는다면 표현을 accept 하는 거죠. 다른 방법도 있어요. 제가 소연님께 ebook을 보내주거나 텍스트 파일로 변환해서 이메일로 보내는 방법도 있을 거에요.

그런데 생각해보면 모두 포맷이 다릅니다.

소설책이라는 하나의 동일한 자원을 두고

목소리로 읽어주기(음성)라는 표현

ebook 이라는 표현

문자열 텍스트라는 표현

이렇게 3가지의 표현이 나온 거에요.

이렇게 여러 가지의 표현을 시도한 이유는 아주 단순해요. 실물을 전달할 수 없기 때문이에요.

그래서 "실물 전송 방법"이 아니라 "표현적 상태 전송 방법" 이라 합니다.

 

만약 우리가 인터넷을 사용해 병아리를 요청했을 때에는

병아리 이미지라던가 병아리에 대한 사전적인 내용이라던가 그런게 돌아오는 거죠

진짜 살아있는 병아리가 컴퓨터에서 나타나지는 않습니다. 그것은 불가능하고요

우리가 인터넷을 통해 전송받는 모든 데이터는 실제 자원의 표현이라는 것이

로이 필딩의 박사 논문 "Architectural Styles and the Design of Network-based Software Architectures"의 전제 중 하나입니다.

이 논문이 우리가 웹 개발을 할 때 사용하고 있는 REST 가 처음으로 나온 논문입니다.

자 그런데 자원의 표현을 요청할 수 있다면

자원에 대해서 뭔가 요청을 하려면 자원을 식별하는 방법이 필요합니다.

우리가 위에서 쓴 "병아리" "소설책" 같은 것은 자원을 식별하는 단어였죠.

"병아리를 보내주세요" -> 병아리 이미지가 돌아옴

병 아 리 라는 3개의 글자를 보고 병아리 이미지를 보내줘야겠군... 하고 판단한 거에요.

그러면 자원을 어떻게 식별할지의 문제가 되는데요

여기에서 우리가 늘 사용하고 있는 파일 시스템을 예로 들어 생각하면 쉽게 이해할 수 있습니다.

/usr/olive/my-files/document/my-recipe.pdf

이 식별자 문자열을 보고 무슨 뜻인지 이해하실 수 있을까요? 저게 어떤 자원을 뜻하는 식별자인지 저에게 설명해 주세요.

 

나 : user 폴더 아래 있는 olive 폴더 아래 있는 my-files 폴더 아래 있는 document 폴더 아래 있는 my-recipe.pdf 파일이요!

 

종립 트레이너님 : 네 맞습니다. 그리고 소연님이 저 "자원"을 실제로 갖고 계신가요?

 

나 : 주소만 갖고 있는듯한데요..!

 

종립 트레이너님 :네 지금 소연님이 주신 답변이 바로 404 입니다. 그 자원을 표현할 수가 없습니다. (왜냐하면 그 자원이 없기 때문에)

로이 필딩은 자원의 식별자로 집합을 사용하는 것을 생각했어요.

/동물/척추동물/포유류/강아지/웰시코기 같은 거죠

 

위에서 제가 이야기한 식별자를 놓고 생각해 봅시다.

/usr/olive/my-files/document/my-recipe.pdf

usr 쪽으로 갈 수록 커다란 집합이고요,

my-recipe 쪽으로 갈수록 집합이 좁아지죠.

이렇게 집합을 기준으로 한 식별자를 사용해 인터넷 너머에 있는 "실물을 주고 받을 수 없는 자원"의 "표현형"을 주고받는 약속이 바로 REST 입니다.

그래서 REST 에서는 자원을 요청하는 것 뿐만 아니라 수정 요청하거나 추가하는 요청이라던가 그런 것도 필요해서

http method를 요청하는 방법으로 쓰자고 이야기를 해요

그게 GET, POST, 그런 것들이죠

그래서 HTTP 요청은 다음과 같이 됩니다. GET /usr/olive/my-files/document/my-recipe.pdf

 

자 이제 uri 로 돌아갑시다.

Uniform Resource Identifier

통합 자원 식별자 입니다.

이제 "자원"이라는 단어가 새롭게 보이실 거에요.

이건 자원에 대한 아이디가 되는 거죠.

즉 우리가 쓰고 있는 uri는 바로 아이디입니다. 식별자고요.

REST 컨셉에 맞는 uri 디자인을 할 때에는 그 대상을 고유하게 지정할 수 있는 식별자인지 아닌지, 상위 집합은 있는지 등을 고려할 수 있어야 해요.

회원 이메일이 uri에 포함되어야 하는지의 문제는 여러가지로 고민해봐야 해요.

일반적으로는 이메일을 uri에 포함시키지 않습니다. 회원이 이메일 변경을 할 수 있기 때문이에요.

그리고 다른 하나로는 이메일 주소가 해당 회원의 표현형을 대표할 수 있는 식별자인지라는 인식론적인 문제가 있어요.

이메일 주소가 나인가? 나는 이메일 주소인가?

그건 잘 모르겠어요.

이건 REST 컨셉을 바탕으로 열심히 생각해볼만한 어려운 철학적 주제인 것 같습니다.

적절한 힌트가 됐는지 모르겠네요. 열심히 생각해보시고, 프로젝트 잘 수행하시길 바랍니다

 

 

https://johngrib.github.io/wiki/REST-paper-summary/

(요약) Architectural Styles and the Design of Network-based Software Architectures by Roy Thomas Fielding, 2000

---

 

😫 새로운 브랜치를 만들다가 만난 에러

 

 

 

---

4. 자기 선언

무너지지 않기로 합니다.

에러 메세지를 차근차근 잘 보기로 합니다.