아키텍트 이야기 - 프로젝트의 성공을 위한 지휘자, 아키텍트가 되자.

사실 프로젝트를 진행해오면서 표준이 필요하다는 생각이 많이 들었습니다.

XP에서도 주장하는 것은 죽은 문서를 만들지 말자는 것이지, 문서를 만들지 말자는 것이 아니듯이, 필요한 문서라면, 자주 참고해야 되는 내용이라면 당연히 문서화 하는 것이 맞습니다.

프로젝트가 오래 진행될 수록 네이밍, 클래스 상관도, 기본 설계 방침과 같은 것들에 대한 필요성이 절실했습니다.

아키텍처가 없을 때 같은 일을 하는 메소드가 중복 되고, 어떤 클래스는 크고 어떤 클래스는 작고, 어설픈 패턴적용으로 클래스 간의 관계가 모호하거나 복잡하고, 기능별 처리 주체 불분명해지는 등의 많은 문제를 안게 됩니다.

이런 문제를 책임지고 해결해줄 사람이 바로 아키텍트였습니다. 이 책에서는 아키텍트를 책임 설계자라고도 칭했는데, 아키텍처와 프레임 워크를 통해 성공적인 프로젝트를 위한 가이드라인을 제시하는 역할을 하는 것이죠.

책에서도 말했듯이 프레임 워크는 표현력을 감소 시키는 악영향과, 프레임 워크가 제공하는 범위를 벗어났을 때 기술적인 문제, 설계적인 문제가 동시에 발생하기도 합니다.

그렇지만 전반적으로 프레임 워크가 생산성 향상이나, 유지보수에 이득을 가져다 준다는 점에서 상황에 따라 적절히 활용하면 좋겠다는 생각이 들었습니다.

아키텍트는 이런 기술적인 문제만이 아니라, 팀원들을 리드하는 리더쉽, 비 기술자와 기술자 사이의 절충과 같은 다양한 역할을 맡고 있었습니다.

우리나라에서 일반적인 관리자로써 불리는 직책에 계신 분들이 하는 일과 다른점은, 기술적으로 좀 더 관여한다는 점인데 이 부분이 매력적인 직책이란 생각이 들었습니다.

이 책을 읽고 프로젝트의 성공을 위해 프로그래머보다 좀 더 많은 기여를 할 수 있는 아키텍트가 되고 싶단 생각이 들었습니다. 물론 그러기 위해서는 우선 다양한 경험을 통해 좋은 프로그래머가 되어야겠지만 말이죠.