TIL-20210516~22

2021. 05. 17. (updated: 2021. 05. 23.)

05.16

  • 이번 주 OS는 IPC 방법들에 관한 것이었는데, 메세지 패싱과 관련된 것들이었다. 주요 내용은 파이프와 소켓이었는데, 예전에 패캠 완주반을 하면서 개념적으로는 둘 다 이해가 된 것이라 읽는데 큰 어려움은 없었다.
  • 소켓에 대한 얘기가 나왔었는데, 소켓이 low 레벨이라 하는 이유를 4계층을 직접 구현한 느낌이라 그렇게 표현한게 아닐까 하는 얘기를 했다. 웹소켓 같은 경우는 HTTP위에 구현이 되어 있으니. 그런데 설명하면서 이론, 개념적인 부분과 구현에 대한 설명 혼동이 되어 제대로 표현이 되지 않은게 아닌가 싶다. 그 동안 이런 상황이 많았던 것 같다. 특히 OS에서 이로 인해 혼동했던 부분도 많았던 것 같다. 네임드 파이프와 소켓에 대한 질문을 하면서 느꼈는데, 네임드 파이프를 여러개 엮은게 소켓이 아닌가? 하는 질문에 개념적인 것인지 구현적인 것인지를 알아야 생각해보기 쉬울 것 같다는 답을 들었다. 그 동안 여러 부분에 걸쳐 학습을 하면서 힘들었던 부분이 딱 이거였던 것 같다. 잘 구분해서 생각해보자.
  • TIL을 주 단위로 작성해보기로 했다. 할 일 목록 관리도 할 겸 해서. 그리고 요즘 반복 작업이 많다보니 TIL의 내용이 많이 단조로워지는 것 같기도 하다. 대신 간단하게 적고 글이 좀 길어지면 별개의 글로 빼서 작성한 뒤 링크를 달아놓는 식으로 해보자.

05.17

  • 오전 강의는 JDBC 템플릿에 관한 것이었다. 크게 어려운 것은 없었던 것 같다. 많이 익숙한 모습이니. 로우 매퍼 사용하는 패턴에 대해 좀 알아보고 어떤게 더 적합할지 생각을 해봐야겠다. 단, 일단 빨리 도입하고 고치는걸로.
  • 파이로가 DAO와 레포지토리의 차이점에 대한 떡밥을 던져줬다. 사실 현재 사용하는 프레임워크들에서 내부 구현에 조금씩 차이가 생기지만 구현 자체가 크게 달라지지는 않는다. 특히 마이바티스도 CRUDRepository는 사용 할 수 없겠지만, 겉으로는 JPA나 Spring Data JDBC와 크게 다르지 않아보이도록 구현할 수 있다. 내가 느끼기에 큰 차이점은 프레임워크 차원에서 객체지향이나 DDD를 강제하느냐 아니냐의 차이가 가장 큰 것 같다. 마이바티스같은 단순 쿼리 매퍼는 구현이 자유롭지만, 반대로 이로 인해 테이블 주도 개발이 되기 쉽다.

    이러한 차이로 미뤄 봤을 때, 두 가지 용어의 차이점은 DDD의 aggregate root에서 도출해낸 단위인지, 아니면 단순히 테이블을 기준으로 도출해낸 단위인지에 따라 달라지는 것 같다. entity가 rich해야 한다는 말도 있는데, 이는 구현하기 나름이니까. 이것도 아마 어제 생각해봤던 개념과 구현의 차이에서 오는 혼동이 아닌가 싶다. entity가 rich해야 하는건 구현의 결과인거고 기본적으로는 DDD에서 사용하는 용어이냐 아니냐와 그 용어를 어떻게 가져와서 사용하는지가 결정적 차이가 아닐까

  • classForName에 대한 떡밥도 던져줬다. 해당 메소드를 실행하면 클래스의 스태틱 구문이 호출된다고 한다. 그런데 잘 생각해보면 스태틱 구문은 이미 실행이 되었어야 하는게 아닌가? 테스트를 한 번 해봐야겠다.
  • 새 프로젝트에 들어가며 이번에는 요구사항 정리가 좀 잘 된것 같다. 이대로 하면 될런지... 지도 API가 들어왔는데 잘 써봐야겠다.
  • 엘라스틱 서치를 적용해볼 수 있는 기능이 있다. 일단은 패스해놓고 다른 기능을 먼저 잡기로 했다. 잘 할 수 있을지...

05.18

  • 프로젝트 기본 세팅을 끝냈다. 헤로쿠 Procfile은 추후에 프로필을 나눌 때 쓸 수 있을 것 같다. 근본적으로는 스웨거 디펜던시를 특정 환경에서만 적용하고 싶기 때문에 그레이들 설정에 뭔가가 더해져야 할 것이긴 한데, 비활성화 설정을 하는걸로도 충분하지 싶다. https://springdoc.org/#properties 를 참고하자.
  • api는 기본적인 사항만 넣고 내가 생각하는 구조로 짜놨다. 일단 클라이언트가 각자 할 일들이 있어 api 피드백을 제대로 주지 못 하는 상황인듯 하다. 목업을 빨리 완성시키고 다른 작업을 해야겠다.
  • 깃헙 커밋 템플릿을 만들 방법을 생각해봤다. config파일을 올려야 하는데, 로컬에서 생성되므로 불가능하다고 볼 수 있다. 별도의 도구를 쓰지 않고 가장 현실적인 해결책은 템플릿 파일을 올려놓고 각자 설정하도록 하는 것이 있을 것 같다. 파일은 올려놨는데 목요일에 팀원들에게 말해줘야겠다.

