2022년 회고, 개발자 편

거창하게 적으려고 하면 잘 안 써지니깐 두서없이 생각나는 이벤트 위주로 적어보자.

 

Kotlin

여름부터 신규 프로젝트에 투입되었다. 개인적으로 Kotlin을 책, 튜토리얼 등으로 조금씩 써보고 있었는데 이번 신규 프로젝트의 API 서버는 Kotlin과 Spring을 써보자고 제안했다. 여전히 Spring을 베이스로 사용하고 있는 곳은 대부분 Java를 사용하고 있다. 최대한 안전한 선택을 한다면 나 또한 Java를 고를 것이다. Spring Framework는 Java로 만들어진 언어고, 아무리 Spring 진영에서 Kotlin 지원을 해준다고 하지만 100%의 호환성을 장담할 수 없기 때문이다. 레퍼런스도 상대적으로 적은 것도 한몫한다. 하지만 지금 시점에서 Kopring(Kotlin + Spring)은 여러 회사들의 실제 도입과 다양한 기술 공유로 인해 어느 정도 검증이 되었다고 판단했다. 그래서 제안했고 감사하게도 팀원 모두 긍정적인 반응을 주셨다.

 

어떻게 보면 Kopring은 Java, Spring을 주 기술 스택으로 가지고 있는 팀이 선택할 수 있는 현실적인 타협안이라고 생각한다. 모두가 새로운 기술에 흥미는 있다. 하지만 개인 프로젝트가 아닌, 돈이 오고 가는 실 서비스에 상대적으로 숙련도가 낮은 기술을 선택하고 사용하는 것은 여러모로 부담이 있다. 이 부담을 느끼는 정도도 각 구성원의 역할에 따라 다를 것이다. 특히 책임을 져야 하는 자리에 계신 분이라면 더더욱 그럴 것이다.

 

Kopring을 이용한 Reactive Application을 가져가는 것이 최초의 목표였으나 Reactive Application 쪽은 다른 Application에 적용할 때 사용하는 것으로 정리되었다. 우선 프로젝트의 모든 시스템을 밑바닥부터 디자인하고 만드는 것이 아니었다. 기존에 잘 사용하고 있는 인프라, DBMS를 이용하는 것은 합리적일 뿐만 아니라 당연한 선택이다. 이 과정에서 MySQL과 R2DBC에 대한 POC를 진행했는데 MySQL R2DBC connector는 MySQL 진영에서 공식적으로 관리하는 것이 아닌 개인 유저가 R2DBC 스펙을 구현해 관리하는 3rd Party 라이브리라는 것이 발목을 잡았다. 또 타 팀, 조직의 프로젝트 코드를 분석하면서 R2DBC 도입에 대해서 안정적이지 못하다는 판단이 들었고 이것을 공유했다. DB만 동기 I/O로 사용하면 Reactive Application이라는 의미가 퇴색되고, 그렇다고 R2DBC connector를 공식 진영에서 관리하는 타 RDBMS 혹은 NoSQL을 새로 도입하는 것은 과감, 도전적이 아닌 무모한 판단이라는 생각이 들었다. 팀의 제한된 리소스와 잦은 요구사항의 변경 등 외부 요인들을 함께 고려하면서 이 모든 것을 기술적 역량을 끌어올리면서 함께 진행하는 것은 현실적으로 어렵다는 판단을 했고, 우선 Kotlin과 Spring, JPA를 가져가는 것으로 정리되었다.

 

하지만 이는 올바른 판단이었다고 생각한다. 실제로 Kotlin을 도입하는 것만으로도 굉장히 다양한 Agenda들이 만들어졌고 관련해서 유익한 기술적 논의가 이뤄졌다. 결과적으로 현재 Kotlin 코드를 그럭저럭 읽고 작성할 수 있게 되었다. 느낀 점이 있다면 새로운 기술을 도입하기 전에는 그 기술에 대한 POC가 개인이 아닌 팀 레벨에서 이뤄지는 것이 이상적이고 이를 위한 시간을 확보하는 것이 필요하다는 것과 이번에 못해본 것은 다음에 하면 된다 정도?...

 

Kubernetes & Logging 시스템

