아는 개발자

sudo apt-get install nodejs

우분투의 패키지매니저 apt 를 이용해서 Nodejs를 설치 할 수 있기는 하다. 그러나 최신 버전이 아니라 우분투 팀에서 마지막으로 테스르를 완료한 버전(현재 글 작성 시점에서는 8.x.x)을 설치돼서 자바스크립트에서 Optional Chaning으로 짠 코드가 컴파일 되지 않는 문제가 있었다. 그래서 apt 말고 다른 방법으로 설치해야한다.

여러가지 방법이 있겠지만 가장 좋은 방법은 nvm(node version manager)를 쓰는 것 같다. nvm을 사용하면 다양한 노드 버전에서 설치가 가능한데 최신 버전도 물론 설치가 가능하다. 

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.35.3/install.sh | bash // nvm 설치
nvm install 14.4.0

참고로 nvm을 이용하면 현재 설치된 node의 버전을 바꿔치기도 할 수 있다. 배포후 테스트 할 때 사용하기 좋을 프로그램이 될 것 같다

nvm use <version-number>

안드로이드 개발중 open source 라이브러리를 임포트 할 때 아래 코드처럼 가이드에 jitpack 주소를 추가하라는 문구를 보는 경우가 종종 있다.

allprojects {
        repositories {
            jcenter()
            maven { url "https://jitpack.io" }
        }
}

여기서 추가한 jitpack 주소는 추가하려는 오픈소스 라이브러리를 저장하고 있는 저장소다. jitpack은 안드로이드, JVM 형태의 오픈소스 라이브러리 배포 플랫폼이다. 추가하려는 오픈소스 라이브러리 뿐만 아니라 깃허브 프로젝트에 올라온 오픈소스 프로젝트들을 저장하고 있으며 프로젝트에서 사용할 수 있게 jar, aar 형태로 빌드한 상태로 받을 수 있다. 깃헙으로 오픈소스를 배포하고 싶은 개발자 입장에선 쉬운 배포 툴이고 깃허브뿐만 아니라 BitBucket, GitLab, Gitee, Azure 같은 저장소에서 올린 오픈소스 프로젝트도 연동이 가능하니 개발한 라이브러리르 전세계 유저한테 배포하고 싶을땐 jitpack이 가장 좋은 옵션이 될 것 같다.

안드로이드 개발중 Gson과 Retrofit을 이용해 Json 데이터를 주고 받을 때 이런 에러를 보게 되는 경우가 있다 

Caused by: com.google.gson.JsonSyntaxException: java.lang.IllegalStateException: Expected BEGIN_OBJECT but was BEGIN_ARRAY at line 1 column 15 path $.documents
  at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$Adapter.read(ReflectiveTypeAdapterFactory.java:224)
  at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$1.read(ReflectiveTypeAdapterFactory.java:129)
  at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$Adapter.read(ReflectiveTypeAdapterFactory.java:220)

이 에러는 서버로 부터 전달 받은 타입과 내가 예상한 타입이 맞지 않아서 발생하는 문제다. 특히 위 에러는 나는 Object가 올것으로 기대 했는데 실제 데이터가 배열인 경우다. 아래 코드를 보면 나는 검색 결과에 대한 클래스에서 documents 인자를 하나의 오브젝트로 받고 있다. 

interface LibraryApi {
    @GET("/v3/search/book")
    fun search(
        @Query(value = "query") query: String,
        @Query(value = "sort") sort: String?,
        @Query(value = "page") page: Int?,
        @Query(value = "size") size: Int?,
        @Query(value = "target") target: String?
    ): Single<SearchResp>
}

@Keep
data class SearchResp(val documents: BookMeta, val meta: SearchMeta)

그런데 실제 서버로부터 응답은 documents는 하나의 오브젝트가 아니라 배열로 날라온다. 클라이언트에서 기대한 데이터 타입이 달라서 발생하는 에러다.

