조엘 스폴스키가 정립한 내용. 

현재 회사의 SW 개발 수준을 측정하는 잣대가 될 수 있다.

물론 팀원으로써의 Test를 수행할 수 있는 역량을 갖추어야 함은 물론이다.

다시 한 번 찾아 읽으며 블로그에 옮긴다.



The Joel Test

  1. Source Control(소스 컨트롤)을 사용하십니까?
  2. 한번에 빌드를 만들어낼 수 있습니까?
  3. daily build(일별 빌드)를 만드십니까?
  4. 버그 데이타베이스를 가지고 있습니까?
  5. 새로운 코드를 작성하기 전에 버그들을 잡습니까?
  6. up-to-date(최신) 스케줄을 가지고 있습니까?
  7. spec(설계서)를 가지고 있습니까?
  8. 프로그래머들이 조용한 작업환경을 가지고 있습니까?
  9. 돈이 허락하는 한도내의 최고의 툴들을 사용하고 있습니까?
  10. 테스터들을 고용하고 있습니까?
  11. 신입사원들은 면접때 코드를 직접 짜는 실기시험을 봅니까?
  12. hallway usability testing(무작위 사용성 테스팅)을 하십니까?


저작자 표시
신고



나는 자기계발서를 거의 보지 않는 편이다. 자기계발서에 적혀 있는 내용이 저자 자신에게는 유용한 방법이었을지는 모르나, 처해 있는 환경이 다른 독자에게는 그다지 유용하지 않은 내용이 많기 때문이다. 자기계발서를 읽으면서 얻을 거라고는 저자의 성공담에 대한 대리만족 밖에 없다. 마치 "내 친구 아무개는 잘 나가" 이런 말을 누구에게 건넬 때 느끼는 감정과 비슷하다. '나는 비록 아니지만 그래도 잘 나가는 친구를 알고 있다. 그러니 날 무시하지 마라.' 아니면 지금 대화를 나누고 있는 상대에게 '너나 나나 그 잘나가는 친구에 비하면 똑같은 처지다.'라고 은연중에 건네는 말. 뭐 이런 식이다. 하지만 정작 그 말을 하고 난 자신이 초라해 지는 자신을 발견하게 된다.


이 책 제목은 다소 도발적이면서도 다른 분야의 사람들도 호기심을 느끼도록 한다. 그래도 주 독자는 이공계인이다. (글을 쓰다 공돌이라는 말은 쓰지 않기로 했다. 이런 책의 소감을 적으면서 재미있자고 스스로를 깎아 내릴 필요는 없다) 전후 대한민국을 일으킨 산업 역군들임에도 불구하고 '이공계 기피 현상'으로 알 수 있듯이 무시당하는 사회 풍토와 실패를 용납하지 않는 국내 IT 벤처 시장의 척박한 환경에서 살아남기 위한 선배들의 조언이 담겨 있다.


저자는 JCE의 창업자로 성공한 1세대 IT 벤처 사업가인 백일승씨와 한양대학교 기계공학과 김재정교수다. 어떻게 보면 둘 다 내 선배라고도 할 수 있다. 한 분은 직접 강의를 들은 적은 없지만 학교 선배이자 속해 있던 과의 교수님이시고, 한 분은 내가 몸담고 있는 분야에서 길을 개척한 선배다. 이런 두 선배의 조언이 담겨 있는 책을 읽는 것은 보통의 자기계발서를 읽는 것과는 다르다. IT분야에도 사람간의 관계가 매우 중요하고 연구도 활발히 이루어 진 지라, 구루들이 쓴 책(프로그래밍 언어 책이 아니다)은 찾아서 즐겨 읽는 편이었으니, 이 책도 인생 선배들에게 한 수 배운다는 자세로 읽었다.


추천사에도 나와 있지만 단순 자기계발서의 수준은 넘어선다. 나처럼 자기계발서를 싫어하는 사람들이 예상했던 그런 수준의 책은 아니라는 뜻이다. 지루하게 충고만 해 대는 것이 아니라 사회를 넓게 보는 눈도 키워 주고, 일반 교양서적에서 볼 만한 이야기나 에피소드도 들어 있다. 백일승씨는 IT 기업의 CSO답게 살벌한 기업환경에서 살아남기 위해 이공계인이 가져야할 소양을 제시해 준다. 업계의 흐름을 읽는 방법, 회사원으로서 능력을 키우고 인맥을 관리하는 방법 등의 내용도 들어 있다. 김재정교수는 공학도로서 대학생에서 부터 박사과정 학생들을 대상으로 조언을 한다. 학점 관리에서 부터 연구실 생활은 어떻게 해야 도움이 될지에 대한 조언은 새겨들을 부분이다.


하지만 조금 아쉬운 부분은 두 분이 업계와 학계에서 성공하신 분이어서 그런지 보통(?) 사람들에 대한 배려가 조금 부족한 부분이 눈에 띈다. 예를 들어 이공계에 필요한 융합형 인간은 전공과 어설픈 인문학을 겸비한 사람이 아니라, IT/BT/NT간 융합형 인간이라고 한다. 하나도 제대로 소화하기 힘든 이공계 전공 여러 개를 익히라는 게 현실과 조금 괴리가 있지 않나 생각한다. 또 아마존의 CEO 제프 베조스의 극단적인 비용 절감 사례와 '사업가의 길'이라는 작자미상의 시구를 삽입해 놓았는데, 이게 너무 인간미가 없다. 왜 재미있게 일하는 방법에 대한 가이드는 없는 것인지?


책에서는 직접 회사명을 언급하지 않았지만 어떤 기업의 문화를 비판하는 내용이 있다. 기업의 존재 이유가 많은 이익을 내서 직원들을 고용하고, 이익을 낸 만큼 세금을 내는 것으로 사회에 기여해야 한다고 하는데, 저자 분에게는 너무 복지만 강조하는 기업문화가 마음에 들지 않았나 보다. 하지만 임직원들의 복지가 최우선이고 그 존재 이유라는 회사도 존재한다는 것을 받아들이지 못하는 점이 아쉽다. 본인에게는 전쟁터 같은 업계에서 힘들게 일군 회사여서 후배들에게 정신을 바짝 차리라는 뜻에서 하는 이야기 일 수는 있겠지만, 비판을 가했던 그 기업은 복지 최선의 기업 운영 방식으로도 꾸준히 성장할 수 있는 사례를 만들었다. 최근에는 입소문과 방송을 타면서 오히려 최고의 인재가 더욱 몰리고 있다고 한다.


이공계 기피 현상으로 시작된 책 본문에는 척박한 환경을 헤쳐 나가기 위한 조언은 많다. 하지만 이런 삐뚤어진 환경에 대한 비판은 그다지 보이지 않는다. 김재정 교수가 이야기 했듯이 대학생이 어려운 전공 공부를 집중해서 할 시간은 부족하다. 그 시간을 쪼개 등록금을 마련하기 위해 아르바이트를 해야 하고 그로 인해 공부할 시간이 줄어 장학금은커녕 중간 성적도 못 내게 되는 악순환이 반복된다고 한다. 그래도 반값 등록금 약속을 지키지 않는 정부에 대한 비판은 없다. 평등하지 않은 출발점에 서서 개인의 탓으로만 돌리기에는 환경이 너무 각박하다. 국내 벤처 기업 환경에서 한 번 실패하면 일어서기 힘들다고 한다. 왜 한국에는 엔젤 투자가가 적은지, 왜 좋은 아이디어를 가진 사람도 용기 있게 자기의 사업을 꾸려 보려 하지 않고 대기업의 직원으로 만족하고 사는 지에 대한 고민이 보이지 않는다. 모든 것을 개인의 탓으로 돌리는 것은 너무 신자유주의적인 발상이 아닌가 싶다.


