Gopher 6개월차

고를 접하고 사용한지 6개월 정도가 지났다.

자바와 스프링부트를 주로 사용하면서 고라는 새로운 프로그래밍 언어를 접하면서, 외국에 나가서 더 넓은 세상을 보는 것처럼 많은 것을 느끼고 배웠다.

고에서 지원해주는 빌드 기능과 멀티 스레드의 기능을 한껏 활용할 수 있게 해주는 고루틴은 고의 매력적인 포인트이다. 외부 패키지 의존성을 간편하게 설정할 수 있고 강력한 표준 라이브러리 기능도 너무 좋다.

자바의 언어적인 특성과 철학이긴 하지만 JVM 위에서 작동하는 바이트 코드로 컴파일이 되면 자바 런타임이 있는 환경 어디서든 작동할 수 있어 이식성이 좋다. 하지만 자바에 대한 의존성을 시스템이 반드시 필요하다. 반면에 고는 프로젝트를 이진파일로 빌드할 수 있다. 이진 파일로 빌드된 이진파일은 동일한 시스템 아키텍처를 가지고 있다면 별도의 의존성 없이 어디서든 실행 가능하다. 또한 빌드 기능도 굉장히 강력해서 다른 아키텍처를 가지거나, C 의존성이 필요한지 여부 등을 고 자체 빌드 명령어로 제공하기 때문에 그래들이나 메이블과 같은 별도의 빌드 툴이 필요하지 않다.

또 강력한 멀티 스레드 기능인 고루틴을 제공한다. 최신의 자바의 스레드도 가상 스레드에 대한 지원을 늘려가고 있는 것으로 알고 있다. 기본적으로 자바에서 사용하는 스레드는 운영체제의 스레드와 일대일로 매핑되기 때문에 병렬적으로 늘릴 수 있는 스레드의 한계가 명확하다. 하지만 고는 가상 스레드인 고루틴을 생성하여 물리 스레드와의 매핑없이 스레드를 늘릴 수 있기 때문에 거의 제한 없이 고루틴을 사용할 수 있다. 스케줄러와 타이머를 통해서 멀티 스레드간 작업 스케줄을 조정하며, 채널을 통해서 고루틴간 안전한 방식으로 데이터 전송을 제공한다.

고를 6개월간 사용한 후기는 기능이나 언어가 가진 특성이 뭐가 더 좋다 나쁘다를 얘기할 수 없다. 하지만 나 개인적으로 가지는 선호는 나는 자바보다 고가 좋다. 이유는 많겠지만 고의 가벼움, 빠른 속도, 낮은 의존성이 좋다. 코드를 짜면서 느껴지는 고가 가진 철학이 자바보다 좋다.

RPG 게임을 하면 캐릭터가 선택할 수 있는 무기중에 여러가지 선택지가 존재한다. 태도, 대검 같은 무기는 한방한방 대미지는 강하지만 전체적인 캐릭터의 속도가 그 묵직함에 맞게 둔하고 느려진다. 다만 한방한방 확실하고 느껴지는 타격감이 있다. 도검과 같은 무기는 대검보다는 한방의 대미지가 약하다. 그렇지만 캐릭터의 모션은 한층 경쾌하다. 날렵하게 움직이고 적당한 대미지를 넣을 수 있다. 자바는 대검과 같고, 고는 도검과 같다. 자바는 무게감이 있고 굳건하다. 고는 가볍고 경쾌하다. 내가 느끼는 언어적인 특성은 그렇다.

근데 그런 언어의 특성이 느껴지는 부분은 웹 프레임워크에서도 똑같다.

자바 진영의 스프링 부트와 같은 웹 프레임워크는 굳건한 자리를 지키고 있다. 하지만 고에선 표준적인 웹 프레임워크가 없다. 사용자의 각가 필요한 기능에 의해 취사 선택으로 사용한다. gin, echo, fiver 등등.