{
  "documents": [
    {
      "authors": [
        "전석"
      ],
      "contents": "주식투자의 성공 요소 중 중요한 것은 바로 수익을 낼 수 있는 종목을 볼 줄 아는 눈을 갖는 것이다. 지금 상승하거나 혹은 상승을 준비 중인 종목들이 본격적으로 상승하기 전에, 세력은 어쩔 수 없이 흔적을 남기게 된다. 『개미대학 세력의 매집원가 구하기』는 그런 종목을 구별해 낼 줄 아는 능력을 키울 수 있게 한다. 처음 기술적 분석을 공부하다가 힘들다고 포기하는 부분이 바로 '캔들과 거래량'인데, 이것을 실전에 적용하려면 암기가 아닌 원리의 이해가",
      "datetime": "2017-0

네트워크 디버깅으로 Stetho 라이브러리와 chrome://inspect 를 이용하곤 하는데, 안드로이드 스튜디오의 Profiler를 사용해도 동일하게 네트워크 디버깅을 할 수 있다. Stetho를 오래 사용하는 경우에 안드로이드 스튜디오랑 연결된 디바이스가 끊기는 문제가 있었는데 이 방식을 이용하면 끊길 염려 없이 사용할 때 더 간편하다. 이번 포스트에서는 Profiler를 이용한 네트워크 디버깅 방법을 간단히 소개한다.

1. Profiler 실행 

View -> Tool Windows -> Profiler 로 Profiler를 실행한다. 

2. 프로파일링할 프로세스 선택 

현재 연결중인 디바이스에서 디버깅할 앱 프로세스를 세션으로 추가한다. 당연한 얘기지만 앱은 debug 모드로 빌드해야 프로파일링 할 수 있다. 선택을 하면 프로세스의 CPU, Memory, Network, Energy 사용량을 시간 순서로 볼 수 있다.

3. 네트워크 프로파일링 선택 

그래프에서 네트워크를 선택하고 앱에서 네트워크 요청을 보내보면 아래 그림처럼 파란 직선 그려진 트래픽을 볼 수 있다. 마우스를 이용해 파란색 직선 영역을 블록처리해보면 해당 구간에서 주고 받은 네트워크 요청 목록을 볼 수 있다. 

4. 네트워크 디버깅 

디버깅하려는 네트워크 요청을 클릭해보면 오른쪽 탭에 상세 요청과 응답을 볼 수 있다. Body가 Json 형태인 경우 깔끔하게 그려준다. chrome://inspect에 비해 좋은 점은 Body에서 에디팅이 쉽다. chrome의 경우에는 복사를 하는 경우 디버깅 화면이 꺼지는 버그가 있었는데 Profiler를 사용하면 이런 버그가 없이 일반 코드에서 에디팅 할 때랑 똑같다.

현재 서버 애플리케이션 플랫폼의 큰 두 축은 Spring Boot 와 Node.js 인것 같다. 각각의 플랫폼마다 고유한 장점이 있을 텐데 정작 나는 '일하고 있는 곳에서 사용중이다', '요새 이게 트렌드라고 한다'는 이유로 본질을 망각한채 공부만 해왔던 것 같다. 그래서 이번 포스트에서는 spring boot와 nodejs 각각의 장점과 단점을 늦었지만 다뤄 보고자 한다.

Node.js

Node.js하면 자바스크립트로 짤 수 있는 서버 애플리케이션을 가장 먼저 떠오르는데 사실 Node js는 Non-blocking I/O를 처리하는데 최적화된 플랫폼이다. Non-blocking I/O는 다른 작업이 처리되는 걸 기다리는 도중에 다른 작업을 하는 것을 말하며 이러한 형태는 짧은 시간에 여러 작업을 처리할 수 있어 효율적이다. 다른 언어에서도 이런 형태로 구현은 가능하지만 코드가 너무 지저분해지고 구현이 어려운 단점이 있었는데 Node js에서는 비동기식 함수를 통해 코드 상에서 이 작업을 구현하기 간편하게 만들어줬다. 실제로 최근에 만든 사이드프로젝트에서 Non-blocking I/O를 구현하는게 정말 간편했다. 그리고 내부적으로는 하나의 Thread를 이용해서 구현했기 때문에 메모리를 크게 잡아 먹지도 않아 효율적이다. 똑같은 애플리케이션을 돌려도 다른 프레임워크보다 Node.js가 소모하는 메모리의 크기가 적다.

단점은 JavaScript 언어를 사용한다는 점이다. JavaScript가 배우기는 참 쉬워서 적은 시간을 투자하고 금방 숙달을 할 수 있으나 프로젝트 규모가 커지면 커질수록 Type Safe 하지 못하는 점이 한계점으로 작용한다. 언어가 Type Safe 하지 못하면 내가 짠 코드가 별것도 아닌 에러로 런타임에 죽을 수도 있다. 대부분 이 에러는 Java나 C언어 를 사용했다면 빌드 중에 발생하는 컴파일 에러 종류인데 JavaScript는 빌드하는 과정이 없기 때문에 실행 전에 잡아 주질 못한다. 구현하고 서버 실행까지 매우 빠르다고 좋아 할지 모르나 이 사이에 컴파일 오류는 없을 지 꼼꼼히 봐야한다. 그리고 Type Safe하지 못해서 IDE에서 자동 완성이 잘 되지 않는다. 프로젝트가 커지면 커질수록 리팩토링을 하거나 기존 코드를 써먹어서 확장해야 할 때 자동완성 기능이 핵심인데 JavaScript를 쓰면 자동완성이 잘 안돼서 큰 애를 먹게 된다. 프론트엔드 프레임워크 React에서는 TypeScript를 도입해서 어느정도 보완하고 있는데 Node.js에서도 TypeScript를 도입하는 시도가 있다고 들었는데 어느 정도 진행됐는지 모르겠다. 

Spring Boot

SpringBoot는 Java로 만든 서버 애플리케이션이다. Java는 유구한 역사를 가지고 있고 지금도 많이 사용되는 언어라 스프링부트를 사용하면 Java 언어에서 있는 기능을 그대로 사용할 수 있다. Java를 개발해본 사람들은 쉽게 Spring Boot에 적응 할 수 있다. 그리고 역사가 오래 됐기 때문에 개발하는데 필요한 왠만한 라이브러리는 모두 Spring Boot에 다 있다. 안드로이드 개발자가 사용한 자바 라이브러리들은 모두 Spring에서도 찾을 수 있다고 볼 수 있고 추가로 서버 개발자들이 어려움을 겪는 데이터베이스 관리도 스프링부트에서는 JPA라는 라이브러리를 통해 간소화 해둬서 손쉽게 다룰 수 있다. 그리고 Java이기 때문에 TypeSafe 하다. 리팩토링하거나 확장 할 때 IDE를 이용해서 수정할 점을 빠르게 체크 할 수 있는데 프로젝트 규모가 커지고 안정성이 중요해지는 시점부터는 큰 장점으로 다가온다. 내부적으로는 Multi Threading을 지원하는 구조로 짜여있어서 길고 반복적인 업무를 처리할 때 효율적이다. 많은 양의 컴퓨팅이 필요한 경우 잘 써먹으면 좋다.

한번 써보신 분들은 알겠지만 Spring Boot는 러닝 커브가 존재한다. Node.js는 처음 배우는 사람도 하루만에 서버 구동하고 api도 하나 만들 수 있는데 Spring Boot를 공부하면 Service, Controller, Repository 에 대해서 알아야하고 각 컴포넌트는 어떤식으로 채워야하는지 공부가 필요해 해야 할 게 많다. Spring Boot에서는 좋은 구조를 유도하기 위해 이런 형태의 디자인을 권장하는데 초심자한테는 러닝 커브가 좀 있다. 그리고 boilerplate 코드가 많다. 스프링에서 권장하는 구조랑 라이브러리들을 사용하려면 이런 저런 코드를 만들어야 하는데 처음에는 어려우나 숙달되면 귀찮아진다. 그래도 안쓰는 것 보다 낫긴 하지만. 내부적으로는 메모리를 좀 많이 쓴다. Multi thread 환경이기 때문에 여러개의 Thread를 띄우다 보니까 어쩔 수 없이 생긴 문제인 것 같다.