당신이 프로젝트에서 놓치고 있는 것

 
다소 자극적인 제목을 선정해보았지만 이 글을 끝까지 읽어봐주시면 좋은 인사이트를 하나라도 얻어가실 수 있을거라 생각합니다. 제가 프로젝트를 개발, 운영해보며 느낀 경험들을 꾹꾹 눌러담아 보았습니다. 
 

이유 없는 기술 도입을 지양하자

프로젝트에서 주어진 요구사항이나 문제를 해결하기 위해 기술을 도입해 본 경험이 있을 것입니다.

동적 쿼리를 편하게 작성하기 위해 QueryDSL 도입, 반복적인 조회 작업을 개선하기 위해 Redis 캐시 저장소 도입, 동시성 문제를 해결하기 위해 비관적 락 적용 등등...

하지만 이런 기술들을 도입하고 적용할 때 여러 기술을 비교해 보지도 않고 이유 없이 특정 기술을 도입하는 것은 지양해야 할 태도라고 생각합니다.

상황에 맞지 않는 기술이지만 단순히 관심이 있어서, 재밌어 보여서...? 도입했다면 면접관 입장에서는 좋게 보이지 않을 것 같습니다.

단지 재밌어 보이기만 하는 기술을 배우지 마라! 하는 말이 아닙니다. 새로운 기술에 흥미를 가지는 것은 더 탐구해 보고 학습할 수 있는 좋은 동기부여가 된다고 생각합니다.

만약 캐시 솔루션으로 Redis 저장소를 도입했는데 Redis와 같은 글로벌 캐시 저장소인 맴캐시드도 있고 스프링 서버라면 캐시 데이터를 JVM 힙 메모리에 저장하는 EH Cache를 사용하면 캐시 데이터를 받으러 네트워크를 타지 않으니 수십배 더 빠른 성능이 나오는데 Redis를 선택한 이유가 무엇일까요?

좋은 방법은 문제를 해결하기 위한 여러 기술에 대해 알아보고 직접 사용해 보면서 현재 상황에 맞는 기술을 적절히 프로젝트에 녹여 낸다면 완벽할 것 같습니다.

현재 프로젝트에서 해결해야 하는 문제나 주어진 요구사항을 해결하기 적합한, 상황에 맞는 적절한 기술들을 비교해 보고 트레이드 오프에 대해 고민해 보는 과정이 중요한 것 같습니다. 적어도 지금 프로젝트에 도입하고 있는 기술에 대해 다시 고민해 보고 더 적절한 기술로 교체하거나 기술 선택에 대한 이유를 생각해 보면 좋을 것 같습니다.
 

끊임없이 개선하고 프로덕트 품질을 높이자

열심히 개발해서 드디어 프로젝트를 완성했습니다! 🥳
자 이제 IDE를 닫고 개발한 프로젝트를 포트폴리오에 작성하면 되는 것일까요?

전체적인 요구사항을 구현했다면 이제 개선할 일이 남았습니다.

이력서에 프로젝트를 넣을때 CURD API 개발.. OOO 페이지 퍼블리싱.. 이런 내용은 1~2줄 밖에 안나오고 채용 담당자 입장에서는 당연한 내용이라 눈길조차 끌 수 없습니다.

진짜 중요한 것은 성능 개선, 품질 향상, 운영 중 발생한 이슈 해결 등등 입니다. 그리고 이러한 이슈를 해결하는 것에서 멈추는 것이 아니라 끊임 없이 개선해야합니다.

코드의 재사용성을 위해 코드 구조를 리펙터링 해본다던가 SPOF가 발생할 여지가 있는 구조를 개선한다던가 슬로우 쿼리를 튜닝한다던가 실제 프로젝트를 운영하다가 마주한 장애 상황을 어떻게 해결하였는지 이후에 발생하지 않도록 어떻게 개선하였는지에 대한 고민과 노력들이 이력서에 묻어나야 한다고 생각합니다.

간단한 예시로 JPA를 사용한다면 적어도 N+1 문제가 발생하는지 실제 쿼리를 분석해보고 캐시 솔루션이나 동시성 제어에 대한 문제는 고민해봤으면 좋겠습니다.

