Karen
15k
2016-02-17 12:46:11
4
2287

Brunch with Roaster Kay - 오함마를 든 건축가



개발은 종종 건축과 비교되곤 합니다. 좋은 설계자와 설계도가 제품을 성공적으로 이끌 확률이 높고, 만들 제품과 관련된 도메인 지식이 많으면 꽤 도움이 됩니다. 소싯적에 병원에서 근무한 적이 있었는데, 병원 건물을 설계한 업체가 그 전까지 주로 사무실형 빌딩을 설계/시공해 왔다고 합니다. 덕분에, 병원을 방문한 환자는 마치 아내를 대신해 처음 대형마트를 찾은 남편마냥 이리 뛰고 저리 뛰어야 했습니다. 동선 계획에 문제가 있었던 거죠. 심지어 주사실은 에스컬레이터 뒤에 처박혀 있어서, 항상 안내원 아르바이트 두 명을 고용해야 했습니다. 잘못된 설계의 전형적인 예시겠죠.


그런데 막상 실무 프로젝트에 몸담다 보면, 과연 건축을 소프트웨어에 대입해도 되는 걸까?라는 원천적 의문이 들 정도로 차이점이 더 많습니다.  그중에서도 단연 가장 큰 차이점은 인부들이 집을 때려 부수고 싶어서 안달이 나 있다는 거죠. 네! 소프트웨어 이야깁니다.


소프트웨어는 건축에 비해 좋은 설계자가 훨씬 드뭅니다. 심지어 개발자에서 자연스럽게 설계자로 성장할 수 있는 교육 모델도 부실하기 짝이 없죠. 설령 그런 게 있다 한들, 변화무쌍한 요구사항을 받아들이고 적용하는 데는 오히려 어설픈 교육이 독이 되기도 합니다. 인터넷 보급 이후 그간 잘 나가던 PM이 줄줄이 처참한 패배를 맛본 건, 시장의 눈높이가 네이버나 페이스북처럼 점점 정교한 UX에 캘리브레이션 되는 현실을 보지 못하고 예전의 트렌드를 밀어붙인 탓도 큽니다. 하지만 무능한 설계자라는 존재가 개발자의 파괴 본능을 정당화할 순 없습니다.


이전에도 언급했지만, 다가올 미래의 변화를 모두 예측하는 건 생각 이상으로 어렵습니다. 이제 막 프로토타입을 끝내고 두세 걸음을 뗀 프로젝트에 생각지 못한 예외 상황이 발생하는 건 꽤 흔한 현상입니다. 보통 오함마를 들고 씩씩대는 개발자에게 프로젝트의 리모델링을 맡겨 보면, 현재까지 나온 이슈에 약간의 가정을 더하고 거기에 다시  ‘마른하늘에 날벼락’같은 시나리오도 더하곤 합니다(보통 그 시나리오가 working 할 확률은 0에 수렴합니다만). 그리고 그 가정에 딱 맞춰진 새 구조를 제안하여 프로젝트를 다시 시작하죠. 그 가정에 또 다른 구멍이 있다는 사실은 보통 첫 3개월 안에 증명됩니다. 이제 그 개발자는 좀 조용해졌으려나요? 물론 그렇지 않죠. 가정이 틀렸으므로 또 짓던 건물을 때려 부수고 새로 만들어야 한다고 주장할 겁니다. 이 개발자에게 몇 번을 인내하고 기회를 줬는지는 중요하지 않습니다. 마지막 단 한번, 리모델링 의견을 기각한 그 순간이 시니어로서 씹새가 되는 그 날입니다. 무능할 뿐 아니라 고집스럽기까지 한 그런 꼴통 말이에요.


사실 SE(소프트웨어 공학)든 OOP(객체지향 프로그래밍)든 그 핵심은 유연성입니다. low coupling, high cohesion과 reusability라는 키워드가 각각 그 가치를 대표합니다. 하지만 SE나 OOP를 글로 배운 얼치기 엔지니어들은 가능한 모든 필드를 private화 하기, 함수의 최대 라인 수 제한하기, 같은 코드가 몇 줄 이상 반복되면 무조건 함수로 빼 버리기 등에 천착합니다. 결과적으로, 코드는 마치 잘 구운 페스츄리마냥 층이 켜켜이 쌓이고 모듈 간의 coupling은 높아지죠. 그러니 조금만 새로운 사례가 생겨도 디렉터리 전체를 넘나들며 수정을 가해야 하는데, 프로젝트를 엎어버리고픈 게 당연합니다.


애플의 아이튠즈는 처음에 모든 사람이 한 대의 PC와 한 대의 아이팟을 갖고 있다고 가정한 듯 만들어졌습니다. 두 대 이상의 아이팟에 각기 다른 플레이리스트를 관리하려면 꽤 귀찮은 작업이 필요했습니다. 또한 개인 PC와 동기화된 아이팟을 사무실 PC에 연결하는 건 모든 플레이 리스트를 날려버릴 위험을 감수해야만 했습니다. 지금은 여러 대의 컴퓨터와 여러 개의 모바일/태블릿 기기가 훨씬 자유롭게 연결됩니다. 이는 거의 entity 레벨의 리모델링이 이루어졌음을 의미합니다 그럼에도, 그들은 뒷 구조가 바뀌어가고 있다는 사실을 사용자에게 쉽게 드러내지 않았습니다. 호수 위를 떠다니는 백조처럼 발을 열심히 저었을 뿐이죠.


구조가 엉망인 소프트웨어는 변화에 기민하게 대응할 수 없습니다. 하지만 더 나은 구조가 떠오를 때마다 프로젝트를 다시 시작한다면, 그 프로젝트는 영영 끝나지 않을 겁니다. 만약 진행 중인 프로젝트를 완전히 갈아엎고 새로 만들고 싶을 때에는 한 가지만 기억하시길 바랍니다. 아직까지는 여러분의 착각이 모두 드러난 게 아니며, 때로는 꾹 참고 더 많은 착각이 드러난 다음에야 프로젝트를 리모델링하는 쪽이 현명할 수도 있다는 걸요.



Roaster Kay님 Brunch 주소
https://brunch.co.kr/@roasterkay/   
0
  • 댓글 4

  • 진C
    1k
    2016-02-17 13:43:00
    오늘도 좋은 글 소개 감사합니다. 기분 좋은 하루 되세요! ^-^
  • Karen
    15k
    2016-02-17 14:07:59

    @진C // 감사합니다 ;) 즐거운 하루 보내세요~~

  • latelove
    690
    2016-02-17 15:53:46
    캬~
  • 사과
    618
    2016-03-17 21:40:13

    설계를 하면서 유연성 때문에 너무 많은 스트레스를 받고 있습니다.

    소프트웨어 공학적으로 더 나은 구조를 위해서 노력하고 있는건 맞는데... 위의 글에서 얼치기로 표현되는 행위들이 바로 내가 하는 행동들이 아닌가 싶기도 하구요.

    중간을 찾는다는게 너무 힘이 듭니다.

    경험이 부족해서 그런건지..  

    부족한 설계 실력과 현실이 조합되면 더더욱 막막해질 뿐입니다.

    누군가에게 가르침을 받고 싶은 심정이네요...


  • 로그인을 하시면 댓글을 등록할 수 있습니다.