멋쟁이 사자처럼 13기 중앙 해커톤 회고

To be a Lazy Engineer

Keep (잘한 점)

열정

이번 중앙톤을 회고해보면, 생애 처음이라고 이야기해도 과언이 아닐 정도로 최선을 다했다. 순수히 개발만 집중하진 않았더라도, 개발을 해야겠다 생각하고 오전 11시에 앉아서 오전 1시가 다 되어서야 잠자리에 들고, 이런 나날의 반복이었다. 전혀 이 활동에 대해 지치지 않았고, 하나라도 더 빠르게 개발해서 프론트엔드 개발자 분들에게 빠르게 서버를 띄워주어야한다는 마음가짐으로 임했다.

신기술 도전

이번 프로젝트에서는 RAG라는 AI 기법과 벡터 임베딩, Flask 구조에 대해 얕게 시도해보았었다. 또, 타사의 API(Payment Gateway Service)를 우리 서비스에 적용시켜보고, 금융 서비스에 있어서 동시성 제어가 얼마나 중요한지를 다시금 느끼게 되었다. 결제에 성공한 경우, 환불한 경우, 결제를 취소한 경우 등에 있어서 데이터를 어떻게 다루어야 할지 조금 더 깊게 공부하고 싶은 마음이 들었다.

Docker with CD

지속적 배포(CD)에 대해 간략하게 배워보고, Docker Container는 어떠한 방식으로 동작되는가에 대해 조금 더 깊게 공부하게 되었다. http 요청만 받아들이는 Spring 프레임워크에서, 나의 개인 호스트에 대해 발급된 https 인증서를 통해 설정파일을 만들고, nginx 컨테이너에 이를 포함하여 올리는 등, 백엔드의 기술 구조 흐름에 대해 조금 더 잘 이해하게 된 것 같다.

Problem

Architecture

많은 프로젝트를 하진 않았다. 백엔드 개발을 시작한지 반년밖에 되지 않았고, 토이 프로젝트같은 느낌으로 현재까지 세개정도 구현했지만, 시간이 지나고 이 세번의 프로젝트를 거쳐 점점 악취를 느끼기 시작했다.

1. 계층형 구조의 한계

   계층형 아키텍처를 채용해서 사용하고 있었는데, 제공하려 하는 서비스가 많아지면 많아질 수록, 도메인 간 의존 결합이 너무 강해졌다. 타 도메인의 엔터티, JPA Repository를 끌어와서 DI한다던가가 대표적이었다. 도메인은 순수해야 하며, 의존 관계를 알게되는 순간, 클린한 아키텍처가 아니라는 생각이 이제 와서 들기 시작했다.

   → 해결방안 - 비슷한 고민을 우아한 형제들의 개발자님들께서도 하신 것 같다.

   • Hexagonal Architecture - 서비스 로직을 중심으로 의존하는 관계라 한다… 클린 아키텍처의 종류중 하나라고 하는데 공부해야 할 것이 생겨서 기분이 좋다.
     

2. Bean과 Singleton 패턴의 이해

   타 컨테이너나, 로컬의 API 서버(우리가 사용했던 것은 Flask.)와 통신하기 위한 RestTemplate, WebClient 등을 고려하다가 발생한 고민이다. 서비스에서 해당 객체를 호출하여 하드코딩하는 것은 해당 서비스 로직에서도 책임이 비대해지고 단순하게 생각해서도 그렇게 하면 안되리라는 막연한 고민이 들었었다. 이 생각에서 조금 더 나아간 생각이 그럼 결국 Bean, Configure, Singleton 이런 것들은 ‘어떤 상황에 사용되면 좋은가?’에 대해 생각이 들었다. 지금 상황에서는 Configure로 의존을 통합 관리하고, 여러 군데에서 사용되는 함수는 Bean 등록하여 Singleton을 적용해야 한다. 라는 앵무새와 같은 말만 읊고 있지만, 실제 서비스에서 적용해보아야 할 것 같다.

   → 전략, 패턴에 대한 이해와 상황에 맞는 사용 경험이 필요

