소프트웨어 아키텍트가 알아야 할 97가지 - 두 번째 이야기
by - Neal Ford
ThoughtWorks사의 소프트웨어 아키텍터. 엔드 투 엔드 개발과 딜리버리에서는 타의 추종을 불허하는 글로벌 IT 컨설턴트. 애플리케이션, 교재, 잡지 기사, 비디오/DVD 프레젠테이션 등의 디자이너이자 개발자이다. 다수의 콘퍼런스에서 발표자로 서고 있다.
"본질적인 복잡성"이라는 것은 문제 자체의 어려움입니다. 예를 들어 항공관제 업무는 본질적으로 복잡한 문제입니다. 모든 항공기의 정확한 위치, 고도 , 속도, 방향, 목적지를 실시간으로 감시하여 공항 근처 상공과 활주로에서의 안전사고를 방지해야 합니다. 끊임없이 급변하는 환경 속에서 공항이 혼잡하지 않도록 비행 스케줄을 관리해야 합니다. 가끔 날씨가 극단적으로 나빠지면 비행 일정 전체가 마비되어 버리는 경우도 있습니다.
"부수적인 복잡성"은 본질적인 복잡성을 해결하기 위해 만든 것에서 부수적으로 나타나는 복잡성을 나타내는 말입니다. 예를 들어, 지금도 사용되고 있는 오래된 항공관제 시스템이 부수적인 복잡함을 설명하기에 좋은 예입니다. 원래는 수천 대의 항공기를 컨트롤하는 본질적으로 복잡한 문제를 해결하기 위해 만들어진 시스템인데 이 솔루션 자체가 너무 복잡하게 만들어져 있습니다. 사실, 지금의 항공관제 시스템은 너무 복잡해서 업데이트가 불가능한 것은 아니지만 그에 버금갈 정도로 매우 어렵습니다. 전 세계의 많은 항공관제 시스템들이 이미 30년도 더 된 오래된 테크놀로지로 운용되고 있습니다.
벤더가 말하는 "솔루션"이라는 것도 상당수, "부수적 복잡병"의 징후를 보입니다. 개별적인 문제를 해결해 주는 프레임워크도 때때로 도움이 되지만 그 범위가 넓으면 도움을 주는 것 이상으로 새로운 복잡함을 초래하게 됩니다.
개발자는 마치 불속에 뛰어드는 나방처럼 복잡한 곳으로 뛰어드는 습성이 있습니다. 개발자는 퍼즐을 푸는 것을 좋아하고, 문제를 푸는 것이 일인 직업입니다. 엄청나게 복잡한 문제를 착착 해결해 보이고 싶으시죠? 생각만 해도 멋집니다. 하지만 대규모 소프트웨어의 경우, 본질적인 복잡성을 해결하면서 부수적인 복잡성까지 배제하는 일은 매우 어렵습니다.
그럼 어떻게 하면 좋을까요? 우선 벤더가 말하는 솔루션은 일단 의심하고 착수합시다. 물론 벤더가 하는 말이 다 틀린 말은 아닙니다. 하지만 벤더는 무심코 부수적인 복잡성을 늘리곤 합니다. 벤더의 해결책이 제대로 문제와 매칭 되도록 컨트롤해야 합니다. 그리고 연구와 고심 끝에 도입한 프레임워크보다 작업에서 파생된 프레임워크를 선호하는 것이 좋습니다. 비즈니스 문제를 직접 해결하는 솔루션 코드의 비율을 확인해야 합니다. 시스템 안에 정말 필요한 코드는 얼마나 되나요?
부수적인 복잡함을 배제하고 본질적인 복잡함 안에 숨어있는 문제를 해결하는 것이 아키텍트의 일입니다.
by Pixabay.
[라이선스] 이 글은 [CC-by-3.0-US] 에 의해 라이선스 되었습니다.
'97가지이야기시리즈 > 소프트웨어아키텍트' 카테고리의 다른 글
| 가장 큰 문제는 기술적인 문제가 아니다 (0) | 2021.06.27 |
|---|---|
| 시스템 구성 요건보다 이력서의 겉모양이 우선시 되어서는 안 된다 (0) | 2021.06.15 |
댓글