지난 2년

깃허브 블로그를 셋팅하면서 2022년 3월 24일에 이런 저런 이야기를 올려 놨었다. 그리고 어느덧 2년이 넘는 시간이 지났고, 그 사이에 꽤 많은 변화가 있어서 정리해보고 싶다.

가장 큰 변화는 구글을 퇴사한 것이다. 작년 초에 퇴사하고 이제 1년이 조금 넘었다. 1년이 넘게 월급도 안 벌어오는 남편에게 크게 잔소리도 안하는 아내에게 감사한 마음이다. 사실 처음에는 파산하는 것도 아니고 영영 돈을 안 벌 것도 아닌데 몇 달 월급 안 벌어오는게 그렇게 큰 문젠가 싶었는데, 작년 10월에 구글에서 친하던 분이 집을 새로 지으셨다기에 집들이를 갔었는데 거기 모인 분들이 다들 나한테 “아내가 뭐라고 안하냐” 라며 몇번이나 의아해하며 물어보시는걸 보고 아내에게 고마운 마음이 생겼다.

1년여의 시간동안 아내와 딸과 많은 시간을 보낼 수 있어서 좋았고, 그 외에도 많은 일들이 있었다.

• 개발
  • jparser
    • 10년 넘게 숙원 사업이었던 jparser를 이제 꽤 쓸 만 하게 만들었다.
    • milestone 파서 알고리즘과 milestone group 파서 알고리즘을 꽤 잘 작동하게 만들었다. 언젠가 알고리즘을 정리해서 설명하는 글을 적어놓아야겠다.
    • 여러 부분에서 코틀린을 지원하게 되었다. 어느 순간부터 내가 스칼라를 거의 사용하지 않고 코틀린만 사용하게 되었다. 코틀린은 스칼라의 강력한 패턴 매칭같은 기능은 없지만 막상 써보면 그런 기능들이 없어도 실제로 추가되는 코드는 몇줄 되지 않는다. 그런데 그런 기능들을 위해 스칼라에 추가되는 복잡성이 만만치 않다. implicit 문법들(implicit argument, implicit class 등등)이나 unapply 등등의 문법은 이해하기도 어렵고, 무엇보다 그런 기능을 잘못 쓰면 자바에서 스칼라 코드를 호출하는게 거의 불가능할 정도로 어려워진다. 그래서 코틀린정도면 간결함과 기능성의 밸런스를 잘 맞췄다는 생각이 들었고, 결정적으로 스칼라 3가 나오면서 스칼라 2와 호환이 안된단 얘기를 듣고 이건 더이상 쓰지 말아야겠다는 생각이 들었다.
    • 그래서 거기에 맞춰서 jparser에도 코틀린 지원을 추가했다. jparser 자체는 여전히 대부분 스칼라 2로 작성되어 있지만, milestone group 파서 알고리즘을 코틀린으로 구현했고, AST 노드 클래스를 코틀린 코드로 생성하는 기능을 추가했고, 파싱 결과를 AST로 바꾸는 코드도 코틀린으로 생성할 수 있게 만들었다.
    • 기존 코드를 스칼라 3로 마이그레이션 하지는 않을 계획이다. 스칼라 개발자들이 스칼라 2를 완전히 버리지만 말고 버그 수정이나 JVM 업데이트 대응이라도 계속 해주면 좋겠다.
    • 그래서 이제 내 개인 프로젝트에서도 jparser를 꽤 안정적으로 쓸 수 있게 되었다. 아래서 소개할 프로젝트들은 대부분 jparser를 사용한다.
  • bibix
    • 빌드 툴인 비빅스도 꽤 쓸 만 해졌다. 물론 내 기준이다. 아직 문서가 없고 IntelliJ 플러그인이 너무 허접해서 누구에게 권하기는 어렵다. 정말 궁금하다면 bibix 프로젝트의 build.bbx 파일을 참고하시기 바란다.
    • 작년 말에 인터프리터를 새로 만들었고, bibix 스크립트를 읽어서 그래프를 만들어서 싸이클이 존재하는지 등을 확인한 다음 빌드를 실행할 수 있게 만들었다. 인터프리터를 새로 만드는건 꽤 골치 아픈 과정이었다.
    • bibix 스크립트는 자체 문법이고, 파서는 당연히 jparser로 만들었다. bibix는 jparser를 사용하고, jparser는 bibix로 빌드하고. 처음엔 jparser를 빌드해서 jar 파일을 만들어서 사용하다가 두 프로젝트가 어느정도 안정화 되면서 이제는 그냥 서로 의존적인 관계가 되었다.
    • IntelliJ daemon을 재구현해서 안정성을 높였고, IntelliJ 플러그인을 사용해서 bibix 프로젝트를 IntelliJ로 임포트해서 사용할 수 있다. 현재는 자바와 코틀린을 위주로 지원한다. 다만 IntelliJ 플러그인이 daemon이 띄워져 있어야만 제대로 동작하기 때문에 사용자가 손수 대몬을 띄워줘야 한다. 그래들의 IntelliJ 플러그인은 대몬을 알아서 다운로드 받아서 실행시키는 기능을 갖고 있는 것 같은데, 비슷한 기능을 bibix IntelliJ 플러그인에도 넣으면 그래도 조금 권하고 다녀볼 수 있을 것 같다.
    • C++ 같은 언어도 지원하고 싶은데, C나 C++의 경우엔 로컬 시스템에 설치된 라이브러리를 그냥 디펜던시로 바로 사용하는 경우가 많아서 자바나 코틀린에서 메이븐 의존성을 리졸브하는 것처럼 쉽게 bibix에서 지원하기가 쉽지 않았다. 도커로 빌드 환경을 만들어줘야하나? 같은 생각도 해 보았다. 못할 일은 아니겠지만 복잡해 보여서 현재는 보류 상태다. 애초에 나는 C++ 을 쓸 일도 잘 없어서.
  • sugarproto
    • 나는 protobuf를 매우 즐겨 사용하고 좋아한다. 하지만 protobuf의 메시지 정의 문법에 약간의 아쉬움이 있었다. 다른 부분보다 service 를 정의할 때 rpc의 인풋과 아웃풋 메시지를 service 밖에서 정의해야 한다는 점이 아쉽다. 때문에 rpc의 시그니처와 인풋과 아웃풋 메시지 내용이 파일 내에서 동떨어진 곳에 위치하게 되고, 그래서 rpc의 이름과 실제 인풋 아웃풋 내용을 확인하려면 proto 정의 파일을 위 아래로 옮겨다니거나 화면을 분할해서 봐야 했다. 이 점을 해결하고, 약간은 구식스러운 프로토의 문법을 조금 바꿔보기 위해서 sugarproto라는걸 만들었다. sugarproto 문법으로 프로토 메시지를 작성하면 proto 파일이 나오고, 그 뒤로는 프로토 컴파일러와 라이브러리를 그대로 사용하게 된다.
    • sugarproto는 bibix로 빌드하도록 되어 있고, 다른 프로젝트에서 sugarproto를 사용할 때도 bibix를 통해야 한다. 물론 sugarproto 문법 정의는 jparser로 한다.
    • 그 외에도 sugarproto에는 몇가지 기능이 더 있다. 여기서 설명은 안 했지만, 1년동안 한 일 중에 하나는 시뮬레이션 게임을 만드는 것이었다. 예전에 팩토리오를 엄청 재밌게 했었는데, 팩토리오에는 사람 캐릭터가 플레이어 캐릭터밖에 없는게 조금 아쉬워서 이주민 NPC들이 함께 등장하는 팩토리오를 만들고 싶었다. 처음엔 쉽게 생각했는데 막상 만들다보니 기획부터 너무 복잡해서 현재는 포기상태긴 하지만, 이 게임을 만들면서 게임 월드를 proto로 저장하고 불러올 수 있게 만들고 싶은데, protobuf 컴파일러가 생성해주는 클래스들을 그대로 사용하자니 뭔가 불필요한 오버헤드가 생기는 것 같았다. 그래서 sugarproto에 메시지 정의를 만들면 1. mutable 코틀린 data class들, 2. protobuf 정의, 3. 코틀린 클래스와 프로토버프 사이의 변환 코드를 생성하는 기능을 추가했다. sugarproto의 build.bbx 파일에 generateMutableKtAndProto 룰을 이용해 사용할 수 있다.
    • sugarproto에 추가중인 또다른 기능은 sugarformat이다. protobuf는 원래 바이너리로 컴팩트하게 데이터를 주고받을 수 있게 하는 것이 목표지만 경우에 따라 json이나 프로토 자체 텍스트 포맷으로 메시지를 주고받을 수도 있다. 그런데 하다보니 yaml 비슷한 protobuf 포맷도 있으면 좋을것 같다는 생각이 들어서 만든게 sugarformat이다. 아직 완전하진 않지만 기본적인 PoC 수준은 만들어서 혼자서 써보고 있다.
    • yaml하고 비슷하게 생긴 sugarformat을 만들다보니 들여쓰기 기반의 문법을 jparser로 처리할 필요가 있었다. 여기서 사용한 방법은 그냥 statement 단위로 파싱하는 것이다. 그래서 각 statement 앞의 인덴트를 저장해놨다가 statement 사이의 관계를 사후적으로 처리해서 statement 사이의 관계를 파악한다. 완벽한 방법이라고 할 수는 없지만, 그래도 그나마 간단하게 jparser로 들여쓰기 기반 문법을 처리할 수 있는 방법인 것 같다. 참고 문법
  • jsontype
    • jsontype은 JSON 메시지의 타입을 지정하면 1. 해당 메시지의 내용을 담을 수 있는 코틀린 data class 코드, 2. GSON을 이용해서 json 메시지를 코틀린으로 변환하거나 그 반대를 수행할 수 있는 변환 코드를 생성해준다.
    • jparser 덕분에 아주 간단하게 만들 수 있었다. 당연히 bibix로 빌드한다.
    • 코인 자동거래 시스템을 만들어보고 싶어서 코인 거래소들의 API를 연동하다보니 이런게 있으면 좋겠다 싶어서 만들었다. 근데 막상 코인 자동거래 시스템은 잠깐 생각만 하고 안 만들었다.
  • 컴파일러 책 쓰기
    • 컴파일러 책을 쓰고있다. 당연히 jparser를 폭넓게 사용한다. 처음 계획은 자바를 LLVM으로 컴파일하는 컴파일러를 만들고, 그 컴파일러에 대한 설명을 쓰는 것이었는데 쉽지 않았다. 자바가 primitive가 아닌 모든 타입을 힙 메모리에 만드는 것부터 LLVM 컴파일러를 만들때 걸림돌로 느껴졌다. 그래서 그냥 새로운 언어를 정의하고, 그 언어를 LLVM으로 컴파일하는 컴파일러를 만들고 그 과정과 숨어있는 원리들을 설명하는 책을 쓰는 쪽으로 방향을 바꿨다.
    • 새로 만드는 언어의 이름을 J1이라고 헀다. jparser로 만드는 첫번째 일반 목적 언어라는 뜻으로 1이라는 이름을 붙였다. J1은 처음에는 C언어 수준의 단순한 기능만 제공하는 언어로 만들고, 후에 클래스 등의 기능을 추가하는 식으로 만들 계획이다.
    • 아직 구현은 못했지만 LLVM을 인텔 어셈블리로 컴파일하는 컴파일러, 즉 컴파일러 백엔드도 만들어서 책에 쓸 계획이다.
    • 내 혼자만의 계획은 책을 두 권 내는 것이다. 1권에는 1. C언어 수준의 기능을 제공하는 J1 -> LLVM 프론트엔드와, 2. 최적화 등은 고려하지 않고 최소한의 기능만 포함하는 LLVM -> 인텔 어셈블리로 컴파일하는 백엔드를 만드는 내용을 담고, 2권에는 1. J1에 클래스, 람다, 패턴 매칭, 예외 처리 등의 고급 프로그래밍 언어 기능을 추가하는 것과, 2. J1에 가비지 컬렉터를 추가하고 메모리 관리에 대한 논의를 담는 것이다. 이런 책을 내 줄 사람이 있을진 아직 모르겠다.
  • 프로그래밍 입문 책 쓰기
    • 예전부터 나는 프로그래밍 초심자에게 프로그래밍 기초를 가르쳐보고 싶은 생각이 있었다. 그래서 프로그래밍 입문 책을 써보고 싶었는데, 타겟은 중학생이나 고등학생 정도의 학생들이었다. 그런데 그런 학생들이 어느 정도 수준의 이해력을 갖고 있는지 모르다보니 막막한 기분이 들었다. 그래서 동네에서 프로그래밍 입문 수업을 해봐야겠다고 생각했다. 월급이 없으니 약간의 수입도 생겨서 좋고, 책 쓰는데도 도움이 되니 좋을거라고 생각했다. 처음에 동네 맘카페에서 이런 수업을 개설하면 들을 의향이 있는 사람들이 있는지 조사했는데 꽤 많은 사람들로부터 연락이 왔다.
    • 그런데 막상 수업을 시작하기로 하고 수강생을 모집하려니 맘카페에 광고 글을 올릴 수 없다고 해서 글이 삭제당했다. 당근에 광고도 해보고 아파트에 전단지도 붙여보았는데 모집이 쉽지 않아서 결국 중학교 1학년 학생 두 명을 놓고 17주동안 수업을 진행했다. 다른 수업자료는 쓰지 않고 내가 수업 자료를 만들어서 수업을 진행했다. 두 학생 중 한명은 본인이 프로그래밍에 관심이 있는 학생이었고 한 명은 부모님의 권유로 온 학생이었는데, 아무래도 관심도가 다르다보니 이해도도 조금 달랐고, 수업의 난이도를 조정하기가 힘들었다.
    • 단순한 프로그래밍 언어에 대한 강의에서 그치지 않고 약간의 알고리즘(정렬 알고리즘, 재귀 호출, 이진 탐색, 시간 복잡도 등)과 자료 구조(스택, 큐, 트리, 이진 트리)를 소개했고, 수업 집중도를 높이기 위해 약간의 GUI 프로그램과 간단한 슈팅 게임을 만들어서 주고 학생들이 수정하게 하는 내용도 포함했다. 막판에는 특강 개념으로 컴퓨터의 동작 원리, 인공지능 개요, 자바 외의 다양한 프로그래밍 언어들에 대해서도 소개했는데, 나는 나름대로 신경써서 준비한 컨텐츠였는데 학생들 반응이 그닥 좋지는 않았다. 특히 컴퓨터 동작 원리에 대한 특강은 너무 졸려해서 나도 조금 당황할 정도였다.
    • 수업은 자바로 진행했다. 자바로 진행하다보니 그것도 약간 아쉬운 부분들이 있었다. 우선 자바에는 보일러플레이트 스러운 코드가 너무 많았다. Hello World 프로그램을 하나 만들기 위해서 써야 하는 코드가 너무 길었다. public class, public static void, System.out.println 같은 이름들이 너무 길었고 요소가 불필요하게 많았다. 아직 영어 타이핑이 익숙하지 않은 학생들에게 너무 많은 영단어를 쓰게 해야 해서 효율이 떨어졌다. 또 어딘가 일관적이지 않게 느껴지는 기능들 거슬릴 때가 꽤 있었다. 스트링은 본질적으로 char의 배열이라고 설명했는데 n번째 글자를 얻어오려면 charAt 메소드를 사용해야 하는 점이라든가, 배열에선 length인데 스트링에선 length()라던가 하는 점 등이었다. 이래저래 자바는 초심자용 언어로 썩 좋지는 않은 것 같다는 느낌이었다.
    • 자바를 사용할지 아니면 다른 언어로 바꾸는게 좋을진 모르겠지만 어쨌든 수업 내용 자체는 나름대로 알차게 만들었다고 생각해서 이 자료들을 정리해서 책을 쓰면 좋을 것 같은데, 아직 본격적인 작업을 시작하진 않았다.
  • autodb
    • autodb는 말하자면 코드를 생성하는 ORM이다. 이걸 만들게 된 계기가 두 가지 있다.
    • 예전에 카카오를 다닐 때 SQL DB를 샤딩해서 쓰는 부분이 많았는데, 그 부분의 코드가 꽤나 복잡하고 상당히 error-prone하다고 느꼈었다. 항상 그 부분을 자동화할 수 있지 않을까 생각했었다.
    • 그 후에 개인 프로젝트를 하면서 ORM들의 동작 방식이 별로 마음에 들지 않았다. 내 생각엔 DB 스키마를 바탕으로 코드를 생성해주면 간단하게 해결될 것 같은 문제들을 리플렉션 따위의 기능을 사용해서 굳이 어렵게 가는 것 같았다. 예를 들어 각 테이블의 row 하나를 나타낼 수 있는 class 코드를 생성해주고, DB에서 데이터를 읽어서 해당 class로 변환하는 코드를 생성해준다거나 하면 언어의 타입 체킹 기능도 그대로 사용하고 좋을텐데 굳이 리플렉션을 써서 런타임에 에러가 난다거나 하는 것이 마음에 안 들었다. 특히 코틀린의 Exposed ORM 의 경우 하나의 테이블에 대해 row 하나를 나타내는 클래스 정의를 직접 쓰고, 테이블의 정의도 별도로 써 주어야 해서 사실상 동일한 내용의 코드가 두 벌 들어가야 했다. (지금은 개선이 되었는지도 모르겠다) 거기에 어떤 테이블의 row들은 사용자에게 일부 내용을 추려서 그대로 전달하는 경우도 많은데, 그럴 때는 프로토 메시지 정의, 프로토 메시지로 데이터 변환 기능까지 직접 코딩해야해서 비슷한 내용의 코드를 3벌 4벌씩 적어야 하는 경우도 생겼다.
    • 이런 문제를 해결하기 위해 내 나름대로 만들고 있는 것이 autodb이다. 코드 생성형 ORM으로, 안드로이드에서 사용하는 Room하고 비슷한 느낌인데, 그걸 서버향으로 만들고 샤딩 기능을 추가하는 걸 목표로 하고 있다. 아직 샤딩 기능까진 제대로 지원하지 않지만 지원할 수 있도록 준비 작업중이다. 그런 준비 작업의 일환으로 쿼리를 정의할 때 SQL을 직접 사용하지 않고 코틀린의 표준 SDK의 콜렉션 클래스들과 비슷하게 생긴 자체 쿼리 문법을 사용한다. 그런 자체 쿼리 문법으로 쿼리를 쓰면 SQL을 실행하고 결과를 가공해서 생성된 코틀린 클래스로 만들어주는 코드를 생성해준다.
    • autodb도 DB 스키마와 쿼리들을 정의하기 위한 자체 문법을 갖고 있기 때문에 문법을 jparser로 정의하고 파싱하, 빌드도 bibix로 한다. 뭔가 내가 만든 성 위에 작품을 하나씩 쌓아 올리는 기분이라 뿌듯하다. 약간 미친 짓이 아닌가 싶을 때도 있긴 하다.
    • autodb는 혼자 꽁꽁 숨겨놓고 만드는 중이지만, 다음에 소개하는 phoclub 서버 개발할 때 실제로 사용했다.
  • phoclub
    • 회사를 퇴사하고 얼마 뒤, 대학 동기 연준이와 앞으로 프로젝트를 하나 하자며 논의를 했다. 그때 의기투합해서 시작한 프로젝트가 phoclub 이다. 아기를 키우면서 사진을 많이 찍게 됐고, 사진을 가족들과 공유할 때 기존 서비스들로 부족한 부분이 있어서 그걸 좀 고쳐보자 하면서 시작한 프로젝트다.
    • 역시나, 언제나 그렇듯 세상 일은 생각보다 쉽지 않다는 것을 다시금 깨닫게 해 준 프로젝트다. 일단 생각보다 기간이 오래 걸렸다. 처음에 완전한 기획 없이 개발을 시작했는데 중간에 내가 기획을 한번 뒤엎으면서 사실상 처음부터 새로 개발을 했던 것이 기간이 늘어지게 한 한가지 원인이었다. 또 한가지 이유는 중간 중간 내가 의욕을 잃고 속도가 쳐지는 부분이 있었다는 점이다. 나는 내 최대 단점이 싫증을 쉽게 느끼는 거라고 생각한다. 그게 때로는 새로운 걸 찾아 다닌다는 장점이 되기도 하지만 대체로는 단점으로 작용하는 경우가 많은데, 이번에도 프로젝트를 처음엔 열의를 갖고 시작해놓고 재미있는(기술적으로 도전적이라고 생각되는) 부분을 넘어서니 급속히 흥미를 잃어서 집중력이 떨어졌다. “이게 진짜 될까? 진짜 차별성이 있는걸까?” 같은 자기 확신 부족도 그런 문제를 일으키는 요소 중 하나였다. 그런 문제들은 어쨌거나 다 만든 다음에야 알 수 있는 부분이고, 꾸역꾸역 도착지에 깃발을 꽂는 것은 그 자체로 중요한 일인데, 내가 여태 해온 일중에 그 과업을 달성한 경우가 많지 않다. 하루키 루틴같은게 좀 필요치 않을까 싶다. 좋든 싫든 정해진 시간만큼 해야할 일을 하는 루틴 말이다.
    • flutter로 UI를 개발했다. 처음엔 로직도 대부분 플러터로 할 수 있을 거라고 생각했는데, 만들다 보니 플러터로 만들기 어려운 부분들이 꽤 있어서 결국 안드로이드와 ios 네이티브 코드가 꽤 많이 필요해졌다. 그래서 플러터와 네이티브 코드를 연결하는 부분을 sugarproto 문법을 응용해서 표준화할 수 있도록 flutter native channel 이라는 일종의 컴파일러를 만들어서 사용하고 있다. 이 flutter native channel 부분은 다른 프로젝트에서도 꽤 유용할 것 같은데 일단 지금은 나 혼자만 쓰고 있다.
