🌈 시작하며

최근에 야심찬 목표를 갖고 동료와 함께 개발하고 있는 프로젝트가 있다.
프론트엔드 쪽 프로젝트를 책임지고 하다 보니 좋은 코드를 집착하게 됐고, 결과적으로 이 코드가 과한 건 아닌지, 오버엔지니어링에 대한 생각이 많아졌다.

결국 타협을 하다 보니 가장 적정선을 타협하게 됐지만, 이 고민을 결정하기까지 걸린 시간에 대한 나름대로의 현타(?)가 발생했다.

그렇다. 이 글은 오버엔지니어링에 대해 스트레스 받은,
어느 우주 건너편에 위치한 개발자의 생각을 정리한 글이다.

🚦본론

나를 괴롭게 하는 오버엔지니어링

최근에 좋은 코드를 집착하면서 내 코드에 대한 엄격함이 심해졌고, 다음과 같은 생각의 분열(?)이 일어나게 됐다.

분열된 생각 1. 왜 쉬운 문제를 어렵게 다가가려 하지? 이건 오버엔지니어링 같은데.
분열된 생각 2. 그렇지만 나중에 A한 상황에서는 이러한 코드가 더 효율적이지 않아? 이런 상황이 곧 발생할 거 같은데.

어쩌면 다양한 생각을 사고하고 적합한 패턴과 로직을 만들어낸다는 측면에서는 분명 좋은 일이긴 하다. 하지만 이에 따라 마치 당장 바빠 죽겠는데 발생하는 수많은 고민들은, 마치chore을 하는 것만 같은 허탈함과 고통이 수반되기도 했다.

분명 쉽게 생각하면 그만일 것을, 적어도 끊임없이 생성되는 오버엔지니어링에 대한 번뇌는 마치 가스라이팅처럼 나를 괴롭게했다.

피할 수 없는 오버엔지니어링의 고통

그렇다면 문제는 오버엔지니어링이니 사실 고통으로부터 벗어나는 방법은 간단하다.
애초부터 오버엔지니어링을 생각하지 않고 만들어내면 된다. 어떤 로직이든 그냥 단순한 풀이를 하면 그만이다.

실제로 쉬운 문제로 풀이를 해버리면 간단하게 문제를 해결할 수 있다.
예컨대 우리가 서울에서 판교까지 물건을 배송하는 로직을 코드로 짠다고 생각해보자.
이럴 때에는 그저, 간단히 자동차로 이동하면 그만이다.
따라서 이때, 만약 비행기로 짜는 로직까지 고려한 개발자의 코드는 이상하게 보일지 모른다. (때로는 왜 그렇게 코드를 짜셨나요?라는 물음을 수반하기도 한다.) 우리는 이러한 과한 디자인을 오버엔지니어링이라 한다.

하지만 그렇다고 오버엔지니어링이 나쁠까? 그렇지 않다.
갑자기 재수가 없게도 물건을 미국까지 옮겨야 하는 상황이 속출했다고 가정하자.

이때에는 기존의 로직을 모두 버리고 새로운 코드로 바꿔야 할 것이다.
이럴 때에는 슬슬 골치가 아파지기 시작한다. 잘 돌아가는 코드를 다 갈아 엎어야 할지 말이다.

반면, 비행기로 이동하는 로직까지를 고민해서 전략 패턴으로 개발해놓았다면? 개발자는 웃으며 코드 몇 줄 추가하고 끝낼 것이다.

확장성은 당장 내게 보이지 않지만 먼 미래의 나를 위해 마치 투자하는 느낌이 들었다.
그래서 난 이 마약같은 오버엔지니어링과 적정엔지니어링의 경계의 달콤함을 벗어날 수 없었다.

그렇다. 오버엔지니어링은 블랙박스의 영역이다.

이 세상에 다양한 블랙박스가 존재한다. 주식시장이든, 비트코인이든, 토너먼트 경기이든. 결국 확률의 싸움은 이 지구에서 쉴 새 없이 발생하고 있다.

우리는 이러한 까고 봐야 알 수 있는 영역을 블랙박스라고 말한다. 오버엔지니어링은 엄연히 이 블랙박스의 영역이다.

사고가 터지기 전까지는 이 과정이 정말 과해보일지 모르나, 막상 터지고 나면 수많은 사람들의 의심을 견디며 이겨낸 그의 혜안에 눈물을 흘리며 공중제비 3바퀴를 돌 수 있지 않을까?

