기획출신아키텍트
516
2021-03-08 16:10:07
4
818

"아키텍트는 사기꾼 많다."에 대한 인정과 개발자 지적


편견 환경 다 내려놓고 속시원히 말해보려고 합니다.

개발자측 발언. 아키텍트는 사기꾼 많다.

일정부분 인정합니다만 그 사람들이 진짜 근본부터 엉망인 사람은 소수입니다. 사기꾼이 많은 이유는 애초에 신생학문으로 정보가 별로 없고 그들도 시행착오를 겪어야하기 때문입니다. 회사경영은 벌써 수백년된 학문입니다. 개발론은 얼마나 됐을까요? 50년도 안됐습니다. 제대로 된 OOP의 시작으 40년도 안됐고 요즘 쓸만한 아키텍트들은 15년안에 만들어진 것이 많습니다. 

일정부분 추측(잘못된 추상화)을 하지 않으면 애초에 아키텍트가 책임져야할 업무를 진행조차 할 수 없을 정도로 아직 정립되지 않은 분야입니다. 환경과 사업을 고려해서 커스터마이징 된 아키텍처를 만들 수 있는 능력자는 학문 개척자급입니다. 당연히 소수일 수 밖에 없습니다. 대부분은 새로운 아키텍처를 습득하고 잘 적용하기 급급하겠죠. 그러면 그들은 과연 필요없는 존재일까요?

그런 멍청한 아키텍트라도 필요한 경우가 더 많습니다. 정치적 이유일 수도, 책임 문제일 수도, 기술적 문제일 수도 있습니다. 그들 모두가 기술적인 설명을 하고 정치적, 사업적 문제를 기술로 다룹니다. 그러나 아무도 확답을 줄 수 없는 문제에 확답을 줘야하는 입장이고 이 부분이 개발자와 충돌되는 부분입니다. 그들은 거짓말도 해야하며 거짓말에 책임도 져야합니다. 일부는 뭉개려할 것이고 일부는 의도적으로 속이려 할 것입니다. 그런 상황에 개발자는 당당히 비난할 수 있습니다. 

그러나 비난하는 개발자를 앞에 세워두고 사업적 요구(시장변화라든지)에 의해 이러한 도메인 변경이 있을 때 당신이 책임지겠습니까? 물으면 그걸 왜 내가 책임져요? 라고 말합니다. 그럼 기술적으로 아무것도 안하고 돈받아먹는 아키텍트가 필요한 겁니다. 실력이 없어도 책임지겠다고 말하는 사람이 존재한다면 경영주는 그 사람을 고용할 것입니다. 물론 그런 거짓이 심각한 경우 사업이 폭발하겠지만요.

도메인의 잦은 변경은 책임지기 어렵다는 것을 모든 개발자가 알고 이를 책임지지 않습니다. 하지만 이러한 사실이 역설적이게도 책임지울 상대를 영입하게 만듭니다. 그 자리가 아키텍트의 자리입니다. 개발자라면 책임지기 어려운 부분을 대신 책임져주는 것입니다. 실력을 어떻게 측정할까요? 여기부터가 헬입니다. 각자 생각하고있는 개발이론을 열심히 설파하며 자신은 책임질 수 있다고 주장합니다. 경영주는 더 그럴듯한 이야기를 하고 업계에서도 돈 많이주던 사람을 믿을 수 밖에 없죠. 그렇게 난장판이 열리는 겁니다.

여기까지가 제 인정이었습니다. 이제부터 개발자측을 지적하도록 하겠습니다.


아키텍트를 제대로 까고 싶으시면 도메인 변경을 안고가는 개발을 하실 수 있으셔야 합니다. 본인이 도메인 변경에 확답을 줄 수 없다면 그 사람이 사기꾼임에도 대체될 수 없다는 말이고 이것은 정치의 영역으로 빠질 수 밖에 없다는 소리입니다. 아키텍트가 하는 일 아키텍트가 책임지는 범위 아키텍트의 필요성 전부를 대체할 수 있을 때 제대로 깔 수 있습니다. 그게 아니라면 불필요한 사내갈등을 만들고(아키텍트 따르는 파 VS 안따르는 파) 생산적이지 않은 업무환경을 초래합니다. 