자바의 스프링은 프레임워크의 역할을 톡톡히 한다. application.yaml 로 관리되는 구성 파일, 스테레오 타입의 어노테이션의 사용, 스프링 컨테이너로 관리되는 빈, 객체 의존성 주입, 프레임워크 레벨에서의 트랜잭션 지원, 요청과 응답의 인코딩과 디코딩 등등. 사용자가 신경쓰고 생각해야 할 부분은 애플리케이션 코드이다. 스프링에서 제공하는 규칙에 맞게 작성한 코드는 스프링의 규칙 하에 멋있게 동작한다. 엔터프라이즈급 프레임워크라는 말이 괜히 있는게 아니다.

고의 프레임워크는 각각의 역할에 맞게 활용이 나뉘어 있다. 대부분의 웹 프레임워크는 라우팅, 미들웨어, 요청 응답 인코딩과 디코딩 등을 지원한다. 고의 언어와 설계 철학에 맞게 프레임워크도 경량이다. 고 커뮤니티에서는 어떤 프레임워크로 웹 프레임워크를 개발하면 좋을까 하면 선호가 개인마다 다르다. 고의 표준 http 패키지로도 충분히 기능을 구현할 수 있으며, 추가적으로 각 프레임워크가 지원하는 기능에 대해서 이렇고 저렇다 하면서 프레임워크를 추천해준다.

경량으로 제공되는 프레임워크 덕분에(?) 개발자가 고려하고 직접적으로 제어해야할 부분이 많아진다. 구조체가 가진 의존성 관리, 데이터베이스의 트랜잭션 처리, 애플리케이션 구성 파일과 환경 변수, 보안 등. 웹 개발을 위한 기능적인 지원이 스프링과 비교하여 귀엽다. 직접적인 제어와 단순함을 중시하기 때문에 많은 기능을 개발자가 직접 관리하고 구현해야 한다. 이는 도검과도 빠르고 경쾌한 느낌의 고의 설계 철학과 사용 철학이 프레임워크에도 녹아있다고 할 수 있다.

그래서 고를 사용해서 웹 애플리케이션 서버를 구성하는 것은 참 별것 아닌 부분에 대해 고민이 많이 된다. 경력과 기술이 부족해서 그렇겠지만 모범 사례를 보면 너무 다양하다. 각자의 경우에서 모범사례라고 하는 것이 너무 많다. 13년차의 시니어 개발자가 자신은 어떤 방법으로 http service 를 작성했는지에 대한 글을 쓰는 것만 봐도 다양한 사례들이 있고 그 속엔 정말 많은 고민의 시간이 있을 것으로 생각된다.

인간은 선택지가 적을때 더 빠르게 선택하고 결정을 내린다. 선택의 역설은 선택할 가지수가 많을때 선택을 못하거나 선택에 오랜 시간이 걸리거나 심지어 선택을 포기하게 되는 것을 말한다. 미국에서 한 연구에 따르면 6종과 24종의 잼을 시식했을때 판매량을 보면 30% vs 3%로 10배 이상 높다. 선택지가 적으면 빠른 선택이 가능하지만 선택지가 많아지면 선택에 시간이 걸리고 심지어 선택에 압도되어 포기한다. 내 생각엔 인간이 기본적으로 손실회피 경항이 높기 때문이다. 내가 얻을 것을 높이는 것보다 잃을 것을 최소화하려는 경향에 다른 선택지에 대한 기회비용을 파악한다. 그게 뇌를 피곤하게 한다.

스프링의 개발 생산성이라는 말은 선택지를 줄임으로서 달성한 결과라고 생각한다. 사용자의 선택이 필요한 부분에 대한 자동 구성을 통해 선택과 고민에 대한 시간을 줄여준다. 선택과 고민의 시간을 줄여줄 뿐 아니라 줄여준 선택지가 필요한 기능은 자동으로 구성해주니 사용자의 입장에선 스프링이 에피타이저부터 디저트까지 준비되어 있는 풀코스를 즐기는 것처럼 개발에만 초 집중할 수 있게 된다. 개발자와 기업 입장에선 생산성이 폭발한다.

나는 오늘도 고로 개발한다. 그렇기 때문에 불쑥 불쑥 나타나는 선택지 중에서 적당히 만족할만한 것을 골라야한다. 구조를 바꿔보고 바뀐 구조로 테스트를 돌려보고 하는 과정이 팀원들과 내가 만족하는 선에서 이루어져야 한다. 그리고 이런 과정이 즐겁고 재밌다.