만약 VoC(Voice of Client)를 잘 들을 수 있는 환경(대표적으로 학교나 동아리, 친구..) 에 있다면 훨씬 더 깊은 고민을 해볼 수 있습니다. 실제로 프로덕트를 사용 해줄 수 있는 사람이 있다면 직접적으로 문제점이나 불편사항들을 들어 개선할 수 있어 프로덕트의 퍼포먼스를 더 향상 시켜줄 수 있다고 생각합니다.
 

운영에 힘쓰자

여러분들의 프로젝트의 목적은 무엇인가요? 여러 종류의 프로젝트가 있을 수 있겠지만 서비스 개발에 초점을 두고 글을 적겠습니다!

저와 같이 취업을 준비하는 개발자분들 이라면 공부 목적의 토이 프로젝트.. 취업하기 위해.. 등등의 이유가 있을 수 있겠지만 결국 사람들이, 사용자들이 우리의 프로젝트를 사용하게 하는 것이, 사용하는 것 자체가 목적이라고 생각합니다.

그렇다면 프로젝트를, 서비스를 만들었는데 사용할 사람은 어떻게 구하지..? 라는 고민을 할 수 있습니다.

위에서 언급했다시피 VoC를 잘 들을 수 있는 환경, 학교에 재학중인 사람이라면 정말 유리합니다. 학교라는 하나의 사회안에서 학생들이 타켓 사용자가 될 수 있습니다.

하지만 마땅히 타겟 사용자를 정할 수 없는 상황이라도 괜찮습니다. 실제 트래픽을 받거나 사용자의 피드백을 실시간으로 받아보기는 힘들어도 프로젝트 운영에 대한 고민은 필요합니다. 이게 곧 프로덕트의 품질과 연관된다고 생각합니다.

그럼 개발한 프로젝트를 어떻게 운영하지? AWS? 배포? 난 백엔드 개발자니까 몰라도 되나? 🤔

물론 몰라도 된다고 생각합니다. 큰 회사에 취업한다면 데브옵스 엔지니어 직군이 있어 백엔드 개발자는 요구사항 구현, 백엔드 서버 개발만 신경쓰면 됩니다.

하지만 우리는 인프라를 직접 구축하거나 관리 할 일이 없더라도 우리는 프로덕트를 개발하고 운영해야합니다. 인프라에 대한 깊은 지식이 필요하다는 말이 아닙니다.

적어도 CI/CD에 대해 이해하고 구축할 수 있을 정도의 간단한 인프라 지식 정도면 충분하다고 생각합니다. 백엔드 개발자가 알아야할 간단한 클라우드 인프라 구축 방법은 그냥 구글링하면 잘 나와있고 도커 파일 정도는 ChatGPT 한테 물어보면서 작성하면 금방할 수 있습니다.

진짜 하고 싶은 말은 실제 프로젝트 운영에 대한 고민이 필요하다는 것입니다. 운영에 신경쓰지 않은 극단거인 예를 하나 들자면

서버 애플리케이션에 장애가 발생했을 때 즉각적으로 알아차릴 방법이 없어서 사용자 피드백을 통해 장애 상황을 알게되고 배포 환경에 cli로 접속해서 직접 로그파일을 열어서 장애에 대해 분석할 것인가요?

모니터링 관련된 도커 컴포즈 파일 가져와서 run 시켜주기만 하면 로그수집 부터 heallth check, 서버에 대한 다양한 매트릭을 수집하고 시각화 해줍니다.

만약 AWS를 사용한다면 로그백 xml 파일 작성해서 실시간 로그 모니터링을 할 수 있고 인스턴스 경보를 설정해서 간단한 람다 함수로 디스코드나 슬랙에 알림을 보내 장애 상황을 즉각적으로 모니터링 할 수 있습니다.

인스턴스에 트래픽이 급증한다면 미리 설정해준 대로 자동으로 인스턴스를 복제해 scale-out 하거나 인스턴스 스펙을 늘리는 scale-up 기능도 간단하게 적용해볼 수 있습니다.