최근에 K8S를 사용해보고 있다. 기초적인 컨셉만 이해한 상태에서 많은 레퍼런스와 구글링을 통해서 어찌어찌 yaml도 만들고, Heml 차트도 만들면서 프로젝트에서 사용할 스크립트를 만들었다. K8S가 편하다는 말이 인제야 공감이 된다. 지금도 완전 자동화가 되어있진 않은데도 배포 작업이 정말 편하다.

K8S 환경도 마찬가지로 Logging 시스템이 필요했다. 기존 Legacy 환경에서 사용하고 있는 ELK와 K8S 클러스터의 File beat을 Daemonset으로 올리고 이를 연동해서 기존과 동일한 환경에서 로그를 확인할 수 있는 파이프라인을 구축했다. 구축이라고 그럴싸하게 표현했지만, 로그 수집해서 시각화하는 작업을 한 것이라 난도가 높은 작업은 아니었다.

 

다만 처음 하는 작업이다 보니 생각보다 삽질을 많이 했다. 보통 config 파일에서 특정 block이나 반드시 선언해야 하는 문구가 빠지면 인프라 애플리케이션이 기동되지 않아야 정상이라고 생각했는데 이쪽 도구들이 다 그런진 모르겠지만 굉장히(쓸데없이) 융통성이 있어서 분명히 말도 안 되는 설정인데도 그냥 애플리케이션이 올라가서 초록불이 떴다. 그러다 보니 설정에 문제가 있을 거라는 생각하지 못하고 이곳저곳을 헤맸다.

다만 이런 과정을 통해 프로젝트 전반에 구성된 로깅 시스템과 ELK 시스템에 대해서 자연스럽게 익힐 수 있었다. 특히 기존 Legacy에서 사용하던 indexing rule이나 naming, 그리고 설정값을 동일하게 가져가야 했었고, 도구 하나하나 깊이 있게 공부했다고는 못하지만 자주 사용하는 환경 설정값이나 시스템 디자인, 기초적인 트러블슈팅 정도는 알게 되었다. 구축한 Kibana 대시보드도 잘 사용하고 있고….

 

스터디

올해는 회사 내에서 진행하는 스터디를 많이 참석, 진행했다.

블록체인 인 액션(Blockchain in Action)

팀 레벨에선 블록체인 스터디를 진행했다. 교재를 가지고 실제로 Solidity로 코드를 작성하고 Smart Contract를 배포하는 등의 실습을 했다. 이 스터디로 블록체인을 이해했다고 하면 거짓말이지만 그래도 블록체인, 암호화폐가 어떤 식으로 구현되어 사용하는지의 느낌(?) 정도는 알게 되었다.

 

그 외에는 독서 스터디를 진행했다. 회사 동기들과 좋은 책을 선정해서 고정된 시간에 함께 읽고 관련 내용에 대해 논의하는 그런 형식의 스터디를 시작해서 진행했고 현재 6회 차가 진행 중이고 읽은 책은 모두 포스트로 남겼다. 동기들과의 커뮤니케이션이 아쉬웠는데 이런 스터디를 통해서 자연스럽게 교류도 하고 기술적 이야기도 나누고 해서 굉장히 만족한다. 어느 정도 지나니깐 계속 스터디를 하는 고정 멤버(?)만 남은 상태라 서로 꽤 친해졌다는 것도 긍정적인 포인트.

 

외부 행사 참석

인프콘, MongoDB 2022 Seoul을 참석했다.

인프콘 2022 후기

개인적으로 인프콘 시기에 약간 지쳐있었는데 운 좋게 참석할 수 있는 기회를 얻어서 다녀왔고 좋은 리프레시가 되었다. 2023년에는 더 많은 오프라인 콘퍼런스가 열릴 것 같은데 기회가 생긴다면 참석해서 리프레시와 인사이트를 얻는 기회로 삼는 것도 좋을 것 같다.

 

사이드 프로젝트

Why Not Here

이전 회사 동료가 진행하는 사이드 프로젝트의 리뷰어로 참석했다. 내가 가진 리소스, 그리고 주제를 고려해보았을 때 개발에 직접적으로 참여하긴 어려울 것으로 판단해서 거절했으나 리뷰어 정도만 해주셔도 괜찮다는 제안을 받고 합류했다. 다른 사람의 코드를 읽으면서 배우는 것이 있다고 생각해서 리뷰어 정도면 괜찮겠다 싶었다. 사실 프로젝트의 코드 퀄리티만 보았을 때는 내가 생각한 방향대로 흘러가진 않았다. 하지만 이것이 빠르게 MVP를 만들고 커뮤니케이션하는 과정이라고 생각했고 코드 작성자에게 의미 있을만한, 실제로 적용하실 것 같은 부분에 대해서만 리뷰를 했다.

 

