최종 발표 및 회고

5주간의 최종 팀 프로젝트가 끝이 났다.

 

내 예상과 달리 만만치 않았다. 하지만 또 그만큼 얻은 것도 많다고 생각하면 위안이 된다.

결과적으로, 이번 팀 프로젝트는 꽤 성공적이었다고 생각한다.

 

특히, 나는 운이 좋았다고 생각한다. 왜냐하면 내가 속한 팀 구성원들의 조합이 매우 좋았기 때문이다. 덕분에 내가 팀 내에서 100% 역량을 발휘할 수 있었다고 생각한다. 나의 의견을 믿고 존중해 준 팀 리더에게 진심으로 감사하다.

 

이번 프로젝트에서 나는 백엔드와 데브옵스 역할을 맡았다. 현업에서의 경험을 프로젝트에 고스란히 녹여내기 위해 노력했으며, 전반적인 아키텍처 설계, 데이터베이스 관리, 그리고 인프라 구축에 집중했다.

 

나는 항상 프로젝트를 진행할 때 코드의 퀄리티와 생산성 간의 균형을 고민한다. 프로젝트에 필요한 모든 리소스도 이를 기준으로 선택한다. 이번 프로젝트에서도 마찬가지다. 또한, 실제 현업에서의 프로젝트라고 가정하며 진행하려고 노력했다. 다만, 5주라는 짧은? 프로젝트 기간을 고려해 적절하게 균형을 맞춰야 했지만... 매번 완벽하게 이 균형을 맞추는 것은 쉽지않다는걸 깨닫는다. 항상 코드 퀄리티에 욕심을 낸다. 인간의 욕심은 끝이 없고 같은 실수를 반복한다.

 

프로젝트 초기는 생산성이 가장 높을 때다. 하지만, 시간이 지날수록 점점 생산성이 떨어진다. 이게 왜 그런고 보니.. 기존 코드에 변경이 일어날 때다. 코드를 새로 작성하는 것 보다, 기존 코드를 변경하는데에 더욱 시간이 걸리는 것이다.

 

그렇다면, 왜 코드의 변경이 더 시간이 걸리는 걸까?

 

예를 들어, 이미 프로덕션 환경에 배포된 기존 서버 코드를 임의로 변경하면, 해당 API를 사용하고 있는 프론트단에서 문제가 발생할 수 있다. 이를 방지하기 위해 하위 호환성(backward compatibility)을 유지해야 하는데, 그러기 위해 기능 플래그(feature flag) 또는 API 버저닝(API versioning)이 필요해지고, 테스팅 및 검증 작업이 늘어난다. 이와 같이 고려사항이 많아짐에 따라 생산성이 저하되는 것이다.

 

그렇다면, 왜 코드의 변경이 일어나는 걸까?

 

기획 변경 또는 새로운 요구사항이 계속해서 발생하기 때문이다. 거의 대부분의 개발에서, 사용자의 피드백과 시장의 변화는 요구사항을 끊임없이 바뀌게 만든다. 처음에는 완벽해 보였던 요구사항도, 실제로 프로토타입을 사용해 보거나 실제로 서비스를 운영해보면서 미처 생각지 못했던 부분을 찾는 경우도 많다. 심지어 단순 변심에 의한 경우도 있다.

 

그렇다면, 초기 설계에서 확장성을 고려하여 어떠한 코드의 변경에도 대응 가능한 구조로 설계하는 것이 가능할까?

 

이론적으로는 가능 할지도 모른다. 그러나 그것은 사실상 불가능하다고 본다. 기획 및 요구사항은 외부 세계의 영향을 받는다. 이를 사전에 완벽히 예측하는 것은 사실상 불가능하다. 그래서 나는 이러한 측면에서 YAGNI 원칙을 따르는 것을 선호한다. 물론 예외는 있다. 만약 설계에 대한 충분한 경험이 있고, 가까운 미래에 특정 기능이나 확장이 필요할 가능성이 매우 높다는 것을 경험적으로 예측할 수 있다면 말이다.

 

즉, 시간의 흐름에 따른 코드의 변경은 불가피하다는 결론이 나온다.

 

그렇다면 이에 대응할 수 있는 최선의 방법은 무엇일까?

 

최대한 변화에 유연하게 대응할 수 있는 설계를 하는 것이다. 예를 들어, 모듈화를 통해 특정 모듈의 변경이 전체 시스템에 미치는 영향을 최소화하는 것이다. 이에 대한 극단적은 예시로 MSA가 있다. 또한, 내부 구현에 영향을 받지 않는 외부 인터페이스를 유지하여 하위 호환성을 보장하는 것이다. 그리고 또 한 가지로, 데이터베이스 설계 시, 유연한 스키마가 가능한 NoSQL 과 같은 MongoDB 를 도입하는 것이다. 그리고 마지막으로 가장 중요한 충분한 설계 경험이 있겠다. 이러한 방법들을 요구사항에 맞게 적절히 조합하는 것이다.

 

아키텍쳐 설계에 완벽한 정답은 없다. 설계 방식은 개발자의 경험, 스타일, 그리고 프로젝트의 특성에 따라 천차만별일 수 있다. 그러나 지금까지의 개발 경험을 바탕으로 내린 나만의 결론은 다음과 같다.

 

