누구나 알고 있지만 아무도 하지 않는 불편한 이야기

15 Sep 2019 » Story

나도 분노조절장애 같은게 있는지, 갑자기 화딱지가 치밀어 올라서, 하루만에 글을 추가하게 된다.

사실은 어제글보다 이런 글을 쓰고 싶었던 걸수도…


우리가 주로 봐오던 글들은 이런거다.

클라우드, AI, 빅데이터, 블록체인을 말하지만 실제 아무것도 모르는 경영자들

아무것도 모르면서 ‘이거 언제까지 돼요?’ 라고 묻는 기획자들

하도급, 단가 후려치기, 낡은 구조와 시스템, 말도 안되는 일정으로 돌아가는 차세대 시스템

우리는 이런 글들을 보며 박수를 친다.

하지만 한편으로 우리는 슬그머니 개발자의 능력부족에 대해서 눈을 돌린다.

문득 이것이 스스로 비판하는 능력을 상실한 우리나라 언론과 마찬가지로 느껴졌다.

요새 언론들 하는 꼬라지를 보면, 개발자 커뮤니티가 스스로 비판하지 못하고 불편한 얘기에서 눈을 돌리면 어떻게 될 지 짐작이 간다.

우리가 눈을 돌리던 것들

  • 문서나 테스트 코드도 없는 코드
  • 수십 수백줄짜리 메소드 혹은 펑션
  • 원리를 모른채 붙여넣은 코드
  • 몇년이 지나도 발전이 없는 (개발자의)기술스택

이것도 다 개발자가 저지르는 짓들이다.

아 물론 이런 부분은 있다. 우리는 암묵적으로(혹은 대놓고) 개발자를 구분하고 있을수도 있다.

적어도, 나는 우리가 흔히 말하는 ‘개발자’를 구분하고 있다.

개발자라는 단어에 걸맞게 개발을 하지 못하고 ‘구현’만 하는 사람, 혹은 그마저도 못하는 사람을 개발자에서 우선적으로 제외한다.1

또 하나, 개발이 목적이 아닌 개발을 수단으로써 대하는 사람을 제외한다. 일단, 이 글에서는 이 부류는 제외하자. 함께 다루기엔 할말이 많다.

분명히 느껴지는 보이지 않는 벽

SI 개발자로 시작해서 IT 서비스쪽도 했지만(정확히는 하고 있지만), 분명히 둘 사이에는 벽이 있다.

그 두 세계 사이에 걸쳐져 있는 내 눈에 그 벽은 앞/뒤, 좌/우를 가르는 것이 아니라 위/아래를 가르는 것처럼 보인다.

그리고 그 벽을 사이에 두고 양쪽은 서로 이해할 수 없는 무언가가 존재하는 것 같다.

작년 팝잇 멘토링 모임에 갔을때도 느낀 부분이지만, 서비스회사들에서 커리어를 쌓아온 -내가 생각하는 ‘엘리트 코스를 걸어온’- 개발자들은 SI 업계의 상황을 알지 못하고 있는 느낌을 받았다.(내가 들어간 세션만 그랬을수도 있다.)

그래서 ‘빵이 없으면 케이크를 먹으면 되지?’ 같은 느낌의 대화도 있었고…

아래쪽 세계에 미련도 없고 관심도 없지만, 분명하게 알고 있는 것은 있다.

이쪽으로 넘어오고 싶어하고, 가능성도 충분하지만 방법을 몰라서 넘어오지 못하는 사람이 극히 일부지만 분명히 존재한다는 것.

반대로 대부분의 경우, 평생이 걸려도 이쪽으로는 오지 못할거라는 것.

보이지 않는 벽의 기준

위에서는 업계 얘기를 했지만, 저 벽의 기준은 당연하게도 개발자의 실력이다.

실력이라 해서 대단한 전문기술을 의미한다기보다, 기본기를 구성하고 있는 실력이 저 벽의 기준이 된다고 보고 있다.

요즘은 연봉상으로나 다른 여러가지 조건으로나 실력있는 개발자가 서비스쪽에 있는 경우가 많지만, 언제나 예외는 존재하니까..

의미없을 정도의 예외 표본은 제외하고, 이런 소리를 하는 개발자들이 있다.

꽤 많은 (그것도 특히 연차가 꽤나 쌓인)개발자들이 잘난척 하는 얘기는 이런거다.

  • 그런거 다 신경쓰면 일정에 못맞춰서.
  • 그런건 현장 상황 모르는 사람들이 하는 얘기.
  • 저런 얘기 하는 사람들 보면 실무는 꽝이더라

여기서 지칭되는 ‘그런거’는 보통 TDD, Clean Code, Refactoring, Agile, 심지어 객체지향(그것도 Java에서)같은 기본기다.