중간에 위기가 있었지만 신규 FE 개발자와 디자이너까지 합류했다. 이후 코드 리뷰어에서 프로젝트 리뷰어, QA 역할도 하면서 UI, 기능, 일정 관련 의사결정에도 참가했다. 특히 의사결정을 나름의 근거를 바탕으로 진행했고 이를 위해 디자이너, 개발자 구분 없이 다양한 레퍼런스를 조사하고 이를 공유했다. 그리고 어떤 주장을 할 때 모두가 다른 구성원을 설득하려고 노력했다. 그리고 정해진 부분은 빠르게 진행하고 그 과정에서 문제가 발생하면 공유 후 함께 수정해나갔다. 이런 협업 경험이 굉장히 즐거웠고 결국 큰 문제없이 런칭했다.

 

런칭 후 홍보를 통해 유의미한 사용자와 데이터를 얻고 있고 이와 관련해서 협업도 들어왔다. 타깃 고객이 불특정 다수가 아닌 특정 그룹으로 포커스를 맞췄기 때문에 얻을 수 있는 결과였지 않았나라고 생각한다. 이후 계속 이 프로젝트에 참여할지는 아직 정해지지 않았지만 굉장히 유익한, 의미 있는 경험이었다. 재밌었다.

 

오픈소스

작지만 몇 가지 오픈소스에 기여했다. 따로 오픈소스 기여를 하기 위해서 돌아다닌 것이 아닌 업무를 하면서 자연스럽게 할 수 있던 점이 좋았다.  대부분 이슈, 버그 리포팅이었지만 영향도가 비교적 큰 내용도 있었다.

• jpmml/jpmml-evaluator (https://github.com/jpmml/jpmml-evaluator/issues/246)  
• jmfayard/refreshVersions (https://github.com/jmfayard/refreshVersions/pull/545)  
• jmfayard/refreshVersions (https://github.com/jmfayard/refreshVersions/pull/617)
• springdoc/springdoc-openapi (https://github.com/springdoc/springdoc-openapi/issues/1820)
• eugenp/tutorial(Baeldung) (https://github.com/eugenp/tutorials/pull/12110)
• docker/for-mac (https://github.com/docker/for-mac/issues/6289)

최근에 팀원 분이 회사 Organization에 오픈소스 프로젝트를 등록하셨다. 이 프로젝트의 콘셉트가 되는 것을 함께 업무에서 개발 및 적용했었는데 콘셉트는 그대로 가져가면서 코드를 개선하고 준비해서 런칭하셨다. 그래서 나도 프로젝트 런칭 후 작지만 오픈소스 기여를 했다. JVM 기반 프로젝트였는데 요즘 많은 오픈소스들이 Kotlin 지원을 위한 별도 모듈도 함께 관리하는 추세라 Kotlin 지원 모듈 추가를 제안했고, 이 모듈에 Kotlin에서 사용할 수 있는 infix function을 추가했다.

 

Implement infix function by doljae · Pull Request #4 · line/conditional

 

따로 오픈소스 기여를 하기 위해서 돌아다닌 것이 아닌 업무를 하면서 자연스럽게 할 수 있던 점이 좋았다. 또 오픈소스 기여를 했다는 것도 좋은 일이지만 내가 오픈소스 기여를 할 정도로 해당 프로젝트에 대해 꼼꼼하게 혹은 깊은 부분까지 보았다는 점이 더 큰 의미가 있지 않나 싶다.

 

목표

주니어 병장(?) 정도의 연차가 되었다. 작년보다 조금 더 기술적 신뢰감을 줄 수 있는 그런 팀원이 되고 싶다.

 

정리

엄청나게 자랑할만한 것은 없는 것 같지만, 그래도 이렇게 적고 보니깐 그럭저럭 나쁘지 않게 보낸 것 같다. 올해도 조바심 내지 말고 차근차근 쌓아가는, 그런 한 해가 되길 바란다.