이러한 운영에 관련된 고민을 해보지 않았자면 지금이라도 관심을 가지고 사용자 입장에서, 실제 장애가 발생했을 때 페인포인트가 있는지 고민해보면 좋을것 같습니다.

배울 점이 많은 선배님의 말씀을 인용하자면 빛 좋은 개살구 같은 코드를 찍어내지 맙시다.
 

어려운 문제는 간단하게 생각하자

제가 가장 중요하게 생각하는 것입니다. 어려운 문제는 간단하게 생각하고 해결하자.

여기서 어려운 문제라는 것은 복잡한 비즈니스 도메인이 될 수도 있고 당장 개발하다 or 운영하다 마주한 문제 상황일 수도 있습니다.

만약 여러분들이 복잡한 비즈니스 요구사항을 전달 받았다고 가정해봅시다. 그럼 여러분들은 이 복잡한 요구사항을 어떻게 코드로 녹여내실 건가요?

결국 코드는 사람이 보라도 작성하는 것입니다.

저라면 먼저 최대한 간단하고 직관적이게 이해할 수 있도록 문제 별로 쪼개어 문서화 할 것 같습니다. 그리고 작성한 문서를 바탕으로 직관적이게 코드를 작성해볼 것 같습니다.

어렵고 복잡한 문제를 맞닥뜨려도 당황하지 마세요. 😣 너무 어렵게 생각하지 말고 어떻게 하면 직관적이게 문제를 해결할 수 있을지 깊이 고민해보고 팀원들과 소통하며 해결책을 모색한다면 읽기 쉬운 좋은 품질의 코드를 작성할 수 있을 것입니다!
 

기록하고 또 기록하자

프로젝트를 시작하기 전에, 개발 진행 중에, 운영 중에, 그리고 프로젝트가 끝난 후에 남은 것이 작성한 코드 뿐인가요? 팀원들과 의사결정이나 새롭게 도입할 기술에 대한 기록은 남기지 않으셨나요?

물론 극단적인 상황을 예로 들긴 했지만 실제로 이런 모습을 많이 보았습니다.

저는 기록을 매우 중요하게 생각합니다. 기록은 나를 증명하는 소중한 자산이자 협업의 관점에서도 필수적입니다.

이 글을 읽고 계시는 여러분들은 개발자입니다. 물론 개발자는 하드스킬(전문 지식)이 가장 중요하다는 것은 사실입니다. 개발을 잘하는 사람은 취업도 잘하죠..

하지만 그렇다고 소프트 스킬(기술 외 능력)이 덜 중요하다는 것은 아닙니다. 개발은 혼자 하는 것이 아니라 함께 하는 일입니다. 실력이 뛰어나지만 커뮤니케이션이 힘든 사람보단, 함께 일하고 싶은 개발자가 되어야 한다고 생각합니다.

그렇기에 문서화는 정말 중요하다고 생각합니다. 팀원들과의 의사결정, 새롭게 도입한 기술, 복잡한 비즈니스 요구사항에 대한 명세 등을 기록하는 것은 필수적입니다. 나 혼자만 이해하고 개발하는 것이 아니라, 팀원은 물론 새롭게 합류할 팀원들까지 빠르게 우리의 서비스와 비즈니스에 대한 이해도를 높일 수 있는 노력이 필요하다고 생각해요.

저희 뇌는 휘발성이기 때문에 비휘발성 저장소인 문서에 잘 기록하는 습관을 지닙시다. 🙌🏻
 

정리

마지막으로 글을 정리하자면 “프로덕트의 품질 향상을 위해 끊임없이 노력하자” 정도로 요약할 수 있을 것 같아요.
내가 만드는 프로젝트에 오너쉽을 갖고 어떻게 하면 내 프로젝트를 더 개선할 수 있을지 더 고민해 보면 좋을 것 같아요. 이런 고민을 많이 하고 여러분들의 이력서에 잘 녹여낸다면 좋은 결과가 기다릴 거예요!!

저도 아직 많이 부족하지만 경험과 실무자 선배님들과 이야기를 나눠보면서 저의 의견을 정리해서 글을 적어봤어요. 부족한 글이지만 끝까지 읽어주셔서 정말 감사합니다. 좋은 하루 보내세요. 😊