보통 개발자 커리큘럼에 설계는 없다.
이외에도 여러 팀 프로젝트 등을 거치면서도, 설계를 제대로 해보고 취업하기란 쉽지 않다.
실무를 하면 자연스레 탄탄한 설계를 하고 일하는 줄 알았다.
막상 실무를 해보니, 설계 시간이 없거나, 요구 사항이 모호한 경우가 많았다.
내가 일해온 회사와 프로젝트 경험 상 설계를 해주는 아키텍트도 못 만나기도 했고, 그렇다 보니 나름의 방식의 설계를 하고 구현하게 됐다.
완벽한 설계를 경험해보지 못한 사람이 설계를 이야기 하는 것이 이상하게 들릴 수 있지만, 적지 않은 개발자가 나와 같은 상황이었을 거고, 앞으로도 그럴 수 있음을 감안하면 나는 설계를 거창하게 바라보기 보다는 구현을 돕는 계획과 같은 수준의 설계로도 충분히 이득을 볼 수 있다고 생각한다.
당연한 얘기지만, 아주 섬세하고 세부적인 부분까지 설계해야 되는 업무를 주로 해오신 분께는 해당 되지 않는 이야기다.
구현의 돕는 설계의 예시
- 시퀀스 다이어그램
- Domain 정의 및 역할 정의
- 필수 조건
- 충족되는지 모든 과정에서 검토 되어야 함
- 전제 조건
- 구현할 기능이 동작하는 데에 필요한 전제 조건
- 팀 내 규칙
- 계획이 팀 내의 구현 규칙을 준수하는가?
- 구현 난이도
- 이미 존재하는 기능만을 이용해 구현 가능한가?
- 기존 규칙들을 따르는 것만으로 구현에 이슈가 없는가?
- 레이어의 기준
- 그 기준에 부합하게 계획되어있는가?
예시 일 뿐 모든 항목에 부합해야만 작업을 진행한다가 아니라, 작업 할 때 마다 고민해보면 좋을 목록이라고 봐도 좋다.
중요한 것은, 어떻게 구현할지가 머릿속에 그려지고 이를 기록으로 옮길 수 있느냐다.
텍스트도 좋고 excalidraw같은 다이어그램 도구도 좋다.
같은 팀 동료가 그 자료를 보자마자 이해할 수 있다면 더 좋겠지만, 적어도 자신이 다시 봤을 때 이해가 될 정도의 기록이면 설계로 의미를 가질 수 있다.
그리고 구현 하면서의 과정, 작업 완료 후 예상과의 차이를 기록함으로써 설계와 구현의 오차를 파악하고 개선할 수 있는 기회로도 쓸 수 있다.
사실 우리가 설계에 시간을 많이 받을 수 있는 프로젝트가 흔치 않다.
그렇다 보니 나름의 효율적 설계의 수준을 일하는 회사와 팀, 시기에 맞춰서 조정하면서 일하게 되는데, 계획을 세우며 일하는 습관의 일환으로 시도해보며 그 수준을 조정해보는 것도 좋은 성장의 방식이라고 생각한다.