정대화 블로그

2021. 06. 21.

06.20

맵으로 카운팅 하는 문제를 풀다 맵을 정렬 하는 방법을 생각해봤다. 엔트리셋은 셋이니까 리스트로 바꿀 수 있다. 이 점을 이용하면 엔트리의 리스트를 뽑아내고 소팅할 수 있다.
쓰레드는 유저 쓰레드와 커널 쓰레드로 나뉜다. 보통 사용자는 유저 쓰레드를 사용하는데 커널 쓰레드와 연결시켜야 한다. 모델 중 many to many는 쓰레드 풀에서 꺼내 쓰는 느낌이라 한다. 헷갈렸던 부분은 결국 쓰레드는 프로세스에서 갈라지니까 자식 쓰레드는 모두 같은 커널 영역을 공유하는 것이 아닌가? 하는 것이었다. 메모리적인 측면에서 생각하면 맞는 얘기인데, 해당 모델은 논리적인 얘기다.
상속은 나쁜 것이라고 말하는 의견을 종종 봤다. 하지만 상속 자체가 나쁘다기 보다는 잘못 쓰이기 쉽기 때문에 나쁘다고 생각하는게 좋을 것 같다. lsp를 준수하면 클래스 상속을 한 뒤 오버라이딩 하면 안 된다. 잘 생각해보면 이를 강제할 경우 ocp가 만족된다. 이런 측면에서 보면 상속은 다형성과는 별개로 재사용을 위한 것 처럼 보인다. 즉 변하지 않는 부분에 잘 사용하면 효과적이지만, 조심해서 사용해야 하는 부분이 아닌가 싶다.

엘라스틱서치는 용량보다는 성능때문에 클러스터링을 한다. 각 노드가 하나의 서버(프로세스)라고 했을때(하나의 서버 안에 여러개의 노드가 있을 수도 있다고 한다), 해당 노드들의 컨테이너를 샤드라고 한다(노드 안에 샤드가 있다). 데이터의 저장 단위는 인덱스인데 이 인덱스를 쪼갠 것을 샤드라고 한다. 샤드는 각 노드에 분산저장된다.

조회는 모든 샤드에서 수행하고 from + size 크기의 결과를 가져와서 정렬하는데(전체 조회 돼야하지 않나?), 처음에는 점수와 id만 가지고 정렬한다. 이후 정렬 된 값 기반으로 검색 결과를 요청한다. 따라서 랭킹알고리즘이 중요한데, 보통은 TF/IDF, BM25 요즘은 Beats가 추가됐다고 한다.

역색인이기 때문에 조회 이외의 동작은 속도가 느리다. 따라서 json 문서들을 모아 둔 세그먼트라는 단위를 만들고 이는 불변으로 만들어서 update가 불가능하게 만들어 놓는다. 즉 insert와 delete만 가능하다. delete한 것도 바로 삭제하지 않고 마크를 해놓은 뒤 나중에 지운다.
멀티파트에 내가 생각하지 못했던 동작이 들어간다. 임시 값을 이용하여 바운더리라는 구분자를 넣어 데이터를 구분한다. 파일일 경우 데이터마다 컨텐츠의 정보가 달라야하기 때문이다.

히로에게 테스트에 대해 설명을 해줬다. 모키토에 메소드 실행 결과를 넣어주는 것이 이해가 되지 않았다고 한다.
OAuth로 사용자 정보를 가져와도 우리 DB에 정보 저장해야하는 부분이 필요하다. 루카스에는 깃헙 id를 그대로 가져다가 쓴다. 그런데 이러면 또 문제점이, 만약 우리만의 새로운 회원가입 정책이 필요하면 id순번이 꼬일 수 있다. 때문에 따로 저장을 해줘야하는데 이걸 처음부터 설계하지 않으면 골치가 아플 것 같다.
히로 소스 보면서 JWT토큰 흐름을 대충 파악했다. 말 그대로 json에 담아서 보내는 토큰. 대신 인코딩 디코딩이 필요하다. 브라우저의 로컬 스토리지에 저장해두고 만료일도 있는 부분이 쿠키와 비슷하지만, 암호화된 시그니쳐를 함께 보내기때문에 더 안전하다 볼 수 있다고 한다. 그럼에도 토큰에 저장된 데이터 자체는 쉽게 볼 수 있으므로 민감한 데이터는 넣지 않는 것이 좋겠다.

OAuth app을 여러개 만들지 않고 클라이언트로 리디렉션해주는 것은 어떨까? 굳이 두 개를 따로 만드는 이유가 있을까? 하나로 하는게 관리가 더 쉬울 것 같은데...
테스트가 장황해지니 시간이 좀 오래 걸린다. 특히 널체크가 계속 발목을 잡았다. 일단은 테스트 기반으로 작성했기때문에 오류를 쉽게 찾긴 했는데, 구조와 코드가 마음에 안 든다. 책임을 나누기가 좀 어려운데 로직을 잘게잘게 넣는게 좋을지 한 번에 처리할 수 있는 곳에 넣는게 좋을지에 관한 것이다. 그런데 잘 생각해보면 테스트가 제대로 짜져있지 않아서 그런것일 수도 있겠다.
히로와 solid를 잠깐 살펴봤다. 결론적으로는 인터페이스로 추상화해서 다형성을 구현하게 된다. 그런데 이런 부분은 결론적인 것이다. 이렇게 도출되는 이유가 조금씩 다르다. 그렇다면 어떤 곳에 초점을 맞춰야할까?

테스트를 짜다보니 막히는 부분이 나왔다. 업데이트를 하게 되면 레포지토리를 여러번 호출하게되어 mock 핸들러도 여러번 설정해야한다. 그리고 무엇보다도 큰 문제가 발생했다. 목 핸들러에 들어오는 파라미터를 확인하는 로직은 equals나 hashcode를 확인하는 방식으로 이루어질 것이다. 그런데, 그렇게 되면 내부의 필드 상태와 상관없이 객체의 id만을 이용하여 비교를 하도록 정의되어있기 때문에 정확한 테스트가 되지 않는다. 고민을 많이 해봤는데, 결론은 이런 문제가 발생했다면 테스트의 단위가 너무 큰 것이다. 도메인 단위의 테스트가 왜 필요한지 조금은 느끼게 된 것 같다.

객체 필드를 recursive하게 검사해주는 메소드가 있었다.. 왜 찾아볼 생각을 안 했을까. 하지만 그럼에도 문제가 하나 있었다. 현재는 id만 업데이트 하면 해당 객체가 업데이트 되었다고 판단하는 식으로 로직이 짜여져 있다. 이럴 경우 해당 객체를 재귀적으로 판단하는 것이 아닌, id로 판단해야된다. 재귀적으로 판단을 하게되면 해당 부분들에서 같은 객체가 아니라 판단하게 된다. id를 제외한 필드들이 다르기 때문이다. 때문에 결과적으로 검증을 위한 로직이 추가로 생기긴 했다. 그런데 이 부분도 프레임워크 단에서 처리할 수 있는 방법이 있을 것 같은데, 아직 그렇게 복잡하지는 않으니 이 선에서 끝내려 한다.
마지막 프로젝트가 끝나며 코쿼도 끝났다. 아쉽긴 하지만 예전처럼 뭘 해야될지 혼란스럽거나 하지 않아서 좋다. 조만간 후기도 써보자.

정대화

DaeHwa_Jeong@outlook.com

Powered with by Gatsby 2.0