왜 XXX를 썼는데도 코드가 쓰레기 같을까?

여러분은 뇌절을 해 본적이 있나?

다른 말로 하자면, 뭔가 유망해보이는 기술을 썼는데도
처음에는 괜찮다 싶다가도 결국 좆같아지는 코드에 뚝배기가 깨져 본 적이 있나?

왜 XXX를 썼는데도 코드가 쓰레기 같을까?
XXX에 지금 최고라고 생각하고 있는 기술이든 방법론이든 넣어 보라.

왜 DB를 썼는데도 코드가 쓰레기 같을까?
왜 OOP를 썼는데도 코드가 쓰레기 같을까?
왜 디자인 패턴을 썼는데도 코드가 쓰레기 같을까?
왜 TDD를 썼는데도 코드가 쓰레기 같을까?
왜 C++을 썼는데도 코드가 쓰레기 같을까?
왜 타입스크립트를 썼는데도 코드가 쓰레기 같을까?
왜 함수형을 썼는데도 코드가 쓰레기 같을까?
왜 Clojure를 썼는데도 코드가 쓰레기 같을까?

나는 이런 일을 수도 없이 경험했다.

작년에만 네 번을 "이렇게 하면 되겠지" 하고 생각한 프로그램에
[네 번 다 대가리가 깨져 버렸다.] #toDO

무엇이 잘못된 걸까?
왜 이런 현상이 일어날까?

일 년 이상 고민하고 다양한 생각을 접하고 나서야 이 현상의 본질을 알게 되었다.
그것은 "문제"에 대한 생각 없이 "해답"만을 생각했기 때문이다.

위에 나열한 XXX의 예시를 다시 보자. XXX는 전부 "해답"이다.
우리가 적용 가능한 기술은 전부 "어떤 문제"를 해결하는 "해답"이다.
그러나 그 해답이 지금 당신이 맞닥뜨린 문제를 해결하리란 법은 없다.

해답만을 생각하면 뇌절을 하기 십상이다.
생각해낸 해답이 정말로 풀려는 문제를 해결하는지 의식적으로 확인을 해야 한다.

남들이 좋다는 XXX나, 다들 쓴다는 XXX나, 아무튼 그냥 느낌으로 문제를 해결해줄 거 같은 XXX는
내 경험상 늘 뚝배기를 터뜨려 버렸다.
그걸 적용해서 잘 된다고 해봤자 그건 그냥 운이 좋았을 뿐이다.
우연과 광기의 프로그래밍일 뿐이다.

프로그램은 문제의 "해답"이다. 이 명제를 반박하는 사람은 없을 것이다.
그런데 많은 프로그래머들이 문제를 푸는 게 아니라 아무튼 해답을 열심히 만들어대고 있을 뿐이다.
그 해답이 문제를 풀 수 있는지에 대한 깊은 생각 없이 그냥 만들고 있는 것이다.

프로그래밍은 문제 해결 과정이 되어야 한다.
프로그램은 문제를 해결하는 해답이 되어야 한다.

그러기 위해서 문제를 해결할 거라 생각하는 해답이
정말로 문제를 해결하는지 항상 확인해야 한다.
가능하면 짜기 전에.