[사이드 프로젝트] 데이터 엔지니어의 백엔드 생존기

들어가며

직무 리셋

 

- 올해 3월부터 데이터 조직 -> 서비스 조직으로 팀 이동을 하면서 elasticsearch(이하 ES)를 이용해 검색 엔진을 개발하는 신규 프로젝트를 맡게 되었다. ES와 데이터 파이프라인, API 서버(Java, Spring boot)를 구성해야만 했다.

- 분석 2년, 엔지니어링 1년 반 정도 업무를 진행한 입장에서 검색 엔진 용도의 ES는 물론이고 Java는 자료구조 수업에서만 써봤기에 다시 신입으로 돌아간 기분이었다. (웬만한 신입은 Spring에 능숙한 상태로 들어올 듯)

- 백엔드 개발에 빠르게 익숙해지기 위해 마침 사내에서 지원해 주는 TDD, 클린코드 with Java 교육을 무작정 수강했다.

- 2개월 정도 교육이 진행됐는데, 솔직히 따라가기 힘들었다. Java와 백엔드를 전혀 모르는데 클린코드라니.. TDD라니.. 리팩토링이라니..

- 어쨌든 교육이 끝날 즈음에 Spring 강의도 정말 기초만 들었는데, 강의만 듣는 건 내 스타일이 아니라서 실습 목적으로 비사이드를 통해 사이드 프로젝트를 시작했다.

 

사이드 프로젝트 진행기

- 비사이드에서는 돈을 내면 사이드 프로젝트를 위한 현직자 매칭과 관리를 도와준다. 총 8명으로 한 팀이 구성되는데, 기획/디자인/프론트엔드/백엔드 2명씩 구성되고 이 중 한 명이 PM 역할을 맡게 된다.

- 나는 당연히 백엔드에 익숙해지고자 시작했기 때문에 백엔드로 지원했다. 데이터 엔지니어가 백엔드로 지원한 케이스는 내가 처음이라고 하더라~

- 비사이드를 시작할 때쯤 7월 초였는데, 검색엔진이 어느정도 구성돼서 Spring으로 API 서버까지 간단하게 구성된 상태였기에 크게 다르지 않을 줄 알았다.

- 근데 서비스 백엔드와 ES를 중계해주는 API 서버는 완전히 달랐다.

- 회원가입, 로그인, DB(JPA, QueryDSL 등), 동시성 등 신경 쓸 부분이 전혀 달랐다. 우리 팀의 프론트는 안드로이드 앱이었기 때문에 안드로이드를 전혀 몰라서 헤맸던 부분들도 많았다.

- 이 사이드 프로젝트를 진행하면서 배웠던 부분들을 기록해본다.

 

구현

GPT와 함께라면 내 일자리 말고는 두려울 것이 없다.

 

- GPT4와 코파일럿만 있으면 구현에서는 두려울 게 없다. 거짓말도 하고, 로직이 이상할 때는 있어도 그것만 잘 다루면 구현이 이전보다 훨씬 쉬워졌다.

- 실제로 나는 카카오 로그인, OAuth, JWT토큰, JPA, QueryDSL, 타임리프 같은 것들을 하나도 모르는 상태로 시작했다. 하지만 GPT와 코파일럿을 쓰면서 구현에 큰 어려움이 없었다.

- 이런 LLM 친구들도 잘 쓰는 것이 중요한 것 같다. 특히 GPT는 GPT3.5와 4의 차이가 디테일로 들어갈수록 크고, 코파일럿은 익숙해져야 효용성 체감이 확실히 된다. 예를 들어 코파일럿을 사용하게 되면 구현 -> 주석이 아니라 주석 -> 구현 순서로 해보자. 단순한 구현에서 내가 할 일은 주석을 쓴 뒤 tab 누르는 것밖에 없어진다.

- 얼마 전, 본가로 가는 기차에서 코딩을 하다가 인터넷이 끊겼는데 GPT와 코파일럿이 멈추자 내 세상도 함께 멈췄다. 얼마나 내가 여기에 의존했는지 느낄 수 있었고 GPT 6~7쯤 되면 내 일자리를 지키기 위해 러다이트 운동 밖에 남은 길이 없을 것 같다.

 

테스트 코드

 

- 테스트 코드의 중요성을 정말 뼈저리게 느꼈다.

- 초기에 Spring을 잘 모르니 테스트 코드를 어떻게 짜야할지 모르겠더라. 그래서 결국 TDD를 배웠지만 사이드 프로젝트에서는 테스트 코드를 하나도 안 짰다.

- 근데 코드가 복잡해질수록 테스트 코드 없이 뭐가 뻑날지 모르는 채 불안감을 가지고 배포하고, 배포한 뒤에 프론트엔드 분들에 의해 버그가 발견되는 일이 반복됐다.

- 그래서 기능 개발/수정할 때마다 직접 Postman으로 하나씩 콜을 날려보면서 배포하는데, 이 시간이 테스트 코드를 짜는 시간보다 길었을 것 같다. 그리고 기능 개발에 대한 부담감이 점점 더 커진다.

- 실제 업무에서는 최대한 테스트코드를 자세히 작성해서 테스트 커버리지가 90% 정도인데, 훨씬 큰 프로젝트인데도 기능 개발에 훨씬 부담이 덜했다.

- 테스트 코드 작성이 오래 걸리는 건 맞다. 기능 개발보다 테스트 코드 짜는 게 더 오래 걸리는 것도 흔한 것 같다. 그런데 테스트 코드는 꼭 짜면서 개발하자. 개발하는 도메인에 대한 이해도가 높다면 TDD를 적용해 보자.

