박가사탕
264
2019-04-09 02:12:38
60
4554

프로그래머의 장점..


방금 개발자지망생분의 개발자에 관한 선망을 글을 읽고서

17년된 현업개발자로써 프로그래머의 장점을 소개해 보겠나이다.


일단 권력이 있습니다.

원래 일이 곧 권력입니다만 개발자는 특히 더 강력합니다.

내가 이룩한 것을 다시 무용지물로 만들어 버릴 수가 있습니다.

일종의 신과 같습니다.


20년동안 IT업계에서는 이 권력을 빼앗아보기 위하여

출시후 팀을 바꿔버린다던지 일부러 여러 개발자에게 분산한다던지

핵심 알고리즘 소유를 포기한다던지 다양한 실험을 해왔으나

결국 수십년간 살아남은 캐시카우는 모두 초창기 개발자의 권력과 지분을

인정한 사례밖에 남지 않았습니다. 결국 백기투항할 겁니다.

권력을 없애면 생산성이 떨어지고 지저분한 권력구도는 성장을 막고

결국 선명한 권력을 인정하는 방법밖에 없습니다.


방송계에서 아이돌스타 개인에게 권력이 돌아가는 현상을

막기 위해서 오랫동안 갖은 수를 써봤지만 결국엔 선명하게

각 멤버를 부각시켜 그 중 하나라도 잘되도록 그토록 애를 쓰는 것은

그만큼 소속사간 경쟁이 치열하기 때문입니다.

SW업계도 10~20년 전에는 핵심 개발자는 외부에 이름도 나가지 않도록

철저히 가리는 분위기였지만, 지금은 컨퍼런스, 유투브등 활동을 장려합니다.

경영진이 착해진 것이 아니라 이제야 자본주의 공부가 된 겁니다.


두번째는 기업이 개발자로부터 기술력을 빼앗을 수가 없습니다.

개발의 노하우는 오로지 사람에게 쌓입니다. "개발자 == 모듈"입니다.

기술력은 곧 돈입니다. 즉, 개발자는 정년퇴임이 없을 겁니다.

물론 아직 제대로 경험하지 못했습니다. 아직 1세대도 55세 전후입니다.

그러나 조금만 생각해보면 알 수 있습니다.


실리콘밸리 다큐를 보다보면 그 원리를 알게 됩니다.

실리콘밸리는 평균 이직이 1~2년인데, 어떻게 기술력이 이어지는가?

당연히 기술력이 이어지지 않죠. 대신 기술력이 "교체"됩니다.

유능한 랜더링엔진 개발자가 퇴사를 합니다.

당분간 그의 업적들은 돌아가긴 하겠지만 향후 조금씩 망가지겠죠.

얼마후 새로운 랜더링엔진 개발자가 입사합니다.

그리고 기존의 랜더링엔진을 폐기시켜버리고 즉시 자기가 준비한 모델로 바꿔버립니다.

능력자일 수록 더 빨리, 해당 모듈을 교체해 버리는 것이죠. "개발자 == 모듈"입니다.

유능한 개발자가 퇴사하면 큰 기술의 구멍이 생기는 것은 실리콘밸리도 어쩔 수 없구요.

대신 더 유능한 개발자를 뽑아서 "즉시" 구멍을 메울 수가 있는 겁니다.


우리나라는 아직 경영진이 무식합니다.

소스코드가 자산이라고 생각을 합니다. 미련을 못버리고 어떻게든

구 소스코드에 다시 생명력을 불어넣어 보려고 합니다. 수십배의 개발비가 들고

회생은 커녕 산소호흡기만 다는 꼴입니다. 그리고 트렌드를 못따라가면서

추월당합니다. 그 멍청한 짓을 20년간 하고 있는데 결국엔 정답에 도달할 겁니다.

소스코드 따위는 보관할 필요조차 없습니다. 코드리뷰? 바보같은 소리죠.


그래서 개발자는 정년퇴임이 없을 겁니다.

입사하는 즉시 어플리케이션과 기술력을 확보할 수 있는데

왜 안 뽑겠습니까? 파일전송앱 개발자 뽑으면 즉시 그 기술 가지는 거고

채팅 개발자 뽑거나, 고스톱 개발자 뽑거나, 스트리밍 개발자 뽑거나,

차량인식 개발자, OCR개발자, 음원압축개발자..

그냥 그 개발자를 뽑으면 회사는 그 기술을 가지는 것이고

기술은 근본적으로 문서나 회사에 축적되는 것이 아니므로

기술을 확보할 수 있는 유일한 해결책이 스카웃인 겁니다.


물론 아무런 자기 색깔, 브랜드도 없고

초보개발자랑 기술력 차이도 별로 없고 아는 건 많은 제너럴이라면

40대에도 정년퇴임이 올 수 있습니다.

머.. 개발자는 그렇게 살면 안됩니다. 제너럴리스트는 개발자 아니예요.

여튼 정상적인 전문가라면 죽을 때까지 일할 수 있게 됩니다.

아! 물론 원한다면요.. ㅎㅎ


늘 즐겁구요. 요새 왠만하면 근무환경 좋습니다.

야근강요? 쫄면 지는 겁니다. 쫄보는 늘 지고 삽니다.

지가 안하면 되거나 적당히 즐겨주면 됩니다.


어딜가도 어떤 업계의 인재랑 붙어도

인텔리함에 안 꿀립니다. 여성분들께는 죄송하지만

뭔가 아주 남성스럽고 강력함이 느껴지기도 합니다.

시스템화된 이 세상 모든 것을 내가 조종할 수 있을 것 같은 느낌.. ㅎㅎ

매트릭스의 네오처럼, 움직이는 사물과 게임, 앱의 흐름이 막 보여..


긴 글 읽어주셔서 감사합니다^^

개발자는 직업적 장점이 참 많습니다.

다만 깡다구가 필요합니다. 모든 것은 마음먹기에 달렸습니다.

장점이 천지에 널려있어도 애써 손을 뻗어서 잡지 않는다면

그게 다 무용지물이겠죠..


