우리는 보통 개발을 하는 과정에서 여러가지 일을 한다.
Project를 관리 작업과 구현을 위한 개발 작업, 그리고 Issue와 Risk 관리, 비용산정 등
크게 나누어도 적지않은 할일들이 있고 또 지금 하려는 얘기의 대상이되는 개발작업을 좀더 나워보면
요구사항 분석, 설계, 설계를 바탕으로 한 구체적인 구현계획 및 설계 등과 같이 역시 적지않은 작업들로 나뉜다.
서론이 길었는데, 하고자하는 얘기를 하자면,
개발 작업에 있어 Architecture는 결코 관가할 수 없는 중요한 작업이라는 것이다.
많은 개발자들이 설계작업을 그리 중요시 하지않거나 불필요한 작업정도로 치부하는 경우가 많다.
이유로는 대부분, "그럴 시간이 없다", "개발하는데 시간이 너무 올래 걸려", "꼭 해야 해?", "그건 규모가 있는 곳 에서나.."등 들어봄직한 말 들일 것이다.
하지만 절대 그렇지 않다. 절대!
Architecture라는 것은 이런 것 이이다..라고 생각하는 몇 가지 예를 들고자 한다.
하나, 우리가 인생을 살아가는 데 있어 크게 두 가지로 많으들 얘기한다. "짧고 굵게"와 "길고 가늘게".
이것의 선택은 각자의 인생관에 따라 결정될 것이고 그에 따라 인생을 그렇게 살아가거나 그렇게 살고자 의지를 가질 것이다.
하나, 길을 찾아갈 때 출발지에서 목적지로 가는 길은 하나만 있지는 않을 것이다. 하지만 최단거리 경로 또는 최단시간 경로는 있을 것이고
이 또한 그 길을 찾아가는 사람의 목적이나 상황에 따라 결정될 것이다.
하나, 도로에는 신호등을 포함해 도로의 상태나 방향 등을 알리기위한 목적의 표지판이 있다는 것을 잘 알고 있을 것이다.
이 신호등이나 표지판은 전 세계가 함께쓰는 하나의 Protocol이다. 그 덕에 우리는 어디를 가든 운전을 하는데 별 어려움이 없다.
그렇다, 이 처럼 Architecture는 Project가 갖는 성격이나 특성에 따라 방향이 결정되고,
Project의 목적에 맞게 다듬어지며, Project 참여자들이 함께 공유하며 함께 작업할 수 있도록 해주는
최소한의 일정한 규칙이 있는 것이다.
그 것이 Architecture인 것이다.
적어도 나는 그것이 Architecture이고 이의 역할이며 목적이라고 생각한다.
위에서 예로 들지는 않았지만 많이들 건물과 같은 실체를 만들기위한 설계에 많이 비유를 하는데
그것만으로 Software에 있어서의 Architecture를 설명하기에는 너무나 식상하고 뻔한 소리같아 조금 다르게 접근해 보았다.
하지만 이 비유는 매우 잘된 비유에 속하며 절대 식상하지 않은 것이다.
개발 작업을 하다보면 여러차례 요구사항이 바뀌고 그에 따라 Code를 수정하는 작업들이 빈번하게 이루어지고
지금도 그 작업을 하기위해 밤을 세우는 개발자들이 많을 것이다.
건물 얘기를 했으니 건물에 비유해 한 번 생각해 보자.
처음의 요구사항은 1층 건물을 짖는 것이었는데 갑자기 2층짜리 건물로 요구사항이 바뀌었다고 생각해보자.
그럼 건물의 높이가 높아지는 만큼 땅도 더 깊이 파야하고, 2층으로 올리기위해 보의 강도도 높여야하고,
층간 소음, 등 고려해야할 것들이 생기고 그에 따른 추가적인 작업이 요구되는 것 처럼,
Software 개발에서도 같은 일이 마찬가지로 발생한다.
"이럴 때 Architecture가 이런 문제들을 쉽게해결해 주기 때문에 Architecture가 반드시 필요하다."라는 말을 하려고 이런 얘길하는 것은 절대 아니다. 의외로 적지않은 사람들이 오해를 하거나 잘 못된 기대를 하는 부분이기도 하다.
하지만 여기서 Architecture의 역할과 목적은 저런 문제를 쉽게 해결하기위한 것이 아니라
올바르게, 정확히는 Project의 특성과 목적에 맞게 진행될 수 있도록 기준을 잡아준다는 것이다.
어떠한 개발 작업이든 개발자가 단 한 번의 Code 작성으로 완성되는 Code는 없다.
이는 오류로 인한 것이든, 요구사항의 변경으로 인한 것이든 여러 외적 요인으로 인해 변경되는데,
그 때마다 정해진 규칙없이 Code가 작성된다면, 그리고 한 사람이 아닌 여러 사람이 그렇게 작성한 Code는
Code의 owner만 알 수 있는 구조와 Logic을 갖게되며 그나마도 얼마간의 시간이 지나면 Owner 역시 당시 자신이 왜 그렇게 Code를 작성했는지 모른다고한다.
부끄럽지만 이것이 현재의 우리네 개발환경의 현실이다.
다음이 없다. 고도화라는 이름을 붙여 Project를 진행하지만 속을 들여다보면 처음부터 다시 같은 동작을 하는 Code를 다른 개발자가 작성하고있는 것 뿐이다.
슬프게도 말이다.
Architecture에는 목적과 방향성 그리고 철학이 있다.
그에 따라 Code를 작성하고, 수정하고, 생각하고 고민해야 한다.
Architecture에서 정한 규칙을 준수해야 한다.
그럼으로 인해 Code에 일관성이 생기고, 사상이 투영된 Logic을 가지며,
Architecture가 말하는 Protocol 대로 해석이 가능하게 함으로써 그 다음을 바라 볼 수 있게 해준다.