그래도 희망은 있다. 최근에 STEM (Science, Technology, Engineering, and Mathematics. 한국에서는 Art를 포함하여 STEAM이라고도 함) 교육이 주목받고 있다고 한다. 미국에서는 STEM분야 전공자에게 영주권을 취득할 수 있는 기회의 폭을 넓혀 주고, 소득 상위 직업군도 이공계 분야가 늘어나고 있는 추세라고 한다. 중국의 경우 책에서도 강조했듯이 주요 지도자들이 이공계 출신이어서 주요 정책에 이공계인에게 유리한 정책을 많이 도입할 수 있고, 이게 국가 경쟁력이 되고 있다. 이공계를 선택하려고 고민하고 있는 독자들이 있다면 일독하기를 권한다. 그리고 이공계가 아닌 분들이라면 어떻게 해야 대한민국이 더 발전하고 좋은 사회가 될지, 이공계 분야는 어떻게 꾸려가야 할지 함께 고민해 보는 시간이 되었으면 한다.


------------------------------

2014-04-27 수정.

특정 기업을 언급했던 부분에서 기업 이름을 삭제했습니다. 출판사에서 연락이 왔는데 저자가 언급한 기업이 제가 생각했던 그 회사가 아니라고 하는군요. 저자께서 언급하셨다던 그 기업주의 강연을 찾아서 보고, 수정할 내용이 있으면 다시 수정하겠습니다.

저작자 표시 비영리 변경 금지
신고


  회사 생활을 하다 보면 평소 일하던 방식이 급격히 변경될 때가 있다. 조직 개편으로 인해 다른 조직으로 발령이 나거나 새로운 업무 방식이 도입될 때가 그렇다. 이때 역시 변화에 대처하는 방법에 썼던 '회피자형', '얼리어답터형', '추종자형'이 나타난다. 자신에게 변화가 찾아올 때 '얼리어답터'는 아니더라도 '회피자'는 되지 말자고 했었다.


빠른 적응력이 요구된다.


  하지만 이렇게 급격한 변화가 일어날 때에는 이야기가 다르다. 적응할지 말지 재는 행동이 오히려 독이 된다. 이 업무방식은 내게 안 맞아. 도대체 위에서는 왜 이런 결정을 내리는 거지? 보나 마나 6개월 정도 있으면 또 바뀔 거야. 이런 부정적인 생각을 빨리 버리는 게 좋다. 일은 이미 벌어졌다. 자신이 그 변화를 원래대로 바꿀 수 없는 위치에 있다면 빨리 적응하는 편이 낫다. 변화에 적응하지 않으면 도태된다. 인류가 30만년동안 진화해 오면서 살아남기 위해 환경에 적응했던 유전자가 꿈틀대게 해야 한다. 길을 가는 데 갑자기 튀어나온 사자로부터 목숨을 건지기 위해서는 발바닥에 땀나게 뛰거나 가지고 있는 무기를 냅다 휘둘러야 한다.



이 업무가 내게 맞는 것일까?


  내 아이의 미래를 위해 적성에 맞는 일을 찾아주려고 한다고 하자. 처음에는 아이의 적성이 어떤지 재능은 있는 지 알 수가 없다. 이를 찾기 위해서는 아이에게  많은 경험을 하도록 해야 한다. 하지만 그 아이가 적어도 어떤 일에 재능이 있고 재미있어 하는 지를 판단을 하기 위해서는 시간이 필요하다. 몇 달 동안은 그 일에 최선을 다 해 보라고 격려하고 필요하면 푸시를 가해야 한다고 본다. 모든 일이 그렇겠지만 기초가 항상 중요하고, 기초는 지루하고 반복적인 작업이 많다. 축구를 잘 하기 위해서는 체력을 기르고 달리기와 민첩성을 기르는 훈련을 반복해야 하고, 피아노를 잘 치기 위해서는 기본 음계의 건반을 두드리는 일을 반복해야 한다. 이 일이 익숙해지면 이를 당연하게 여기고 운동 전 스트레칭을 하는 것처럼 받아들이게 된다. 이런 자기 검증화 과정이 필요하다. 적성에 맞고 재능까지 겸비되었는 지를 아는 방법은 의외로 단순하다. 일단 최선을 다해 부딫혀 보는 이다. 그 후의 평가가 좋지 않다면 깨끗하게 포기하고 다른 것을 찾아보는 게 낫다.


  새로운 업무도 마찬가지다. 처음에는 익숙하지 않아 업무 진행이 더디다. 다른 방식으로 일하는 것이 자기 몸에 맞지 않는 옷을 입은 것처럼 어색할 지도 모른다. 하지만 그 방법이 자신에게, 자신의 조직에 맞는 방법인지는 먼저 최선을 다해 수행해 보고 평가할 일이다. 이렇게 반박할 수도 있다. 그렇게 실패할 게 뻔한데 뭣 하러 처음부터 시도하나. 시간 낭비일 뿐이다. 맞는 말이다. 그러면 실패할 지 성공할 지는 어떻게 알 수 있나? 직접경험을 할 수는 없으니 책이나 논문 또는 성공한 사례를 통해 간접경험을 얻을 수 있다. 경영진이나 파트 리더는 이런 간접경험을 이미 거쳤을 가능성이 99.99%다. 실패 가능성을 줄이기 위해 당연한 절차다.  물론 팀원의 의견을 무시해서는 안 된다. 다만 팀원이 자신의 견해와 다르다고 리더의 의견을 무시해서는 안 된다고 생각한다. 적어도 최선을 다해 몇 차례 수행해 보고 피드백을 주어서 방향을 수정해 나가는 것이 좋다. 이게 민주적이라고 생각되지 않나? 처음부터 팀원의 의견을 반영해서 결정하면 좋겠지만 조직원의 모든 의견을 수렴하기에는 너무 오랜 시간이 걸린다. 이것이 리더와 정치가 존재하는 이유다. 리더의 의견을 따르고 그 의견을 평가해서 수정, 보완하는 것이 조금씩 좋은 방향으로 갈 수 있는 가장 빠른 길이다.