그렇지만 투자는 많은 비판과 회의감을 감당해야 한다.

하지만 모든 투자가 그러하듯, 이러한 결과가 일어나기 전까지는 많은 의문과 질타를 견뎌내야만 한다. 오버엔지니어링 역시 이러한 범주에서 벗어나지 않는다. 특히 혼자서 하는 프로젝트면 성향과 상황에 따라 모르겠지만, 여럿이서 할 때는 더 그러하다. 우리의 코드는 엄연히 사유재가 아닌, 공공재이기 때문이다.

가끔 나는 당연히 확장성 있게 설계해야 한다고 생각하고 구축한 로직이, assertive한 비판이 날아올 경우 당혹감이 발생하기도 한다. 그럴 때면, 왜 나는 이렇게까지 비효율적으로 일하는가?라는 회의감이 들 때도 있다.

사실 이에 대한 답을 고민하는 시간을 갖기 위해 긴 글을 쓰고 있다.
그리고 얼추 이 문제에 대한 해결 방법을 조금은 찾은 것 같다.

코드에 대한 투자를 아끼지 않은 개발자에게

분명, 그대는 틀리지 않았다

내가 내린 결론은, 오버엔지니어링은 개발자의 숙명이라 생각한다. 아이너리하다. 개발자의 숙명이 곧 과한 방법론을 따른다는 것이라니.

하지만 나는 오버엔지니어링이라는 말을 듣고 기죽지 않았으면 한다. (이건 나에게 하는 말이기도 하다.) 오버엔지니어링을 생각한 개발자에게는 질타보다는 우선적으로 고마움을 느껴야 한다고 생각한다.

갇혀있을 때에는, 결코 확장적인 생각을 할 수 없다.
알고리즘 문제를 풀다 보면, 가끔은 이 수십 줄 때문에 왜 내가 며칠을 고민했을까하는 허탈함이 들지 않는가? 그렇다. 갇혀진 생각은 스스로 새로운 영역으로 확장하기까지 엄청 오랜 시간이 걸린다.

오버엔지니어링은 그러한 생각을 넓혀주는 데 일조한다. 막상 A만 생각했던 팀원들에게, B와 C라는 선택지도 있음을 코드로 보여줄 수 있는 것이다. 비판이라는 것도 결국에는 비즈니스를 사고하기 때문에 가능한 것이다. 만약 누군가가 반복되는 오버엔지니어링으로 인해 싫증이 났다면, 내가 이 비즈니스에 대한 확장성을 어디까지 생각해보아야 할지를 다시 고민해보자. 알고 보면, 내가 우물 안 개구리였음을 가끔 깨닫고는 다른 사람의 코드에 놀라게 된다.

다만, 코드는 항상 비즈니스와 가용 자원을 먼저 생각하자.

그렇지만 모든 낙관적인 엔지니어링은 결과적으로 기준선을 모호하게 만들 수 있다. 결국에는 과하게 디자인하는 것이 최고라고 묻는다면, 그건 아니다.

1주일의 시간을 줬는데 1달만에 완벽하게 마무리했다면, 그것은 좋은 결과물을 얻었을지언정, 좋은 결과를 얻었다고 말할 수는 없기 때문이다. (모든 것은 기회비용을 따르기 때문이다.) 그렇기에 오버엔지니어링은 부분적으로는 관용적이면서, 또한 남용되지 않도록 경계를 해야 한다.

다만 '관용적인 오버엔지니어링'은 어느 정도의 범위인지 그 모호함에 의문을 품게 됐고, 마침내 핵심을 정하게 됐다.

그것은 바로, 이 코드가 현재의 자원과 비즈니스를 생각하는가이다.

비즈니스를 생각하는 코드

결국 개발자도 회사의 일원이며, 개발은 회사의 문제를 해결하기 위한 솔루션일 뿐이다. 따라서 회사의 비즈니스의 상황과 미래를 생각하고 개발해야 한다.

어떤 코드가 정상적으로 돌아갈 때, 우리가 납득할 수 없는 코드는 내 생각에는 둘 중 하나이다.

1. 그 코드를 본 사람의 context가 부족하거나,
2. 그 코드를 짠 사람의 context가 부족하거나이다.

