blip.jpg

때는 8월 26일, Challenges 프로그램이 끝나갈 무렵이었습니다. 데브옵스 관련 PR을 끝내고 다음 이슈를 찾던 중, 멘토님께서 저에게 SQL의 CASE 구문을 구현하는 이슈를 주셨습니다. 당시 원래 진행하던 분이 계셨는데 잠시 중단한 상태였습니다. 나름 여러가지 PR을 1달동안 진행해본 터라 자신감 넘치는 타노스 짤을 쓰면서 그 이슈를 Get 해버렸습니다... 앞으로의 고단한 여정은 예상도 못한 채 말이죠. 9월 초 쯤에 간단한 문법들을 사용하여 기능 구현은 완료 했습니다. 그 때 당시에는 CASE 구문의 디테일을 잘 몰랐던 터라 간단한 테스트들은 통과했지만 결과값의 자료형 일치, 구문마다 evaluate 여부를 따지는 로직... 등등 더 신경 쓸게 많다는 것을 멘토님의 리뷰를 통해 알고 차차 코드를 고쳐나갔습니다. 또한 GlueSQL에서 아주아주 중요히 여기는 “no unwrap()”, “no clone()”, “no mutable” 의 엄격한 철칙들을 지키면서 코드를 고쳐나가다 보니 9월 말 즈음 정확히 기능은 같지만 코드는 크고 아름다운(?) 100줄 정도가 되어 있었습니다. 그 100 줄의 코드 속에는 Rust 언어의 다양한 함수형 프로그래밍 기법들, 소유권 개념을 잘 활용하여 deep copy 없이 쓰여진 구문들 등... 지금 다시보다 너무 감격스러운 코드였습니다. 그렇게 몇가지만 더 고치면 끝나가려던 찰나, Maintainer 이신 멘토님께서는 GlueSQL의 확장성을 위해 과감하게 다양한 API에서 Row 마다의 자료형 체크를 하지 않기로 결정하셨습니다. 그 말인 즉슨, 저에게는 다시 9월 초에 작성했던 코드(보다 심지어 덜 엄격하게)로 돌아가면 된다는 말이였습니다. 그렇게 기준을 맞춰서 다시 코드를 짜보니... 100줄이었던 것이 22줄이 되었습니다! 아까 제가 자랑했던 그 Rust의 다양한 아름다움을 보여주던 코드는 아쉽게도 다소 컴팩트하고 노멀하게 바뀌었죠. 이렇게 결국 Merge가 되기까지 약 1달 반이 걸렸습니다 ㅎㅎ 이슈: https://github.com/gluesql/gluesql/issues/140PR: https://github.com/gluesql/gluesql/pull/330