저작자 표시 비영리 변경 금지
신고


  SW 개발 과정에는 수많은 테스트 절차가 있다. 회사마다 실시하는 종류는 다르겠지만 위키피디아에 기록된 것만 해도 무려 16가지나 된다.[각주:1] 요즘 읽고 있는 책에 테스트에 관한 흥미로운 견해가 있어 본문을 옮겨 본다.


  테스트를 많이 할수록 품질이 좋아진다고 생각하는 사람도 있다. 정말 그랬으면 좋겠지만, 안타깝게도 그렇지가 않다. 테스트하면 결함을 찾는 데 도움이 되긴 하지만 코드 여기저기 숨어있는 결함을 테스트만으로 찾아내는 건 불가능하다. 아무리 열심히 테스트해도 상당수의 결함이 잡히지 않고 남아있을 것이고, 여기서부터 불편한 진실이 나타나기 시작한다. 테스트에서 기존 결함 중 특정 비율(예를 들어 65%)만큼을 찾아낸다고 해 보자. 그러면 테스트를 통해 찾아낸 결함이 많아질수록 찾아내지 못한 결함도 많아지리라고 예상할 수 있다. 테스트에서 결함이 많이 발견되면 실제 출시된 제품에 있는 결함 개수가 줄어드는 게 아니라 늘어나는 것이다. 직관적으로 보면 말이 안된다는 생각이 들 수도 있는데, 테스트 과정이 버그를 다 잡아내기 위한 절차라기보다는 품질을 측정하기 위한 통계적인 방법이라고 보면 이해가 될 것이다. 이런 이유 때문에 소프트웨어 공학 분야에서는 기능 테스트와 시스템 테스트를 각각 "기능 검증 테스트", "시스템 검증 테스트"라고 부른다. 소프트웨어 공학을 과학적으로 공부해 온 사람은 테스트 작업이 문제를 고치기 위한 작업이라기보다는 검증 절차에 가까운 것으로 봐야 한다는 인식이 자리 잡았기 때문이다. (..중략..) 안타깝게도 아직은 아무도 버그가 없는 소프트웨어를 개발하는 방법을 발견하지 못했다. 테스트를 통해 모든 버그를 찾을 수는 없기에, 테스트만을 통해서 최고 품질의 코드를 만들어내는 것은 불가능하다. 많은 회사에서 그런 시도를 했지만 모두 실패로 돌아가고 말았다. 역사적으로 보면, 코드 품질을 개선하고 버그를 없애는 데 있어서 가장 좋은 방법은 코드 검토다. 최고 품질의 코드를 개발하기 위해서는 설계 및 명세서, 코드 검토, 형식적인 인라인 (런타임) 확인 테스트, 측정 코드(Instrumented Code), 철저한 테스트 중 어느 하나도 소홀히 해서는 안 된다.

- 프로그래머로 사는 법, 한빛미디어, p324


  결론은 버그는 다음 그림과 같이 개발 후반부로 늘어나는 수정하는 비용이 늘어나기 때문에 초반에 잡으라는 말이다.



  위 그림은 SW를 업으로 삼는 사람이라면 책이나 교육을 통해 몇 번은 보았을 것이다.[각주:2] 물론 폭포수 모델을 가정하고 있기는 하지만 개발 방법론이 무엇이 됐든 프로젝트 후반부로 갈수록 버그 수정 비용이 늘어난다는 점이다. 하지만 현실에서는 잘 지켜지지 않는다. 당장 눈앞에 구현해야 할 기능과 지난번에 만들어 둔 버그들이 쌓여 있기 때문이다. 시간이 항상 부족하기 때문에 본인이 작성한 코드를 대충 테스트하고 검증 부서에 넘겨 버리기 일쑤다. 악순환이다. 더 문제는 이게 반복되면 '기능 완료'의 정의가 기본기능만 돌아가지만 벌레가 스멀스멀 기어 다니는 상태로 받아들여진다는 것이다.


  많은 코드를 작성하고 버그는 있지만 기능은 완료시킨 것이 성과의 지표가 되는 문화도 이런 엉성한 SW가 만들어 지는 데에 한 몫 한다. 버그 트래킹 시스템에 올라와 있는 버그를 많이 수정한 사람이 일을 잘한다고 여기기도 한다. 물론 그 사람이 수정한 이슈가 다른 사람이 만든 버그를 잡았다면 훌륭한 일이다. 그런데 자기가 버그를 왕창 만들어 낸 장본인이라면? 그 사람은 일을 잘 하는 사람인가, 그렇지 않은 사람인가? 관리자는 지표로 나타나는 분석 내용을 좋아하기 마련이지만 버그 수정 개수만을 가지고 성과를 판단하는 오류는 범하지 말아야 한다.


  습관은 반복적인 행동으로 이루어진다. 나쁜 습관도 마찬가지다. 아직 나쁜 습관에 물들지 않았다면 좋은 습관을 가지도록 노력하자. 코드리뷰를 귀찮게 여기지 말고 개발과정의 필수과정으로 인정하는 문화가 정립돼야 한다. 테스트 코드의 커버리지가 70%밖에 되지 않는다면 나머지 30% 부분은 직접 실행해 보아야 할 것 이다. 당신이 관리자라면 기능 완료의 정의를 돌아가는 SW가 아니라 완성도 높은 SW로 받아들여야 한다. 


  테스트는 검증부서만의 몫이 아니다. 검증부서는 현재 SW의 상태를 "검증"한다는 것을 다시 한 번 명심하자.



  1. https://en.wikipedia.org/wiki/Software_testing [본문으로]
  2. 그린 코드 구현 전략 - 정적 프로그램 분석, http://www.imaso.co.kr/?doc=bbs/gnuboard.php&bo_table=article&wr_id=33321 [본문으로]
저작자 표시 비영리 동일 조건 변경 허락
신고


  서점에는 한 쪽 벽면을 당당하게 차지하고 있는, 일명 '자기 계발서'라고 불리는 책들이 있다. 언젠가 부터 이런 류의 "성공하기 방정식 A to Z"식 서적들이 넘쳐나기 시작했다. 나도 몇 권 사서 보고 따라해 보았다. 학창 시절에 "성공하는 사람들의 7가지 습관(김영사)"을 읽고 원문 제목 대로 effective한 사람이 되려고 한 적도 있었다. 그나마 사회생활 하면서 도움이 되었던 자기 계발서는 이 책 뿐이고, 그 외에 책들은 제목조차 기억에 남아 있지도 않다. 


  이런 자기 계발서들의 문제는 독자의 대상을 일반 대중에 맞추다 보니, 성공하기 위한 디테일한 실천법이 오히려 모든 사람들에게 끼워 맞춰지지 않는다는 것이다. 사람들은 너무나 다양한 삶의 스펙트럼을 가지고 있는데 한 권의 책으로 모든 사람을 만족시키려 하다 보니 어쩔 수 없이 내용을 형이상학적으로 기술하거나 저자가 성공 모델로 삼고 있는 인물에 초점을 맞추고 있다. 또한 이른바 '성공'이라는 것의 정의를 부자가 되거나 조직의 높은 자리에 올라가는 것 만으로 내리게 되는 오류도 범한다. 이를 맹목적으로 따라하다 보면 반드시 실패하기 마련인데, 이런 경험을 하면 오히려 나는 실패한 인간이다라는 자괴감만 가지게 되고 나에게 맞는 방법은 따로 있을 것이다라는 착각에 또 다른 자기계발서를 찾아 헤매게 된다.[각주:1]


  하지만 당신이 몸담고 있는 분야, 바로 SW개발분야의 고수 프로그래머들이 들려주는 이야기는 어떨까? 다행히 SW분야에도 이런 자기계발서류가 많이 있다. 이런 책을 찾아 읽어야 한다. SW엔지니어를 위한 자기계발서는 형이상학적이지 않다. 읽으면 읽을 수록 공감이 가고 회사생활에, 경력을 쌓는데, 코딩 실력을 늘리는 데에 도움이 된다. 요즘 '프로그래머로 사는 법'을 읽고 있다. 마치 두권의 책을 한권으로 압축해 놓은 듯 내용이 풍부하다. 중간중간 섞여 있는 구루들의 인터뷰도 책을 읽는 맛을 더한다. 내가 이 블로그를 쓰고자 하는 내용이 다 담겨있다.(그래도 나는 루키 개발자를 위한 조언에 초점이 있으니 계속 하련다.)



   그리고 한 권 더 추천할 책이 있다. '실용주의 프로그래머(앤드류 헌트, 데이비드 토머스 저, 김창준 역, 인사이트)'인데 너무나 유명해서 따로 설명은 필요없을 것 같고 혹시 아직 읽지 않은 분이 있다면 서점으로 얼른 달려 가라. 난 이 책을 신입사원 때 사서 3번 정독했다. 처음 읽을 땐 내공이 부족해 무슨 소리인지 이해가 안되는 내용이 많았는데, 나중에 읽으니 공감이 더 가는 경험을 했던 책이다.



  기왕 책소개를 하는 김에 프로그래머를 위한 교양서적이라고 할 수 있는 책들을 몇권 더 소개한다.

  • More Joel on Software - 조엘 스폴스키 저, 지앤선
  • Hard Code(나잘난 박사의 IT 정글 서바이벌 가이드) - 에릭 브레히너 저, 마이크로소프트 프레스
  • "실용주의 사고와 학습(Pragmatic Thinking & Learning - Refactor Your Wetware)" - 앤디헌트 / 박영록 번역 / 김창준 감수, 위키북스
  • 김창준 씨가 추천하는 책 목록 - http://agile.egloos.com/5181803


