NHN Forward - 발표

1,4 세션-JPA

 

신동민님이 발표하셨고 발표 내용은 간단했다 JPA 를 사용하면서 우리가 가장 쉽게 당황할수 있는 부분들에 대한 내용이였다. 

 

보통 1대다 경우 에서 발생 할수 있는 이야기를 기준으로 발표가 진행 되었다. 

 

1대 다일 경우 JPA 로 연관관계를 만들때 양방향으로 서로 관계를 맺어준 상태에서 쿼리를 실행하면 내가 의도하지 않은 update 문이 추가로 실행되는것을 확인할수 있다. 

 

이경우는 서로 관계를 명시할때 중복으로 일어나느 경우인데 그에 따른 해결 방법들과 github 을 통한 소스 공유를 해주는 자리였다. 

 

그리고 N+1 현상에 대한 이유와 대응책에 대해서 공유 해주는 시간을 가졌다. fetch join , entity grafh 사용시 많이 발생하는데 특히 paging 을 사용하는 상태에서 fetch join 을 사용할경우 아주 위험한 상황이 발생 할수 있다고 한다. 

 

숨겨진 JPA 기능이라고해서 get, read , find 에 대해서 설명하였다. 결론은 전부 select 와 같은 동작을 한다는것이다. 

그리고 slise 와 paging 에 대한 비교가 있었는데 데이터 가 많을경우는 slice 가 좀더 유리하다는것 그리고 DTO 를 활용하는 방법등 좋은 이야기들 이많았다. 

 

솔직히 당장 이해가 잘가진 않았다 ( JPA 를 잘 안사용한다... ) ORM 을 사용할때 자동으로 무엇인가 서포팅 해주는것이 내 의도와 다르게 적용 될수 있다는걸 항상 명심해야한다는 경각심을 가진것에 의의를 두었다. 

 

 

2 세션- MSA ( PAYCO ) 

과연 NHN 은 MSA 를 적용하기 위해 어떤생각을 했고 어떻게 진행했을까 ? 난 그것이 궁금 했다. 그리고 아주 간결하게 정리가 할수 있었다 

 

1) spring cloud gateway

2) zookeeper

3) kafka 

4) spring config 

5) ansible 

6) jenkins 

7) docker 

8) netfrix histrix

9) nexus3 

 

내가 평상시 MSA를 적용할때 이런것들은 써야 하겠다고 생각한것들의 대부분이 있었다. 여기서 흥미 로웠던건 ansible 로 배포를 하고 kubernatis 는 고려하다 포기했다는 점과 docker 이미지를 nexus 3 로 관리가 가능하단 점이였다. 단순 library 관리를 위해서 nexus 를 구축해서 사용한다고 생각했는데 3버전 이후로는 docker 이미지 도 관리가 가능하단 소리에 분명 적용해서 사용하면 좋을거 같단 생각이 들었다. 

 

 

3.세션- HTTP API 설계 후회 고민 

 

음... 개인적으로는 너무 Dooray 서비스에 대한 이슈에 편향 되있는 내용있고 , 발표자의 회고록 같은 진행이여서 생각했던바와는 많이 달라서 아쉬웠다. 일기장 같은 진행 이였는데 분명 도움이 되는 분들도 있었겠지만 좀더 범용적인 내용이였으면 했었다. API 네이밍, 파라미터의 구성 , API 구성시에 depth 에 대한 후회 그런 이야기들은 참고 할만 했다. 발표중에 소개해준  관련 서적 두권을 보는것도 괜찮을 거 같다. 

 

 

5 세션- Spring Kafka 

아주 명확했다 kafka 로 시스템 알림을 받는 서비스에 적용한 이야기였다. 하지만 아주 필요한 부분들과 내가 긴가 민가했던 것들에 확신을 심어준 세션이였다. 이것도 간단히 정리하면 spring kafka 를 쓰면 정말 아주 손쉽게 kafka 와 연동이 가능하고 쉽게 적용이 가능하다 였다. 항상 라이브러리를 받아서 단순하게 사용했는데 보면서 느낀건 좀더 사용하기 쉽게 인터페이스화가 잘되있다는것이다. spring cloud 가 분명 인턴페이스가 잘되있다는 강점은 있지만 반면 버전업이 다소 느리다는 문제가 있다. 그럼에도 불구하고 충분히 활용 가능성이 높아 보였다. 

 

6 세션- Kotlin 전환기 

 제일 아쉬운 세션이였다..... 내용은 한줄로 정리 할수 있다.

   " intellij 를 이용하여 코틀린으로 전환했습니다. "

뭔가 kotlin을 아트적으로 사용하여 최적화 하면서 겪었던 뭔가의 노하우가 있을거라 생각했는데 대부분 자동전환으로 커버가 되고 어노테이션들은 잘안된다 이정도 였다. 그리고 결과물에서 대해서 참... 실망 스러웠다.. 

java 코드 대비 5~10% 정도의 코드량이 줄었다고 한다. 성능은 별차이 나지 않았다고 한다. 

성능은 별차이 없는데 대충 5% 정도 코드량을 줄이기 위해 위험부담을안고 전환을 해야하는지 의문이 들었다. 코틀린을 쓰는 사람들이 주장하는것은 java 대비 코드량이 특별하게 많이 줄어 들어 코드 품질이나 운영에 유리함을 가진다가 한가지 이유라고 알고 있는데 저정도면 안하는게 낫지 않을까 ? 라는 생각이 들었다. 

 개인적인 생각으로는 자동전환에 의존해서 코드량이 저정도 밖에 안들지 않았나 싶다. 물론 코드 리팩토링을 수행했다고 하지만 그렇게 했는데도 저정도만 줄어든다면 정말 진지하게 코틀린을 써야하나 ? 란 의문이 들었다. 

 

 

다소 짧게 짧게 진행 되서 많은것들이 전달 되지 못한 느낌이 없지 않아 있다. 그리고 생각보다 인공지능에 대한 세션이 많이 열렸고 참여자들은 대부분 백엔드 / 인공지능 쪽에 많이 사람들의 인기가 몰린거 같아 보였다. 다음엔 좀더 시간을 할애 해서 더 많은 내용이 공유 되는 자리가 되었으면 좋겠다.