2023년 3월 정보들

특정한 문제를 예시로 이야기를 만들어서 설명하는 것이 인상적이었다. 실제로 있을 법한 담론이 펼쳐져서 빠져들게 하는 매력이 있다. 내용도 알차서 한번 읽어서는 다 담을 수 없을 것 같다. 특히 마지막에 사가패턴에 대한 정리가 일목요연하게 잘 되어있다. 책을 두번 읽지는 않더라도 이 내용은 여러번 읽어야겠다는 생각을 했다.

오랫만에 스프링을 구경하기 위해 조쉬 롱의 세미나를 보았다. 조쉬 롱은 단순히 인사이트가 있는 사람이 아니라 내가 생각하는 개발자 즉, 개발을 놓지 않는 사람임이 틀리없다. 만드는 속도가 어떤 개발자의 능력을 바라보는 유일한 지표는 아니지만 유의미한 지표라고 생각한다. 그가 세미나에서 코딩을 하면서 설명하는 모습을 보니 기술자란 저래야 하는구나 라는 생각을 했다.

자신이 사용하는 기술을 매끄럽게 사용하는 것을 보면서 나도 그렇게 하고 싶다는 생각이 들었다.

https://www.youtube.com/watch?v=Y2gZz8-yK7Y&t=3308s&ab_channel=IntelliJIDEAbyJetBrains

처음 발표의 시작이 아래처럼 새작한다.

boring -> mature mature -> more sleep more sleep -> more fun

새로운 기술이 아닌 변하지 않는 기술에 좀 더 집중하자는 말로 보인다. 나도 새로운 기술을 찾아보면서 습득하는 것에 가끔씩 허망함을 느끼긴 하지만 새로운 기술이 별볼일 없더라도 계속 찾아보는 것은 숙명과 같은 것 같다.

요즘 쿠버네티스에 대한 이야기를 많이 듣는다. 그린랩스에서는 github action으로 테스트가 모두 통과한 이후에 도커 이미지에 jar실행파일을 넣어서 fargate로 실행한다.

github action에서 가장 오래 걸리는 부분이 이 도커를 생성하고 ECR에 등록 후 ECS로 배포하는 부분이었다. 요즘은 마이크로서비스의 시대이고 쿠버네티스가 대세가 되었나보다.

큰 회사에서 인프라를 어떻게 구축하는지 좀 더 고민해보지 않았다.

이 때문에 Spring6는 마이크로서비스를 좀더 지원하기 위해 Native Image Support와 AOT 강화를 위해 박차를 가하려는 모습니다.

실제로 Graalvm Native Image 가 지원된지는 꽤 오래된 것 같다.(오랫만에 스프링의 세상으로 오니 많은 것이 바꼈다) 현재 gradle에는 bootBuildImage 로 바로 실행되는 도커 이미지를 만들 수 있다. 실행파일로 만들기 때문에 이미지 크기가 100MB가 안된다. 나의 기준으로 Spring Web, Native Image Support 의존성을 추가한채로 만들어보았으나 70MB정도로 도커이미지가 생성되었으며, 스타트업시간은 가히 경의적으로 빨라졌다. (10배 이상)

또한 메모리 사용또한 최적화된 것을 느꼈다. 이것은 내 로컬 맥북으로만 테스트를 해보았으나 200MB 사용에서 60대로 줄어든 것을 확인할 수 있었다.

이러한 물결에 따라 Quarkus라는 프레임워크는 애초에 Graalvm Native Image를 위해 만들어진 프레임워크 같다. Quarkus의 특이한 기능 중에 하나는 서버를 실행한채로 코드를 바꾸면 Spring Dev Tool 처럼 재시작한다는 느낌보다도 더 빠르게 순식간에 반영된다는 느낌이 강했다. 그리고 Graalvm Native Image를 만드는데 매끄럽게 진행되었다. 참고로 Graalvm Native Image를 만들 때에는 리플렉션, 메타데이터를 많이 이용하지 않는 것이 좋다고 한다. Spring은 이를 적극적으로 사용함에 있어 aot를 수행하고 native image를 만드는데 이점을 최대화 하긴 어려운 점이 있다. (물론 이것도 어노테이션 힌트를 달면 되는 것 같다) Quarkus와 Micronaut는 마이크로서비스를 만나고 만들어진 신생 웹 프레임워크이므로 리플렉션을 잘 사용하지 않는다고 한다. (aot & native image 때문이라는 듯)

Quarkus는 특정 설정을 추가하면 코드가 바뀔 때마다 테스트를 자동으로 실행시켜준다. 테스트가 자동으로 실행되는 기능은 어쩌면 Spring도 이를 따라하지 않을까 싶다.

특이한 점은 모든 웹 프레임워크의 코딩방식이 아주 비슷하다는 것이다. Quarkus는 좀더 개발을 할 때 재미가 있을 것 같다는 생각이 들었다. 뭔가 즉각적인 반응을 해주기 위한 기능들이 많기 때문으로 느껴진다.