.

  1. 딴지라디오, 그것은 알기 싫다 8회 "안아픈데 청춘이다"에서 인용. http://radio.ddanzi.com/index.php?mid=broadcast&category=1176709&page=2&document_srl=582993 [본문으로]
저작자 표시 비영리 변경 금지
신고

'SW 개발자를 위한 멘토링' 카테고리의 다른 글

새로운 업무를 대하는 자세  (0) 2013.06.28
테스트와 품질  (0) 2013.06.06
프로그래머를 위한 자기 계발서  (0) 2013.05.22
무엇을 배워야 할까  (0) 2013.05.12
청소하기  (0) 2013.03.30
개발자(SW 엔지니어)라는 직업의 매력  (2) 2013.03.26


  신입사원이 처음 팀에 투입되면 방치되는 경우가 종종 있다. 맡게 되는 업무라고 해 봐야 팀내 자산조사와 같이 그다지 가치를 느끼지 못하는 일이 대부분이다. 당장 급한 업무를 신입에게 맡기기에는 못 미더울 뿐더러 업무를 일일이 가르치면서 진행하기에는 시간이 너무 오래 걸린다. 하지만 당신은 이 시기를 허비해 버리면 안된다. 당신은 앞으로 회사생활을 하면서 이 시기만큼 마음대로 공부할 시간을 얻지 못할 수도 있다. 평소 항상 좋은 책들을 찾아 읽어라. 무슨 책을 읽어야 할 지 모른다면 선배에게 자문을 구해보라. 필요한 지식을 얻기 위해 노력하는 후배를 위해 기꺼이 시간을 내 줄 것이다. 사내에 멘토링 제도가 있다면 멘토를 적극 이용해라. 멘토는 멘티의 실력을 키워서 한 명의 어엿한 팀원으로 키워내야 할 의무가 있다.


  어떤 책을 찾아 읽어야 하는 지, 어떤 분야의 지식을 쌓아야 하는 지도 중요하다. 내가 처음 입사했을 때 동기들과 책을 제본해서 본 적이 있다. 한 녀석이 휴대폰 개발자의 필독서라고 하면서 침을 튀기며 추천했던 "GMS Switching, Services and Protocols" 라는 책이다. 그 친구가 속해 있던 파트의 업무가 퀄컴과 같은 칩셋 업체가 제공한 SW가 제대로 동작하지 않을 경우 휴대폰 망의 규약을 잘 알고 있어야 문제를 해결할 수 있는 것들이었기 때문에 이 책은 필독서였다. 우리 팀 선배에게 이책을 공부해야 되냐고 물어봤는데 "뭐 공부해 두면 좋긴 하지"라는 어정쩡한 대답이 돌아왔다. 휴대폰을 만드는 제조사에 몸담고 있으니 모르는 것보다 알아두면 도움은 된다는 그런 뜻이었다. 우리 팀은 애플리케이션을 만드는 팀이었기 때문에 사실 망이 어떻게 구성되는 지 프로토콜은 어떻게 이루어져 있는 지 몰라도 업무에 크게 지장은 없었다. 나는 사실 팀에 바로 기여할 기술을 익히기에도 바쁜 신입시절에 언젠가 도움이 될 지 안 될지도 모르는 책을 파고 있었던 것이다.


  나의 요즘 주 업무는 휴대폰에 기본 탑재되는 안드로이드 앱 개발과 관련된 일이다. 문서를 검토하고 회의를 통해 의견조율을 한 후 프로그래밍으로 요구사항을 구현한다. 이후는 검증 부서에서 등록한 이슈들을 해결한다. 이외에도 자잘한 일들이 매우 많이 있지만 개발자들의 업무를 단순히 압축하면 이정도가 된다. 주 업무가 안드로이드 앱 개발이지만 순수 앱 개발 자체에 대한 서적은 한 권도 가지고 있지 않고, 처음부터 끝까지 독파한 책도 없다. Framework을 분석한 책 한 권만 가지고 있다. 개발에 필요한 대부분의 지식들은 Android Developer's 사이트에 잘 정리되어 있고, 시중에 나와 있는 많은 책들이 이 사이트의 문서를 번역한 수준이기 때문이다. 또한 구글링을 조금만 해 보면 개발 팁이 넘쳐난다.


  그렇다고 이런 책을 읽을 필요가 없다는 뜻이 아니다. 나는 Android가 이제 시장에 나와서 사람들에게 퍼지기 시작할 즈음 - 당시 버전이 Cupcake이었다 - 1주일짜리 사내 교육을 통해 앱 개발에 필요한 기초 지식을 쌓았고, 팀내 세미나를 통해 좀 더 세부적인 사항들을 공부했다. 그 후에 책을 한 권 사려고 서점에서 몇권 뒤져 봤는데 그다지 볼 만한 책이 없었다. 지금은 그런 기초적인 책이 필요하지 않게 된 수준이 되어 보지 않을 뿐이다.

  아무리 웹상에 정보가 넘쳐나도 책의 가치는 떨어지지 않는다. 책을 한 권 쓰기 위해 저자는 그 분야에 대해 독자보다 앞서 공부하고 개념을 이해하기 위해 자료를 뒤지고 쉬운 표현으로 전달하려고 고민한다. 위에서 말한 개발자 사이트를 단순 번역한 수준의 책에서도 한글로 매끄럽게 표현하는 데에 노력을 기울일 것이다. 예전에는 컴퓨터 관련 일선에서 뛰고 있는 전문가가 아닌 전문 번역가가 번역한 전공 서적이 많이 있었다고 하지만 요즘은 그렇지 않다. 해당 분야에 충분한 경험이 있고 저자의 뜻을 완벽히 이해한 후 독자에게 충실히 전달하려고 하는 좋은 책들이 많이 있다.


  주위에 도움 줄 사람이 없다면 다음 내용이 도움이 될 것이다.