- TDD 교육에서는 도메인에 익숙하지 않다면 개발한 후에 개발한 코드를 날려버리고 TDD로 다시 짜보는 것도 좋다고 했다. 듣기엔 이게 무슨 소리인가 싶지만 한 번 해보니 개발 시간이 처음에 비해 반 이하로 줄어들고 코드가 깔끔해지는 것을 경험해 봤다. (시간이 부족한데 하진 말자.)

 

개발 원칙

 

- 백엔드 개발을 공부하면서 여러 원칙을 배웠다.

- TDD, DDD, 디자인 패턴, SOLID, 소프트웨어 개발 3대 원칙, 클린코드 등 많은 개발 원칙들을 다 신경 쓰다 보니 개발을 못 하겠더라. 

- 개발 원칙을 다 지키려다 보니 테스트 코드를 짜는 것이 너무 어려워졌다. 예를 들어 테스트 코드가 기능 구현에 영향을 주지 않기 위해 클래스 접근자를 private -> protected로 안 바꾸고 테스트 코드를 짜려고 하니 리플렉션을 쓰는 등 너무 어려워졌다.

- 그리고 세터를 하나도 안 쓰려니 코드가 더 더러워졌다. 세터를 안 쓰는 이유는 단순 setter는 비즈니스 로직의 의도가 드러나지 않는 문제와 일관성 유지에 대한 문제 때문인데 DTO에도 세터를 안 쓰는 것이 중요한가? 이 부분에 대해서 개인적으로는 아니라고 생각했다.

- 이런 것처럼 개발 원칙을 다 따르는 게 중요하다기보다는, 그 의도를 이해하고 내 주관을 가지고 적절히 적용하는 것이 중요하다는 생각이 들었다.

 

인프라

- 비사이드에서 NCP(Naver Cloud Platform)와 제휴를 맺어서 100만 원 크레딧을 줬다. 그래서 처음으로 NCP를 써봤다.

- NCP를 3개월 정도 써본 입장에서는 가격, 편의성, 서비스 다양성 측면 모두에서 AWS나 GCP에 비해 상대적으로 열세라고 느껴졌다.

- 가격: Server 하나로 비교하면 AWS, GCP보다 저렴하지만 Kubernetes, VPC나 LB 등의 구성, DB 서비스 등을 포함하면 오히려 비싼 것 같았다. 특히 Kubernetes는 마스터 노드와 VPC 구성 하나하나에 비용이 나가기 때문에 GCP의 오토파일럿 모드나 Vultr에 비해 2배 이상 비싸다.

- 편의성: 대부분의 프레임워크, 라이브러리에서는 AWS, GCP는 기본으로 지원해 줘도 NCP를 지원해 주는 곳은 못 봤다. 대부분 커스터마이징을 하거나 직접 구현해야 했다. 그리고 문서화 측면에서도 AWS는 유저들이 문서화를 대신 다 해줬고, GCP는 문서가 엄청 친절하고 자세하다. 그런데 NCP는 기본적인 문서화만 되어 있다. 사용 편의성 측면에서도 딱히 GCP에 비해 편하다고 느껴지진 않았다.

- 서비스 다양성: AWS는 정말 온갖 서비스가 다 있다. 필요하면 다 가져다 붙이면 되기 때문에 인프라에 종속성이 생기지만 정말 편하긴 한 것 같다. NCP는 당연한 이야기지만 AWS나 GCP에 비해 서비스 종류가 많지는 않다.

- 그래서 다음 사이드 프로젝트를 진행할 때는 아마 무료 크레딧을 주는 GCP를 쓰거나 AWS 프리티어로 시작하지 않을까 싶다.

- 그리고 사이드 프로젝트로 실제 돈이 나가는 것이 애매하다 보니 100만 원 크레딧을 최대한 아껴 쓰려고 최대한 간단히 구성했다. 회사에서는 쿠버네티스 기반으로 펑펑 쓰다 보니 가난하게 구성한 것이 처음이었다.

- Server 한 대와 DB 한 대, 도메인&LB로 구성해서 쓰고 있다. 그러다 보니 docker-compose와 github actions를 처음 써보게 됐는데, 'github actions 진짜 좋다!'와 '쿠버네티스가 진짜 좋았구나..'를 느꼈다. 깃허브 액션은 참 편했고, docker-compose는 쿠버네티스에 비해 서버 운영에 신경 써야 되는 게 너무 많았다.

 

마치며

- 요약해 보자면,

- 사이드 프로젝트로 만든 안드로이드 앱은 곧 출시한다. (초기 계획보다 1~2개월 늦어짐..)

- LLM이 우리의 일자리를 뺏기 전에 최대한 친해지자. 매달 돈이 나가더라도 LLM 기반 개발에 익숙해지면 생산성이 크게 증가한다.

- 테스트 코드는 진짜 중요하다. 안 짜면 내 불안감도 건강에 해롭고 결국 수동 테스트하느라 시간마저 더 들어간다. TDD를 적용하는 것에는 도메인 이해도가 중요하다.

- 개발 원칙에 집착하지 말자. 개발 원칙의 의도를 이해하고 내 상황과 주관에 맞게 적절히 활용하자. 개발 원칙은 헌법이 아니다. 하지만 개발 원칙으로 여겨지는 데에 이유가 있는 것도 맞다.

- 인프라는 AWS, GCP가 좋은 것 같다. 편의성은 GCP, 표준은 AWS, 가격은 Vultr..(아는 사람이 별로 없을 듯하다. 진짜 싸긴 하다)

- 쿠버네티스 조아