가장 중요한 요소는 경험이라 생각한다. 충분한 경험이 축적되면, 프로젝트의 기획 단계에서부터 미래에 직면할 수 있는 문제들을 어느 정도 예측할 수 있다. 이를 바탕으로, 기획자와 협의하여 초기 요구사항 자체를 조율하거나, 설계 단계에서부터 잠재적인 문제를 예방하는 방향으로 나아갈 수 있다. 결국, 아키텍처 설계에서 중요한 것은 완벽한 설계를 추구하는 것이 아니라, 미래의 불확실성에 대비할 수 있는 설계를 목표로 하는 것이다. 이는 오직 경험을 통해서만 다듬어질 수 있다.

 

다음으로는 지극히 개인적인 생각이다. 

 

바로, 매우 빠른 프로토타이핑이다. 즉, 요구사항을 만족하는 최소한의 확장성을 유지한 채, 생산성을 극대화하는 것이다. 그리고, 이 과정에서 발생하는 기술 부채는 주기적인 코드 리팩토링을 통해 점진적으로 해소한다. 이러한 방법을 고수하는 이유는 단순하다. 프로토타입을 통해 유저에게 빠르게 피드백을 받고, 이를 신속하게 반영하기 위함이다. 초기 단계에서 지나치게 완벽한 설계를 고민하는 대신, 사용자와의 상호작용을 통해 실제로 중요한 부분을 빠르게 파악할 수 있다. 이러한 사이클을 반복하다 보면, 어느 지점에서 확장성을 우선적으로 고려해야 할지 자연스럽게 파악된다. 또한, 우선순위를 재설정하면서 필요 없는 과도한 설계를 피하고, 현실적인 요구사항에 초점을 맞출 수 있다.

 

지금까지 이야기한 내용은 코드의 퀄리티와 생산성에 관한 것이다.

 

다음으로는 협업의 측면에서 얘기를 해보고 싶다. 구성원들의 업무가 겹치지 않게 기능을 잘게 쪼개는 법과, 코드 리뷰에 관한 것이다. 

 

협업의 핵심은 구성원들 간의 작업이 서로 독립적으로 진행될 수 있는 환경을 만드는 것과, 코드 리뷰를 통해 코드 퀄리티를 지속적으로 높이는 데 있다. 그러나, 이 또한 앞서 설명한 것과 긴밀히 연관되어 있다. 특히, 모듈화된 설계와 기존 코드의 상태가 협업에 미치는 영향은 절대적이다.

 

구성원들 간의 작업이 겹치지 않게 하려면, 기능을 잘게 쪼개어 독립적으로 진행할 수 있도록 해야 한다. 이를 위해서는 모듈화에 유리한 아키텍처 설계가 선행되어야 한다. 또한, 공통적으로 사용되는 공유 모듈을 사전에 구성해두면, 모듈 중복이나 코드 충돌을 미리 방지할 수 있다.

 

코드 리뷰는 팀의 코드 일관성을 유지하고, 버그를 사전에 방지하며, 개발자 간의 학습을 촉진하는 중요한 과정이다. 그러나 코드 리뷰는 항상 기존 코드의 상태에 영향을 받는다. 구성원들은 일관성을 위해 기존 코드 스타일에 맞추려 하고, 기존 코드의 퀄리티가 낮으면 새 코드 역시 그 수준에 머물 가능성이 크다. 이 경우 코드 리뷰의 효과가 떨어지며, 전체적인 코드 퀄리티는 점점 하락한다.

 

만약, 모든 구성원들이 기능 구현에만 급급하고, 코드 리팩토링이나 기술 부채 해결을 해결할 여유가 없다면, 코드 퀄리티 저하는 피할 수 없다. 퀄리티가 낮아질수록 유지보수가 어려워지고, 이는 다시 생산성 저하로 이어진다.

 

결국, 협업의 성공은 올바른 설계와 코드 리뷰를 통해 코드 퀄리티를 유지하는 데 달려 있다. 이는 팀의 코드 퀄리티를 주도적으로 관리해야 하는 테크 리더의 책임이 막중한 이유이기도 하다.

 

나 역시 데브옵스로서 이러한 문제들로 많은 어려움을 겪었고, 여전히 이를 해결하기 위한 최선의 방법이 무엇인지 끊임없이 고민하고 있다. 나는 개발자를 위한 개발자가 되어, 팀의 개발 생산성을 극한으로 끌어올리는 것을 목표로 하고 있다.

 

앞서 말했듯이, 이번 팀 프로젝트는 꽤 성공적이었다고 생각한다. 평소에 고민하던 것들을 이번 프로젝트를 통해 다시 한 번 도전하고 검증할 수 있는 기회가 되었기 때문이다. 게다가, 내가 사용하고 싶었던 기술 스택을 마음껏 사용할 수 있었던 것은 덤이다.

 

크래프톤 사옥, 프로젝트 "소켓팅" 발표 질의응답 현장

 

(왼쪽에서 두번째, 마이크 들고 있는 사람이 나다.)

 

프로젝트 소스코드:

https://github.com/everyone-falls-asleep

 

웹사이트:

https://socketing.hjyoon.me/