1. 기본기

  SW 개발자들 중에는 학교에서 컴퓨터 관련학과를 전공으로 하지 않은 사람이 많이 있다. 당신이 만약 이런 부류라면 더 늦기 전에 컴퓨터 공학과의 커리큘럼을 찾아보고 관련 전공서적을 구해 업무와 관련 있는 것부터 읽어야 한다. 운영체제, 자료구조와 알고리즘, 객체지향 설계, 데이터베이스 뿐 아니라 개발 언어도 2가지 이상은 자유자재로 구사할 수 있도록 해야 한다.


2. 유행하는 최신 기술

  SW분야에도 유행이 있다. 개발 방법론에도 유행이 있고, 사용하는 언어나 프레임워크 같은 시스템에도 유행이 있다. 지금은 휴대폰에서 사용되는 대부분의 OS가 Android나 iOS이고 그 위에서 돌아가는 애플리케이션은 Java나 Objective-C로 작성된다. 하지만 앞으로 몇년 후에는 시장의 판도가 어떻게 변할 지 아무도 모른다. HTML5가 시장을 장악하여 사용자가 쓰는 대부분의 프로그램이 웹 애플리케이션이 될 수도 있다. 최신 기술에 뒤쳐지지 않게 1년에 하나 정도 새로운 언어를 익혀 두도록 하자. 마이크로 소프트웨어와 같은 잡지를 구독한다면 최근 유행하는 기술이 무엇인지 감을 잡는 데에 도움이 된다.


3. 업무 프로세스와 사내 시스템

  SW개발은 수많은 파트의 사람들과 함께 쌓는 탑과 같다. 각자 맡은 역할이 다르고 전문 분야가 다르다. 서로의 의견을 조율하기 위한 커뮤니케이션 능력은 매우 중요하다. 서로의 의견을 쉽게 소통하고 공유, 관리하기 위해 만든 시스템도 많이 있다. 가장 간단하게는 이메일이나 게시판이 그 역할을 한다. 위키도 있고, 사내에서 직접 만든 시스템도 있을 것이다. 이를 능숙하게 사용할 수 있도록 익히도록 해야 한다. 빠르고 정확한 커뮤니케이션은 업무효율을 배가시켜 주지만, 약속하지 않은 일방통행식 소통은 문제만 낳을 뿐이다. 

  또한 업무에 관련 파트가 늘어나면 정치가 끼어 들고 입장 차이가 생기기도 한다. 이게 맞는 방향인 것 같은 데 왜 일을 어렵게 만드는 지 이해가 되지 않을 때도 허다하다. 이를 매끄럽게 진행하기 위해 사내에는 업무 프로세스라는 게 존재한다. 이는 게임의 룰이다. 서로 지키고 따를 때 일이 원할하게 돌아간다. 불필요한 프로세스라고 생각된다고 해서 무시하지 마라. 당신의 안일한 생각으로 인해 프로세스를 따르는 많은 사람들에게 피해를 끼칠 수도 있다. 마음에 들지 않는 프로세스는 정식 루트를 통해 개선하도록 해라.


4. 개발 문화

  회사마다 독특한 기업문화가 있지만 업계를 관통하는 문화도 존재한다. 이른바 개발 방법론이라고 하는 것인데 최근에는 애자일이 인기를 얻고 있다. 하지만 이를 만병통치약인 것처럼 맹신하면 안된다. 조금씩 시도해 보고 팀에 맞는 것을 골라 사용하도록 해야 한다. 당신의 업무는 훌륭한 소프트웨어를 만드는 것이지 프로세스를 완벽히 지키고, 완벽한 문서를 만드는 게 아니다.


5. 개발자 모임

  업계 동향을 넓게 바라 볼 필요가 있다. 사내에만 갇혀 지내는 것은 경력을 쌓는 데에 도움이 되지 않는다. 웹상에는 많은 개발자 사이트와 동호회가 있다. 맘에 드는 것을 하나 골라 적극적으로 활동하는 것도 좋다. 최근에는 정부에서 Open Source SW에 많은 관심을 가지고 있으니 committer로 참여하는 것도 실력도 쌓고 인맥도 늘리는 좋은 방법이라고 생각한다.


  세부적인 책과 좋은 자료들을 추천해 주고 싶지만 너무 내 관심사에 국한되는 것 같아 제외했다. 공부할 자료를 직접 찾아서 정리하는 시간을 가지는 것만으로도 좋은 공부하고 생각하니 시간내서 나만의 커리큘럼을 정리해 보자.

저작자 표시 비영리 동일 조건 변경 허락
신고


  신입사원일 때 한 선배에게 빌드할 때 Warning 메시지가 많이 뜨는데 고쳐야 되지 않냐고 물은 적이 있다. 돌아온 대답은 그럼 네가 한 번 고쳐봐라는 말이었다. 문맥상으로는 본인은 다른 일도 많고 동작하는 데에 별 문제도 없으니 시간이 많은 신입 너가 한 번 고쳐봐란 뜻이었다. 그런데 그는 과연 컴파일러가 친절히 시간을 들여가며 화면에 뱉어 준 경고를 무시할 정도로 바빴는지, 과연 그 경고 메시지들은 무시할 정도로 사소했는 지는 지금까지도 의문이다.

  당신이 훌륭한 SW엔지니어가 되고 싶다면 "청소하는 습관"을 몸에 익혀라. 여기서 말하는 청소는 단순히 책상 위를 깨끗이 정돈하고 먼지를 닦아내라는 뜻이 아니다. 실력 있는 개발자도 책상 위가 지저분한 사람들이 많다. 어제 야근 중에 먹고 반쯤 남겨놓은 커피는 1회용 종이컵에 그대로 담겨 있고 테스트 장비들은 배배 꼬여 있는 전선과 함께 여기저기 널브러져 있다. 구석에는 먼지가 뭉쳐서 굴러다니는데 당사자는 걸레질은 언제 했는지 기억도 하질 못한다. 사실 책상의 청결도와 업무능력 간의 상관관계는 크지 않다. 위에서 언급한 엉망인 책상의 소유자가 업무에는 뛰어는 역량을 발휘하는 것을 많이 보았다. 그렇다고 책상 위를 일부러 지저분하게 하란 소리가 아니다. 마치 책상 위가 어지러운 게 일하는 것처럼 보인다고 여기는 사람들이 있는데 절대 멋있어 보이지 않는다. 집중력만 흐트러뜨릴 뿐이다. 그리고 주위 사람에게 자신의 역량을 보여주기 전에 선입견만 심어 준다. "저 녀석은 자기 책상처럼 평소 업무처리도 깔끔하지 않을 거야."

  주변을 깨끗이 정리한다고 모두 개발의 고수는 아니지만, 고수들은 모두 주위는 지저분하더라도 [각주:1]코드베이스는 깔끔하게 유지한다. 혼자서 진행하는 프로젝트라면, 아니 혼자서 진행하는 프로젝트라도 다음과 같은 짓은 하지 마라. 너무 당연한 내용을 이야기 하는 게 남우세스러울 정도다. 하지만 당연한 것을 당연하다는 듯이 실천하지 않는 사람이 많으니 이제 개발자로서 새 출발하는 당신은 마음에 깊이 새기고 실천해라. 상대방에 대한 '배려'가 조금이라도 있다면 지켜질 것들이다.