그런데 과연 그들이 실무를 매우 잘하고, 저런 얘기를 하는 사람들이 실무를 못하는 문제일까?

생각해 봐라. 상대성이론이나 양자역학을 이해하지 못하는건 그 이론을 가르치는 학자들의 문제인가, 아니면 이해를 못하는 사람들의 물리학 수준이 낮아서인가.

지금의 내 시점에서 말하자면, 그걸 다 신경쓰면 일정에 못 맞추는 가장 큰 원인중 하나는 내 실력부족이었다. 내가 느렸던거다.

애초에 그들이 다루는 실무보다 복잡한 실무를 다루면서도 일정 맞추며 하는 개발자들이 있다. 있더라.

유형1 : 우물안 개구리 개발자들

주로 위와 같은 얘기를 잘 떠들고 다닌다. 자기 주변영역 밖을 이해하지 못한다.

옆자리 개발자들 돌아봐도 TDD, 객체지향 같은건 이해하지 못하고 관심도 없다.

젊었을때는 그런 고민을 해봤던 것도 같은데 부장님한테 물어봐도 모르고, 혼자 공부해봐도 감이 오지 않아 포기했다.

개발의 주체가 언제나 클라이언트라서 넘어오는 일을 하나하나 처리하는 것도 버겁다.

그러다 보니 저런 개념은 하느님 같다.

있다고 하긴 하는데 본적은 없다.

결국 이렇게 된다.

  • 지구가 둥글다니 그게 무슨 헛소리야? 이렇게나 평평한데. 지구가 둥근거 니 눈으로 직접 봤어? 내가 30년을 살았는데 한번도 본적이 없어!

유형2 : 학교를 졸업하지 못한 개발자들

아직도 누군가가 문제와 보기를 주고 그중에서 고르세요. 라고 해주길 기다리는 것 같은 사람들이 있다.

주로 그런 류의 사람들은 구글에서 How To Use를 찾아서 코드를 복붙한다. 그리고 돌아가는 것을 보고 흐뭇해하며 코드를 머지한다.

애초에 그 코드가 어떤 원리로 돌아가는지, 어떤 목적으로 짜여진 코드인지는 관심이 없다.

그는 훌륭하게 주어진 답을 찾았고, 그 답을 제출했다.(아마도 누군가 채점해주는 사람이 있다고 믿는 것 같다.)

그게 문제없이 잘 돌아가면 좋겠지만 원리를 모르는 기술을 사용하는 것은 모르는 사람을 안방에 들인 것과 같다.

때때로, 사실은 꽤 높은 확률로, 그 코드는 갑자기 우리집 안방에서 칼을 휘두르며 날뛴다.

메모리는 요동을 치고 시스템이 미쳐돌아가기 시작한다.

애초에 원리를 모르기 때문에 디버깅이 될 리 없다.

운이 좋으면 팀 내에 누군가가 코드를 쓱 보더니 고쳐서 상황이 종료되고, 운이 없으면 revert다.

아마 혼자서 조용히 생각할거다.

‘분명히 그대로 가져다 넣었는데…’

유형3 : 수박 껍데기를 열심히 핥아대는 개발자들

  • 에스파냐에서 서쪽으로 가면, 인도에 도착한다.(true)
  • 그는 에스파냐에서 서쪽으로 항해했고, 육지에 상륙했다.(true)
  • 그는 죽을때까지 그 땅이 인도라고 믿었다(false)

왜 콜롬부스는 그 죽을 고생을 하고도 인도에 도착하지 못했는가 : 인도를 몰라서
왜 Clean Code, Agile, 객체지향, TDD 등이 의미없는 얘기라고 말하는가 : 그게 뭔지 몰라서

이 유형은 이렇게 된다.

본질을 이해하지 못하고 있기 때문에 죽을때까지 도달하지 못한다.

예를 들어 객체지향 5원칙만 책으로 보다가 흉내내본다던가, 애자일 도구를 몇개 써본다. 객체지향 그 자체나 애자일의 핵심가치 따위는 모른다.

더 최악의 경우는 이도저도 아닌 결론에 도착해서 몇번 흉내내보고 ‘이거 아무 쓸모 없잖아?’ 라고 자랑스럽게 떠든다.

가끔씩 그럴싸해 보이는 말에 휘말려 같이 거미줄에 휘감기는 주니어도 있다.

유형4 : 파랑새를 찾는 개발자들

뭔가 혁신적인 것이 있을거라고 믿는다.

어떤 기술이나 방법론을 쓰면 실력이 갑자기 뻥튀기 될것처럼 생각한다.

혹은, 마치 내가 큰 회사로 이직하면 내게 잠재된 어마어마한 포텐셜이 폭발해서 실력이 쭉쭉 성장할 것처럼 착각한다.

