3 min to read
Architecture의 중요성
지옥의 회고록
Architecture의 중요성…
다들 안녕하세요
나름 오랜만에 찾아왔습니다!
오늘은 제가 회사에서 겪으며 느꼈던 것에 대해 편하게 이야기 해볼까 합니다 :>
여러분은 아키텍처 설계가 왜 중요하다고 생각하시나요?
서비스 구조를 파악하기 쉬워지기도 하고, 생산성 높은 구조를 갖출 수 있기도 하고… 여러모로 많이 알려진 장점들에 대해 여러분 모두 잘 알고 계실거라고 생각합니다.
저는 사실 아키텍처 설계가 왜 중요한지 잘 모르고 있었습니다.
글로 한두번 읽은 보편적인 정보만 알고 있었을 뿐, 실전에서 느껴본 적은 없었으니 그저 탁상공론처럼 보이기도 했습니다.
이렇게 빡빡하게 무언가를 설계할 시간에 코드 몇줄을 더 쓰는게 좋지 않나..? 라는 생각도 했었죠.
심지어 이런 생각은 행동으로 옮겨지기도 했습니다. 사수가 없으니 바로잡아 줄 사람도 없었으니까요.
행동으로 옮겼다는 것… 그건 예견된 파멸이었습니다.
왜 그랬어 과거의 나…
저 행동의 결과로 나온 하나의 서비스가 있었습니다.
그 서비스를 지탱하는 서버는 극히 일부 코드를 제외하고 전부 main.py에 다 박혀있는… 정말 괴랄하기 짝이 없는 서버입니다.
저 당시의 저는 딱 이런 생각이었습니다.
주어진 짧은 시간에 완성하려면 이 방법 밖에 없지
아키텍처 설계나 이런건 시간도 상황도 충분해야 할 수 있는거 아닐까? 모든 상황이 다 똑같은건 아닐테니까
이 생각이 전혀 합리적이지 못하다는 것은 최근에 읽고 있는 Clean Architecture라는 책의 1장에서 완벽하게 증명하고 있었습니다.
코드는 나중에 정리하면 돼. 당장은 시장에 출시하는 게 먼저야!
개발자가 속는 더 잘못된 거짓말은 지저분한 코드를 작성하면 단기간에는 빠르게 갈 수 있고, 장기적으로 볼 때만 생산성이 낮아진다.
엉망으로 만들면 깔끔하게 유지할 때보다 항상 더 느리다.
그리고 사실, 책에서 이 증명을 발견하기 전에 제가 직접 경험하며 스스로 증명해버리기도 했습니다.
저 괴랄하게 구성된 서버는 다행히도 첫 요구사항에 대해서는 나쁘지 않게 동작했습니다.
꽤나 뿌듯했고, 정해진 시간에 완성되어 동작하는 서버는 마치 안정적인 것 처럼 보였습니다.
그리고 그 때가 왔죠.
저희 요구사항이 바뀌었어요
이 말을 처음 들을 때만 해도, 제 미래가 얼마나 어둡고 고통스러울지는 상상도 못했습니다.
그저 딱 이런 반응을 했어요.
아, 어떻게 바꿔야하죠?
저 스스로를 과신하는 베이스에서 끌어나온 말이었습니다.
변경하는거 금방 하지! 라는 생각이었어요.
그리고 그렇게 변경사항을 받아들고… 서버 코드를 딱 키는 순간 느꼈습니다.
망했다.
여기서 잠깐 제가 서비스 했던 것을 간단하게 설명드리자면,
저는 사용자의 요청을 받고 해당 요청을 1차적으로 처리한 뒤에, 처리한 결과를 사내 솔루션 서버에 전달하여 2차 가공을 거치고 해당 2차 가공이 끝난 데이터를 최종적으로 상대 서버가 요구하는 API 형식에 맞게 전달하는 방식이었습니다.
그리고 여기서 발생했던 변경점은, 2차 가공을 담당했던 사내 솔루션 서버의 교체였습니다.
해당 서버의 업데이트나 변경이 아닌, 완전히 다른 서버로의 교체였습니다.
어디서부터 어디까지 바꿔야하지…?
정말 막막했습니다.
해당 서버의 교체로 인해 서버가 요구하는 폼도 다 바뀌었을 뿐만 아니라, 리턴값과 에러 반환 폼, 심지어 받을 수 있는 요청 개수의 제한과 같은 것들도 전부 바뀌었습니다.
그리고 당연하게도, 모든걸 기존 서버에 맞게 짜놓았던 저는 어디서부터 손을 대야 할지 알 수 없었죠.
차라리 정말 완벽하게 중복되는 메소드 없이 순차적으로 작성했다면 달랐을지도 모르겠습니다.
하지만 그 당시 나름 맞춰 짠다고 반복되는 로직은 하나로 병합해서 사용하는 등, 특정 서버에 귀속된 메소드들을 여기저기 남발했고, 심지어 그 특정 서버가 아닌데도 해당 메소드를 필요로 한다면 그 메소드를 그대로 가져다 사용하는 기염을 토했습니다.
당연하게도, 서버는 수정을 하면 할수록 망가져갔습니다.
뭐야, 이걸 수정했는데 왜 이상한데서 에러가 나지?
서버를 수정하며 수백번도 넘게 반복한 이야기입니다.
모니터를 멍 하니 바라보며 차라리 타임머신을 만들어서 과거의 나를 찾아가 기절시키고 새로 짜는게 더 빠르겠다 라는 생각도 했습니다.
아직도 멀었나요?
저의 멘탈이 와장창 하던 순간입니다.
이전에 첫 배포를 마쳤던 저의 감상과는 전혀 반대되는 이야기였죠.
결국 저는 기한을 맞추지 못했습니다.
일주일이나 연장해서 겨우겨우 동작하는 서버를 배포하긴 했지만, 그 마저도 이전 서버가 지원하던 일부 마이너한 기능들을 뺀 서버였어요.
추후에 수정을 통해 완성시키는 했지만, 정말 완벽하게 잘못된 상황이었습니다.
어디서부터 잘못된걸까… 생각하다가
이때쯤 아키텍처의 중요성을 느끼고 책을 사기 시작했습니다.
제가 이전에 적었던 이 이야기가 바로 위의 사건에서 느낀 바를 되짚으며 적은 글이기도 합니다.
만약 첫 설계단계부터 외부에 의존하는 부분을 분리해서 설계했었다면 이런 일이 발생하지 않지 않았을까…
추상화된 청사진을 가지고 있었으면 해당 메소드나 설계들이 어디에서 무엇을 위해 쓰이는지 좀 더 명확히 알 수 있지 않았을까…
과거의 저에게 해주고 싶은 이야기가 산더미입니다.
그럼 지금은 잘 짜고 있나요?
안타깝게도 제가 잘 짜고 있는지는 잘 모르겠습니다…
하지만 이전처럼 저를 과신하고 이러면 된다! 라고는 안하려고 노력하고 있어요.
이전 사건에서 여실히 느꼈던 것 처럼,
요구사항은 언제든지 바뀔 수 있고, 나아가 코드를 작성하는 사람조차도 바뀔지 모르는 일이죠.
어떻게 보면 좋은 아키텍처 설계는 결국 불명확한 미래에 대한 최소한의 대비가 아닐까 싶습니다.
그럼 저는 이만 들어가볼게요.
다들 행복하세요 :>!
톰도 이렇게 될지는 몰랐겠지…
Comments