- 들여쓰기를 들쑥날쑥하게 해서 가독성을 떨어뜨리지 마라.
- 선언만 해 두고 쓰지 않는 변수, import(또는 include)가 있다면 바로 지워라.
- 나중에 사용할 지도 모른다고 넣어둔 테스트 코드는 당신의 노트에만 기록해라. 코드베이스는 메모장이 아니다.
- 마찬가지로 주석으로 막혀 있는 사용하지도 않는 코드 블록 역시 즉시 삭제해라.
- 사내 코딩 표준안을 지켜라. 지키기 어려우면 Editor의 formatter기능을 설정해서 편집할 때 자동으로 맞춰지게 하라.
- 중복코드는 만들지 마라. 중복코드를 만나면 그 자리에서 고쳐라.
- 코드는 1번 쓰고 100번 읽는다는 것을 명심해라. 지저분한 코드는 다시 읽을 때 방해만 될 뿐이다.

  가끔 위에서 언급한 지저분한 코드를 코드베이스에 머지하는 몰상식한 개발다들과 함께 일할 때가 있다. 코딩을 하면서 위의 것들을 지키지 않는 것은 마치 바둑의 기본도 배우지 않고 묘수풀이를 하는 것과 다르지 않다. 선과 선이 만나는 교차점에 착수를 해야지 돌 위에 돌을 놓는 격이다. 걸음마를 배우기 전에 육상 선수를 흉내 내는 사람이다. 기본 박자도 배우기 전에 스틱 돌리기만 연습하는 초보 드러머와 같다.

  지금 당장 사내에 정해진 Coding Rule(또는 Coding convention)이 존재하는 지 알아보라. 만약 있다면 자신의 코딩 스타일을 거기에 맞게 바꿔야 한다. 준비된 문서가 없다면 일반적으로 업계에서 통용되는 것을 찾아 익히도록 해라.[각주:2] 이 기회에 팀원들과 함께 만들고 공유하는 것도 좋다. 

  코드베이스를 더럽히지 않는 것도 중요하지만 만약 누군가 똥을 싸 놓았다면[각주:3] 보는 즉시 치워라. 한 개의 깨진 유리창이 건물 전체를 망가뜨린다는 것을 항상 기억해라.
  오랜 기간 수리하지 않고 방치된 창문 하나가 거주자들에게 버려진 느낌을 스며들게 한다. 당국자들이 그 건물에 별 관심이 없다는 느낌말이다. 그래서 다른 창문이 하나 더 깨진다. 사람들은 이제 어지르기 시작한다. 낙서(Graffiti)가 등장한다. 심각한 구조적 손상이 시작된다. 꽤 짧은 시간 안에 소유주가 그걸 고치려는 의지를 넘어설 정도로 건물이 손상되고, 결국 버려진 느낌은 현실이 되어 버린다. 
  '깨진 창문 이론'은 뉴욕과 다른 주요 도시 경찰들에게, 큰일을 막기 위해 조그만 것들을 엄중 단속해야겠다는 영감을 불어넣어 줬다. 정말 그렇게 된다. 깨진 창문, 낙서, 기타 작은 위반 행위를 잘 단속했더니 중범죄가 줄었다. 
  '깨진 창문'(나쁜 설계, 잘못된 결정, 혹은 형편없는 코드)을 고치지 않은 채로 내버려 두지 마라. 발견하자마자 바로 고쳐라. 적절히 고칠 시간이 충분치 않다면 판자로 덮는 것만이라도 하라. 불쾌한 코드를 주석처리 하거나, '아직 구현되지 않았음(Not Implemented)'이라는 메시지를 표시하거나, 가짜(dummy)데이터로 대치해 놓거나 하라. 더 이상의 손상을 예방하기 위해 어떤 조치든 취하고 현 상황을 잘 관리하고 있다는 것을 보여줘라
  깨끗하고 잘 기능하는 시스템들이 일단 창문이 깨지지 시작하면 급속도로 악화되는 것을 많이 보아 왔다. 소프트웨어의 부패에는 다른 요인들도 있지만 방치는 다른 어떤 요인보다도 부패를 더 가속시킨다.

- 실용주의 프로그래머, 앤드류 헌트, 데이비드 토머스, 인사이트, 35쪽

  도요타가 급성장했을 때 그 생산방식과 경영철학에 대한 연구가 활발히 이루어졌고 이를 SW에 접목시킨 사례[각주:4]도 있었다. 도요타의 5S 정신 중 "청소(Seiso)"는 자동차 업계에만 통용되는 게 아니다.


  1. 공용으로 관리하는 SW 소스코드. 매일 작성한 코드를 코드베이스에 머지해서 공유한다. (참조) http://en.wikipedia.org/wiki/Codebase [본문으로]
  2. 예를 들어 Java 클래스 이름은 대문자로 시작하고, 메소드 이름은 소문자로 시작하지만 단어마다 대문자로 붙여서 지어야 한다. [본문으로]
  3. 다른 사람이 만든 버그를 수정해야 하거나, 안해도 될 일을 해야 할 때 "똥을 치운다"라고 한다. [본문으로]
  4. 린 소프트웨어 개발의 적용. 메리 & 톰 포펜딕. 위키북스 [본문으로]
저작자 표시 비영리 변경 금지
신고


  흔히 '개발자'라고 하는 [각주:1]SW엔지니어가 직업으로서 어느 정도 매력이 있는 지 생각해 보자. 사람들이 생각하는 좋은 직업이 갖추어야 할 조건을 나열하면 다음과 같은 것들이 있다.

1. 고액의 연봉
2. 전문 지식이 필요함 (진입장벽이 높음)
3. 근무시간이 규칙적이거나 자기 마음대로 조절이 가능함
4. 업무 진행을 주관적으로 할 수 있음
5. 적은 스트레스
6. (무언가 더 나은 세상을 만들기 위해 노력한다는) 주위의 인정

  개발자라는 직업이 위에서 열거한 것들에 몇 가지나 만족할 지 생각해 보면 2번외에 없는 것 같다. 그나마 2번 역시 닷컴 버블을 거치면서 직업훈련원과 학원에서 대량 양산된 인력들로 인해 장벽이 많이 낮아진 상태다. 개발자는 과연 좋은 직업일까. 어떤 아기의 돌잔치에서 돌잡이 쟁반 위의 마우스를 그 아버지가 집어 던졌다는 웃지 못 할 이야기를 들은 적이 있다. 개발자였던 아버지는 자기 자식도 같은 길로 들어서기를 바라지 않았던 것이다. 
  개발자는 항상 시간이 부족하고 과도한 업무에 시달린다. 개발자의 시급이 맥도널드 알바생보다 못하다는 자조 섞인 이야기도 한다. 물론 과장해서 표현한 것이지만 들이는 노력 대비 받는 대가가 적다는 것을 빗대서 하는 말이다. 또 개발자는 끊임없이 공부해야 한다. 신기술은 하루가 멀다하고 쏟아져 나오고, 시대에 뒤쳐지지 않으려면 어제 배웠던 것들은 박스 속으로 던져 버리고 꾸준히 새 책을 사서 읽고 익혀야 한다. 지금 산적해 있는 문제를 풀고 새 제품을 만들기도 바쁜데 주위는 잔소리꾼들뿐이다.