무협지스러운 인생을 사는 사람들 같다. 기연을 찾아서 절벽이라도 타고 오를 기세다.

그나마 동화속 결말처럼 파랑새가 우리 곁에 있었음을 눈치챈다면 해피엔딩이지만,

대부분 맨 위의 유형으로 돌아가는 것 같다.

  • 파랑새? 그런거 없어! 내가 10년을 찾아다녀봤는데 말야….

벽을 넘는다는 것의 의미

Tablets

파란 알약을 먹으면 쉽다. 하루하루 넘어오는 일을 감당하며 버티면 된다.

늘 하던 일의 반복이고 가끔씩 예상치 못한 일이 발생하지만, 적당히 넘길 수 있다.

다만 어디까지나 나는 매트릭스의 식량, 내 생사여탈권을 포함한 모든 것은 매트릭스가 제어한다.

빨간 알약은 위험하다. 그 알약을 먹는 순간 살아남으려면 매일같이 훈련을 계속해야 하고, 한계를 뛰어넘기 위한 고민은 반복된다.

주변에 같은 고민을 하는 개발자를 찾아 네트워킹을 하고 가끔 매트릭스 안쪽 세계에서 발생하는 사고의 뒷처리도 우리 몫이 된다.

대신 자유롭다. 이쯤되면 일은 한도 끝도 없이 많지만, 내가 알아서만 하면 아무도 나를 터치하지 않는다.

시민과 신민의 차이

학부시절에 사회학이었는지 정치철학이었는지는 가물가물한데, 시민과 신민의 구분에 대한 내용이 있었다.

이 둘의 차이는 시민은 주권을 가지고 행동하며 책임을 지는 주체가 된다는 점이다. 그래서 ‘시민혁명’ 같은 단어가 성립할 수 있다.

지금의 개발조직은 이러한 차이를 아주 잘 대변하고 있다.

  • 어딘가에선 개발자가 탑다운으로 내려오는 일정에 시달리고

  • 또다른 어딘가에선 개발자가 주도적으로 더 나은 방식을 제안하고 새로운 기술을 도입하며 개발한다.

  • 어느 조직은 새로운 방법론 도입을 외치며 신민들을 데리고 고생하고 있으며,

  • 어느 조직은 고전적인 시스템 내에서 왜 개발자들이 주도적으로 일하지 못하는지를 고민한다.

그리고 분명히 더 자유로운 세상에서 주도적으로 일하기를 바라며 빨간 알약을 꿈꾸는 개발자가 있을거다. 나처럼.

문제해결능력보다 중요한 것이 있다.

문제해결능력은 매우 중요하지만 주도적으로 일한다는 것은 ‘문제를 발견하는 능력’이 필요하다.

누군가에 의해 발견되어지는 문제를 넘겨받아 해결하는 것이 아니라, 스스로 문제를 발견하고 그것을 해결할 수 있어야 한다.

개발자에 한정해서가 아니라 민주주의 사회에서 자신의 의견을 개진할 수 있는 것은 필수 항목이다.

물론, 지구는 평평하다! 라던가, 태양이 지구 주위를 돈다! 라는 주장은 의견 개진으로 보지 않는다. 이런건 우리가 보통 ‘상식의 문제’ 라고 한다.

‘비밀번호를 암호화해서 저장해야 한다’ 라고 말하는 사이에서 ‘하나도 안중요합니다!’ 라고 외치는건 의견 개진이 아니라 몰상식이다.

어디까지나 일반 상식 하에서 남들이 놓친 부분에서 합리적인 의견을 개진할 수 있으면 충분히 주도적으로 1인분을 할 수 있다고 생각한다.

물론 의견을 개진한다는 것은 주장만으로 이루어지지는 않으며, 경험이나 충분한 배경지식이 뒷받침되어야 한다.

일단 마무리

개발자가 부족하고 몸값이 비싸지다 보니 개발자 커뮤니티도 과도기를 겪고 있지 않나 싶다.

사실 개발자가 암묵적으로 구분된다고 생각하는 쪽인데, 세간에서는 코딩에 대한 지식이 조금만 있어도(실제 제대로 된 코드를 짜는지를 보지 않고) 일단 개발자로 분류하는 것 같다.

이전글에서도 말했지만, 개발조직은 자유로운 분위기가 일찍 도입되었다.

그것이 성립 가능한 이유는 개발자가 탑다운으로 이어지는 봉건적 회사조직과 달리 개발자가 각각의 주권자로써 행동 가능하기 때문이다.

물론 한편에는 유명한 개발자(자칭 잡부)님을 찾아가 고민을 상담한 SI에 있는 주니어 개발자와, 과제를 내주고 코드리뷰를 해주는 분도 계시는 것을 보면


  1. 이전 글에서도 주장했지만, 구현 = 개발일수 없다. 


Tags : philosophy