하지만 Spring 6 에서 중요하게 생각하는 Native Image Support, Aot 기능이 점점 더 개선되면 Quarkus와 Micronaut과의 차이는 많이 줄어들지 않을까 싶다. 물론 Quarkus와 Micronaut과 다르게 도커 이미지의 크기의 차이는 줄일 수 없겠지만(실제로 테스트를 해보니 Quarkus는 37mb 정도였고 Spring Boot 3는 그 두배였다.) 그럼에도 사용하기 충분한(?) 서비스를 만들어내지 않을까 기대해본다.

겪었던 문제로 gradle에서 nativeCompile 을 잘 되는데 buildBootImage 명령어는 7시간이 넘어도 돌지않는 문제를 발생했다. 아무도 느끼지 못한 것인가? 싶어서 여러가지 버전으로 시도 했으나 실패했다. 결국 6년이 넘은 intel mac을 이용하니 6분 정도걸려서 이미지가 만들어지는 것을 확인했다.

좀 더 찾아보니 아직 M1에서는 잘 안되는 경우가 있나보다.

요즘 쿼커스라는 프레임워크에 조금은 관심을 갖고 있다. 스프링 부트의 왕좌를 넘을 수는 없지만 몇가지 특징들이 아주 인상적이다. 이 내용은 Quarkus에서 어떻게 Project Loom 을 미리 넣어서 사용하는지 알려주는 내용이다. 미리 사용할 수 있는 기반을 만들어 놓은 것이다.

@Path("/")
public class FortuneResource {
    private final FortuneRepository repository;
    private final Random random;
    private final Logger logger;

    public FortuneResource(Logger logger, FortuneRepository repository) {
	this.repository = repository;
	this.logger = logger;
	this.random = new Random();
    }

    @GET
    @Path("/blocking")
    public Fortune blocking() {
	log();
	List<Fortune> list = repository.findAllBlocking();
	return pickOne(list);
    }

    @GET
    @Path("/reactive")
    public Uni<Fortune> reactive() {
	log();
	return repository.findAllAsync()
			.map(this::pickOne);
    }


    @GET
    @Path("/loom-jdbc")
    @RunOnVirtualThread
    public Fortune loomJDBC() {
	log();
	List<Fortune> list = repository.findAllBlocking();
	return pickOne(list);
    }

    private Fortune pickOne(List<Fortune> list) {
	int idx = random.nextInt(list.size());
	return list.get(idx);
    }
}

이렇게 @RunOnVirtualThread 를 추가하면, 저절로 Loom이 된다는 것 같다. 하지만 영상을 보면 아직 webflux보다는 안정적이지 않은 것 같다는 생각이 든다. 이것은 quarkus 팀의 문제는 아니고, project Loom이 아직 프리뷰이기 때문이지 않을까 싶다.

Project Loom의 장점은 비동기적인 코딩이 아니라 기존 MVC 방식으로 코드를 간결하게 짤 수 있다는 점이 아주 인상적이다.

코루틴에 비하면 뭔가 기능이 좀 적은 것 같긴하지만, 지켜봐야할 문제인 것 같다.

https://developers.redhat.com/devnation/tech-talks/integrate-loom-quarkus

David Nolen은 ClojureScript의 주요 개발자이다. 그는 많은 경력을 가지면서 Clojure의 REPL이 개발자에게 어떤 의미인지 알려준다.

https://www.youtube.com/watch?v=3HxVMGaiZbc&t=2558s&ab_channel=ChariotSolutions

core.async 라이브러리에서 사용하는 macro의 결정판을 보여준다.

https://www.youtube.com/watch?v=HXfDK1OYpco&ab_channel=TimothyBaldridge

go macro의 내부를 보여준다. 이상하게도 예전에는 전혀 이해가 되지 않는 내용이었는데, 이번에는 이해가 되었다. 공부를 한 적이 없음에도 불구하고 이해가 되었다는 것은… 어쩌면 Clojure로 실제로 프로젝트를 해본 것이 큰 영향을 미친 것 같다.

실제 프로젝트에서도 go macro에 대해 깊게 생각해본 적이 없었다. 아마 여러가지 경험을 해보면서 이런 내용들이 이해가 되는 것 같다.

이제 정말로 Clojure의 끝을 볼 수 있을 것 같다. 이전에는 macro를 이용한 클로저로 패턴매칭을 만들어보았다면 이번에는 비동기 프로그램까지 만들 것 같다.

https://www.youtube.com/watch?v=R3PZMIwXN_g&ab_channel=TimothyBaldridge

이 내용은 좀 더 깊게 go macro의 내부를 보여준다. 지루한 감이 없잖아 있었다. 왜냐하면 몇가지 파싱하는 함수들을 나열하고 그것들을 하나하나 간략하게 설명해주는 것이었는데 좀 더 깊은 내용이 있기를 기대했는데, 그런 내용은 없었다.

