박가사탕
378
2019-04-14 03:43:15
18
1157

커뮤니케이션에 대한 반론..


스크럼 좋아하는 사람들이 개발자의 새로운 능력을 만들어 버렸는데

바로 커뮤니케이션능력이다. 너무 길다. 소통능력이라고 하자.


http://www.zdnet.co.kr/view/?no=20170814090312

바로 이런 글이 자꾸 나온다는 거다.

그런데 소통능력이라는게 뭘까? 이해력? 통찰력? 설득력?

애자일이 망한 이유와 같다.

애자일주의자들이 말하는 소통능력이란 단어는 너무 방어적이다.

(애자일이 왜 망했는지에 대한 친절한 링크1 : https://www.slideshare.net/jbgo93/ss-64683535)

(친절한 링크2 : http://morethanair.com/archives/817)


결국 소통능력이란 용어 자체가 이미 소통을 실패했다.

내가 보기에는 곁가지 다 때면 "설득능력"인데 근본적으로 남을 왜 설득하는가?

일에 필요한 권한이 없기 때문이다. 애자일주의자들은 자기 팀원에게

아무런 권한도 넘겨주지 않는다. 모든 것이 자신을 설득해야 되도록 만든다.


따라서 일이 잘 될래야 될 수가 없다. 빌어먹을 교육비 때문에.

조직이 튼튼해지려면 책임과 권리를 분산하고 모듈을 분리해야 하는데

모든 결정에 "설득"이라는 과정이 들어가면 동등한 사원끼리는 책임소재가

불분명해서 아무도 나서려고 하지 않게 되고, 상관과 부하직원간에는

상관이 독박쓰는 구조가 된다. 하자고 결정한 것도 상관이고

하지 말자고 드랍한 것도 상관이기 때문이다. 근본적으로 책임과 권한이

분산되려면 독자적인 결정권도 나누어져야 하는 것이다.


코드리뷰도 같은 맹점이 있다. 모두가 다 상대방의 소스코드를 확인하면

소요시간은 놔두고서라도 책임소재도 불분명해지는 것이다.

다같이 OK한 것이기 때문이다. 엄격하게 보면 끝없는 싸움판이고

대충보면 책임만 흐지부지되는 것이다.


그럼 어떻게 할 건데?

같이 프로그래밍은 해야 하고, 품질은 높여야 하고

프로그래머간 실력격차는 상당한데, 어떻게 해야하는 것인가?


외국에는 답이 있다. 바로 QA프로그래밍.

모듈단위로 성능과 품질을 기계적으로 돌려보는 것이다.

사람이 눈으로 보고, 문법을 지적하는 원시시대같은 방법이 아닌.


즉, 거창하게 말하면 TDD(테스트주도개발)가 답인 거다.

반드시 애자일론자들이 그럴거다. "그래! 내가 말한게 그거야!"

애자일론자들은 자기들이 살아남기 위하여 어떤 변신도 마다하지 않는다.

처음부터 특별한 색깔도 없다. 철학자체가 이미 너무 방어적이라

거꾸로 보면 아무론 지론도 내용도 없는거다.

서서 회의하고, 포스트잇을 좋아하는거?


하지만 나는 애자일스럽지 않기에 확실하게 말한다.

즉시 반론이 들어온다는 것은 거꾸로 말하면 소통에 성공한 것이다.


즉, 프로그래머에게 소통능력 같은 것은 필요없다.

책임과 권한을 분리한 다음, 그 결과를 SW적으로 테스트해서

통과되면 끝인거다. 새로운 아이디어도 사람을 설득할 필요가 없다.

핵심부분을 프로토타이핑해서 역시 테스트해서 결정하면 되는거다.

이 모든 것을 기계적으로 하면 되는 것이다.


애자일, 스크럼, 소통능력, 코드리뷰..

한 시대의 희극이다. 한국의 관리자가 얼마나 SW에 대하여

무지한 지를 보여주는 코메디다. 하지만 그대가 있어 꽤 즐거웠다.


-5
0
  • 댓글 18

  • fender
    13k
    2019-04-14 07:43:07 작성 2019-04-14 07:45:27 수정됨

    외국에는 답이 있다. 바로 QA프로그래밍.

    모듈단위로 성능과 품질을 기계적으로 돌려보는 것이다.

    사람이 눈으로 보고, 문법을 지적하는 원시시대같은 방법이 아닌...

    애자일, 스크럼, 소통능력, 코드리뷰..

    한 시대의 희극이다. 한국의 관리자가 얼마나 SW에 대하여

    무지한 지를 보여주는 코메디다.

    지난 글에서 실리콘밸리에선 코드리뷰 안한다느니, 남의 코드는 안건드린다느니 하는 황당한 주장하다 망신당하고도 느끼신게 없나봅니다.

    이번에는 본인이 근거라고 찾은 내용조차 제목만 보고 내용은 안보셨나보군요. '애자일이 망했다'는 근거로 드신 두 링크 모두 '개발자는 소통할 필요없는데 애자일은 소통을 하다 망했다'는 식의 주장과는 아무 관계도 없고, 심지어 첫번째 내용은 이름만 '애자일'이 아닌 진정한 애자일을 하자는 취지의 자료입니다.

    소통은 그래서 중요한 겁니다. 널리 받아들여지는 관행을 비판하는 것도 일단 그 내용을 이해를 한 다음에 해야 의미가 있는거지, 혼자만의 상상으로 애자일이나 TDD는 어떨 것이다, 외국에선 코드리뷰를 안할 것이다 등등 엉뚱한 결론부터 정해놓고 남들이 무슨 근거를 들어 어떤 지적을 해도 다 "해석의 차이"라고 무시해 버리고 본인 주장만 반복하면 웃음거리 밖에 안됩니다.

    2
  • fender
    13k
    2019-04-14 08:18:22 작성 2019-04-14 08:39:41 수정됨

    참고로 "애자일은 죽었다"라는 표현은 실제로 외국 개발자들 사이에서도 흔하게 나오는 말이긴 합니다.

    하지만 이는 본문의 주장처럼 애자일한 접근 자체가 망했다던지, 소통을 강조해서 나쁘다는 등의 이야기가 아니라 기업들이 애자일을 도입하는 과정에서 특정 관행에 집착을 하거나 애자일을 감시의 도구로 오용하는 등 애자일의 본질을 무시하고 있다는 반론일 뿐, 애자일의 주요 개념 자체는 이제는 대체적으로 상식으로 받아들여지고 있다고 보아도 무방합니다.

    애초에 처음 "애자일은 죽었다(Agile is Dead)"는 말이 유명해진 건 애자일 매니페스토(Agile Manifesto) 작성에 참여했던 데이브 토마스(Dave Thomas)가 애자일의 본질로 돌아갈 것을 주장했기 때문이기도 합니다.

    참고로, 애자일과 관련한 정기적인 대규모 여론조사인 버전원(VersionOne)의 최신 자료에 따르면, 응답한 기업의 과반수가 절반 이상의 팀에서 애자일 절차를 도입하고 있으며, 애자일을 전혀 사용하지 않는다는 응답은 2%에 불과했습니다. 조사의 특성상 편향성은 어느 정도 감안하더라도 "애자일은 죽었다"라는 것이 문자 그대로 "더 이상 애자일을 사용하지 않는다"를 뜻하는 것이 아님은 명확할 것입니다.

    테스트 주도 방법론(TDD) 또한 개발자의 소통 능력이나 코드 리뷰를 폄하하는 것과 아무 상관도 없습니다. 단적으로, 위키 백과의 해당 항목에서 조차 TDD를 시행하는 기업들이 공통적으로 권장하는 관행으로 다른 개발자들과 테스트 코드를 리뷰 하는 것을 언급하고 있습니다:

    Individual best practices states that one should... get together with your team and review your tests and test practices to share effective techniques and catch bad habits. It may be helpful to review this section during your discussion.

    참고로 본문에서는 TDD를 QA 절차와 혼동하고 있지만, 이는 TDD보단 단위 테스트 자체에 더 가까운 내용이고, TDD의 본질은 단위 테스트를 품질 보장 뿐 아니라 방법론을 대체하는 목적으로 사용하는 것입니다.

    따라서, TDD에서 테스트는 그 자체가 방법론의 산출물을 대체하는 역할을 하며 따라서 단위 테스트도 마치 기술 명세를 읽는 것처럼 다른 개발자들이 쉽게 이해할 수 있도록 작성하는 것을 권장합니다.

    그런 TDD를 코드 리뷰나 소통을 대체하는 것이라고 하는 건 TDD에 대한 몰이해에서 나온 주장일 뿐이고, 굳이 따지자면 TDD는 애자일 보다 아직까지는 훨씬 덜 보편적인 방법론이기도 합니다.

    다시 한 번 강조하지만, 널리 받아들여지는 의견에 대해 반론을 제시하는 것은 좋은 것입니다. 하지만 그 것이 헛소리가 되지 않으려면 주장하는 내용에 대한 최소한의 이해는 필요하고, 적어도 사실 관계와 다른 내용을 외국의 보편적인 관행인 것처럼 왜곡하는 일은 없어야 한다고 봅니다.

    2
  • 하마
    6k
    2019-04-14 08:26:36 작성 2019-04-15 07:39:29 수정됨

    - 모듈화 해아하고, (반론 여지 없으며..)

    - 각자 결정하게 하고, 그 사람이 책임지게 하자 (맞는 말. 다만 이렇게 되면 팀에서 코딩 하는 일부만 하게 됨.즉 대체로 쥬니어와 시니어의 수준차 있기에 설계 토론, 소스리뷰는 필요하다고 봄.모두 박가사탕님 수준이라면 필요 없긴 할 듯) 

    - 애자일 언급 부분 ( 애자일/스크럼이 필요 한 팀에서 일해보지 않아서 통과~  논외로  '진정한' 객체지향처럼, '진정한' 시리즈에 하나로 애자일도 추가 되야 할 듯...'니가 진정한 애자일을 안해봐서 그래' 라는 무적의 반론이 가능한  영역) 


    이번 글도 취지는 ok, 글을 읽는 사람이  알아서 필터링 해서 읽으면 ok
    하지만 필터링 못하는 / 안하는 사람들에게 오해를 불러일으킨다는 면에서 김포프 영상과 비슷한 우려가 되긴 하네요. 

    4
  • 머신러닝
    512
    2019-04-14 09:53:15

    전 박가사탕님이 바라보는 인간상이 뭔질 모르겠군요. 

    제가 보는 사람은 불완전하여 실수가 없을 수 없고, 자기의사가 있으므로 설득없이 무조건 일을 시키려하면 저항하는 존재입니다.

    또 간결하고 이해하기 쉬운말을 듣고 싶어합니다. 정리 안 된 글이나 말을 듣는건 힘들죠.

    개발자도 사람이니 똑같은 위의 특성을 가지고 있다고 봅니다.


    불완전하기에 끊임없이 서로가 올바른 방향으로 가고 있는지 당연히 확인해야하고요,

    한 명의 인격체를 움직이려면 설득은 당연히 필요하고요,

    설득과 소통의 과정에서 서로 상대방을 배려하는 차원에서라도 소통 능력 배양은 필요하다고 생각합니다.

    딱 보면,

    이미 박가사탕님은 소통능력을 배양하려고 여러모로 노력하고 계신 것 같은데

    박가사탕님은 개발자가 아닌가요?

    잘 이해가 안 갑니다. 자기는 소통능력이 있으면 좋고 다른 개발자는 필요없다고 하시니.

    애초에 이렇게 글로 다른 개발자와 왜 소통하시려는지...

    0
  • 박가사탕
    378
    2019-04-14 10:34:34

    실리콘밸리에서 코드리뷰 안한다고 제가 말했나요?

    그런건 전 모르는데요? ㅋ

    -3
  • fender
    13k
    2019-04-14 10:39:01

    박가사탕 //

    실리콘밸리 다큐를 보다보면 그 원리를 알게 됩니다... 
    우리나라는 아직 경영진이 무식합니다... 소스코드 따위는 보관할 필요조차 없습니다. 코드리뷰? 바보같은 소리죠.
    실리콘밸리의 잦은 인재이동이 가져오는 발전... 문서나 리뷰, 패턴강요가 아닙니다...
    정보를 A인체에서 B인체로 리뷰나 문서화, 인수인계같은 소통과정을 통해서 전달하는게 아니라...

    직접하신 말씀들입니다.

    1
  • 박가사탕
    378
    2019-04-14 11:03:58

    음 실리콘밸리에서 제가 포커싱하는 것은

    잦은 인재이동에서도 기술을 유지하는 비결입니다.

    실리콘밸리도 스크럼이니 아마 하겠죠. 코드리뷰도

    “할지도” 모르고. 그들이 안한다고 한적 없습니다.

    실리콘밸리도 완벽한 건 아닙니다.

    특징점은 잦은 인재이동에 따른 시너지부분이죠.


    -1
  • 박가사탕
    378
    2019-04-14 11:10:53

    머신러닝님.

    인간은 불완전하죠. 함께 발전해 가야합니다.

    그러나 스크럼은 잘못된 방식입니다.

    20살 이상의 인간을 “독려”해서 쓸 모 있는 존재로

    만든다는 발상은 다 틀렸다고 봅니다.

    그리고 내 경험을 강요한다고

    상대에게 맞을 리도 만무합니다.


    코드가 가장 훌륭한 의사전달의 매개체입니다.

    컴파일러가 판정해 줍니다. 성능으로 말하는 겁니다.

    책임과 권한을 가진 인간만이 그 시간동안만

    유의미한 발전을 합니다^^

    -1
  • 박가사탕
    378
    2019-04-14 11:22:40

    글구 펜더님의 말은 너무 어렵네요..

    상대의 말을 인용할때 말은 “아 다르고 어”다르고

    앞뒤 상황에 따라 다른건데 매도하기 위한

    프레임공격인지 제가 소통능력 부족해서 잘못 전달된

    것이지 모르겠지만.. 여튼 뭔가 분명치가 않습니다..


    소통이야기 하는 김에요.. ㅎ

    0
  • fender
    13k
    2019-04-14 11:45:30

    박가사탕 // 제가 글을 지나치게 길게 쓰는 습관이 있다는 건 인정하겠습니다만, 이 경우 제 글이 분명하지 않고 어렵게 느껴진다면 그건 박가사탕님이 지난 글타래부터 사실 관계가 잘못된 주장을 했음을 어떻게든 인정하지 않고 '해석의 차이' 등으로 무마 시키려 하시기 때문일 겁니다.

    "코드 리뷰는 필요없다", "개발자는 각자 맡은 모듈만 작성하고 다른 사람 코드는 안건드리는 것이 좋다" 같은 일반적 상식에 벗어나는 주장이라도 근거만 충분하면 얼마든지 좋은 토론을 이끌어 낼 수도 있습니다.

    하지만 제가 항상 박가사탕님 글에 눈살을 찌푸리게 되는 이유는 그런 내용이 이미 실리콘밸리에서 보편적인 프로세스라느니, 애자일이나 노드JS는 이미 망했으니, 가상 머신 언어는 다 걷어내는 추세라느니 등등 자신의 주장을 위해 사실 관계 왜곡을 서슴치 않는다는 것입니다.

    왜 본인이 그렇게 생각하는지 제대로 된 논거 대신 경력이나 실력 등을 은연중 내세우면서 마치 외국에선 이미 그런 내용이 대세인 것처럼 왜곡한 내용으로 아직 실력이 부족한 개발자들을 현혹하는 내용을 계속 쓰시니, 저로서도 굳이 덧글로 사실관계를 바로 잡고 날선 반박을 할 수 밖에 없습니다.

    스크럼이든, 고수준 언어든, 코드 리뷰든 디자인 패턴이든 비판은 마음대로 하셔도 좋습니다만, 무언가를 "쓰레기"니 "망했다"느니 하는 식으로 비판하려면 해당 주제에 대해선 최소한의 이해와 사실관계 확인 정도는 하는 것이 기본이라고 봅니다.

    1
  • 산들바람_
    830
    2019-04-14 12:09:59

    개발자라면 특히 더 소통해야 할것 같아요

    물론 사사껀건 참견하거나 그러면 안되겠지만

    소통만 잘해도 개발자들의 역량이 결집되서 대규모 프로젝트의 성공이 보장될듯 해요 ^^

    0
  • 아이원가습기
    162
    2019-04-14 13:04:21

    세상은 변수가 무수히 많기때문에 그에 맞는 완벽한 러닝 모델은 없다고 생각합니다. 모든것에는 각기 다른 단점들이 존재하죠. 이전에 나왔던 방법론들이나 알고리즘들도 그 당시에는 좋은 효과를 얻기위해 나왔고 기존보다 더 나은 방향이기때문에 사용된것이겠죠.

    비판은 좋지만 이전에 나온것들을 비난하며 다른것을 정답이라 여기는 것은 잘못됐다고 생각해요. 좀 더 나은 방법이 나왔을뿐이고 완벽하지 않을 뿐더러 이전 방식을 사용했던게 바보는 아니니까요

    이론적으로는 다 이상적이고 좋은방법들이죠. 다만 수많은 변수(사람, 조직, 환경, 그냥 내기분 등...)때문에 생각한 대로 잘 안되는것이구요. 심지어 짠대로 돌아가는프로그래밍도 실수하거나 사이드이펙트 관리 못하면 생각하는대로 잘 안되는경우가 많은데 세상에 그걸 바라는건 아니라고봐요.

    그래서 사람이라는 변수를 최대한 제거하고 싶으신것같은데 어느정도 이해는 갑니다만 세상을 사는데 사람이 빠질 수 없고 사람이없으면 아무것도 의미가 없잖아요. 사람 하나하나가 컴퓨터이며 수많은 모델 집합이며 라이브러리라고 보면 소스에서 모듈화 시켜야 좋듯이 사람에게 있어선 그게 다른 사람, 조직과 잘 어울리고 소통하는능력이라고 생각해요. 성능좋은 라이브러리라고 무조건 뜨고 다 쓰는게 아니니까요. 세상을 뒤집어 엎을만큼 좋다면 모를까..

    본인의 머리속에서 만든 로직과 러닝 모델을 공리화 하고싶으신것같은데 무한대의 변수 속에 사는 세상에서 이런 고차원의 문제를 선 긋듯이 딱 나눌 수 없음을 인정하시고 좋은 방향으로의 발전을 위해 "참된" 소통을 하시고 세상을 너무 프로그래밍적으로 안보시길 바랄게요. 되돌아서 자신을보면 자기 생각과 몸도 원하는대로 관리 잘 안되잖아요~? ㅎㅎ

    0
  • 박가사탕
    378
    2019-04-14 13:46:29

    제가 거친 표현을 쓰고 있다는 점은 인정합니다..

    짧으면서 더 확실한 표현을 찾을 수가 없어서.

    저는 제 글을 방어하고 싶진 않습니다.

    펜더님이 여러가지 반박을 해주시니

    글이 더 풍성해진 느낌입니다 ㅎㅎ


    진짜 팩트를 알 수 있을까요? 대세? 망했다?

    다 자기 입장과 선입견이 투영된 주장입니다..


    -1
  • 박가사탕
    378
    2019-04-14 13:51:41

    아이원가습기님.

    좋은 의견이십니다^^

    참고하겠습니다 ㅎ

    -1
  • fender
    13k
    2019-04-14 14:14:50 작성 2019-04-14 14:25:01 수정됨

    박가사탕 //

    진짜 팩트를 알 수 있을까요? 대세? 망했다?
    다 자기 입장과 선입견이 투영된 주장입니다..

    간단한 예를 들어보겠습니다:

    통계에 의하면 노드JS는 스택오버플로의 사용자들이 가장 흔하게 사용하는 프레임워크이다.
    (출처 - Developer Survey Results 2018)

    이런 걸 '팩트'라고 합니다.

    노드JS는 (...)한 이유로 현존하는 최고의 웹프레임워크이다.

    이런 걸 주관이 개입된 '주장'이라고 합니다.

    얼마전까지 node.js가 신의 선물이라고 믿던 개발자들은 다양한 표도 참고했고 근거도 있었습니다. 그리고 너도 나도 해봤고 지금은 버려졌습니다.

    하지만 이런 건 바로 '사실 관계 왜곡'이나 'FUD'라고 합니다. 참고로 위의 내용은 박가사탕님이 다른 글에서 한 주장을 한 글자도 안바꾸고 그대로 인용한 것입니다.

    노드JS에 대한 건 예시일 뿐이고, 가상 머신 기반 언어의 성능 문제든, 실리콘 밸리의 개발 관행이든 이제까지 쓰시는 논쟁글마다 저런 식의 허위 정보가 잔뜩 포함되어 있습니다.

    이건 해석의 문제도 아니고 관점의 차이도 아닙니다. 어떻게 포장해도 그냥 허위 사실 유포일 뿐입니다.

    간단한 웹검색 한 번만해도 사실 확인을 할 수 있는 내용들을 꾸준히 자신의 주장에 맞게 왜곡해서 근거로 쓰는건, 애초에 그런 주제에 대해 강한 주장을 할 만큼 지식이 없거나 아니면 의도적으로 지식이 부족한 다른 개발자들을 속이려는 시도라고 봐야합니다.

    누구나 한 두 번은 잘못된 주장을 할 수야 있지만, 매번 그런 식의 왜곡된 내용을 이야기하고, 근거를 들어서 왜 그것이 사실과 다른지 지적을 해도 항상 '관점의 차이'라는 등의 이야기로 얼버무리는 식이라면 해당 주제에 대한 이해 정도나 의도를 의심할 수 밖에 없는 것입니다.

    2
  • 머신러닝
    512
    2019-04-14 14:42:06

    박가사탕 // 박가사탕님 주장의 큰 그림에는 동의하는 바가 있습니다. 링크거신 발표자의 회사 중, 제 전직장이 있기도 하거든요. 그 분이 고생하신거 전해 듣기도 했고요.


    다만 아쉬운점이 있다면 님 주장의 근거로 드신 것들 중 논쟁을 부르거나 오해를 부르는 것이 있는 것 같습니다.

    그래서 가르키려는 대상을 보지 못하고 가르키는 손가락만 보게 되네요.


    제가 오해(?)한 부분 중 하나는 소통능력이 개발자에게 필요없다고 하신 부분입니다.

    사실 전 소통능력이 전무한 개발자는 역량이 없다고 보거든요. 특히 머신러닝 분야에선 더욱 그렇습니다. 

    다만 박가사탕님은 애자일에서 요구하는 소통능력이 필요없다고 하신거 맞나요?

    보편적인 소통능력이 아니라?

    0
  • satis
    687
    2019-04-14 15:46:51


    즉, 프로그래머에게 소통능력 같은 것은 필요없다.

    소통능력이 필요없다고 생각하는 개발자는 피하고 싶네요.

    팀원중에 저런 개발자가 있다면 거부하겠습니다.

    1
  • 박가사탕
    378
    2019-04-14 18:27:08

    개발자에게 궁극적으로 소통능려은 필요없단 겁니다.

    말로 설득하고 말로 전달하는 시스템 자체가

    잘못된 거거든요. 잘못된 것을 고쳐야지

    잘못된 것을 전제로 하고 보완능력을 기를 필요는

    없다는 겁니다. 구구절절 설명하지 않아도

    캐치하시는 분들이 있어 다행입니다^^

    전 소통능력이 떨어지는 편이라.. ㅎ

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