기능이 형태를 지배해야 한다
아래는 문래학당 임춘봉훈장님께서 편집해주신 루이 설리번의 고전이다.
내가 아키텍트 혹은 설계자로써 딱 하나 잊지 않는 유일한 공학원리 항목이기도 하다. 공학적 배경지식이 없거나 건축에 소프트웨어 설계 은유를 하는 부분이 생소한 분을 위해 가벼운 글을 쓴다.
핵심가치가 무엇이냐? 혹은 너 기능이 뭐야?
가장 중요한 질문이다. '당신은 뭐하는 사람이냐?'라는 질문이 나타내는 바와 같다. 공존을 전제로 할 때 정체성을 묻는 것이다. 개성 말고 당신이 봉사하는 바 혹은 만들어내는 사회적 가치를 묻는 질문이다. 정체성에 따라 행동하라는 말로 바꿔도 크게 틀리지 않다.
RESTful architecture 혹은 Micro-Services Architecture
목적이 될 수는 없다. 재작년 봄인가 모 업체 팀장님 고민을 듣고 FFF에 입각한 조언을 해드린 일이 있다. 하지만, 국내에서는 대단히 소수인 인터넷 서비스 업체가 아닌 이상 비즈니스와 IT가 동등한 위치에서 시너지를 내기는 힘들다. 외산 장비와 기술 도입으로 시작한 전산실 문화가 (숫자로는) 주종을 이룬다. 그렇다보니 IT 경험이 없는 경영자분들이 간접경험으로 IT 의사결정을 해야 한다. 또한, 고용 경직성 회피를 위해 외부 업체에 시스템 구축을 의뢰하다보니 조직내에 노하우가 쌓이지도 않는다.
만일 여러분 조직이 MSA 혹은 REST 등의 키워드로 고민하신다면 적은 투자로 ROI를 확인하는 실험부터 하시라고 조언하고 싶다. 이에 대해서는 다음에 기회가 되면 RAT 개념을 설명하면서 다룰 수도...
버려야 할 베스트 프랙티스 신화
아직도 계획 수립하며 Best Practices를 필수 양념처럼 말씀하는 분들이 있다. 그런 식은 청산해야 할 과거가 된지 오래다. 현재의 시장 변화는 다른 기업이나 과거에 벌여졌던 성공사례가 재현되길 기대할 수 있는 상황이 아니다. Time-to-Market을 놓쳐 가면서까지 BP를 따지는 이유는 단 하나다. 내 자리가 위태로울까봐... ^^;
Domain-driven development의 참 의미
가장 좋아하는 책 중 하나다. 하지만, 구현은 해보지 못했다. 아직은...
허나 도메인 주도의 참 의미는 다양한 패턴을 다루는 프로그래밍 모델에 있지 않다. 진짜는 먼저 현장 중심의 비즈니스 친화적 사고와 결부되어야 의미는 갖는다. 그게 아니라면 그저 예쁘게 코드를 만들자는 개발자 개인의 욕구 실현일 뿐이다. 또한, 현장 중심 대신 문제 중심이라고 말할 수도 있다. 도요타의 5Whys처럼 문제를 다양한 관점에서 바라보고 근본 원인까지 발굴하는 노력... 그것이 DDD라는 도구를 활용해 목적을 달성하기 위한 필수 요건이 아닐까 싶다. (실제 구현은 해내지 못해서 그저 생각에 지나지 않지만)
결론
주객전도를 막아야 한다. 목적이 형태가 되어선 안된다. 순수예술이라면 이야기가 다르지만, 응용을 다루는 공학이라면... 목적(기능)을 도외시하고 형태(UI 거나 코드)가 우선시되는 개발은 지양해야 한다. 요즘은 애자일도 형식에 치우치는 경향이 있는데... 그 문제도 기회가 되면 Un-애자일을 다루는 글로 다시 여러분을 만날 날을 기다린다. ^^
