개발자가 비즈니스적 고민도 필요할까?(2)

나무를 넘어서 숲을 봐야하는 이유

과거에 필자는 코드를 보다 깔끔하고 우아하게 작성하려는 노력의 일환으로, DDD(도메인 주도 설계)와 클린 아키텍처(Clean Architecture)에 관한 자료들을 크롬 탭에 수십 개 열어놓고, 단 한 줄의 코드를 작성하기 위해 몇 시간을 할애한 적이 있다. 이 글을 읽는 많은 개발자분들 역시 필자와 유사한 경험을 하셨을 것이라 생각한다.

 

필자는 깔끔하고 완벽한 코드를 작성하기 위한 노력하다가 프로젝트를 기한 내에 완수하지 못하게 한 경험이 있다. 이러한 경험을 통해, 단순히 코딩(나무)에만 집중하는 것이 아니라, 코딩+α(숲)를 고려하는 관점에서 사고하는 것이 중요함을 깨달았다.

 

개발자로서 앞으로 발생할 수 있는 상황을 고려하여 유지보수가 쉽고 확장성 있는 설계를 기반으로 코딩하는 것은 중요하다. 하지만, 숲을 보는 관점에서 벗어나 코딩 중심적인 관점만을 생각하기보다는 비즈니스 및 기술적 요구 사항의 중요성을 인식하고, 균형 있는 우선순위를 설정하는 것이 더욱 중요하다고 생각된다.

 

그러면 나무만 보고 숲을 못봤을 때 어떤 문제가 뒤따를까? 예시로 영화"콰이강의 다리"를 통해서 확인해보자.

영화 "콰이강의 다리" 줄거리

제 2차 세계 대전 당시, 영국군 장교인 니콜슨 대령과 그의 부하들은 일본군에게 포로로 잡혀 콰이강 근처의 포로 수용소로 끌려가게 되었다.

포로 수용소에서 일본군 지휘관인 사이토 대령은 포로들에게 콰이강을 가로지르는 철도 다리를 만들라는 명령을 내렸고, 처음에는 명령에 불복했지만, 니콜슨 대령은 부하들의 사기와 영국군의 명예를 위해 다리 건설에 동의하게 되었다.
니콜슨은 다리가 일본군에게 전략적으로 유리하게 작용할 수 있다는 사실을 알면서도 다리를 완성하는 데에만 집중했다.

얼마 후, 미국 특공대가 포로들을 구하기 위해 콰이강에 진입했고, 특공대는 다리에 폭탄을 설치했지만, 다리에 강한 집착을 보이던 니콜슨 대령은 판단력을 잃어버리고 특공대원들을 막으려 했다. 그러나 결국 특공대는 일본군에게 발각되어 모두 사살되었고, 니콜슨 대령은 포격에 의한 파편을 맞고 다리에 설치된 기폭제 위로 쓰러지면서 다리를 폭파시켰다.

 

 

"콰이강의 다리 실수" (a.k.a 숲을 지나치고 나무만 본 경우)

"콰이강의 다리" 문제에서, 니콜슨은 다리 건설이라는 구체적인 과제에만 몰두하여, 그것이 전쟁의 전체적인 맥락에서 어떤 의미를 가지는지를 잊어버린다. 다시말해, 그는 자신의 임무와 기술적인 도전에 성공하는 것에만 집중하다가 그의 노력이 실제로는 적에게 이익을 주고 있다는 사실을 간과하게 된다.

나무 = 다리 건설이라는 구체적인 과제에만 몰두
숲 = 다리가 전쟁의 전체적인 맥락에서 어떤 의미를 가지는지를 잊어버림

 

이러한 상황은 소프트웨어 개발에서도 발생할 수 있다. 개발자나 팀이 프로젝트의 본래 목적이나 목표를 잊고, 기술적인 도전이나 복잡성에 매몰되어 프로젝트가 본래 해결하려고 했던 문제를 간과하게 되는 경우이다. 예를 들면 아래와 같다.

1. 목표에서 벗어남: 개발자가 프로젝트의 궁극적인 목표나 사용자의 필요를 무시하고, 기술적인 완성도나 개인적인 성취에만 집중하는 경우
2. Over-engineering: 프로젝트에 필요 이상으로 복잡하거나 고급 기술을 사용하여, 결과적으로 유지보수나 확장성에 문제를 일으키는 경우
3. 프로젝트 관리 실패: 명확한 우선순위나 목표 설정 없이 프로젝트를 진행하며, 자원이나 시간을 낭비하는 경우

 

위의 문제는 기술적인 성취에만 초점을 맞추고, 그 과정에서 본래의 목적이나 더 큰 가치를 간과하는 상황을 의미한다. 이는 개발자 뿐만 아니라 다양한 분야에서 일하는 사람들이 경계해야 할 일반적인 함정이다. 프로젝트의 비즈니스적 가치와 궁극적인 목적에 대한 인식을 잃지 않기 위해서는, 개발자들이 정기적으로 자신의 작업을 평가하고 전체적인 관점에서 프로젝트를 바라볼 필요가 있다.

숲을 보기 위한 자신만의 원칙을 세워보자.

나무도 중요하지만, 전체적인 숲을 보기 위한 원칙을 하나쯤 만들면 어떨까? 이미 무수한 방법들이 있지만, 필자는 아래와 같은 방법들로 숲을 보기 위해 노력한다.

 

1. 정기적인 목표 재평가: 프로젝트의 진행 상황을 정기적으로 검토하고, 목표가 여전히 유효한지, 혹은 조정이 필요한지 평가한다.

2. 사용자 중심 설계: 사용자의 필요와 경험을 중심으로 생각하며, 기술적인 결정을 내린다.

3. 팀 내 커뮤니케이션 강화: 다양한 배경을 가진 팀원들과의 지속적인 소통을 통해 다양한 관점을 수렴하고, 프로젝트의 목표에 대한 공통된 이해를 구축한다.

4. 단계별 목표 설정: 큰 목표를 달성하기 위한 구체적이고 달성 가능한 단계별 목표를 설정하여, 전체적인 목표에서 벗어나지 않도록 한다.

5. 피드백 반영: 사용자와 이해관계자로부터의 피드백을 정기적으로 수집하고 반영하여, 프로젝트가 올바른 방향으로 나아가고 있는지 확확인한다. 이러한 접근 방식을 통해 개발자는 기술적인 세부 사항에만 몰두하는 것이 아니라, 프로젝트의 더 큰 비즈니스적 가치와 목적을 지속적으로 염두한다.

 

이러한 접근 방식을 통해 필자는 기술적인 세부 사항에만 몰두하는 것이 아니라, 프로젝트의 더 큰 비즈니스적 가치와 목적을 지속적으로 생각는 습관을 만들기 위해 노력한다.

마치며

"나무를 보지 말고 숲을 봐야 한다"는 교훈은 개발자와 더불어 프로젝트를 같이 진행하는 모두에게 중요하다. 우리가 작업하는 개별적인 요소나 기술적인 세부 사항에만 집중하는 대신, 프로젝트의 궁극적인 목적과 사용자의 필요를 계속 염두에 두어야 한다는 것을 상기시켜야 한다.

프로젝트가 전체적으로 어떤 비즈니스적 가치를 창출하는지, 그리고 그것이 사용자나 사회에 어떤 영향을 미치는지를 이해하는 것이 중요하다. 이러한 관점은 더 효율적이고 사용자 중심적인 비즈니스를 개발하는 데 도움이 될 것이라 확신한다.