프로젝트를 하며 느꼈던 것들

최근 또 하나의 프로젝트를 마무리하였습니다.

21년 말 개발을 시작하고 난 이후 참 많은 일을 겪고 개발적으로도 사람으로서도 많이 성장한 것 같습니다.

이번 글을 통해 지난 프로젝트 경험을 되돌아보며 "프로젝트를 하며 느꼈던 것들"에 관한 글을 작성해 보려 합니다.

 

프로젝트에는 성장 포인트가 많다

지난 3년간 여러 번의 프로젝트를 경험하다 보니 프로젝트에는 다양한 성장의 포인트가 있다고 생각하였습니다.

프로젝트하면 가장 먼저 떠오르는 성장 포인트는 저 역시 기능 구현입니다.

단지 기능 구현 그 자체만으로, 더 나아가 조금 더 어렵고 복잡한 기능을 구현하기 위해서 공부하고 고민하면서 성장한다는 느낌을 받을 수 있었습니다.

그리고 혼자 기능 구현할 때와 달리 함께하는 사람에 따라 맞추어 나가며 같은 기능이라도 다르게 구현하며 성장한다고 느낄 수 있었습니다.

프로젝트에 대해 고민하면서도 성장할 수 있었습니다.

책, 강의 그리고 레퍼런스를 많이 보고 다양한 기능을 구현하는 것은 더욱 기술적인 코드를 작성하는 것에 도움이 될 것으로 생각합니다.

하지만 항상 기술적인 코드가 좋은 코드라 생각하지 않습니다.

저는 좋은 코드를 작성하기 위해서는 개발적 지식 외에도 프로젝트에 대한 고민도 필요하다 생각합니다.

"프로젝트가 어떠한 문제를 풀려고 하는 것인지?", "프로젝트가 어떠한 가치를 전달하는지?", "프로젝트가 어떻게 확장할 수 있을지?"

저는 위와 같은 프로젝트에 대한 고민을 네이밍, 패키지 구조, 도메인 구분에 적용하여 코드에 스며들게 하였을 때, 구현을 통해 느낄 수 있는 성장과는 또 다른 방향의 성장을 느낄 수 있었습니다.

마지막으로 함께하는 동료와 함께하며 성장할 수 있었습니다.

함께하는 동료에게 많은 것을 배울 수 있는 상황이라면 일방적인 관계가 되지 않도록 부지런히 행동하는 동료가 되려 노력했습니다.

새로운 것을 머리로 이론으로 받아들이는 것이 아닌 작은 단위로 쪼개서 적용해 보며 그 과정에서 느끼는 것을 공유하려 노력했습니다.

반대로 함께하는 동료에게 저의 무언가를 공유할 수 있는 관계라면 내가 원하는 것이 아닌 동료가 원하는 것이 무엇인지 파악하고 전달하려 노력하고 있습니다.

 

임기응변은 필요하다. 하지만 많이 준비하자

우선 프로젝트에 필요한 기본 기능을 구현할 수 있는 개발 역량을 준비합시다.

최소 단위로 자신이 구현할 기능을 구현해 보며 프로젝트를 진행하며 일어날 수 있는 문제 사항을 예측하고 대비해 봅시다.

그러면 프로젝트를 진행하며 만날 조금 더 가치 있는 문제를 해결하는데 시간을 많이 투자할 수 있을 것으로 생각합니다.

팀 프로젝트는 하나의 목표를 위해 여러 직군의 사람들이 모여 함께 작업합니다.

이때 직군 간 병목이 생기는 부분을 파악하고 해결해 봅시다.

저는 백엔드 직군으로 지난 여러 번의 프로젝트를 경험하며 프론트엔드 직군과 협업 간 API 명세와 서버 요청/응답에서 병목을 지속해서 경험하였습니다.

이를 임기응변으로 대응하기도 하였지만, 프로젝트를 반복하며 해결해야 할 필요를 느꼈습니다.

그렇기에 제대로 문제를 파악할 필요가 있었고 API 명세는 개발 도중에 자주 변경되는 것, 서버 요청/응답은 기능 구현이 끝나야 테스트를 할 수 있다는 문제가 있었습니다.

저는 이를 API에 대한 논의를 기획 단계로 전진 조정하고 서버 요청/응답을 기능 구현까지 기다리는 것이 아닌 목 서버로 대체하여 병렬적으로 일이 진행될 수 있도록 개선하였습니다.

개발 기간에는 정말 개발에만 집중할 수 있도록 준비해봅시다.

각자마다 코드를 작성하는 스타일이 다를 것입니다.

이를 위해 공통 린트를 적용하고 코드 컨벤션을 정해봅시다.

그리고 각자가 개발하는 환경 역시 다를 것입니다.

이를 위해 도커 혹은 스크립트를 활용하여 어디서든 같은 환경에서 개발을 진행할 수 있도록 환경을 구성해 봅시다.

이렇게 함께하는 사람 간의 차이를 줄이고 공통점을 늘려가는 작업을 개발 기간 전까지 만들어 봅시다.

레퍼런스는 레퍼런스일 뿐이다

저 역시 개발 경험이 많이 없었을 때 레퍼런스의 함정에 빠졌던 적이 있습니다.

구현해야 할 프로젝트의 상황과 참고하는 레퍼런스의 상황은 다른데 레퍼런스를 제대로 이해하고 활용할 수 없어 프로젝트를 레퍼런스에 맞추었습니다.

이때의 경험을 통해 레퍼런스를 참고하여 내 것으로 만들기 위한 기본기의 중요성을 다시 한번 느낄 수 있었습니다.

지금 본인이 다루는 것에 대한 제어권이 본인에게 있지 않다고 느낀다면 조금은 재미가 없을 수 있지만, 프로젝트가 아닌 이론적인 공부를 통해 이를 보충해 봅시다.

 

질문도 능력이다

프로젝트를 진행하며 지금은 몇몇 경우 질문을 받는 입장인 경우도 있지만, 여전히 질문해야 하는 경우가 더 많습니다.

저 역시 경험이 많이 없던 초반에는 어떤 것을 질문해야 하는지 머리가 새하얗게 변했던 것 같습니다.

저는 이렇게 우리가 질문하기 어려워하는 것은 질문 내용을 상상으로 만들기 때문이라 생각합니다.

그러지 말고 내가 해야 할 일의 최소 단위의 무언가를 만들어본 이후 눈에 보이는 결과와 경험을 바탕으로 질문하는 것은 어떨까요?