최근 몇 달 동안 LogNet/grpc-spring-boot-starter로 API를 만드는 작업을 했다. 그런데 나는 처음이었고, 회사도 처음 도입한 경우였다.

gRPC 자체는 좋았다. 하지만 당연히도 gRPC는 통신에만 관심이 있고 gRPC 메시지의 변환이나 검증에 관심이 없었고, Springframework는 바인더를 따로 준비해두지 않았다. 그러니 HTML이나 JSON을 쓸 때와는 달리 POJO/DO 오브젝트와 gRPC 메시지 사이의 변환은 일일이 코딩을 해줘야 하고, 검증도 해줘야 한다.

어쩔 수 없이 매우 많은 양의 코딩을 해야만 한다.

거기다 gRPC의 Java 구현체는 성능 향상을 위해 java.nio의 IO를 사용하면서 다이렉트 버퍼를 통해 익숙한 힙 영역이 아닌 커널 영역의 메모리를 사용한다. JVM 프로세스는 한정된 메모리를 커널 영역과 힙 영역으로 나눠 써야 하다보니 커널 영역을 포기할 수 밖에 없어 한번에 큰 용량의 메시지를 보낼 수 없다. 그래서 메시지를 쪼개서 스트림 형식으로 주거나 받아야 한다. 아니면 공유 메모리/DB/파일시스템을 쓰거나 그러면 또 로직적으로는 스레드 동기화 문제가, 인프라적으로는 스케일 아웃시에 HTTP/2 Stream(gRPC service의 rpc에 해당) 단위로 라우팅을 해줘야 한다.

결국 통신 효율을 끌어올리려다 보니 로직이나 인프라가 JSON 통신에 비행 높은 기술력을 요구한다.

로직은 단순히 스레드를 블로킹하거나 리액티브를 사용해 개발자가 공부해가며 만들 수 있다. 하지만 인프라는 HTTP/2 Stream를 지원하는 L7 라우터/로드밸런서가 있어야 스케일 아웃을 할 수 있는데 이걸 하드웨어로 해결하려면 비용 문제가 생기니 불가능하다. 그러면 소프트웨어 라우터/로드밸런서를 써야 하는데 자료가 부족한 이런 걸 다루려면 어느 정도의 기술 숙련도와 급여가 필요할 것인가?

가장 큰 위험은 책임자가 이런 위험을 하나도 고려하지 않았다.말해도 못 알아듣는다