제대로 체계를 갖추기 못한 회사에서는 개발자가 경력이 늘어갈 수록 거짓말이 늘곤 한다.
비효율적인 것을 알지만 (혹은 모르기도 하고) 자신의 기득권을 지키기 위해서 거짓말로 경영자를 현혹하곤 한다. 고의적인지 아닌지 그 경계는 매우 모호하다.
물론, 뛰어나고 훌륭한 고참 개발자들도 많다. 회사의 기술을 리드하고 후배들을 이끌며 귀감이 되는 개발자들도 많다는 것을 잘 알고 있다.
많은 개발자들이 이 글을 보고 반발할 수도 있음에게 이 글을 쓰는 이유는 자의든 아니든 경영자를 거짓말로 현혹하는 개발자들이 꽤 있기 때문이다. 경영자는 이러한 거짓말에 현혹되지 않기를 바라는 마음이다.
많은 개발자들이 이 글을 보고 반발할 수도 있음에게 이 글을 쓰는 이유는 자의든 아니든 경영자를 거짓말로 현혹하는 개발자들이 꽤 있기 때문이다. 경영자는 이러한 거짓말에 현혹되지 않기를 바라는 마음이다.
경력이 많은 개발자들에 비해서 경력이 부족한 신참 개발자들은 솔직한 편이다.
신참 개발자들은 지켜야 할 기득권이 별로 없고, 아직 개발에 대한 열정이 남아 있고, 앞으로 개발해야 할 날이 많이 남아 있으므로 올바른 선택을 하려고 노력한다.
고참 개발자들이 하는 대표적인 거짓말들은 다음과 같은 것들이 있다.
- 프로세스 무용론 : 프로세스란 대기업이나 필요한 것이다. 프로세스는 오히려 효율을 떨어뜨린다.
- 신입 무능론 : 요즘 신입은 실력이 부족해서 일 시키기가 어렵다. 개발도 느리고 버그도 많이 만든다.
- 나 밖에 못한다 : 이것은 복잡하고 어려워서 나 아니면 아무도 못한다. 그래서 뭐든 자기가 하려고 한다.
- 문서는 개발을 더 늦게 만든다 : 우리 회사는 개발 일정이 너무 촉박해서 문서를 만들 수 없다.
경영자들은 주로 고참개발자들과 얘기를 하기 때문에 신참 개발자들의 솔직한 얘기를 듣기가 어렵다. 그래서 옛날 왕들처럼 가신들에 둘려 쌓여서 실정을 제대로 모르는 경영자가 된다. 이렇게 실정을 모르는 경영자들은 회사가 어려워져도 개발조직이 문제라는 것을 쉽게 알아차리지 못한다. 결국 망해가는 길 밖에 없다.
여기에 현혹되지 않는 가장 좋은 방법은 능력 있는 CTO를 두는 것이다. 능력과 경험이 있는 CTO에게는 개발자들이 하는 어떠한 거짓말도 통하지 않는다. 심지어는 몇 마디만 딱 들어도 왜 거짓말을 하고 실력이 어느 정도 인지 다 파악이 된다. SW개발이 아닌 다른 분야도 마찬가지 아닌가. SW도 똑같다.
경험과 능력 있는 CTO가 절대적으로 부족한 우리나라에서는 경영자가 신참개발자들과 자주 소통을 하는 것이 중요하다. 그러면 고참개발자들과 다른 얘기를 할 것이다. 그러면 둘 중 하나는 거짓말을 하고 있는 것이다. 물론 고참이 거짓말을 할 가능성이 더 높다.
CTO가 없다면 개발자들의 말만 듣지 말고 주변의 능력있는 CTO급 개발자에게 가끔 조언을 구하는 것이 좋다. 단 이해가 얽히지 않는 사람이어야 한다. 경영자가 절대로 알지 못하는 얘기를 해줄 것이다.
그러한 조언자도 없지만 회사의 여러 개발자들과 골고루 얘기를 해야 한다. 그렇지 않는다면 가신에 둘러싸인 왕 신세가 될 수도 있다.
이 글을 보고 발끈한 개발자들 중에는 본인이 여기에 해당하지 않나 생각해보기 바란다. 그렇지 않다면 회사의 진정한 기술 리더 일 것이다.
개발에는 사람대신 프로세스와 문서화를 주장하는데 해결책은 능력있는 CTO(사람)라면 모순아닌가요?
답글삭제해결책도 회사내 프로세스개선쪽으로 가야할 것 같습니다.
회사내에 제대로된 평가 프로세스라도 있으면 거짓말의 상당부분은 막을 수 있을것 같습니다.
이야기하신 신참하고 이야기한다거나 , 프로젝트가 끝나면 고생한사람 투표로 칭찬하기라던가... 뭐가 되던간에요.
CTO는 경영자버전의 '프로세스는 비효율적이야 사람이 최고야'아닌가요?
글쎄요. 개발자의 거짓말일 수도 있겠지만 대부분의 위와 같은 경우는 진심이더군요. 물론 정말 그렇다는 것이 아니라 그런 경험밖에 못해봤기 때문 아닐까요.
답글삭제안녕하세요. Jake님
답글삭제동감입니다. 진심인 경우가 더 많습니다. 글에도 있는데요...
모르고 얘기하는 경우
알고도 거짓말하는 경우
이 글은 알고도 거짓말을 하는 경우도 많다는 얘기를 하는 겁니다. 물론 그 경계는 매우 모호합니다. 반쯤 알고 반쯤 모르지만 자리보존을 위해 어쩔 수 없이 비합리적인 것을 주장하기도 하고... 아무튼 복잡합니다.
하지만 경영자들인 이런 것에 휘둘리기 쉽다는 얘기입니다. ^^
1. 정직과 성실이 업무에 제일 중요하다는 것이 제 기본적인 생각입니다. 그렇지 않으면, Win/Win이 안 되기 때문이죠. 다만 위(이 때는 교수님이셨습니다.)에서 자꾸 프로토타입 만들라 강요를 받을 때, 그대로 눈에 보이는 프로토 타입 만들어 드리면서, 해 달라는 것은 해 주게 되는데, 코드 내용은 완전히 사기(!)가 되어 버려서 마음속으로 많이 괴로웠던 기억이 있습니다.
답글삭제그 후에 왜 그런 일이 일어났을까 고민을 해 보게 되었는데, 결국은 개발에 대한 이해가 부족하기 때문이라고 결론을 내릴 수 있었습니다.
교수님이 부족한 것이 아니라(조금은 부족했지만, 그러다 보니 지금은 교수님들도 100% 이해하지 못하는 소프트웨어 공학을 어찌 일반인이 100% 이해하리 하는 생각을 하며 삽니다.), 제가 더 부족해서 그런 일이 벌어졌던 것이더군요.
2. 불필요한 것만 가득한 프로세스를 만든다면 분명효율이 떨어지겠지만, 잘 만들면 그만한 게 없고,
신입을 잘못 뽑았다면 분명 개발이 느리고 버그를 많이 만들겠지만, 개발 능력이 있는 사람을 뽑았다면 그런 재산이 없을 테고,
설계를 안 해 보면, 모든 것이 내가 해야 할 것처럼 느껴지지지만, 설계 해 보면 일을 어떻게 나눠야 할 지 보이고,
문서가 코드를 따라가면, 재미없고 지루하고 시간만 끌지만, 코드가 문서를 따라가면 문서 만들기가 제일 재미있다는 것을 알면 좋은데,
몰라서 문제이고, 경험하지 못해서 문제라고 생각합니다.
3. 대학 마지막 학년을 보내면서 졸업 작품을 개발 중인데, 개발 능력이 비교적 부족한 두 명(팀은 총 저까지 4명입니다.)에게 약간 실력 있는 친구 한 명을 붙여, 짝 프로그래밍(Pair Programming)의 변형을 시도해 보려 합니다. 적절한 결정일까요?
J님 안녕하세요.
답글삭제저도 동감입니다. 회사는 프로세스와 문서 위주로 돌아가야 합니다. 하지만 이렇게 변화하기도 전에 이런 일이 일어난다는 뜻입니다.
그래서 그런 방향으로 이끌어 줄 사람이 필요하다는 뜻입니다. 휘둘리지 않을 사람이 있어야 프로세스 개선의 방향으로 갈 수 있습니다.
프로세스가 효율적으로 제대로 정착된 회사에서는 사람의 역할이 더욱 빛나게 됩니다. 프로세스 중간 중간에 사람, 즉 전문가들의 판단이 더욱 중요한 역할을 하게 됩니다.
프로세스가 잘 될 수록 사람이 더욱 중요해집니다. 이는 특정인이 아니고 전문가를 말합니다.
가끔 경영자 중에는 프로세스가 공장 생산라인처럼 완전 기계화 자동화 될 수 있다고 생각하는 사람들이 있는데 이런 프로세스는 SW를 개발하는데 있어서 너무 간 겁니다.
핵심적이고 Compact하고 효율적인 프로세스가 중요합니다.
우리나라 CTO가 됐어야 할 분들은 치킨집에 계시다는 얘기가...
답글삭제(개발하다 막히면 치킨집 사장님에게 물어보라는 우스개 소리도 있죠 -.-)
졸업작품 프로젝트를 어떻게 모듈로 나눠서 개발하느냐 따라 다르겠지만..
답글삭제일반적으로는 본인과 약간 실력있는 친구가 한명씩 맡고 짝 프로그래밍을 하는것이 더 적절하지 않을까 합니다.
고참 개발자들의 거짓말의 원본 원인은
답글삭제기본적으로 극단적으로 짧게 결정되는 프로젝트 기간이 문제라고 봅니다.
물론 이런 식의 프로젝트를 진행하지 않는게 좋겠지만
회사입장에서 영업을 따오기 위해서 진행할 수 밖에 없는 상황은 언제든지 발생하게 마련입니다.
(특히 우리나라에서는 비일비재합니다. )
1. 프로세스는 생각할 겨를 없다.
2. 신입을 가르칠 시간이 없음 , 고참 개발자라긴 하지만 자기가 맡은 코딩에 바쁘다
3. 실제로 본인밖에 못할 경우도 많음 , 소스 리뷰 & 공유가 안되서
4. 문서를 잘 만들어본 경험이 없어서 문서 얘기는 좀 애매하군요.
위와 같은 문제는 결국 프로젝트 몇개를 포기하더라도 시간에 맞는 일정을 세우고 프로세스를 정립해 나가면서 개발을 할 의지가 있느냐의 문제인것 같습니다.
이런 결정을 경영진이 아닌 고참 개발자가 할 수 있을지는 회사마다 분위기나 차이가 있겠지만
대부분은 아무리 고참 개발자라고 하더라도 영업적인 문제가 걸려 있는 상황에서
프로세스 정립, 신입교육, 소스 공유 등의 시간을 요청하기란 우리 나라 현실에서 쉽지가 않습니다.
주의사신님 안녕하세요.
답글삭제정직과 신의는 SW뿐만 아니라 모든 업계의 공통 요구사항 같습니다.
SW는 시스템과 프로세스에 의해서 투명하게 일해야 합니다.
짝프로그래밍이 적절한지는 스스로 판단하셔야겠습니다.
저 같으면 가장 실력이 뛰어난 개발자가 분석, 설계를 주도하고 다른 개발자들도 참여를 하면서 스펙과 아키텍쳐에 대해서 잘 습득한 이후에 각자 실력에 맞게 컴포넌트를 나눈 후 개발을 하겠습니다. 그리고 뛰어난 개발자들이 리뷰를 잘 해주면 좋겠지요.
하지만 전체적으로 분석, 설계 능력이 부족하면 같이 짝프로그래밍을 하는 곳도 좋을 것 같습니다.
청설모님 안녕하세요.
답글삭제이런 얘기 종종 듣습니다. 안타까운 현실이네요.
안녕하세요. 이성열님
답글삭제이미 악순환의 고리에 빠져서 회사나 개발자나 역량이 부족한 경우 딱 이런 현상이 벌어집니다.
정상적인 경우 프로세스와 문서가 프로젝트 일정이 단축되기 때문에 이것을 경험해보려면 변화가 필요합니다.
작은 조직에서는 그럭저럭 해냈어도 조직이 조금만 커져도 악순환의 고리로 점점 들어가게 됩니다.
그렇게 되면 신인교육, 소스공유가 저절도 해결 됩니다.
역설적으로 경영자가 개발을 알면되지
답글삭제왜 항상 개발자에게 경영을 알게하나 싶긴합니다.
물론 개발자 입장에서는 차라리 모르는 경영자가
어디서 주워들은것만 많은 경영자 보다는 속 편하긴 하지만 말이죠
구차니님 안녕하세요.
답글삭제어설프게 개발을 아는 경영자가 더 문제가 되는 경우를 많이 봤습니다. 서로 자신의 일에 전문이 되어야죠.
개발자도 위로 올라갈수록 비즈니스를 잘알아야 하는 것은 당연합니다.
흠 저는 고참 개발자가 한말은 실제로 대부분 거짓말이 아니라 대부분 진실일 확율이 더 높다는 쪽입니다. 다만 고참 개발자는 CEO에게 앞에 수식어를 잘 언급하지 않아서 그렇게 보일뿐입니다. 왜냐면 CEO는 듣기를 원하지 않는 수식어이기 때문이죠. 그 수식어는 다 아시는 걸 껍니다.
답글삭제"그 기간내에"/"그 비용 내에"/"그 계약자(갑)일 경우" /"그 인력으로"/"그 환경에서는"
대부분 CEO는 논의된 내용과 관련된 시간과 비용을 지불할 용의가 없으며
갑의 횡포(요구 변경등)로 부터 개발자를 보호할 의지가 없고
또한 돈과 시간을 추가로 지불하여 더 낳은 인력을 키울 생각이나 정상적인 개발 환경 구축비용을
지불할 의사가 없을 때가 많습니다.
그럼 고참 개발자들은 다만 지쳐서 매번 반복한 앞에 의미 없는 수식어를 뺄 뿐인거죠. 현재 국내
열악한 IT상황에서 CEO도 대부분 어쩔 수 없다는 것을 알 수준이니 까요
안녕하세요. MR.D님
답글삭제대다수의 고참개발자를 대상으로 하는 내용은 아닙니다. 일부가 그렇다는 얘기죠. ^^