개발자가 오류 만들 수 있다. 당연한 거다. 사람이 만드는 건데 오류 안생기면 그게 이상한거지…. 정말로 오류가 없다면 그건 진짜로 오류가 없거나 아니면 오류가 숨는 경우인 거다. 근데 대부분은 후자의 경우이다. 전자의 경우대로라면은 사용자의 요구 조건에 따라 전부 다 진행되었다는 것을 표현하는 것이지 그게 오류 없는 완벽한 코드라는 것이 아니다.
근데 이넘의 오류가….
수정 불가능한 오류일 경우가 허다하다. 그 덕에 진짜 많은 코드를 새로 짰다.
수정 불가능한 코드… 만들기 쉽다. 대게는 설계 미스상에서 생기는 꼼수 부리다가 더 이상 어떻게 할 수 없는 경우에서 많이 일어난다. 이 외에는 아예 처음부터 특정 패턴, 특정 설계 방식에만 맞춰서 이용하려다가 나중에 알고보니 이렇게 짜면 안되는 거였다. 그래서 수정하려면 전부 다 고쳐야 한다 이런 식인데…. 뭐, 오씨의 코드는 양쪽 다 가지고 있었다.
앞에껀 뭐 누구나 할 수 있는 거다. 시간에 쫓기고 진행상황 체크하고 하는 거에 쫓기고 하다 보면 개발자가 그때그때 잠깐 넘기기 위해서 여러모로 구상하여 짤 때가 있다. 이게 나중에 리펙토링이 되어서 어느 정도 여유가 있는 코드로 바뀌고 그러면 좋은데 문제는 그게 안쉽다는 거…ㅡㅅㅡ 그런 코드들이야 뭐 여러모로 나중 가서 더 깊게 생각해서 해결하고 하는 경우도 있겠지만 보통은 왜 이럴 수 밖에 없었다는 것이 개발 기록이나 코드에 많이 남는다. 특수한 상황에 대한 해결을 못해서 하는 경우가 은근히 많기 때문이다. 이런 건 나중에 QA에서도 나타날 수 있고, 나중에 프로그램 사용 도중에도 터질 수 있는 것들이라 항상 경계해야 한다.
문제는 뒤에꺼다.
이건 좀…. 이런 걸 했을 경우에 다시는 이런 걸 하면 안된다는 걸 배워야 한다. 실제로 회사 입사할 때에나 대학교 3,4학년들한테서 여럿 보이는 증상 중 하나가 이제 본인이 좀 공부 좀 해서 여러모로 짤 수 있으니 이러면 좀 더 좋겠다 저러면 좀 더 좋겠다는 것이 보이는 건 좋은데…. 그걸 했을 때에 대해서 깊은 사고가 덜 미치는 경우가 있다. 그래서 실제로 구현하고자 하는 내용대로 초반에는 되었는데 나중에 가면 갈수록 요구사항이나 수정사항이 생기고, 그에 따라서 변경해야 할 때에 더 이상 변경되지 않는 설계 구조를 가진 경우… 그로 인해서 사용자의 데이터까지 침해할 수 있는 심각한 오류…. 거기다가 이게 돈 계산 문제라고 생각해봐라. 엄청나게 심각한 거다.
자 이런 문제를 일으킨 거에 대해서는 좋다. 그렇다 쳐. 이제 해결을 해야 하는데… 두 가지 반응을 보인다. 하나는 이거에 대해서 반성을 하는 사람이고, 다른 하나는 그냥 오류 중 하나 터진 거니깐 그냥 수정하고 말면 되는 거 아니냐는 반응이다.
전자는 그냥 자기 혐오에만 안 빠지면 충분히 자기 개발이 될 사람이다만… 후잔 절대 반성 안한다. 이 문제가 나중에 여기저기서 말 나오면 그때에는 적반하장이 뭔지 보여줄 정도로 이야기 꺼내는 사람마다 죄다 시비걸고 싸울 꺼다. 이런 식으로 가는 개발자가 그냥 기술만 익히고 자기 기교만 부린다고..? 그러면서 무슨놈의 개발을….
이런 자기 반성도 안되는 개발자들은 익스퍼트 비기너가 되면서 이런 비슷한 실수를 계속 반복할 것이다. 그러면서 자기가 짜는 구조대로만 돌아가는 코드를 만들어놓고는 이 대로 사용자들이 써야만 하는 걸 왜 이해 못하냐고 지랄하겠지…. 이렇게 개발 년수가 몇 년 단위로 쌓인다고 해서 뭐 제대로 만족스러운 프로그램 개발을 할 수 있을까?
그래서 많은 사람들이 설계를 어렵다고 하는 거다. 그냥 쉽죠 하고 덤볐다가 나중에 사양 변경을 위해 여러 검토를 해야 되는데 설계 단계에서 문제가 터진다..? 이러면 그냥 못하는 거다. 설계부터 다시 해야 하는 거다…. 아니면 코드를 밑바닥부터 다 드러내서 싹 다 고쳐야 되는데.. 이 고치는 과정 중에 데이터베이스까지 건드리고 하는 사태가 벌어져서 사용자 데이터가 훼손되고 그러면…. 그것도 라이브 서비스 중에….
……아 상상도 하기 싫다.
그리고 그걸로 지금 내가 스트레스 너무 받고 있어서… 너무 힘들다….