물론 스트레스 해소용으로 개발자 커뮤니티에 그들의 무능을 폭로하는 것도 나쁘진 않지만 마치 원래 필요없는 직종인 양 아키텍트 평균이 없는 것만 못하는 존재인 양 생각하는 것은 편협한 사고라고 생각합니다.

기존 아키텍트가 사라지고 그 자리에 본인이 대체할 수 있다면 위의 사고는 편협한 사고가 아닐 것입니다.증명의 영역일 것입니다.

그것이 제가 기획자 출신 PM에서 아키텍트가 된 이유이기도 하기때문입니다. 사기꾼 아키텍트에게 "넌 사기를 치고 있다. 내가 해도 너보다 잘하겠다." 라고 말한 것이 계기였고 아키텍트로 전향했으며 1년 넘게 개발자와 좋은 관계를 유지할 수 있는 것을 보니 제가 크게 틀리진 않았나 봅니다. 아키텍트를 까는 글을 볼 때마다 씁슬하곤 합니다. 사실일수도 있지만 오해일수도 있기 때문입니다.

능력을 넘어서는 책임을 갖은 사람은 수단과 방법을 가리지 않거나 죽어라 능력을 키울 수 밖에 없습니다. 아키텍트는 능력에 맞는 책임이 있는 게 아닙니다. 책임의 양은 원래부터 존재했고 그것에 맞춰 어떻게든 해내야하는 것입니다. 그 과정은 추할 수도 있고 억지일 수도 있습니다. 한가지 확실한 것은 추한 그들을 다 없앤다고 죽어라 노력하는 아키텍트만 남지 않는다는 점입니다. 아키텍트는 일정규모 프로젝트에 반드시 필요하고, 개발자가 도메인 변경을 모두 책임질 수 있게 되는 그날까지 필요할 것이기 때문입니다.

1
  • 댓글 4

  • 삼식이
    1k
    2021-03-08 16:43:06
    요즘도 아키텍쳐 쓰는데가 있나요?
    그냥 특급개발자가 설계하고 진행합니다만
  • 장독깨기
    3k
    2021-03-08 16:55:49

    음.. 무슨 말씀이신지 알겠고 일정 부분 동의하는 부분도 있습니다.


    근데, 보통 그 역할을 PM 이 하지 않나요?

    아키텍트라고 따로 직책을 두고 하나요? 


    좀 혼란스럽네요 ㅎㅎ

    아키텍트는 보통 엔지니어 역할일텐데요..



  • 아슈
    988
    2021-03-08 17:05:13 작성 2021-03-08 17:06:37 수정됨

    사람마나 관념의 차이가 있듯이 저는 아키텍트는 중규모 이상의 사업에서는 꼭필요하다고 생각하고

    기술적으로 리딩이 가능해야 한다고 생각하는데요. 

    적어도 어떤 프로젝트를 진행할때 필요한 요소기술이라던지

    제약사항 같은걸 잘알고 초기 세팅과 샘플 코드 제공,

    신규 기능 필요시 도입할 라이브러리 검토/적용, 개발표준 가이드라인이나

    시큐어코딩, 접근성코딩 같은 가이드라인을 제시하는게 아키파트에서 하는 주역할이고..

    사전에 미리 가이드하면서 각파트 PL들을 기술적으로 이끌어야 하는게  아키라고 생각하는데...

    개발자가 아닌 아키라.....만나보질못해서 허허...뭐라해야할지

    제가볼때도 윗분처럼 도메인변경등 요구사항에 대한 책임과 수용여부는 PM역할이 맞는거같은데요.

  • 천사와악마
    2k
    2021-03-08 17:11:38

    아키를 욕하려면 자격을 갖춰라(?) 인가요

    클라이언트의 요구사항을 정리하고 조율하고 개발파트가 유연하게 진행될수 있도록 가교역할을 해야 하는데 그러지 않죠

    페이는 고임금이면서 똥만 싸고 빠지고 책임은 남은 개발자가 지고... 그러니 개발자 입장에선 좋게 보일수 없다는

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