05.19

  • 공룡책을 읽다가 모르는 개념이 나왔다. 발표 준비 할 때 참고하자.

    • serialization은 객체를 스트림 등의 연속된 형식으로 변환시키는것이다. 통신에 사용하거나, 객체의 스냅샷을 찍을 수 있다. 왜 굳이 바꾸는 것이지? 라는 생각을 했었는데... 잘 생각해보니 당연한 것이었다. 운영체제가 달라지면 바이너리 파일이라도 구조가 달라지니, 객체의 구조 자체를 변환하여 저장해야 제대로 전송이 가능할 것이다.

    Marsharlling은 여기에 통신의 개념이 추가 된 것이다. 두 가지를 혼용하여 쓰는 경우도 있지만, 통신이 이루어지거나 통신을 위해 객체를 바이트 스트림으로 변경하는 뉘앙스가 더 강한 것 같다.

    • 데이터그램은 UDP 바이트스트림은 TCP. TCP는 Reliable Byte Stream이다.
    • RPC와 애플리케이션 서버의 차이점은, RPC의 경우 전송만 되면 된다. 인터넷 프로토콜을 따르지 않아도 된다. 진짜 원격에서 메소드 호출만 이루어지면 된다. 그리고 언어의 제약이 생기는데, 분산처리 시스템에서 주로 사용될 것이다.
  • 컨트롤러 테스트를 추가했다. 인수테스트라고 할 수 있을지 모르겠으나, 어쨌든..

    인코딩에서 애를 먹었는데, 예전에도 비슷한 문제가 있었던 것 같다. MockMvc를 생성할 때 필터를 걸어주면 되는데, WebMvcTest를 사용할 경우는 이게 쉽지 않으니 강제로 response를 인코딩하도록 서블릿 옵션을 추가해줬다. 그런데 지금 생각해보니 어플리케이션 컨텍스트를 가져와도 상관없지 않나? 라는 생각이 들었다. 스프링을 이용하여 테스트 하려면 해당 컨트롤러만 들어있는 컨텍스트가 존재는 할테니까.

    이외에 결과를 어떻게 판단할지 고민이 많은데, 리스폰스 바디를 잭슨으로 객체화시켜 비교하도록 했다. 좋은 방법인지 모르겠지만 더 좋은 방법이 생각나지 않는다.

05.20

  • 오전과 저녁은 집중이 잘 되지 않아 쉬었다.
  • 오후에는 야구 미션을 다시 설계해보는 수업을 했다. 역시 복잡한 부분이 많았는데, 나만의 목표를 정해놓고 했던게 잘 한것 같으면서도 좀 더 요구사항을 정리하고 할 수 있지 않았나 하는 생각이 들었다. 기능 구현을 다 하긴 했지만 아쉬움이 많이 남는 프로젝트 같다. 정말 멋지게 만들 수도 있는 건데

05.21

  • 어제 너무 일찍자서 새벽에 일어난 뒤 상세, 가격정보 api 틀을 잡았다. 오전에 이걸로 회의를 좀 했는데, 얘기하기를 잘 한것 같다. 혼자 끙끙 앓아봐야 해결되지 않았을 것 같다. 에어비앤비도 참고해봤는데, 거기는 아예 막대그래프를 쓰고 있었다.
  • 파라미터 들어가도 조회가능하도록 수정하고 validator도 달아놨다. 검증 어떻게 할건지 정하는것도 좀 힘들었는데, 그냥 가장 쉬운 방법으로 가기로 했다. 구현 중에는 크게 어려운 것은 없었는데, 어디까지가 컨트롤러의 검증 영역이고 어디까지가 비즈니스 검증 영역인지 정하기가 어려웠다. 일단은 클래스 내부에서 서로 참조하여 판단해야 하는 정보는 비즈니스 로직이라 생각하기로 했다. 좀 더 헷갈리는 부분은 컨트롤러에 단위테스트가 필요한가? 였다. 단위테스트로 해볼 수 있는게, 상태 코드나 컨텐츠 타입 등 정도이고 객체가 올바른지 확인을 해볼 수 있으나 컨트롤러를 가볍게 간다면 어차피 서비스에서 받아온걸 특별한 가공 없이 바로 리턴하는 형식이 될텐데 이럴거면 차라리 통합테스트를 돌리는게 낫지 않나라는 생각이 들었다.

05.22

  • TIL을 주 단위로 쓰는건 좋은 것 같다. 문제는 TODO를 마지막날까지로 길게 잡아놓으니까 시간 개념이 없어진다는 것 정도? 주 시작할때 미리미리 해놨어야 했던 것들인데 그게 잘 안 됐던 것 같다. 다음 주에는 저런것들은 따로 써놓고 매일 하나씩 처리하거나 하는식으로 해봐야겠다.

TODO

~ 05.18

  • 목업 api(전체조회, 상세조회, 가격조회)
  • 지도 검색 시 내 위치(현재 위치는 숙소 검색에 적합하지 않을 수 있다?)

    하지만 그렇게 하지 않으면 위치 검색을 해야하기 때문에 나중에 생각

~ 05.20

  • 컨트롤러 테스트 코드 작성
  • 상세, 가격정보 api 완성
  • 파라미터 들어가도 조회가능하도록 수정 및 validation

~ 05.21

Optional

  • 엘라스틱서치
  • 서브넷 구분
  • s3 이용
  • 깃헙액션으로 aws 배포
  • classForName 테스트
정대화
DaeHwa_Jeong@outlook.com

Powered with by Gatsby 2.0