(출처: Google 이미지)

  나는 위에서 이야기 했던 아이의 아버지가 자기 직업을 나쁜 직업이라고 여겼으리라고는 생각하지 않는다. 개발자라는 직업에는 이 분야에 발을 들여놓게 하고 쉽게 떠나지 못하게 만드는 매력이 있다. 밤을 새가며 재현도 잘 되지 않는 이슈를 해결했을 때, 그저 한 마리 벌레를 잡았을 뿐이지만 왠지 스스로가 자랑스럽게 뿌듯하게 느껴진다. 하지만 이것만으로는 만족할 수 없다.
  개발자라는 직업이 좋은 점은 다음 두 가지가 있다. 첫째 위에서도 언급했듯이 끊임없이 공부를 해야 한다. 단점으로 이야기 했던 것이 오히려 매력이 된다. 연차와 실력은 정비례하지 않는다. 개발자들의 특성 중 하나가 무언가 새로운 것을 계속 배우고 도전하고 싶어 한다는 점인데 지식 노동자로서 일신우일신 하는 자신의 모습을 보며 만족감을 느낀다. 거꾸로 이야기해서 당신이 만약 발전 없는 하루하루를 보낸다고 느낀다면 분명히 불행한 회사생활을 하고 있다고 확신한다.
  다음으로 좋은 점은 무엇을 '창조'한다는 점이다. 물론 그 아이디어가 당신의 아이디어가 아닐 수 있다. 상품기획 부서의 요청에 의해 또는 시나리오를 쓰는 UX개발부서에 의해 만들어 진 기능일 수도 있다. 하지만 결국 그 아이디어를 검토하고 실제 구현해서 사용자가 실물로써 만질 수 있도록 하는 것은 개발자의 몫이다. 그 목표를 이루기 위해 기존에 없는 해법을 찾아내는 것도, SW의 성능을 향상시키는 것도 개발자 외 그 누구도 하지 못한다. 음악, 미술, 문학과 같은 예술 분야에만 '창조성'이 필요한 것은 아니다. 혁신은 항상 기존 형식을 파괴했던 창조적 작업에서 만들어 진다. SW 개발이라는 분야가 [각주:2]70년이 채 안 되는 역사를 거쳐 오면서 어느 정도 외형적 틀은 갖추어 졌다. 하지만 창조성이 결여된 SW개발은 기존 방법을 답습하는 것에 지나지 않는다.
  SW 엔지니어는 그저 그런 직업이 아니다. 돈을 많이 벌기를 원한다면 다른 직업을 찾아보는 게 낫다. 물론 멋진 아이디어를 구체화해서 돈방석에 앉을 기회는 얼마든지 열려있다. 우리나라에서는 한 번 실패하면 재기하기 어렵다는 점이 있기는 하지만 주위 인맥을 쌓고 국가 지원 프로그램을 잘 이용하면 도전해 볼 만한 가치도 있다. 공무원처럼 안정된 노후를 보장하지는 않지만 자기만족감은 무엇보다 큰 직업군이라고 생각한다.
  치열한 개발자의 세계의 문을 연 당신을 환영한다. 함께 한 번 즐겨보자.

이미지 출처: http://sangminpark.wordpress.com/2011/09/27/너드의-코드/


  1. 이 글에서는 개발자라는 용어와 SW엔지니어라는 용어를 동일한 뜻으로 혼용한다. [본문으로]
  2. 1946년 18,000여 개의 진공관과 1,500개의 계전기로 이루어진 ENIAC에서 배선반에 일일이 배선하던 것을 SW개발의 시초로 본다면 아직 채 70년이 되지도 않았다. http://ko.wikipedia.org/wiki/컴퓨터의_역사 [본문으로]
저작자 표시 비영리 변경 금지
신고

  먼저 내 소개부터 해야겠다. 
  나는 우리나라 사람이라면 누구나 아는 모 대기업의 휴대폰 사업부에서 근무하고 있다. 입사 전에는 학부에서 기계공학을 전공했고 관련 업계에서 병역 특례로 군복무를 대신했다. 학사 병역특례가 대게 그렇듯 (물론 그렇지 않은 좋은 업체도 많은 것으로 안다) 열악한 근무환경에서 일을 하다 보니, 공부할 때에는 그나마 재미있었던 전공이 앞으로 내가 먹고 살아야 할 업(業)으로 삼기에 적합한 것인가 하는 의문이 들었다. 3년 정도야 군대에서 고생하는 셈치고 참고 견딜 수 있었지만 평생을 이 업계에서 몸담을 자신이 없었다. 그래서 전공을 멀티미디어 공학으로 바꾸고 대학원으로 진학했다. 그 후 지금까지 IT업계에서 그것도 최전선이라고 할 수 있는 개발자의 삶을 살고 있다. 
  IT 기술은 미쳐 따라가기 힘들 정도로 빨리 변한다. 기술 변화 속도가 빠른 만큼  익혀야 할 지식은 쌓여가고 갈고 닦아야 할 기술들도 늘어난다. 끊임없이 공부하지 않으면 금세 뒤쳐지게 된다. 내가 몸담고 있는 휴대폰 업계 역시 최근 10여년간 눈부신 발전을 이루었고 그 가운데에서 많은 것들을 겪었다. 말 그대로 산전수전 다 겪었다.
  군대 다녀온 남자들이 군대 이야기를 시도 때도 없이 화제로 올리는 이유는 그만큼 군대에서 고생했고 인생에서 힘든 시기를 보냈기 때문이다. 아무리 후방의 '땡보직'에서 복무를 마쳤다 해도 군대생활은 힘들기 매한가지다. 어느 IT 업계든 힘들지 않은 곳이 없으랴만, 휴대폰 개발자로의 삶은 어디 못지 않게 고되다. 그 힘든 삶을 지속하게 해 준 것들에 대해 감사를 느낀다. 그리고 그 것들을 글로 남겨서 공유해야 겠다는 마음이 생겼다. 
  가끔 3개월을 못 채우고 퇴사하는 사람들을 본다. 그 사람들의 끈기가 부족하다고 생각하지 않는다. R&D, 흔히 말하는 '개발'이라는 업무가 적성에 맞지 않았던 것이다. 오히려 이를 일찍 깨우치고 다른 일을 찾아 떠난 이들이 더 현명하다. 그렇지 않다면 꿋꿋이 견디고 깨지고 부딪칠 각오를 하라.
  이제 휴대폰 제조 회사의 R&D 부서에서 8년간 쌓은 경험을 여러분께 공유하려 한다. 물론 나보다 더 훌륭하고 똑똑한 분들이 많을 것이다. 학부 때부터 컴퓨터 공학을 전공하고 체계적인 교육을 받으며 내공을 쌓은 고수들은 차고 넘친다. 하지만 앞으로 쓰여질 내 글이 이제 막 개발자로서의 사회생활을 시작했거나 준비하고 있는 후배들에게 조그마한 길잡이가 되었으면 한다.

저작자 표시 비영리 변경 금지
신고


  얼마 전에 공무원이라는 영화를 봤다.일상에 변화가 없다는 게 가장 큰 장점이라고 생각하는 7급 공무원이 그 주인공이다. 하지만 공무원이라고 업무에서 가정에서 그리고 자신의 인생에서 변화가 생기지 않을까? 회사 업무를 하다 보면 주위에 모든 것이 변한다. 조직개편이 되서 몸담고 있던 조직이 이동되기도 한다. 신입사원이 들어오고, 주위에 누가 퇴사했더라 하는 소식이 들려온다. 조직개편 되서 조직책임자가 바뀌면 무언가 이전에 있던 프로세스가 사라지고 새로운 프로세스가 생기기도 한다. 그런데 이게 그분이 처음에 의도했던 데로 항상 좋은 방향으로만 흐르지 않는 게 문제이긴 하다. 이건 다음 기회에 다시 이야기 하기로 하고 오늘 주제로 다시 돌아가자.


  소프트웨어 개발 업무 중에도 역시 많은 것이 변경된다.