나중에 한 번 더 봐야겠다는 생각이 들었다.

https://www.youtube.com/watch?v=SI7qtuuahhU&ab_channel=TimothyBaldridge

왜 클로저를 사용하지 않는가에 대한 글이다. 여러가지 논쟁이 이루어졌지만 seancorfield의 글이 가장 인상적이었다.

Clojure는 다른 언어로 인해 특정 종류의 고통을 충분히 겪은 숙련된 개발자가 흥미로운 문제를 해결하기 위해 "활용도가 높은(high-leverage)" 도구를 원하는 숙련된 개발자를 위해 설계된 것이지, 주류가 되는 것은 Clojure의 목표가 아닙니다. 모든 사람을 위한 것은 아닙니다. 설계상 그렇습니다.

seancorfield가 자신의 의견을 정당화 하는 근거는

• 8년간 ANSI 표준위원회(CC+)
• 최초 ANSI 검증 C 컴파일러 시스템 제작
• 함수형 언어의 설계 및 구현에 관한 박사 학위('80s) 취득

무언가 Clojure는 아마 평생 주류가 되긴 힘들 겠다는 생각이 드는 날이었다.

또한 이 스레드에는 Timothy Baldridge가 Clojure를 사용하지 않는 이유를 적어놓았다. 이 글은 20202년도에 트위터에서 작성되었으며, 지금은 아카이브되어있는 것 같다.

@KirinDave Since pulling back from the Clojure community about 1.5 years ago, I've realized something: Clojure isn't a silver bullet. You can write good code in any language, and often tools can easily make up for the lack of expressiveness in a language. @KirinDave 지난 1.5년간 Clojure 커뮤니티에서 떨어져나온 후에, Clojure가 실버 총알이 아니라는 것을 깨달았습니다. 어떤 언어에서도 좋은 코드를 작성할 수 있고, 툴을 사용하면 언어의 표현력이 부족한 부분을 쉽게 메울 수 있습니다.

@wazound @metasoarous @LittleFunnyGeek @jamie_allen You make a good point. In the past few years I've spent a lot of programming time outside of Clojure. With C#, Python, F#, and a few other languages. And surprisingly I've found that they've grown more similar to Clojure than apart. @wazound @metasoarous @LittleFunnyGeek @jamie_allen 좋은 지적이네요. 지난 몇 년간 Clojure 외의 다른 언어를 사용하면서 느낀 점은, Clojure와 다른 언어들이 Clojure와 더 가까워지고 있다는 것입니다.

또한 스튜어트 할로웨이의 트위터도 눈에 띈다. 이 글은 seancorfield의 의견을 뒷받침한다.

#Clojure was designed by and for, and continues to appeal to, experienced developers who want keen tools to solve interesting problems. #Clojure 는 경험 많은 개발자들을 위해 설계되었고, 흥미로운 문제를 해결하기 위한 도구를 원하는 개발자들을 위해 설계되었다.

반대의견으로 Rich Hickey의 아티클을 보자. (https://www.linuxjournal.com/article/10708)

I discovered Lisp after ten years of C++ and said to myself, “What have I been doing with my life?” I realized it was just much more productive for me. I fell in love with it right away. Basically, I said to myself, “At some point in my life, this is really what I want to be doing.” I spent several years subsequent to that continuing to do my commercial work in Java and C#, but all the while hoping at some point to be able to get Lisp into the mix. That’s what drove me to doing Clojure, because I saw that either .NET or the JVM were requirements for all the customers I was encountering. Lisp really couldn’t reach those platforms, so I decided to make a Lisp that could. 나는 10년간 C++를 사용하고 나서 Lisp를 발견하고 나서, “내 인생을 어떻게 보냈나?”라고 생각했습니다. 그때부터 나는 Lisp가 훨씬 더 생산적이라는 것을 깨달았습니다. 바로 사랑에 빠졌습니다. 기본적으로, “내 인생의 어느 시점에 이것이 내가 하고 싶은 일이 될 것이다.”라고 생각했습니다. 그 후 몇 년 동안 나는 Java와 C#을 사용하면서 상업적인 일을 했지만, 언젠가는 Lisp를 사용할 수 있을 것이라는 희망을 가지고 있었습니다. 그것이 Clojure를 만들게 한 원동력이었습니다. 왜냐하면, 나는 .NET이나 JVM이 모든 고객들이 필요로 하는 플랫폼이라는 것을 알았기 때문입니다. Lisp는 그러한 플랫폼에 도달할 수 없었기 때문에, Lisp를 사용할 수 있는 Lisp를 만들기로 결정했습니다.

위에 리눅스 저널이 흥미롭다. 해당 저널을 읽고 인사이트를 얻어야겠다.

https://clojureverse.org/t/why-not-clojure/5914