• 음악
  • 언젠가부터는 클래식 음악만 듣고 있다. 22년 말이었나, 임윤찬이라는 피아니스트가 미국의 유명한 콩쿨에서 우승했다고 유튜브에 자꾸 뜨길래 대체 뭔데, 하고 공연 실황 영상을 열었는데 누워서 휴대폰을 든 채로 40분이 넘는 공연 영상을 끝까지 다 봐버렸다. 아 클래식이 다 지루한게 아니구나, 클래식 중에도 마음을 울리는 곡들이 있구나, 라는걸 느꼈다. 그 뒤로 그 영상을 하루에도 몇 번씩 돌려 보다가 조금 지루해질 때 즈음 같은 곡의 다른 연주, 다른 작곡가들의 곡들도 찾아보기 시작했다. 그때 들었던 라흐마니노프 피아노 협주곡 3번은 들어본 중엔 임윤찬의 연주가 제일 좋게 느껴진다. 그냥 처음 듣고 마음을 움직였던 연주라 그럴 지도 모르겠다.
  • 나는 다른 악기보다는 피아노, 교향곡보다는 피아노 협주곡이 좋다. 라흐마니노프 피아노 협주곡 2번, 차이코프스키 피아노 협주곡 1번, 쇼팽 피아노 협주곡 1번, 베토벤 피아노 협주곡 5번 등등을 찾아서 듣다가 라벨 피아노 협주곡 G장조를 듣게 됐는데 첨엔 이게 뭐지 싶었다. 이게 클래식 음악 맞아? 라는 느낌. 그런데 첫 음(채찍 소리같다고들 표현하는)부터 흡입력이 대단해서 그 뒤로 계속 듣게 되었고, 생각보다 많이 연주되고 인기있는 곡이라는걸 알게 되었다. 그 뒤로 라벨에 빠져서 지금도 가장 좋아하는 곡은 라벨의 곡들이다. 1년이 넘도록 지금까지도 피아노 협주곡 G장조 말고도 (그 유명한) 볼레로, 라 발스, 밤의 가스파르, 그 중에서도 특히 스카르보, 물의 유희, 쿠프랭의 무덤, 현악사중주(특히 바이올린으로 기타 소리 내는 2악장) 등을 거의 매일 빠지지 않고 듣는다. 라 발스를 피아노 버전으로 처음 들었을 때는 너무 정신사납고 시끄러워서 싫었다. 프로코피예프나 스트라빈스키를 들으면 좀 정신사납고 불협화음처럼 느껴지는 부분들이 있는데 라 발스도 그런 느낌. 그런데 신경쓰지 않고 유튜브의 알 수 없는 알고리즘이 추천하는 곡들을 듣던 중 고막에 와서 꽂히는 것 같은 음악이 있어서 알고 보니 라 발스 오케스트라 버전이었다. 그래서 한동안 라 발스 오케스트라 버전을 듣다가 순간 이게 원래 피아노 곡인데 대체 이 소리를 어떻게 피아노로 낸다는거지? 하고 피아노 버전을 다시 들었는데 너무 좋았다. 특히 원전이라고 할 수 있는 2피아노 버전은 몇 번을 들어도 들을 때마다 빠져들게 된다. 라벨 피아노 협주곡은 조성진이 보스턴 심포니와 연주한 유튜브 영상이 개인적으로는 가장 좋은데, 레코딩 품질이 좀 아쉬운 느낌. 어차피 블루투스 이어폰으로 들어서 그런지 큰 차이는 못 느끼긴 한다. 아바도 선생님이 라벨 연주를 많이 하신 것 같은데 왠지 들어본 연주들 중에는 가장 자연스럽게 느껴져서 즐겨 듣는다.
  • 이런 음악들을 듣다보니 피아노를 배우고 싶은 생각이 들었는데, 내가 쳐보고 싶은 곡들은 라벨의 곡들, 그 중에서 너무 어려운 곡들은 언감생심 탐내지 않고 예를 들면 죽은 왕녀를 위한 파반느같은 곡들인데, 아무 기본도 없는 내가 학원에 가면 바이엘부터 시작해서 한동안 배워야될 거고, 그러면 그 사이에 흥미를 다 잃을 것 같아서 그냥 듣는걸로 만족하기로 했다.
  • 라벨과 비슷한 스타일의 음악을 찾아보려고 드뷔시나 포레같은 사람들의 곡도 들어보는데, 다 좋긴 하지만 라벨만큼 빠져들진 않았다. 거슈윈의 랩소디 인 블루를 듣고 어라 라벨 피아노 협주곡하고 비슷하네 했는데 알고 보니 라벨이 랩소디 인 블루를 듣고 영향을 받아서 피아노 협주곡을 쓴 것 같더라. 근데 개인적으론 랩소딩 인 블루는 첫 1분정도 빼곤 별로 재미 없다. 라벨이 작품을 많이 안 쓴게 아쉽다.
  • 그 외에도 유명하고 인기있는 클래식 음악들을 들어보려고 주기적으로 시도하는데 성공률이 썩 높진 않다. 그래도 그 중 좋아하는 곡들은 슈만 피아노 협주곡이 좋아서 일주일정도 그 음악만 듣고 지냈던 것 같고, 드보르작 교향곡 8번 9번이 종종 생각나서 찾아 듣는다. 말러가 인기 있다기에 말러를 들어보려고 주기적으로 시도하는데 마음에 잘 들어오진 않는다. 그래도 말러 교향곡 1번은 몇 번 들었더니 처음 들었을 때 느껴지던 뭔가 모를 이질감은 없어진 것 같다. 더 듣다보면 말러를 좋아하게 될까? 옛날 음악가들의 곡들도 잘 듣게 되진 않는다. 모차르트나 그 이전의 바흐나 하이든같은 사람들의 곡은 특히 흥미가 생기지 않는다. 어릴때부터 여기 저기서 하도 많이 들어서 식상하게 느껴지기 때문일까? 다만 베토벤의 곡들은 지금 들어도 생명력이 느껴지고 현대적인 느낌이 든다. 악성같은 엄청난 별명이 붙은덴 이유가 있구나 싶기도 하다. 현대 음악에선 스트라빈스키, 프로코피예프, 쇼스타코비치 등을 들어보려고 계속 시도하는데 음악이 너무 현대적인 것인지(그렇다면 내가 너무 구식인 것인지?) 영 적응이 안된다. 특히 프로코피예프 피아노 협주곡 3번은 유튜브 뮤직의 추천으로 어쩌다 별 생각 없이 듣다가도 시끄러워서 헤드폰을 빼버리곤 한다. 스트라빈스키가 작곡가들이 뽑은 가장 영향력있는 작곡가라는 글을 본 뒤로 봄의 제전이나 불새를 종종 시도하는데, 불새는 들을때마다 궁예랑 클래식 공연에서 졸아선 안되는 이유 영상만 떠오른다. 그래도 계속 듣다 보면 나름의 질서와 매력이 있는 것 같기는 하다. 핑크 플로이드를 들을때랑 비슷한 느낌이랄까
