[Avro4K] 야호 나도 Avro4K 컨트리뷰터!

https://github.com/avro-kotlin/avro4k/issues/425

Add Field Naming Strategy Support to Gradle Plugin · Issue #425 · avro-kotlin/avro4k

 

링크드인만 올리고 여기는 안올리고 있었네.

현재 회사에서는 AWS Glue를 Schema Registry로 사용하고 있다.
여기서, 빌드 단계에서 Java/Kotlin 클래스를 생성하기 위하여 davidmc24를 보통 사용하는데, Rest DTO로 바로 사용하기에 좀 heavy 해서 avro4k도 같이 사용함.

avro4k만 사용해도 사실 되긴한데, 이 기능이 나온지 (회사에서 도입할때에는) 얼마 안되서, kafka 용으로는 사용하지 않고 있는 중.

무튼 이걸 섞어서 쓰다보면 좀 거슬리는 지점이 있었는데,
davidmc24 쪽은 Java 클래스를 생성하다보니 Kotlin에서 getter/setter 자동 프로퍼티화가 돼서 대충 camelCase처럼 보인다.
근데 avro4k는 스키마에 정의된 필드명을 거의 그대로 Kotlin 클래스에 생성해버려서,
필드명이 snake_case로 되어 있으면 Kotlin 코드에서도 그걸 그대로 snake_case로 써야했다.

요것이 아주 거슬려서(...)
Kotlin 코드에서 모델 프로퍼티를 계속 snake_case로 다루는게 아무래도 좀 덜 자연스럽기도 하고,
코드 읽을때도 은근 흐름이 끊김.

그래서 작년 12월쯤 avro4k에 이슈를 하나 올렸고,
.avsc 스키마 파일을 읽어서 Kotlin 클래스를 생성하는 Gradle Plugin 쪽에
field naming strategy를 추가하는 방향으로 얘기를 꺼냈다.
쉽게 말하면, 스키마에는 snake_case로 정의돼 있어도
생성되는 Kotlin 클래스에서는 camelCase로 바꿔서 쓸 수 있게 하자는 거였다.

기능 자체만 보면 엄청 큰건 아닌데, 근데 최종 머지까지 거의 한달 가까이 걸렸고, 개인적으로는 되게 재밌는 경험이었다.

무수히 많은 리뷰와 커밋

이번에는 메인테이너랑 진짜 밀도 있게 얘기를 많이 했다.

단순히 기능 하나 넣고 끝이 아니라, 이 옵션을 유저가 어떻게 설정하는게 제일 직관적인지, DX 관점에서 어떤지,
generator core 쪽이랑은 어떻게 결합되는게 제일 깔끔한지, 기존 라이브러리 철학을 안 깨면서도 확장 가능하게 가려면 어디까지 열어야 하는지 이런걸 계속 왔다갔다 하면서 맞춰갔다.


이런게 재밌는 것 같다.
그냥 "내가 필요한 기능 넣었다" 로 끝나는게 아니라,
좋은 UX 가 뭐고, 유지보수하기 좋은 구조가 뭔지,
유저 입장에서 덜 헷갈리는 옵션 명이 뭔지,

요즘 AI니 바이브 코딩이니 그런 얘기 많이 나오는데, 그래도 결국 개발 철학이나 기본기는 어디 안가는 것 같음.
이런 얘기들은 결국 사람이랑 사람이 계속 맞춰가야 하는 영역이라서.

전세계 어디 사는지도 모르는 개발자랑 GitHub에서 한달 가까이 코멘트 주고받으면서
조금 더 나은 방향을 같이 찾아가는 과정이 꽤 즐거웠다.
기능 하나 추가한 것도 좋았지만,
좋은 코드를 두고 진지하게 얘기하는 시간이 더 기억에 남는 기여였던 것 같음.