-. 고객 요구사항

  일명 시나리오. 시도 때도 없이 바뀐다. 일정한 주기나 근거가 있으면 그나마 받아들이는데 스트레스는 안 받겠다. 저 위에 누군가가 하라고 하는 것들이 너무나도 많다. 제품 책임자가 권한이 그나마 좀 있어서 어느 정도 쓰잘데기 없는 기능을 잘라주기라도 하면 다행이다. 시나리오가 바뀌는 게 나쁘다는 게 아니다. 소프트웨어가 진화하는 과정에서 아주 자연스러운 일이다. 문제는 원칙없이 즉흥적으로 바뀔 때가 많다는 거다.


-. 소스 코드

  시나리오가 바뀌는 데 소스코드가 안 바뀔리가. 버그를 수정할 때도, 리팩토링을 할 때도 소스는 바뀐다. 몇 달 동안 변하지 않는 코드가 있다면 시간을 내서 다시 한 번 들여다 보시길 바란다. 사용자가 쳐다 보지도 않는 기능을 구현해 놓아서 바뀔 필요가 없었던 것은 아닌지.


-. 개발 프로세스

  이전 프로젝트에서 사용하던 프로세스는 이젠 구식이다. 누군가는 (대부분은 회사에서 제품 출시에 영향력이 있는 부서. Q부서가 힘을 가지면 개발 부서는 피곤하다.)  이전 프로세스를 개선하여 다른 부서에 요청합니다. 개발 프로세스가 바뀌면 시스템도 변경된다. 새로운 업무 시스템 사용법도 익혀야 한다.


-. 개발 환경

  예전에 프로젝트에 새로운 솔루션을 처음 적용해서 안정화 시키느라 그룹사람들 100여명이 죽도록 개고생한 적이 있다. 그 때 모 그룹장님께서 이번 프로젝트만 출시되면 좀 낫지 않겠냐고 아주 설득력 있게 연구원들을 독려했던 적이 있다. 정확하게는 아니지만 당시 K군의 MSN 대화명이 기억에 남아있다. "희망은 가장 강력한 독이다." 

  개고생한 프로젝트가 끝난 뒤의 프로젝트도 만만치 않았다. 남들 보다 좋은 제품을 시장에 내 놓으려면 이전 것을 우려먹어서야 되겠나? 뭔가 새로운 걸 또 만들어야지. 또 이야기가 잠시 옆으로 샛다.


  어쨌든 개발언어도 바뀌고 컴파일러도 바뀌고, 다운로드 툴도 바뀌고 많은 것들이 바뀐다. 그 때 마다 새로운 언어를 익히고 팁도 배우고 500페이지 넘는 책을 보고 따라하기도 해 보고 한다. 게다가 코드 리뷰 시스템도 새로 익혀야하고, 소스 관리 툴도 ClearCase에서 요즘 대세인 GIT으로 넘어갔으니 이것도 공부해야한다. 새로운 이슈 트래커를 도입했다고 하니 이 놈은 또 어떻게 쓰느 것인 지 알아봐야 한다. 남들 다 쓴다는 WIKI 사용법도 공부해야 된다. 개발자가 순수 개발 외에도 컴퓨터 앞에 오래 앉아 있을 수 밖에 없다.


-. 일정

  경영진 이하 일명 관리자라고 불리는 직급의 계신 분들이 가장 신경쓰는 것. 일정이 안지켜 지는 이유에 대해 간단히 한 마디만 하자면, 개발자의 참여 없이 Deadline을 정한 다음 역산으로 일정을 짜 맞추기 때문다. 개발할 수 있는 만큼만 개발해서 시장에 출시하면 과연 경쟁사를 이길 수 없을까? "집중과 선택" 전략으로 채택된 기능이 Key Feature라면 충분하다. 프린터기가 달린 커피머신을 만드는 과오는 범하지 말아야 한다.


-. 팀원

  팀장의 입장에서는 이게 제일 골치 아플 것 같다. 팀원들 장단점도 파악하고 업무도 어느 정도 돌아가게 만들어 놓았다. 그런데 어느 날 한 녀석이 더 이상 못해먹겠다고 퇴직한다. 그러고 신입이 보충됩니다. 뭘 더 말하겠나. 팀원만 바뀌는 게 아니다. 시나리오 담당이 바뀌어서 기존 소프트웨어가 가지고 있던 특색이 사라지고 다른 쪽으로 변질된다. GUI 담당이 바뀌어서 새로 만든 아이콘이 뭔가 어색하다. 상사가 바뀌어서 업무를 A-Z 설명해 줬더니 이젠 프로젝트가 산으로 가려고 한다. 조금 과장했지만 프로젝트를 진행하다 보면 인원 변경은 비일비재하다.



  개발을 하다 보면 변하지 않는 게 없다는 게 더 맞는 말인 것 같다. 그럼 이런 변화가 생길 때 사람들은 어떻게 대응을 하는가? 크게 다음 3가지 부류로 나눌 수 있다.


1. 회피자형

  변화를 거부한다. "이런 일을 왜 또 벌이나?"하고 투덜거리며 자신에게 익숙해 있던 방식으로 업무를 처리한다. 뭐 당분간은 그렇다고 해서 생산성이 떨어지는 것도 아니다. 변화에는 어느 정도 과도기라는 게 있어서 새로운 방식과 이전 방식이 둘다 통용되기도 하니까.

  문제는 이전에 자신만의 경험에 빗대어 판단을 내린다는 겁니다. "이전에 비슷한 거 해 봤는데, 소용 없어. 다 쓸데 없고 결국 없어 질거야"라는 말을 자신이 자주 한다면 회피자형이라고 할 수 있겠다. 하지만 결국 그도 새로운 방식을 익혀야 한다. 주위에서 다들 변하는 데 자기만 그대로일 수 없다.


2. 얼리어답터형

  변화에 아주 민감하다. 변화에 긍정적인 비판을 해 본다. 좋다는 판단이 들면 주위에 퍼뜨리려고 노력한다. 보통 이런 사람들에 의해 시스템이 개선되어 전파되는 경우가 많다. 그렇다고 해서 얼리어답터가 항상 좋은 것만 채택하는 건 아니다. 나중에 보니 아무도 쓰지 않는, 쓸모 없고 누군가의 KPI만 채워 주는 것들도 있다.  하지만 이런 것들이 쌓이고 쌓여서 발전을 한다고 생각한다.


3. 추종자형

  대부분이 여기에 속할 것이다. 얼리어답터에게 설득당하고 주위에서 좋다는 소리를 들으면 따라서 변화에 몸을 담근다. 스트레스는 가장 적다.



  당신은 이 중에 어느 부류에 속하는가? 적어도 회피자는 되지 말아야 겠다는 생각을 해 본다.

저작자 표시 비영리 동일 조건 변경 허락
신고

티스토리 툴바