10
3
  • 댓글 60

  • fender
    13k
    2019-04-09 08:19:50 작성 2019-04-09 09:28:30 수정됨
    실리콘밸리는 평균 이직이 1~2년인데, 어떻게 기술력이 이어지는가?
    당연히 기술력이 이어지지 않죠. 대신 기술력이 "교체"됩니다.
    유능한 랜더링엔진 개발자가 퇴사를 합니다.
    당분간 그의 업적들은 돌아가긴 하겠지만 향후 조금씩 망가지겠죠.
    얼마후 새로운 랜더링엔진 개발자가 입사합니다.
    그리고 기존의 랜더링엔진을 폐기시켜버리고 즉시 자기가 준비한 모델로 바꿔버립니다.
    능력자일 수록 더 빨리, 해당 모듈을 교체해 버리는 것이죠. "개발자 == 모듈"입니다.
    ...
    소스코드 따위는 보관할 필요조차 없습니다. 코드리뷰? 바보같은 소리죠.

    다른 내용은 공감할 수 있는 부분도 꽤 있지만, 인용한 부분에 대해서는 반론을 제기하고 싶습니다.

    이제까지 쓰신 글들과 일맥상통하는 내용인데, 제가 느끼기에 박가사탕님은 20년 전통 국수집 장인이 절대 요리 비법은 공개 안하는 것 처럼, 개발자도 비슷한 것이 본인만의 알고리즘 비슷한 무언가로 쌓이고 그게 곧 실력이라는 착각을 하고 계시는 것 같습니다.

    실제 그런 식으로 기술 동향이나 다른 개발자들의 선행 작업, 유지보수를 위한 소프트웨어 공학적 배려, 방법론 등을 무시하고 자기만의 세계에 갇혀있는 '숨은 고수' 같은 개발자가 없지야 않겠습니다만, 그건 바람직한 것도 일반적인 것도 아닙니다. 실리콘 밸리의 우수한 기업들이 대부분 그런 식으로 돌아갈 것이라 생각하신 다면 그건 현실과 동떨어진 환상입니다.

    예컨대, 코드리뷰를 '바보같은 일'로 단언하는 박가사탕님의 믿음과는 달리, 실제로는 미국의 경우 대다수의 개발자들은 코드 리뷰를 소프트웨어 품질향상에 가장 효과적인 도구로 생각하고, 회사들도 매우 다양한 방식의 코드 리뷰 절차를 적극 도입하고 있습니다.

    (참고자료 - The State of Code Review 2017)

    만일 어느 기업에서 개발자가 핵심 모듈 하나 움켜잡고 그걸 밥줄 삼아 아무에게도 '비법'을 안알려주고 버티는 경우가 있다면, 이는 그 개발자가 뛰어난게 아니라 그 회사가 제대로된 소프트웨어 방법론이나 소프트웨어 공학적 관행에 무지하다는 증거일 뿐입니다.

    흔히 '버스 팩터(Bus Factor)'라고 하는 개념이 있는데, 프로젝트에서 핵심 인력이 몇 명이나 동시에 버스에 치여서 일을 못하게 되면 프로젝트가 망하는가를 따지는 다소 장난스러운 지표입니다.

    하지만 버스 팩터가 제시하는 문제는 그 보단 좀 더 진지한데, 개발자의 예상치 못한 퇴사나 이직은 개발자 대우가 좋은 기업에서도 매우 흔한 일이기 때문입니다. 그리고 소프트웨어 공학은 지난 수십년 간 그런 식의 문제를 해소하기 위해  발전해 왔다고 해도 틀린 이야기는 아닙니다.

    박가사탕님은 어떻게 생각하시는지 몰라도, 넷플릭스나 아마존 같은 기업에서 핵심 개발자가 퇴사한다고 해당 개발자의 후임이 기존 모듈 폐기하고 자신만의 방법으로 똑같이 새로 만들 때까지 서비스 중단하거나 심각한 오류를 방치하는 따위의 일은 발생하지 않습니다.

    애초에 그런 일이 발생하지 않도록 핵심 모듈은 팀의 여러 명이 지식을 공유하며 공통된 관행에 따라 개발하는 것이 일반적이고, 그런식으로 핵심 개발자가 빠져나가면 일시적으로 생산성이 떨어질지언정 서비스 품질에 심각한 문제가 생기지 않도록 하는 것입니다.

    그리고 개발자가 자신만의 '비법' 따위를 팀원들에게 조차 악착같이 꽁꽁 숨기고 매달리면 그건 '실력있는 개발자'가 아니라 그냥 '우물안 개구리' 같은 개발자일 뿐입니다. 그런 개발자는 개발 관행이 제대로 안잡힌 회사에서 왕노릇은 할 수 있어도 그 이상으로 발전하긴 어려울 겁니다.

    말씀대로 개발에 대한 노하우는 개발자 본인에게 축적되는 건 사실입니다만, 그건 무슨 '20년 개발 비법서' 같은 형태로 존재하는 것이 아니라 자신의 분야에 대한 폭넓고 깊은 지식, 설계나 개발, 팀운영에 대한 통찰, 추세에 맞는 관행을 이해하고 프로젝트에 성공적으로 도입할 수 있는 능력 같은 형태로 존재합니다.

    그래서 이러한 능력을 종합적으로 고려해서 '능력있는 개발자'라는 평가를 할 수 있는 것이고, 기업들은 그런 개발자를 자기만의 비법도 없는 '제너럴 리스트'라고 멸시하는 게 아니라 높은 연봉을 주고 스카웃 경쟁을 하는 것이 현실입니다.

    5
  • 박가사탕
    264
    2019-04-09 08:36:14

    비법따위는 저도 없습니다만..

    중요한 것은 인수인계가 안된다는 사실입니다.

    어떤 언어든, 어떤 분야든

    만줄만 넘어가면 사실상 안됩니다.

    3
  • fender
    13k
    2019-04-09 08:45:18 작성 2019-04-09 08:51:23 수정됨

    저희 회사는 손바닥 만한 스타트업이지만 스칼라 클래스 수천 개 넘고 코드는 20만 줄 넘는 프로젝트인데 경력 일 년 조금 넘은 초급 개발자까지 코드 리뷰 참여하고 서로 기술 공유를 위해 모듈 돌려 가면서 잘만 개발하고 있습니다.

    그런 환경을 제공해야 후임 개발자도 실력이 향상되고 동기가 부여되는 것이고, 회사 입장에서도 앞서 말한 '버스 팩터' 같은 위험 요소를 해소할 수 있다고 봅니다.

    그리고 그런 문화를 정착시키고 팀을 이끌어 좋은 제품을 만드는 것이 바로 시니어 개발자의 역할이고, 그 정도 경력의 개발자는 그런 능력으로 인정 받아야 되는 것이 아닐까 싶습니다.

    3
  • aka스님
    61
    2019-04-09 08:55:02

    fender 님이랑 일하는 개발자는 좋겠어요

    3
  • 박가사탕
    264
    2019-04-09 08:55:55

    분업이 안된다고 한적 없습니다..

    인수인계가 안된다는 거죠.

    펜더님 만드신 20만줄.

    후임자오면 엎자고 할겁니다..

    못만들어서가 아닙니다..

    1
  • fender
    13k
    2019-04-09 09:15:13 작성 2019-04-09 09:16:11 수정됨

    박가사탕 // 어느 회사나 가끔 프로젝트의 일부, 혹은 전체를 버리고 다시 만들어야 하는 일을 경험합니다. 하지만 중요한 건, 이는 보통 기술 부채(technical debt)의 누적으로 인한 코드의 리거시화의 결과이지, 말씀처럼 개발자 한 명이 인수인계 불가능한 코드를 부여잡고 있다가 퇴사하면 다른 개발자가 똑같이 인수인계 안되는 본인만의 무언가로 대체하는 과정으로 인한 것이 아니란 점입니다.

    클래스 수천개에 코드 20만줄만 되도 아무리 날고 기는 개발자가 온다해서 하루 이틀에 새로 짤 수 있는 분량이 아닙니다. 그럼 그런 개발자가 새로 짤 때까지 몇 달이 걸리건 서비스에서 발생하는 오류나 고객 요구사항은 방치해야 하나요?

    적어도 어느 정도 체계가 잡히고 규모 있는 회사라면 회사의 핵심 서비스를 그런 식으로 개발하는 건 바람직하지도 않고 가능하지도 않습니다.

    2
  • coffpro
    480
    2019-04-09 09:21:28

    과거 나사에서 개발자로서 근무하던 사람들은 전부 여자였다고 기억하고 있는데 이 글에서 <전문 개발자에게는 아주 남성스럽고 강력함이 느껴지기도 합니다.>라는 문장을 보니 할 말이 없어지네요... 

    0
  • 박가사탕
    264
    2019-04-09 09:24:37

    모든 코드가 그래요..

    다시 “정상화”가 가능한 인수인계는

    이 세상에 없습니다.


    0
  • 카트맨
    2k
    2019-04-09 09:36:18


    관리자가 개발에 대해 잘 모르는데 개발자의 실력이 뛰어나다면 정말 글쓴분 말처럼 됩니다. 

    프로젝트를 거의 원맨쇼로 진행하는게 흔하죠. (물론 중견기업 이하 한정)


    요즘들어 개발자 대우가 좋아지는걸 느끼긴 한데,  이것도 양극화가 심하네요. 


    글쓴 분처럼 실력있고, 소스코드를 어느정도 확보한 개발자는 정말 갈데가 많은데 비해

    화면위주로 SQL 하던 사람은 그다지 메리트가 없는것도 사실입니다. 


    0
  • ercnam
    1k
    2019-04-09 10:05:24

    프로그래머가 권력자가 된다는건 적어도 개발사 내에서나 가능한 일이지

    비 개발 부서관점에서 볼땐 그냥 X밥 컴돌이 그 이상이하도 아닌듯 합니다 (...)

    1
  • 산들바람_
    570
    2019-04-09 10:21:04

    부럽네요.. 펜더님이랑 박가사탕님 두분다

    실력이 있고 자신감있는 프로그래머가 행복한건 사실인듯 합니다

    인수인계 불가능하다는건, 구글에도 없는 그런 기술 때문일까요 ? ㅎㅎ

    0
  • 즈루시
    11k
    2019-04-09 10:42:56

    보넥스가 보넥스했는데...

    착한 옥희 회원님들 기만당하지마세요. 정상적인 내용 안에 어그로 밀어넣는 재주가 있는 분입니다 ^^

    0
  • 박가사탕
    264
    2019-04-09 10:52:49
    채산성이라고 하죠.
    소스코드를 인수인계하여 계속 개발해 나가는게
    새로 만드는 것보다 채산성이 나와야
    의미도 있고, 가치가 있는것이죠.

    그러나 원점에서 개발하는 경력자도 없고
    새로 개발하는 것이 훨씬 빠를 수 있구요.
    이전 결과물은 레퍼런스의 가치까지가 딱 좋습니다.

    분리가 되어 있다면 더욱 좋죠.
    하나씩 교체하면 리스크가 줄어듭니다.

    버스-팩터가 알려주는 시사점은
    치명적인 존재감을 가지는 개인을
    만들지마라가 아닙니다. 개인의 성공이
    곧 팀의 성공입니다. 아이돌 매니징으로 설명드렸드시.
    진짜 시사점은 “프로덕트를 분리하라”입니다.

    0
  • 산들바람_
    570
    2019-04-09 11:00:20

    하긴 슈퍼개발자면 새로 모듈을 갈아업고 다시 짜는게 더 편할수도 있을것 같습니다.

    개발자마다 성향이 다르고 사고방식이 다르기 때문에 , 기존꺼를 고치는게 더 공수 많이 들어갈수도 있을것 같아요

    대량의 작업을 해야 하는경우라면 불가능하지만

    핵심 모듈의 경우라면 가능할것 같습니다.

    아. 난 언제쯤 저 두분과 같은 내공의 개발자가 될수 있을까요 ㅠ

    아무래도 전 그냥 짬뽕개발자가 될듯 합니다 ㅠㅠㅠ

    0
  • 조앙마두
    71
    2019-04-09 15:07:20

    오키님들의 내공은 정말 높으신 것 같아요! 

    좌 우 공방 하시는 님들 글을 읽으면서 헤깔리기는 커녕 졸렵던 눈에 힘이 들어가구 막 더 열심히 좋은 개발자가 되고 싶어지는 열정이 생겨나는 것 같네요. 

    고견 잘 듣고 갑니다. 

    0
  • 박가사탕
    264
    2019-04-10 00:11:51

    펜더님의 20만줄.. 하루이틀에 못짜요 당연히.

    그러나 펜더1, 펜더2, 펜더3님이 동일한 역할에 대하여

    나름대로 수립한 각자의 20만줄이 있다면 어떨까요?

    A회사, B회사, C회사를 펜더1/2/3이 교체이직을

    하는 겁니다. 1~2년 주기로 교체이직하면서

    상대방이 만든 구멍을 내가 채우는 겁니다.

    시간이 지나면 아예 구멍 자체도 표준화됩니다.

    이게 바로 실리콘밸리의 시스템입니다.

    0
  • lllllllllllllll
    7k
    2019-04-10 00:21:58

    사실 남이 짠 긴 코드는 알아보기 힘들긴하죠. 그래서 나중에 들어온 사람이 반쯤 짜다 만 코드를 수정하는 것보다 차라리 엎고 내가 새로 짜는게 더 빠르기도...

    0
  • fender
    13k
    2019-04-10 06:42:28 작성 2019-04-10 06:54:29 수정됨

    박가사탕 // 그럼 큰 회사들이 왜 코드 리뷰나 코딩 컨벤션 같은 걸 중요시 한다고 생각하시나요? 어차피 그런 식으로 '각개전투'를 할거면 그냥 자기 맡은 부분은 멋대로 짜도 아무 문제 없을텐데요.

    그리고 이직은 계획적으로 일어나기만 하는 것도 아니고, 갑자기 핵심 모듈 맡은 개발자가 교통사고라도 나면 그 때부터 사람 뽑아서 몇 달 씩 코드 교체할 때까지 서비스에서 발생하는 장애 대응 같은 거 다 무시하고 기다릴 수 있는 것도 아닙니다. 애초에 하루 이틀 - 큰 서비스에선 그 정도 장애 방치도 안합니다만... - 에 사람 바로 뽑아서 갈아 엎을 코드라면 그 정도 코드 짜는 사람이 평소 강조하시는 능력있는 개발자도 아니겠죠.

    외국의 제대로 된 회사들은 그렇게 "나는 떡을 썰테니 너는 글씨를 쓰거라"하는 식으로 각 부분을 무작정 개발자들에게 던져두고 멋대로 개발하게 방치하지 않습니다. 구현 전에 전체 아키텍쳐나 설계에 부합하게 큰 틀을 잡고, 개발시에도 수시로 리뷰해가면서 코딩 컨벤션, 테스트 커버리지 등 세세하게 해당 회사가 요구하는 수준에 부합하는 코드인지 확인하는게 일반적입니다.

    차라리 박가사탕 님이 말씀하시는 그런 식의 개발은 국내 SI 환경에서 흔히 볼 수 있습니다. 자바가 시장을 장악했지만 객체지향 설계 분석이 제대로 정착한적이 없어서, 그냥 비즈니스 계층 설계는 디비 스키마나 SQL로 대체하고 분량 단위로 끊어서 각 개발자가 알아서 스프링MVC 패턴에 맞게 페이지를 찍어내는 식으로 많이 개발하니까요.

    코드 리뷰 따위도 무시하고 그런 식으로 사람 바뀌면 모듈 교체하는 식으로 개발하는 것이 '실리콘 밸리 시스템'이라는 것은 어느 사이트에서 보셨는지 궁금합니다.

    1
  • 박가사탕
    264
    2019-04-10 10:19:04

    다큐를 많이 보는 편입니다.

    해외에 취업을 한다고 해도 개인의 약소한 경험으로는 전체를 파악할 수는 없겠죠.

    EBS다큐프라임 글로벌인재전쟁에 보면 기업들이 인재를 대하는 풍토를 알 수 있습니다.

    아마 제가 의심에 의심을 계속 하다가 뭔가 확 느껴진 것은 그 편이었던 것 같습니다.


    1~2년 주기로 이직자들이 "기술을 날라주기" 때문에 실리콘밸리가 전체적으로 경험을

    공유하고 발전한다는 취지의 인터뷰가 있었습니다.

    과연 이직자들은 기업 기밀을 빼돌린 것일까요? 아닙니다. "기술을 날라줄 수" 있는 까닭은

    원래 자기 기술이었기 때문입니다.


    해외 유명 오픈소스중에 VG분야의 선구자가 한 사람 있습니다.

    해당 오픈소스는 14년이 되었더군요. 지금은 20년쯤 되었겠네요.

    당시 어떤 회사에 소속되어 있는데, 아주 이직을 많이 하는 것 같았습니다.

    페북등을 따라가며 봤습니다.

    자기 기술을 오픈소스해놓고 회사를 옮겨다니며 전파하고 있는 겁니다!


    0
  • satis
    250
    2019-04-10 10:20:21

    이게 바로 실리콘밸리의 시스템입니다.

    실리콘 벨리 시스템 출처좀 부탁드립니다.
    실리콘 벨리 시스템 정보는 어디에 있나요?
    0
  • 박가사탕
    264
    2019-04-10 10:26:50

    다큐를 보십시요~^^


    자기 브랜드를 만들기 위해서 몰두하는

    실리콘밸리 이직자들의 모습을 확인할 수 있을 겁니다.

    자기 브랜드가 뭘까요? 오픈소스죠.


    물론 다큐내용은 일반인을 대상으로 하는 것이니

    깊은 내용은 유추해보는 수 밖에 없습니다.

    떠먹여주는 고급정보는 없습니다..

    0
  • satis
    250
    2019-04-10 10:30:40

    자기 기술을 오픈소스해놓고 회사를 옮겨다니며 전파하고 있는 겁니다!

    개발자로 가장 이상적인 모습이네요.
    기술전파, 다큐 한번 찾아보고 싶네요.
    몇년도 방송인가요?
    0
  • fender
    13k
    2019-04-10 10:35:13 작성 2019-04-10 10:59:36 수정됨

    박가사탕 // 당연히 소프트웨어 선진국에서도 개발자의 능력을 중요시하고, 그런 개발자들이 이직하면서 개발 노하우를 전수하곤 합니다. 하지만 거기서 바로 그 '노하우'가 곧바로 그 개발자 본인만이 유지보수 할 수 있는 무언가를 이직한 회사에서 새로 만드는 것이라는 결론이 도출되지 않을 뿐입니다.

    말씀하신 오픈소스를 통한 기술 혁신이라는 측면을 보다 자세히 살펴보면 이 점이 명확해 질 것으로 생각합니다. 핵심 기술이라는 것이 정말 소통되지 않는 개발자마다 고유의 무언가라면 애초에 오픈소스라는 게 어떻게 가능할까요?

    만약 기술 혁신이 그런식으로 발전하고 실리콘 밸리 회사들이 기술 공유 대신 그렇게 개발자 개인의 테두리를 벗어나지 못하는 비법 수집에만 몰두했다면 오픈소스가 지금처럼 대세가 될 수 없었을 것입니다. 왜냐하면 말씀대로라면 실력있는 개발자가 짠 가치있는 코드는 개발자 본인만 다룰 수 있을테니 협업이 안될테고, 그게 진짜 대단한 영업 비밀이라면 기업에서 공개할 리도 없으니까요. 협업하지 않고 공개하지 않는 기술이 오픈소스가 될 수 있나요?

    현실에서는, 코딩 컨벤션, 베스트 프랙티스, 디자인 패턴, 패러다임, 방법론 등은 개발자 커뮤니티에서 널리 공유되는 도구일 뿐이고, 능력이 있는 개발자란 바로 그런 도구를 적재 적소에 활용해서 규모가 커지고 기능이 추가되어도 최대한 유연하게 유지보수 가능한 코드를 작성할 수 있는 프로그래머를 뜻합니다.

    그래서, 뛰어난 개발자가 이직을 한다면 이직한 회사에서 기존 모듈이 그 개발자만 다룰 수 있는 다른 모듈로 대체되는 것이 아니라, 그 개발자가 지닌 설계나 아키텍쳐에 대한 통찰, 기술 동향에 대한 이해, 보다 발전된 관행이나 방법론 등 다양한 노하우가 팀에 전파되어 상승효과를 얻는 것이 핵심입니다.

    0
  • fender
    13k
    2019-04-10 10:52:18

    여담이지만, 만일 누가 능력있는 개발자가 협업이나 기술 동향과 담을 쌓고 자신만의 방법으로 무언가를 만들어가면 어떤 것을 이룰 수 있는가란 질문을 한다면 저는 템플OS(TempleOS)의 사례를 떠올릴 것 같습니다.

    템플OS를 만든 테리 데이비스(Terry A. Davis)는 뛰어난 개발자였지만 정신분열증을 앓고 있었는데, 무슨 이유에서인지 기독교에서 말하는 '하나님의 성전'을 짓는 것을 운영체제를 만드는 것으로 이해하고 신이 직접 자신에게 그런 사명에 대한 계시를 내렸다고 믿게 됩니다.

    심지어 그는 신이 '해상도를 640x480으로 하고 16 색상을 지원하라'는 등 구체적인 요구조건을 지시했다고 주장합니다. 중요한 건 데이비스는 그런 신념으로 20년 동안 자신만의 운영체제를 위한 C언어의 변종부터 컴파일러, 커널, 드라이버, 통합 개발도구는 물론 비행시뮬레이터 같은 게임까지 직접 만들었다는 것입니다.


    (템플OS의 스크린샷)

    하지만 당연한 이유로 그런 노력은 개발자들 사이에서 이야깃 거리 이상의 파장을 만들진 못했고, 데이비스는 작년에 열차 사고, 혹은 자살로 생을 마감합니다.

    만일 데이비스가 정신병을 앓지 않았다면 보다 의미있는 결과물을 만들 수 있었을지는 알 수 없습니다. 하지만 실제 소프트웨어 분야의 기술 발전은 그런 소통하지 않는 개인의 혼자만의 연구 결과 보다는, 오픈소스를 중심으로한 전 세계 수 많은 개발자들의 공통의 노력을 통해 이루어지는 경우가 압도적으로 많다는 것만은 분명한 것 같습니다.

    1
  • 박가사탕
    264
    2019-04-10 11:10:01

    기업이 오픈소스문화를 주도한다고 생각하세요?

    기업은 오픈소스를 사는데 관심이 있을 뿐입니다.

    개발자가 자기 필요에 의해 자연스럽게 도출된

    문화입니다. 순리에 따라 도출된 문화.


    오픈소스 개발자들 백수인가요?

    전부 기업 근무자입니다.

    arm컴파일러 개발자들이 낮에는 암 개발하고

    저녁에는 gcc를 만들었단 일화는 유명하죠.


    전세계에 얼마나 많은 오픈소스가 있을까요?

    그들만으로도 실리콘밸리는 인재가 넘쳐날 겁니다.

    낮에는 자기 오픈소스 기술을 프로젝트에 접목하고

    밤에는 커밋하고.. ㅎ

    0
  • fender
    13k
    2019-04-10 11:18:08

    박가사탕 // 말씀하시는 논점을 모르겠습니다. 제가 지적한 것은 오픈소스를 기업이 주도하는지 여부가 아니라, 개발 능력을 개발자 개인 안에 갇혀있는 무언가로 정의하면서 그런 주장의 근거로 오픈소스를 언급하는 것의 모순입니다.

    이제까지 쓰신 글에서 코드리뷰, 코딩 컨벤션, 리팩터링, 디자인 패턴 등 개발자 커뮤니티가 공유하는 지식들을 '쓰레기'라고 까지 단언하고 코드는 어차피 사람 바뀌면 다시 짜야 하는 것이라고 주장하지 않으셨나요?

    그리고 최근 글에서 기업들은 그런 본인만의 모듈을 만드는 개발자를 스카웃해서 자신의 회사에서 다시 그 개발자만 만들 수 있는 모듈을 만들게 하는 것이 실리콘 밸리 기업들의 관행이고 경쟁력이라고 주장하셨습니다.

    그 두 가지가 사실이라면 당연히 여러 개발자들이 하나의 코드 베이스를 두고 협업하며, 알고리즘이든 무엇이든 서로 공유하는 오픈소스라는 건 존재할 수 없는 것 아닌가요?

    0
  • 박가사탕
    264
    2019-04-10 11:43:28

    "개발자 개인 안에 갇혀있는 무언가" <- 이게 뭐죠 도대체? ^^;

    내가 하면 로맨스고 남이 하면 불륜인가요? ㅎ


    자기 기술이라고 숨기고 꽁꽁 싸매지 않습니다.

    소통하고 이해시키려 노력하고 문서화합니다. 아예 오픈소스화하죠.

    그렇게 하는데도 불구하고 인수인계는 안된다는 겁니다.

    인수인계를 못하도록 나쁜놈들이 의도적으로 누가 숨긴다는 얘기가 아니라

    새 글로 풀어 쓴 것처럼 근본적으로 인수인계가 안되는 메커니즘이 있다는 것입니다.


    오픈소스 커미터되면 오픈소스 전부 이해하고 있을까요?

    지가 참여한 부분만 겨우 아는 거죠.

    좀 유명한 왠만한건 30만줄, 50만줄. 큰건 100만줄~500만줄(리눅스)입니다.

    주력 커미터가 휴가가면 어떻게 되냐면요.

    해당 부분의 업데이트가 밀리기 시작합니다.

    결국 사람에서 시작해서 사람으로 끝납니다.


    0
  • fender
    13k
    2019-04-10 12:07:16 작성 2019-04-10 12:52:19 수정됨

    박가사탕 // 남이 짠 코드는 이해하기 어렵다는 것과 그래서 코드 리뷰 같이 코드 품질 유지를 위한 노력 따위는 "바보같은 짓이다"라는 주장 사이엔 꽤 아득한 간극이 있습니다.

    또한, 가끔은 리거시를 버리고 새로 작성하는 것이 낫다는 주장과, 개발자는 자기 모듈만 담당하다가 개발자 바뀌면 처음부터 갈아엎는 것이 "실리콘 밸리의 관행"이라는 주장 역시 같은 것이 아닙니다.

    제가 박가사탕님께 드리고 싶은 말씀은, 과격한 주장은 좋지만 적어도 그것이 사실 관계가 불분명한 내용이라면 경험이 부족한 분들이 오해하지 않게 주장과 사실은 좀 구분하셨으면 좋겠다는 점입니다.

    제가 기억하는 것만해도 가상 머신 언어는 성능 때문에 막대한 비용이 발생해서 기업들이 기피해는 추세라던지, 노드JS는 버려진 기술이라던지, 코드 리뷰 따위 우리나라 경영진이 무식해서 중요시한다는 등등 사실 관계조차 왜곡하는 내용이 한 두 가지가 아닙니다.

    때로는 발상의 전환이 의미있는 경우도 있으니 다양한 시각은 존중합니다만, 그런 식으로 사실과 다른 내용을 디자인 패턴, 리팩터링 따위 '쓰레기 지식'이라느니 가상언어를 주력으로 하면 커리어를 망친다던지 하는 식의 과격한 주장의 근거로 교묘하게 섞는 방법으로 아직 경험이 부족한 다른 개발자들이 잘못된 인식을 가지게 하는 일은 자중하셨으면 좋겠습니다.


    0
  • 박가사탕
    264
    2019-04-10 12:17:35

    누군가는 과격하다고 느낄 수도 있겠고.

    누군가는 명료하다고 느낄 수도 있을 겁니다.

    제가 말하는 모든 것은 제 경험입니다.


    글을 읽으시는 분들이 그리 멍청하지 않습니다.

    걱정마시란 말씀을 드리고 싶네요^^


    -1
  • 쥬드노
    771
    2019-04-10 13:09:04

    @fender 님이 먹이를 주신듯.

    가치 없는 글엔 무플이 답입니다. ㅎㅎ

    0
  • 0
  • fender
    13k
    2019-04-10 14:07:07

    박가사탕 // 미리보기 내용 어디를 보아도 실리콘 밸리에선 개발자가 이직하면 기술이 '교체'가 된다던지 코드 리뷰가 필요없다던지 하는 이야기는 없는 것 같습니다.

    URL을 보니 근거를 찾으려고 "실리콘밸리 패턴"이라고 인터넷 검색을 하신 듯 한데, 애초에 소프트웨어 공학에 대한 책도 아니고 잠깐 언급하는 실리콘밸리에 대한 내용도 이직과 특허에 대한 내용이군요.


    0
  • 박가사탕
    264
    2019-04-10 14:23:50

    맞아요. 실리콘밸리에서 패턴을 많이 쓴다는 펜더님의

    주장에 무슨 근거가 있는질 확인해 보려고 검색하다가

    우연히 책 미리보기를 발견하여 읽어보니

    저랑 가치관이 같아서 링크 올려본 겁니다^^

    0
  • 박가사탕
    264
    2019-04-10 14:28:17

    초기 인용구, 정보를 전송하는 최선의 방식은 정보를 인체안에 넣어서 보내는 것이다.

    두번째, 기업의 성공에 인재를 통한 무임승차의 필요성

    세번째, 경업금지 하지 않는 실리콘밸리의 잦은 인재이동이 가져오는 발전


    문서나 리뷰, 패턴강요가 아닙니다.

    정보(기술)를 인체안에 넣어서 “보내고” “받았기”

    때문이죠. 실리콘밸리의 성공은.

    0
  • 박가사탕
    264
    2019-04-10 14:31:51

    정보를 A인체에서 B인체로 리뷰나 문서화, 인수인계같은 소통과정을 통해서 전달하는게 아니라.

    “A인체”를 직접 보낸다는 거죠. 어디에?

    B인체가 이직한 그 회사의 TO에.

    0
  • fender
    13k
    2019-04-10 14:32:22 작성 2019-04-10 14:41:00 수정됨

    자바 같은 언어로 복잡한 프로젝트를 설계하고 분석하는데 디자인 패턴이 필요한가 하는 질문은 거의 "C언어를 배우려면 정말 포인터를 알아야 하는가"와 비슷한 수준의 이야기입니다.

    굳이 그에 대한 근거가 궁금하시다면 "실리콘밸리 패턴"같은 주제어보단 구글에서 "design pattern analysis importance" 정도로만 검색하셔도 논문부터 스택오버플로우까지 읽을 만한 내용이 한 가득 나오니 참조하시기 바랍니다.

    한편, 인터넷에서 이번 주제와 관련한 내용을 찾자면 저는 이런 내용을 소개하고 싶습니다. 소프트웨어와 별 관계없는 서적이 아닌, 소프트웨어 공학 분야에서 유명한 아키텍트인 마틴 파울러의 블로그입니다:


    박가사탕님은 개발자는 모듈을 전담하고 개발자가 이직하면 다른 개발자가 와서 해당 모듈을 새로 짜는 것이 '실리콘 밸리의 관행'이라고 주장하셨는데, 링크한 글은 코드 소유권과 관련해서 실제 어떤 방식의 관행이 있는지 소개하고, 말씀하신 방식의 개발이 왜 가장 안좋은 접근인지 설명하는 내용입니다.

    실리콘 밸리 기업들 대다수가 코드리뷰를 코드 품질 유지를 위한 가장 중요한 관행으로 지목하고 적극 도입하고 있다는 근거는 가장 첫 덧글에서 소개했으니 다시 반복하지 않겠습니다.

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

    문서화, 코딩규칙, 리뷰따위가 아니라

    “정보를 인체안에 넣어서 보낸다”는 발상에

    뭔가 느끼는 점은 없으신지요?

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

    미틴파울러는 강한 코드소유권을 싫어한다네요.

    어쩌라구요. 개취로 싫어한다는디.. ㅎ


    0
  • fender
    13k
    2019-04-10 14:44:43 작성 2019-04-10 15:13:59 수정됨

    그렇게 스타트업 운영하다 개발자 이직하면 회사 망하겠구나 하는 점은 느껴집니다.

    그리고 코드 소유권에 대해선 마틴 파울러의 의견이 업계의 상식에 가깝고, 박가사탕님의 주장이 너그럽게 봐서 '개취'라고 표현할 수 있는 정도일 듯 합니다.

    특정 모듈은 혼자만 개발하다 이직하면 갈아엎고 코드 리뷰 따위 안하는게 상식이면, 가져오기 요청 / 코드리뷰 / 병합으로 이어지는 깃헙 방식의 작업흐름이 대세가 된 건 어떻게 설명하실 건가요?

    다시 한 번 말씀드리자면, 업계 관행과 동떨어진 개인 취향에 대한 주장을 하시는 건 좋습니다. 그런데 그걸 마치 실리콘 밸리에선 다 그렇게 한다는 식으로 근거없이 포장하는 것은, 이 글을 볼 초보 개발자들을 위해서라도 자제하셨으면 합니다.

    0
  • fender
    13k
    2019-04-10 15:01:22 작성 2019-04-10 15:15:48 수정됨

    검색하다가 우연히 코드 소유권에 대한 켄트 벡(Kent Beck) - TDD나 객체지향 디자인 패턴, 애자일 방법론 등의 분야에서 선구적 역할을 한 아키텍트입니다 - 의 의견을 찾아서 같이 소개합니다.

    I submit that code ownership is not a generally good thing. I have been working with a group of eight engineers on a fairly complex system. We have no such concept. In fact, we go the other way - no one works on the same part of the system for more than two ThreeWeekIterations, and generally not for more than one. The result is a team that can quickly and easily shift resources where they are needed, code that is communicated and refined, and a high TruckNumber.

    (출처 - Code Ownership)

    역시 코드의 강한 소유권을 비판하는 내용이고, 앞서 소개한 '버스 팩터' 역시 해당 개념의 또 다른 이름인 '트럭 넘버'로 언급하고 있는 점이 흥미롭습니다.

    0
  • 박가사탕
    264
    2019-04-10 15:03:08

    확실한건 실리콘밸리는 우리나라 업계의

    이직, 인재 관행과 다르단 겁니다. 머.. 중요치 않습니다.

    실리콘밸리가 다 정답도 아니고 펜더님에겐

    아주 중요한 절대적 지표인지는 모르겠으나 실리콘밸리가

    통념적으로 뭔가를 한다고 해서 무조건 인정하고픈

    생각은 없거든요 전.


    여튼 전 그렇게 해석하고 있습니다.

    제 뇌가 그렇게 해석하고 있어요. 실리콘밸리를.

    근거는 수십개의 다큐와 해석된 글과 블로그가 전부죠.

    하지만 같은 내용을 보고도 해석은 달라집니다.

    펜더님의 다른 해석도 인정합니다.


    하지만 사회통념 같은 기준은 좀 우습죠.

    99% 프로젝트가 망하는 승자독식의 SW세상에서

    통념따위가 무슨 의미나 권위가 있을까요?

    -1
  • fender
    13k
    2019-04-10 15:11:42 작성 2019-04-10 15:20:33 수정됨

    실리콘밸리가 다 정답도 아니고 펜더님에겐  아주 중요한 절대적 지표인지는 모르겠으나 실리콘밸리가 통념적으로 뭔가를 한다고 해서 무조건 인정하고픈 생각은 없거든요 전.

    생각하시는 내용을 널리 쓰이는 관행으로 착각해서 이 글에서 '실리콘 밸리'를 여러차례 언급하면서 본인 주장에 대한 '근거'로 삼으신 건 제가 아니라 박가사탕님입니다 :


    실리콘밸리 다큐를 보다보면 그 원리를 알게 됩니다.
    실리콘밸리는 평균 이직이 1~2년인데, 어떻게 기술력이 이어지는가
    이게 바로 실리콘밸리의 시스템입니다.
    1~2년 주기로 이직자들이 "기술을 날라주기" 때문에 실리콘밸리가 전체적으로 경험을 공유하고


    2
  • 박가사탕
    264
    2019-04-10 15:40:30

    착각인지 아닌지 펜더님도 알 길은 없죠..

    모두가 추측인거죠.


    0
  • 박가사탕
    264
    2019-04-10 15:42:52

    인용 따위는 쉽게 한겁니다. 제 추측을.

    제 글은 모두 제 추측 아니겠어요? ㅎㅎ

    법전을 편건 아니니까요.


    그러나 이렇게 여러번 이야기할만큼

    중요한 가치는 아닙니다. 정답도 없구요.

    각자 마음속에 정리되는 믿음이 결론이죠..

    -1
  • flydof
    268
    2019-04-10 21:40:54

    보넥스님 인가여... 나무관세음보살...


    글이 보넥스님보다 ,20% 정도 퀄리티가 높네요

    0
  • flydof
    268
    2019-04-10 21:41:47

    문장에 허술한 패턴이 버넥스님과 유사하네여

    0
  • exexexe
    102
    2019-04-11 09:28:46

    재미있는 두분이 만나...재미있는 글을 써주셔서 감사합니다.

    신과 구의 대결구도 같구만..ㅎㅎ



    0
  • 가난디지털단지
    144
    2019-04-11 13:02:51

    작성 -> 반박 -> 깨갱 -> 정신승리

    0
  • 박가사탕
    264
    2019-04-11 14:16:14

    깨갱~~ ㅎㅎㅎ

    재밌네요 ㅋㅋ

    0
  • m1d2h3
    915
    2019-04-11 22:14:59

    공감은 못하지만 카카오부럽네요 ㅎㅎ

    0
  • 잠만보 
    4k
    2019-04-12 08:05:12

    0
  • sm&si
    2k
    2019-04-12 10:57:12

    혼자서 20만줄을 다 만들 수 있다면 가능한 얘기겠죠.

    예를 들면, 혼자서 자동차를 만들 수 있는 사람이라면 정년 걱정없이 살 수 있겠죠.

    하지만, 우린 컨베어 벨트에서 바퀴나 끼우고 있는 노동자일 뿐.


    0
  • kim
    294
    2019-04-12 11:17:10

    정신승리 오지네요..

    0
  • gondor
    254
    2019-04-13 13:26:28

    두분다 맞는 말씀 하신거 같은데요. 가치관이나 생각이 다른거지 틀렸다고는 생각하지 않아요. 저런 견문을 가졌다는게 부럽네요.

    0
  • smasma
    2k
    2019-04-14 18:45:34

    저는 "당연히 기술력이 이어지지 않죠. 대신 기술력이 교체됩니다."

    라는 의견에는 동감합니다. 물론 인수인계는 하고 나오겠지만 오리지널 개발자만큼 해당 프로그램을 이해할수 없는것은 어쩔수 없는 한계일 것입니다. 혹은 더 능력있는 개발자가 오면 기존 개발한것을 폐기하고 새로 개발하면 된다는 식으로 반론 하시는 분들도 계시겠지만. 그런건 운좋은 경우이고 그렇지 않은 경우도 있다는 것을  저는 이미 경험해 보았기  때문입니다. 코드의 복잡함보다는 코드를 만들기 위한 많은 아이디어들이  동원된 경우에는 더더욱 그러하더군요.. 그러한 많은 아이디어들을 모두 녹여내어서 그대로 새로 재창조하는것 또한 시간이 들어가는 일이며 회사입장에서는 비용일 것입니다.

    하지만 "코드리뷰는 바보같은 짓이다" 라는 견해는 저는 동의하지 않습니다. 아무리 작은 프로젝트라도 최소 2인이상 개발하는 경우가 흔하고. 코드리뷰는 기술의 공유라는 관점보다는 코드리뷰를 통하여 집단지성의 장점을 코드에 녹아들게 해서 좋은 코드 품질과  더욱 향산된 방향으로의 개발 결과물을 유도해 낼수 있다고 믿기 때문이기도 합니다. "좋은 개발 결과물은 집단지성의 논의과정을 거쳐야 나온다라고 생각합니다."


    0
  • 참서빈
    3k
    2019-04-14 20:22:21 작성 2019-04-14 20:22:55 수정됨

    ♥ 자신의 생각이나 의견은 

    사실인 것으로 오해할 소지가 없도록

    ... 인것 같습니다.

    ... 로 생각됩니다.


    정도로 표현하는 것이

    어떤가 생각 됩니다.


    글을 읽는 분들을 배려하는 마음도 

    중요하다고 생각 되구요..


    대립과 분열 보다는

    협상과 조화가 

    협업에는 필요한 것 아닐까 합니다..


    27년차 개발자의 댓글이었습니다.

    0
  • 박가사탕
    264
    2019-04-15 09:53:23

    서빈님의 고견 새겨듣도록 하겠습니다^^

    다만 저는 남의 글 볼때 전부 필터링합니다..

    저는 그래요. 외국의 유명한 분 멘트 인용해도

    안 넘어갑니다..


    다들 그렇지 않나요? ㅎㅎ

    방어적인 뭉탱이글.. 걍 스크롤링 해버리지

    감탄하고 있지 않고던요. 신선한 발상에만

    스크롤이 잠시 멈춰요.


    그렇기에 크게 걱정하지 않는데..

    걱정이 되시나 봅니다..

    0
  • 장지락
    646
    2019-04-15 13:27:10

    맞는 말도 있고 틀린 말도 있고,

    개발자가 "권력을 가졌다." 또는 "가질 수 밖에 없다."라고 주장해도 아닌 경우가 더 많죠.

    현존하는 기업중 CTO vs. CFO 권력의 헤게모니 싸움에서 왠만하면 CFO가 승자이며, 일반적으로도 힘이 더 좋죠. 즉, "돈 == 인사권" 아니겠어요?

    0
  • 손이시렵다
    1k
    2019-04-15 13:54:54

    글에서 꼰대 냄새가 물씬 풍기네요 이런분이랑은 정말 같이 일하기 싫을거같습니다.

    17년동안 어떤 환경에서 갇혀 일하셨는지는 모르겠지만

    적어도 제 주변의 동료중에 당신같은 분이 안계시다는 것에 감사해야겠네요

    0
  • 에스쇼콜라
    132
    2019-04-16 11:18:25

    @fender 좋은 글과 반박 댓글 남겨주셔서 감사합니다.

    상대방을 존중하면서 말씀 하시는 모습이 귀감이 되었습니다.

    글도 정말 잘 쓰시네요.

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