• 근황
  • 올해 3월 마지막 날에 아버지가 돌아가셨다. 22년 말에 폐암 진단을 받으셨고 수술을 받으셨었는데, 작년 말에 재발해서 항암을 진행하고 있었는데, 4차 항암 이후 아마도 항암제 부작용으로 인한 것으로 보이는 폐렴으로 병원에 입원하시고 2주정도 입원해 계시다 돌아가셨다. 아빠는 이미 예전에도 심근경색으로 위험한 고비를 넘은 적이 있고, 그 뒤로도 담낭 제거수술을 할 때 심장이 약해서 생명에 지장이 생길 가능성이 있다는 이야기를 들은적도 있었고, 폐암을 진단받은 지도 1년 반이 넘었었기 때문에 아빠가 돌아가시는 상상은 옛날부터 종종 해왔다. 그런데 아빠가 돌아가시는게 그렇게 슬플지는 일을 당하기 전까진 미처 몰랐다. 임종하시기 며칠 전부터 병원을 오가며 한번씩 울컥하다가, 그 전날 밤부터는 거의 계속 울었던 것 같다. 3월 마지막 날은 부활절인 일요일이었는데, 새벽부터 산소포화도가 계속 떨어지고 어느 순간부터 내가 잡고 있던 아빠의 왼손이 점차 차가워지다 어느 순간 바이탈 모니터의 노란 경고등이 빨간색으로 바뀌었다. 장례를 치르는 동안 많은 분들이 도와주시고 위로해주셨다. 인생에 대해, 인간에 대해, 가족에 대해, 사랑에 대해, 믿음에 대해 다시금 생각해보게 되었다.
  • 나는 AI가 너무 무섭다. 사람들도 나와 같은 두려움을 느끼고 있을까? 별로 안 그런것 같아서 더 무섭다. 5가지 정도의 아이디어를 갖고 있고, 그 중 3편은 실제로 쓰고 있다. 웃긴건 이런 이야기를 쓰면서도 이걸 빠른 시간 안에 다 쓰지 못하면 기계가 더 나은 소설을 써버리고 말거라는 두려움을 갖고 있다는 점이다. 다행인건 아직은 소설을 챗GPT나 Claude에게 주고 뒤에 이어질 내용을 써보라고 하면 좀 어설프게 써온다는 사실이다. 아, 유료 구독을 안해서 그런건지도 모르겠지만, 그래도 아직은 소설 쓰기는 내가 조금은 나은 것 같다.
  • 이제는 회사를 다시 다니려고 구직 활동을 시작했다. 어떤 회사를 가는게 좋을까? 잘 모르겠다. 어떤 회사가 나를 받아줄 지도 잘 모르겠다. 다양한 경로로 연락해보고 사람들을 만나보고 해야 알 것 같다.