개발문화 썸네일형 리스트형 SW 산업의 부실한 계약문화(개발문화 시리즈9) 이번 개발문화 이야기는 '계약 문화'다. 나는 개발자지만 여러 차례 계약의 경험이 있다. 특히 한국, 일본, 미국의 계약 문화를 두루 경험해봤다. 회사 설립 관련된 계약도 해보고 프로젝트 계약도 많이 해봤다. 그러면서 나라별로 계약 문화에 많은 차이가 있음을 알게 되었다. 어찌 보면 계약만의 문제는 아닌 것 같다. 일상의 약속, 구두 계약에서도 비슷한 현상이 벌어진다. 한국에서는 선비정신과 의리문화 영향인지 몰라도 돈에 관해서 직접적으로 말하기를 꺼려하는 경향이 있다. “좋은 게 좋은 것”이라는 말이 있듯 서로 좋은 얘기만 하려고 한다. 계약 조건에 대해서 꼼꼼하게 점검하고 따지면 너무 깐깐하다는 얘기를 듣기도 한다. 하지만 미국의 개발문화는 좀 달랐다. 나도 처음에는 이질감을 많이 느꼈다. 개인적으로 .. 더보기 SW개발, 맥가이버식 전문가가 위험한 이유(개발문화 시리즈8) 이번 개발문화 이야기는 '전문가문화'다. 어떤 개발자가 국내 유수의 소프트웨어 기업에 취업하려고 한다고 가정 해보자. 개발자가 수백명에 달하는 이 회사에 지원을 하면서 본인을 다음과 같이 소개한다고 보자. “저는 빌드 전문가입니다. 빌드 기술 연구와 실무 경험이 5년이나 됩니다.” 그럼 이 개발자는 취업에 성공할 수 있을까? 모든 회사가 상황은 아니지만 이 개발자가 주장하는 “빌드 전문가”라는 것에 대해서 제대로 이해하고 그 가치를 높게 평가할 회사가 그렇게 많지는 않을 것이다. 오히려 이렇게 생각하는 개발자도 있을 수도 있다. “빌드 전문가? 그게 그렇게 어려운 건가? 나는 비주얼스튜디오나 이클립스에서 버튼하나 누르면 그냥 빌드가 다 되는데 전문가가 필요한가? 그냥 프로젝트에 투입할 수 있는 프로그래머.. 더보기 회의 많았던 SW 개발 회사의 비극(개발문화 시리즈7) 이번 개발문화 이야기는 '회의 문화'다. 회의 문화는 IT 분야에만 국한된 얘기가 아니다. 이미 많은 논의가 있었고, 회의 문화가 개선된 회사들도 많다. 그러나 변화가 필요한 회사들도 아직 많다. 회의가 많은 회사는 망한다는 속설도 있는데, 하루종일 회의하느라 정작 일은 퇴근 시간 지나서야 할 수 있다고 하소연하는 고참 개발자나 팀장들을 많이 봤다. 회의를 많이 하는 증상이 있는 회사는 회의 자체의 문제보다 근본적으로 해결해야 할 문제들이 따로 있을 가능성이 높다. 회의를 하는 방식 자체보다는 근본적인 원인에 대해서 얘기를 해보고자 한다. 첫째, 우리나라 회사들은 재택근무가 쉽지 않다. 이것은 여러 문화의 결과이기도 하다. 업무지시를 서로 만나서 해야 하고 얼굴을 봐야만 얘기가 되는 상황이라면 재택근무로.. 더보기 SW개발과 규칙의 두얼굴 (개발문화 시리즈6) 이번 개발문화 이야기는 '규칙 준수 문화'다. 우리 주변에서 규칙을 무시하는 현상을 자주 볼 수 있듯 소프트웨어 개발에 있어서도 규칙을 준수하지 않는 일은 자주 벌어진다. 물론 규칙을 정말 상세히 정하고 모든 사람이 규칙에 따라 소프트웨어를 개발한다고 더 잘되는 것은 아니다. 계속 강조하지만 규칙은 최소한으로 정해야 하고 성숙된 개발문화에 의한 개발이 더 효율적이다. 그래도 규칙은 지켜야 하며 지킬 수 있고 지켰을 때 개발 효율이 최대화 되는 규칙을 만들어야 한다. 그럼 규칙을 무시하는 현상이 자주 벌어지는 이유를 살펴보자. 첫째, 규칙을 지키지 않는 개발자들이 있다. 보통 회사의 최고 개발자들에게서 종종 벌어지는 현상이다. 소수의 개발자들에게 목을 메고 있는 회사들은 그런 개발자들이 어떤 방식으로 개발.. 더보기 서열문화가 SW산업 망친다. (개발문화 시리즈5) 이번 개발문화 이야기는 '서열이 지배하는 조직문화'다. 우리나라는 옛날부터 서열을 매우 중요시 한다. 사람들이 모이면 서로 나이를 비교하고 서열을 정한다. 회사에서도 대리, 과장, 부장이 되려고 열심히 일한다. 직급에 따라 업무가 달라지고 급여도 서열에 비례한다. 물론 많은 변화가 있어 왔지만 뿌리깊게 자리 잡은 서열문화의 뿌리는 여전히 튼튼하다. 소프트웨어 산업에서도 서열 문화는 조직 문화에 많은 영향을 주었고 그로 인해서 많은 문제와 생산성 저하를 불러일으켰다. 소프트웨어 개발자도 직급에 따라 서열화 되며 주로 윗사람이 일을 시키고 아랫사람은 시키는 대로 일하는 형태가 많다. 이러한 수직적인 조직문화는 수평적인 조직 문화에 비하여 소프트웨어 개발에는 적합하지 않다. 자율성과 창의성이 강조되는 소프트웨.. 더보기 SW개발과 빨리빨리 문화의 저주(개발문화 시리즈3) 이번에 다룰 개발문화 이야기는 '빨리빨리 문화'다. 일을 빨리 하자는게 나쁜 건 아니다. 오히려 이런 '빨리빨리 문화' 덕분에 우리나라가 짧은 기간에 성장했을지도 모른다. 더 짧은 시간에 똑 같은 일을 해낼 수 있다는 것은 경쟁력이 있는 것이다. 우리는 그동안 많은 산업분야에서 '빨리빨리 문화'의 혜택을 입었고, 관련 노하우도 많다. 그런데, 이런 '빨리빨리 문화'가 소프트웨어 분야에서는 독이 되는 경우가 많다. 실제로 독이 되는 경우를 많이 보았다. 시제품은 빨리 만드는데 본제품을 완성하는데는 시간이 훨씬 오래 걸리며 품질도 떨어지고 시간이 흐를수록 유지보수가 무척 어려워져서 제품을 포기하는 경우도 흔하다. 상황을 수습하지 못해, 회사의 종말로 이어질 때도 있다. 유독 왜 소프트웨어 분야에서 '빨리빨리.. 더보기 바람직한 스타트업 SW 개발문화의 조건 우리나라 소프트웨어 회사들의 가장 큰 취약점 하나만 꼽으라고 하면 나는 개발문화를 꼽겠다. 문화란 오랫동안 습득된 구성원들의 공통된 행동 양식이기 때문에 개인이 전체의 문화를 짧은 시간에 바꾸기가 매우 어렵다. 특히 조직이 크면 클수록 문화를 바꾸는데 엄청난 시간과 비용이 필요하다. 하지만 개발문화의 개선 없이는 소프트웨어 개발 역량을 얘기하기가 어렵다. 소프트웨어 개발은 너무 복잡하기 때문에 획일화된 프로세스대로 따라 한다고 잘 할 수 없다. 하나 하나는 완벽해 보이지 않는 문화적인 활동들이 모여서 개발을 효과적으로 이끄는 것이다. 효과적인 개발문화의 필요성을 먼저 깨달은 많은 개발자들도 조직 내에서 접목을 시도하다가 쓴맛을 봐온 것이 사실이다. 그만큼 집단을 바꾸는 것은 쉬운 일이 아니다. 조직 문화.. 더보기 이슈관리시스템을 쓰면서 일이 더 많아졌다. 이슈관리시스템을 쓰기 시작하면서 일이 오히려 더 많아졌다고 하소연하는 경우들이 많다. 이슈관리시스템을 쓰지 않다가 또는 전사적으로는 쓰지 않고 소수의 팀내에서만 쓰다가 이슈관리시스템을 전사적으로 제대로 쓰기 시작하면서 일이 더 많아졌다고 하곤 한다. 이것은 오히려 긍정적인 신호이다. 이슈관리시스템을 쓰지 않고는 회사내의 모든 이슈를 다 표면위로 드러낼 수도 없고 관리도 할 수 없다. 일이 많아졌다고 느끼는 것은 절대적인 일이 늘어난 것이 아니고 숨어 있던 이슈들이 모두 공유된 것 뿐이다. 이슈관리시스템이 없다면 잊혀지거나 개인이 알아서 챙기다가 유야무야되는 이슈들이 매우 많다. 이슈관리시스템은 모든 이슈들이 등록이 되고 개인의 의지에 따라서 해결이 되고 안되고가 결정이 되는 것이 아니고 전사적으로 공개적.. 더보기 주먹구구를 더 좋아 하는 이유 이론과 실제는 다르다. 모두들 착하게 살아야 한다는 것을 알지만 많은 사람들이 착하게 살지 않고, 운동을 해야 하는 것을 알지만 대부분의 사람들은 운동을 하지 않는다. 이유는 다 있다. 착하게 살고 꾸준히 운동을 하는 사람들은 꾸준히 하다보니 특별한 목적보다도 그 자체가 좋아하고 자연스러운 행동이 된다. 소프트웨어 회사도 주먹구구식으로 개발하면 안되고 체계적으로 개발해야 한다는 것을 이론적으로는 알아도 그 구성원들은 막상 체계적으로 변화를 하려고 하면 완전히 적응되기 전까지는 크고 작은 거부감과 저항이 있게 된다. 그래서 주먹구구로 회기하려는 힘이 강하게 작용하게 된다. 많은 회사들은 자신의 회사는 주먹구구가 아니라고 생각할 것이다. 물론 Black and White로 구분할 수는 없지만 나의 경험에 의.. 더보기 매일 불난 호떡집 같은 회사 (중요한 일 vs. 시급한 일) 필자가 컨설팅을 진행했던 수많은 회사들 중에서 80% 이상은 불난 호떡집처럼 매일 불끄느라고 정신이 없습니다. 너무 바빠서 새로운 기술을 연구할 시간도 없다고 한다. 프로젝트를 진행할 때도 가장 빠른 방법으로 문서도 작성하지 않고 가장 뛰어난 개발자가 바로 코딩부터 한다고 한다. 고객들은 기다려주지 않기 때문에 요구하자마자 바로 며칠 안에 제품에 기능을 반영해야 한다고 한다. 제품에 버그가 발견되면 하루 이틀 안에 버그를 수정해줘야 한다. 그렇지 않으면 고객들이 엄청나게 컴플레인을 한다. 사소한 버그 수정도 빨리 해야 하기 때문에 신입 개발자들에게는 시킬 수가 없다. 고참 개발자가 2시간이면 고칠 것을 신입 개발자를 시키면 2일이 걸릴 뿐더러 고참 개발자가 신입 개발자에게 일을 시키고 검토해주는데 2시간.. 더보기 이전 1 2 3 다음
