현실

뿌리

하고자 하는 일이 어떤 철학을 가지고 있는지 또는 어떤 뿌리로 부터 시작된 것인지를 인식하는 것은 중요하다. 사실 S/W 공학도 다른 분야에 있는 공학적 개념을 가져온 것이 많다. 예를 들면, 설계와 코딩를 칼로 자르듯 구분짓는 행위가 거기에 속한다. 이것은 순수하게 S/W에서 시작된 개념은 아니다.

제조(manufacturing)는 소프트웨어 개발에 대한 메타포(은유)로 자주 사용되곤 한다. 이 메타포로부터 얻게 되는 한 가지 결론은 고도로 숙련된 엔지니어는 설계를, 덜 숙련된 노동자는 제품을 조립한다는 것이다. 이 은유는 소프트웨어 개발은 모든 것이 설계라는 한 가지 단순한 이유로 많은 프로젝트를 엉망으로 만들어 왔다.- Eric Evans, Domain-Driven Design

설계와 코딩

설계자는 설계하고, 코더는 설계에 맞추어 코딩한다는 생각 즉, 설계와 코딩을 분리할 수 있다는 생각에 난 반대 의견을 가지고 있다. 코딩을 수준 낮은 행위로 단정 짓는 사람들의 태도에 불쾌감을 느낀다. 완벽한 설계는 존재할 수 없으며 코딩은 설계를 완성하는 단계가 아닐까 한다.

코딩도 설계 활동이다.

이렇게 말하면 빈약일까? 나는 그렇게 정의해야 이상과 현실의 괴리감을 극복할 수 있다고 생각한다.

물론 추상화 레벨이 높아서 코딩과 멀어진 설계가 있을 수 있다. 필요에 따라 다양한 이해 관계자와 커뮤니케이션 해야 하기 때문이다. 이를 위한 적당한 View가 존재한다.

현실I

현실은 불안하다. 계속된 혼란과 수시로 바뀌는 생각에 회의적인 생각이 스쳐지나갈 때가 있다. 내가 하는 일이 정말 의미가 있는지에 대해 계속 질문하게 된다. architect 가 바라봐야 할 적당한 View의 Level을 찾기가 쉽지 않다. Code Level 에서 돕지 않으면 무시를 당하기도 하고, 반대의 경우엔 숲, 전체를 보지 못한다고 욕을 먹을 수도 있다.

또 다른 한가지는, S/W 외부에서 시작된 다양한 툴을 S/W에 맞추려는 시도에 대한 답답함이다. 물론 Design Pattern 과 같이 건축에서 아이디어를 따서 S/W에 적용한 좋은 사례도 있지만.

현실II

회사의 규모가 크면 다양한 혁신의 툴을 가지고 온다. 사실 그 누구도 부정적인 의견을 내기 쉽지 않다. NO! 라고 말할 수 있는 사람은 거의 없다. “대안 없는 비판은 지양하자”는 논리 앞에 아무 말도 못하고 있을 때가 많다. 제조사에서 S/W 개발을 하다보면 그 시작이 S/W의 본질과 거리가 먼 것들이 많다. 맞지 않는 옷을 입으려는 노력이 안타깝다.

결론

S/W 의 본질은 “사람”에서 출발한다. 자발적이고 창조적 행위인 S/W 개발을 잘 맞지 않는 툴에 끼워놓으려는 수많은 시도에 소극적으로(속으로) 반대한다. 그것은 S/W 개발을 수동적으로 만들며 책임을 회피하게 만들고 형식적인 결과를 만든다.

S/W 개발은 S/W 의 속성(본질)을 잘 이해하는 툴로 혁신할 수 있도록 해주면 좋겠다.

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Google photo

Google의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

%s에 연결하는 중