3. 지속적 통합과 구조 이해

   프로젝트를 진행하면서, 어쩔 수 없이 개발자는 다른 개발자들의 코드를 읽고 이해해야 하는 능력이 필수 라고 느꼈다. 이유는 단순하다. 내가 그 로직들을 사용을 안할 리가 없지 않은가. 그런 관점에서 보았을 때, “문서화”라는 것과 그것을 이해하는 능력이 필요하다고 여실히 느꼈다. 그리고, 여러 오픈 소스들을 공부하려고 프로젝트들을 뒤져보았지만, 정말 단순한 내용이거나 너무 복잡한 내용이어서 이해하기 어려웠을 때, 참고하기 좋은 자료가 TestCase라고 했다. Test는 구현을 알 필요 없이, 서비스의 흐름만을 명시적으로 적어 제대로 흘러가고 있는지를 체크하기 위함이라 생각한다. 여기서 지속적 통합과 TDD(Test-Driven Development)라는 말이 뇌리를 스쳤다. 현재까지는 그저 스파게티 코드여도 제대로 된 응답만 출력할 수 있다면 괜찮다고 생각했지만, 이제는 속도와 유지보수에 대해 더욱 신경을 써야 할 시기라고 생각이 들었다.

   → Test 케이스 작성과 CI 환경 구성 및 세세한 코드 리뷰(여기서는 비즈니스 흐름을 도식화 해보는 것이 좋을 것 같다.)가 필요할 것 같다.

4. co-work에서의 문제점 발견 방식

   현재까지는 프론트엔드 개발자분들께서 친절하게도 OOO 부분에서 XXX 예외(보통은 Internal Server Error, 예외처리 되지 않았는데 발생된 예외이다.)가 발생했는데, 확인 한번 부탁드려요. 라고 말씀을 주시면, “직접 ssh로 접속해 Docker Container 로그를 조회했다.” 생각만 해도 악취가 진동한다. 지금 하고 있는 프로젝트에 적용해보고 있는 기술이긴 하지만, Promtail-loki with Grafana를 통해서 서버에 있는 Docker Container의 로그 파일을 추적, 모니터링 서버에 있는 loki container에 전달한다. 그리고 Grafana에서 loki를 DataSource로 등록하여, Error라는 메세지를 라벨링 후 알림을 전송하는 방식으로 드디어 마침내 프론트엔드분들이 직접 예외를 전달하는 수고를 해결할 수 있었다.(이 과정에서 오랜 기간동안 발생하는 Log 파일들을 주기적으로 날리는 작업도 같이 했다.) 이후 조금 더 공부해보아야 할 항목이다.

Try

이번 해커톤에서 가장 아쉬웠던 점은 뭐니뭐니 해도 코드 완성도에 관한 부분인 것 같다. 사용할 수 있는 기술의 유니크함들도 다소 아쉬운 점은 있었으나, In My Best였다고 생각한다. 하지만, 여러 관점에서 나와 함께한 팀원의 코드는 여전히 유지보수가 어렵고, Dirty Architecture라고 해도 무방했다.(그래서 1차 AI 예선에서도 탈락한… 것 같다 죄송스럽다.) 목표는 우선 SOLID한 설계이다. 프로젝트를 진행하면서도 항상 내 코드는 SOLID하지 않은 것 같다는 말을 입에 달고 산 만큼, 다음 프로젝트를 진행하게 된다면 이것이 1순위이다. 직접 코드를 일일이 리뷰하지 않아도 확인할 수 있게끔 문서화하는 작업과, TestCase를 유연하게 작성해두는 것(모든 마이크로 서비스에 테스트를 적용하는 것도 굉장한 손해이다.) 그리고 기술 의존적이지 않게끔 하기 위한 설정이다(Hexagonal Arch 등).