프로젝트를 처음 마무리하며

지난 4월 초부터 약 3달 정도 매진했던 Data Processing 플랫폼 개발을 마무리하게 됐습니다. 남은 이슈 몇 가지가 정리되고 나면 아마 기존에 하고 있었던 사내 CI/CD 플랫폼 관련 개발을 다시 시작하게 될 것 같습니다.

돌이켜보면, 회사를 다니며 이런 저런 프로젝트를 진행하고 개발해왔지만, 프로젝트를 완전히 마무리하는 것은 처음인 것 같아 3달 동안의 경험을 통해 느낀 점을 글로 써볼까 합니다. 아무래도 회사 일이기 때문에 구체적인 프로젝트의 명세를 자세히 설명하지 못해 다소 추상적인 글이 될 수 있겠습니다만, 그래도 최대한 제가 느낀 바를 글에 잘 담아내 보도록 노력해보겠습니다.

Mind the Gap

런던 지하철을 타게 되면, 승강장 바닥과 안내방송에서 가장 많이 접하게 되는 문장입니다. 한국어로 번역하면 승강장과 열차 사이의 틈을 조심하라는 내용입니다. 동시에 지난주 데모 시연이 끝나고 오늘 이 글을 쓰는 순간까지 계속 제 마음속을 맴돌고 있는 말입니다.

큰 틀에서 이번 프로젝트의 주된 목적은 특정 유저의 로깅 파이프라인을 개선하는 일이었습니다. 명확한 유저가 있었기 때문에 그들의 문제를 진단하고 해결하는 것에만 집중하면 잘 끝낼 수 있는 작업이었습니다. 결론부터 말하자면 현행 아키텍처를 유지하기로 했습니다. 이러한 의사결정의 배경에는 이런저런 이유가 있겠지만, 가장 큰 이유는 제가 느끼는 문제와 유저가 느끼는 문제 사이에 “갭”이 있었던 것이 아닐까 생각합니다.

저는 데이터 가공 자체에 초점을 맞추고 기존 아키텍처의 안정성, 확장성, 성능 등을 개선하는 것을 최우선 과제로 보았습니다. 반면 유저는 데이터 파이프라인의 안정성은 어느 정도 확보됐다고 보고, 알람이나 분석처럼 가공된 데이터를 활용하는 부분에 더 관심이 있었습니다. 저 또한 이 관심 자체는 인지하고 있었으나 이를 과소평가하고 오히려 서로 데이터 가공 방식 변경의 필요성에 대해 유저가 저만큼 공감했다고 착각했습니다. 그 결과 데이터 가공 단계를 먼저 수정하고 변경된 인터페이스에 맞춰 Reactor나 모니터링 툴 등을 변경해야 한다는 생각을 가지고 프로젝트를 진행하게 됐습니다. 이번 데모 시연도 개발한 플랫폼을 이용해 데이터를 가공하는 방법이 주를 이뤘습니다.

그러나 이 결과물은 유저가 원하던 바와 다소 갭이 있었습니다. 익숙해졌던 기존 스택을 버려야 한다는 것은 유저에게 있어 불편함입니다. 그런 불편한 변화를 유저에게 설득하기 위해서는 합리적인 이유와 매력적인 포인트가 모두 필요했습니다. 그러나 저희의 새로운 플랫폼은 유저의 문제의식과 먼 곳을 지향하며 만들어졌고, 따라서 불편함을 감수할 만큼 매력적이지 않았습니다.

개발자와 유저는 엄연히 다른 배경지식을 갖고 있습니다. 편하고 불편한 것도 각자 체감하는 바가 다릅니다. 따라서 이 갭을 좁히기 위해 유저와 자주 소통하고, 가끔은 스스로 유저의 입장이 되어보며 공감할 줄 알아야 했습니다. 그러나 돌이켜보면 과연 스스로 저와 유저 사이에 갭이 있다는 것을 되새기고 있었느냐는 질문에 선뜻 당당해지기 어렵습니다. 오히려 유저보다는 문제를 어떻게 해결할지에만 집중했고, 이를 다 해결할 즈음 저도 모르는 사이에 유저와의 갭은 더 벌어져 있었습니다.

Tech Stack

아쉬운 일이 있었지만, 기술적으로만 본다면 지난 3개월은 어렴풋이 알고만 있었던 데이터 엔지니어링 관련 기술 스택을 깊이 있게 경험해볼 수 있었던 즐거운 시간이었습니다. 그중에서도 Apache Kafka는 꼭 대규모 파이프라인을 구축할 때가 아니더라도 이곳저곳에서 (예를 들어, 현재 사용하고 있는 ElasticSearch의 부하를 조절하기 위해서 Logging agent와 ES 중간에 둔다든가) 유용하게 쓸 수 있을 것 같습니다.

이번 3달 동안 가장 열심히 파고든 것은 아무래도 Apache Flink인데, 성능도 훌륭하고 Job을 만드는 것도 어렵지 않고, Cluster를 운영하는 비용도 많지 않아 다음에 비슷한 니즈가 생기면 꼭 다시 쓰고 싶습니다. Micro-batch가 아닌 진정한 의미의 Streaming이라는 점이나 Checkpoint를 통한 Fault tolerance와 Exactly once 보장 등은 정말 매력적이라고 생각합니다.

리서치 단계에서 스쳐 지나간 것들도 많았습니다. 별도의 실행 프레임워크 없이 사용할 수 있어 관리 부담이 적었던 Kafka Streams와 ksqlDB, Flink보다 생태계가 좀 더 풍성한 Apache Spark, 성능은 조금 부족하지만 toml 중심의 편리한 인터페이스와 다양한 데이터 Source 및 Sink를 지원하는 Vector. 요구 사항에 따라 모두 고려해볼 만한 스택입니다.

끝으로 데이터 엔지니어링과는 상관없지만, 이번에 Kotlin을 통해 처음으로 JVM 생태계를 프로덕션 레벨로 경험하게 됐는데, 이 과정에서 Gradle, Nexus를 이용해 빌드 / 배포를 관리해보았습니다. 향후에 이 경험이 CI/CD 플랫폼 개발에 도움이 되지 않을까 기대해봅니다.

마치며

초반에 서술했던 것처럼 아쉽게도 유저의 니즈를 만족시키는 것에는 실패해 초기의 목적을 달성하지는 못했습니다. 대신 기존에 목표로 하던 높은 수준의 성능, 사용성, 안정성은 모두 확보했기 때문에 이 플랫폼은 팀 내에서 사용하던 다른 데이터 파이프라인을 대체하기 위해 사용될 예정입니다.

이번 실패를 딛고 항상 개발자와 유저 사이의 간극에 유념하며 다음번에는 꼭 “쓰고 싶은” 매력적인 제품을 만들고 싶습니다.