만약 전자라면 전자는 이 코드가 왜 적정엔지니어링이라고 판단했는지 설명해주어야 한다. 결과는 결국 같이 코드를 공유하는 사람이 내려줄 것이다. 설령 오버엔지니어링이라는 평가를 받아도, 결국 이 문제가 회사의 문제를 해결하기 위한 과정이라고 사람들이 생각했다면, 아쉬워하지 말자. 당신은 오늘도 팀원에게 더 폭넓은 시각을 제공해준 고마운 팀원이다.

후자라면 오히려 팀원들에게 또 감사해야 한다. 당신은 미처 알지 못했던 문제의 본질을 다른 팀원들을 통해 더욱 확실히 알게 되었다.

결국 비즈니스는 각자가 추상화한 개념이 다르며, 이를 서로 합쳐야 할 순간이 온다. 따라서, 오버엔지니어링을 고민하는 순간은 단지 그 순간이 왔을 뿐이다. 이를 부정적으로 받아들이기보다는, 서로가 생각하는 비즈니스의 상태를 일관성 있게 맞춘다는 느낌으로 받아들이면 어떨까 싶다.

자원은 한정적임을 이해하자

또한, 시간, 인적 자원 역시 생각해봐야 한다. 가끔, 오버엔지니어링이 질타를 받는 경우는 정말 할 일이 많은데, 주어진 문제를 딜레이하는 경우이다. 이를 미연에 방지하려면, 코드 품질은 어느정도 타협선을 가져야 한다는 것을 인정해야 한다.

어느 누구도 무한의 자원이 주어졌을 때, 문제를 깔끔한 코드로 해결하지 못하리라는 법이 없다. 우리가 가치를 가질 수 있는 이유는, 제한된 시간적, 인적 자원 안에, 충분히 만족할 만한 생산성을 갖고 있기 때문이다.

일단 주어진 자원 안에 문제를 해결할 수 있는 리스트를 찾고, 가장 모두가 만족할 만한 코드로 결과를 만들어내자. 안타깝게도, 이 역량은 결국 경험이라는 다소 두루뭉술한 답변을 내놓아야 하겠지만 말이다.

그래서 요새는 과한 디자인을 보면, 오히려 그 코드를 짠 개발자들에게 고생했다는 마음이 든다. (이는 끊임없이 좋은 설계인지 의심하며 자신을 괴롭히면서도 스스로에게 느낀다.)

모두가 쉬고 싶다는 욕심을 가지고 있다. 그럼에도 이 코드를 짠 사람은 그러한 욕심을 뒤로한 채, 자원을 고려해서 최선을 다해 짠 코드라고 생각하기 때문이다.

이런 마음이 든다면, 어느 순간 다른 사람들의 코드에 좀 더 너그러워진다.
그렇기에 오버엔지니어링은 비즈니스와 자원(시간, 사람)에서 어느정도 허용해야 하지 않을까.

우리는 오버엔지니어링에 대한 경계를 하면서도, 동시에 관용적이어야 하지 않을까. 왜? 이것은 블랙박스이며, 미래에 대한 투자이기 때문이다.

🚀 마치며

사실 내 프로젝트가 더 잘되고 싶은 마음에, 더 코드를 확장적이면서도 안정적으로 설계하면서도, 하여금 이렇게 짜여진 코드가 너무 과하지는 않은지 걱정하다 보니 이러한 생각들을 머리 속에 수놓게 됐다.

나를 변명(?)하는 것일 수도 있지만, 비즈니스와 자원 속에서 아직은 과하다 싶은 디자인으로 엔지니어링된 코드는 비즈니스적인 고려가 있었다면 충분히 서로 맛볼 기회가 있어야 한다고 생각한다.

결국에 오버엔지니어링인지, 적정엔지니어링인지 판단하는 것은 다같이 고민해야 할 일이기 때문이다. 그 과정이 어떻게 되든, 서로 고민하면서 성장하는 것이 결국 개발자로서의 삶이 아닐까.

여튼, 이 글을 쓰는데 꽤나 오랜 시간이 걸렸지만, 충분히 이 의식의 흐름을 따라가본 것은 충분히 가치있는 일이었던 것 같다.

오늘도 설계와 씨름을 하는 개발자 분들 모두 화이팅하시길 바라며. 이상.