얼마 전부터 내가 맡은 일은, 기존에 다른 이가 기획하고 코딩한 도구를 판매용의 새 프로젝트에 이식하는 것이다. 그리고 이는 마이그레이션을 포함하고 있다.
문제는 현재 만들고 있는 상품에서 내가 맡은 부분을 제외하면 대부분 자신이 코딩한 부분을 계승하고 있거나 아직 그 도구를 만든 이가 회사에 남아있는 반면, 본인이 맡은 부분은 그렇지 않다는 점에 있고, 더군다나 이전에 그 부분을 코딩했던 사람이 만들었던 도구들이 상당히 엉망이라는 점이다.
그런데 중요한 점은, 코딩이 엉망이라는 것이 아니다. 코딩이 엉망인 것은 경험 부족의 산물이나 성의없는 작업의 결과일 수도 있지만, 당시의 프로젝트 방향이나 상황에 따라 그런 것일 수도 있기 때문이다. 솔직히 그 부분이 짜증이 안 나는 것은 아니지만 그것 자체는 그래도 납득할 수 있는 문제이다. 오히려 심각한 것은, 코딩 자체의 질이 문제가 아니라 도구의 설계 시점에서 애당초 방향성이 제대로 잡혀 있지 않았다는 점이다.
이전에 만들어진 도구를 보면, 같은 계통에서 유명한 모 도구의 기능을 고스란히 옮겨놓고 있다. 문제는 이것이 ‘겉보기로만’ 옮겨놓았다는 데에 있다. 애당초 참고했던 원래의 도구가 실현하려고 하는 ‘관점’ 을 이해하지 않은 채로 단순히 베껴 만든 탓에, 확장성이니 독립성이니 뭐니 하는 거창한 것은 다 집어치우고, 내부적인 구조 자체에 통일성이 없다. 좀 더 엄밀히 말하면 ‘모습만 똑같게’ 만들려고 했기 때문에, 참고했던 도구의 ‘겉 껍데기 수준만’ 나타내고 있을 뿐, 실질적으로는 그렇게 동작하지 않는다.
만약 이 도구를 작성했던 사람이 참고했던 그 도구의 ‘방향성’ 을 이해하고 그 도구의 구조에 대해 이해하려는 노력이 있었다면, 그 도구의 기능 중 도저히 이식하지 못한 기능이라는 것이 있지 않았을 것이다. 왜냐하면, 그 부분에 대한 충분한 이해가 있었을 경우에는 구현할 수 없을 것 같은 기능이 무엇인지를 인지하고 다른 방향으로 도구의 구현 방향을 맞추거나 하는 등의 대응책을 마련했을 것이기 때문이다. 하지만 현재 도구는 그렇지 못하다. 그리고 그렇기 때문에 어디서 현재 방식으로 코딩한 것이 문제가 발생하는지조차 이해하지 않은 상태로 코딩되어 있다.
최소한 어떠한 도구를 제작할 때 그것의 기반이 되는, 혹은 참고가 되는 도구를 선정했다면, 그 도구가 가지는 방향성, 관점에 대한 이해를 수반해야만 한다. 그리고 그렇지 않다면 스스로 자신만의 방향성과 관점을 설정하고 그에 맞추어 제작을 수행해야만 한다.
이것이 없다면 현재 자신이 코딩하는 것이 무엇인지조차 모르는 상황이 충분히 발생한다. 사람의 생각은 언제나 변하기 마련이고, 따라서 본인 자신조차도 시간에 따라 생각하는 바가 달라진다. 따라서 이러한 방향을 고정하지 않으면 자신이 코딩하는 모듈 내에서조차 이랬다가 저랬다가 하는 상황이 발생한다. 그렇지 않다면 애당초 코드 자체가 생각할 필요도 없이 단순무식하게 되어 있든가 (Copy & Paste 로 대변되는). 그리고 이런 상황은 결과적으로 코드가 너저분해지고 디버깅을 어렵게 만드는 상황을 일으키게 된다.
프로그래밍을 위한 다양한 설계 표현 방식은 기본적으로 이런 관점을 표현하기 위한 수단이다. 하지만 대부분의 경우 이 수단을 목적으로 착각하고 있는 듯 하다. 그러니까, 다시 말하면 ‘도구의 설계사상’ 이 구축되고 이를 표현하기 위해 설계 표현 방식을 사용하는 것이지, 설계 표현 방식을 통한 문서가 완성되었다고 ‘도구의 설계사상’ 이 이루어진 것은 아니라는 것이다. 하지만 대부분의 사람들은 착각한다. 그 문서가 완성되었다고 설계가 완성된 것이라고.
실질적으로 중요한 것은 그것이 아니다. 만약 정확하게 설계사상만이라도 잡고 있다면 모듈을 이해하기 위해 저런 설계문서 따위는 굳이 필요하지 않다. 엄밀히 말한다면, 사실 메소드에 대한 설명이나 부분적인 주석 등도 굳이 필요한 것은 아니다. 저런 방향성이 충분하다면, 코드 자체가 무슨 일을 하는 것인지 스스로 표현하고, 프로그래머들은 이러한 소스코드만으로 이 도구가 어떤 일을 어떻게 수행하는지 이해할 수 있다. 이것이 잘 되어 있는 것이 우수한 코드이고 실제로 널리 알려진 수많은 우수한 코드들이 그러하다. 특히 Java 나 C# 등 자신의 설계사상을 코드만으로도 충분히 표현할 수 있는 언어라면 더욱 그렇다. Java API 코드들이 그 중요한 예 중 하나이다. 오히려 설계 표현 문서는 그렇게 개발자들이 작업한 도구들을 어떠한 방식으로 서비스 할 것인가에 중요하다.
문제는 현재 만들고 있는 상품에서 내가 맡은 부분을 제외하면 대부분 자신이 코딩한 부분을 계승하고 있거나 아직 그 도구를 만든 이가 회사에 남아있는 반면, 본인이 맡은 부분은 그렇지 않다는 점에 있고, 더군다나 이전에 그 부분을 코딩했던 사람이 만들었던 도구들이 상당히 엉망이라는 점이다.
그런데 중요한 점은, 코딩이 엉망이라는 것이 아니다. 코딩이 엉망인 것은 경험 부족의 산물이나 성의없는 작업의 결과일 수도 있지만, 당시의 프로젝트 방향이나 상황에 따라 그런 것일 수도 있기 때문이다. 솔직히 그 부분이 짜증이 안 나는 것은 아니지만 그것 자체는 그래도 납득할 수 있는 문제이다. 오히려 심각한 것은, 코딩 자체의 질이 문제가 아니라 도구의 설계 시점에서 애당초 방향성이 제대로 잡혀 있지 않았다는 점이다.
이전에 만들어진 도구를 보면, 같은 계통에서 유명한 모 도구의 기능을 고스란히 옮겨놓고 있다. 문제는 이것이 ‘겉보기로만’ 옮겨놓았다는 데에 있다. 애당초 참고했던 원래의 도구가 실현하려고 하는 ‘관점’ 을 이해하지 않은 채로 단순히 베껴 만든 탓에, 확장성이니 독립성이니 뭐니 하는 거창한 것은 다 집어치우고, 내부적인 구조 자체에 통일성이 없다. 좀 더 엄밀히 말하면 ‘모습만 똑같게’ 만들려고 했기 때문에, 참고했던 도구의 ‘겉 껍데기 수준만’ 나타내고 있을 뿐, 실질적으로는 그렇게 동작하지 않는다.
만약 이 도구를 작성했던 사람이 참고했던 그 도구의 ‘방향성’ 을 이해하고 그 도구의 구조에 대해 이해하려는 노력이 있었다면, 그 도구의 기능 중 도저히 이식하지 못한 기능이라는 것이 있지 않았을 것이다. 왜냐하면, 그 부분에 대한 충분한 이해가 있었을 경우에는 구현할 수 없을 것 같은 기능이 무엇인지를 인지하고 다른 방향으로 도구의 구현 방향을 맞추거나 하는 등의 대응책을 마련했을 것이기 때문이다. 하지만 현재 도구는 그렇지 못하다. 그리고 그렇기 때문에 어디서 현재 방식으로 코딩한 것이 문제가 발생하는지조차 이해하지 않은 상태로 코딩되어 있다.
최소한 어떠한 도구를 제작할 때 그것의 기반이 되는, 혹은 참고가 되는 도구를 선정했다면, 그 도구가 가지는 방향성, 관점에 대한 이해를 수반해야만 한다. 그리고 그렇지 않다면 스스로 자신만의 방향성과 관점을 설정하고 그에 맞추어 제작을 수행해야만 한다.
이것이 없다면 현재 자신이 코딩하는 것이 무엇인지조차 모르는 상황이 충분히 발생한다. 사람의 생각은 언제나 변하기 마련이고, 따라서 본인 자신조차도 시간에 따라 생각하는 바가 달라진다. 따라서 이러한 방향을 고정하지 않으면 자신이 코딩하는 모듈 내에서조차 이랬다가 저랬다가 하는 상황이 발생한다. 그렇지 않다면 애당초 코드 자체가 생각할 필요도 없이 단순무식하게 되어 있든가 (Copy & Paste 로 대변되는). 그리고 이런 상황은 결과적으로 코드가 너저분해지고 디버깅을 어렵게 만드는 상황을 일으키게 된다.
프로그래밍을 위한 다양한 설계 표현 방식은 기본적으로 이런 관점을 표현하기 위한 수단이다. 하지만 대부분의 경우 이 수단을 목적으로 착각하고 있는 듯 하다. 그러니까, 다시 말하면 ‘도구의 설계사상’ 이 구축되고 이를 표현하기 위해 설계 표현 방식을 사용하는 것이지, 설계 표현 방식을 통한 문서가 완성되었다고 ‘도구의 설계사상’ 이 이루어진 것은 아니라는 것이다. 하지만 대부분의 사람들은 착각한다. 그 문서가 완성되었다고 설계가 완성된 것이라고.
실질적으로 중요한 것은 그것이 아니다. 만약 정확하게 설계사상만이라도 잡고 있다면 모듈을 이해하기 위해 저런 설계문서 따위는 굳이 필요하지 않다. 엄밀히 말한다면, 사실 메소드에 대한 설명이나 부분적인 주석 등도 굳이 필요한 것은 아니다. 저런 방향성이 충분하다면, 코드 자체가 무슨 일을 하는 것인지 스스로 표현하고, 프로그래머들은 이러한 소스코드만으로 이 도구가 어떤 일을 어떻게 수행하는지 이해할 수 있다. 이것이 잘 되어 있는 것이 우수한 코드이고 실제로 널리 알려진 수많은 우수한 코드들이 그러하다. 특히 Java 나 C# 등 자신의 설계사상을 코드만으로도 충분히 표현할 수 있는 언어라면 더욱 그렇다. Java API 코드들이 그 중요한 예 중 하나이다. 오히려 설계 표현 문서는 그렇게 개발자들이 작업한 도구들을 어떠한 방식으로 서비스 할 것인가에 중요하다.
반응형