본문 바로가기

개발문화

Peer Review의 치명적인 유혹 Peer Review는 익히 언급했다시피 가장 중요한 소프트웨어 개발 문화 중에 하나입니다. 그런데, Peer Review를 시행하다보면 경영층에서는 Peer Review를 평가에 이용하고 싶은 생각이 들게 마련입니다. Peer Review 시행자체를 권장하기 위해서 Peer Review 시행 여부를 관리자들의 평가 기준에 포함하는 것은 일리가 있지만, Peer Review의 내용을 평가에 반영하는 것은 자칫 부작용이 더 클 수도 있습니다. 평가에 반영 가능한 Peer Review 결과 Peer Review 실시가 잘 진행되고 있는지 관리자를 평가 얼마나 많은 Peer Review에 참석해서 Peer Review에 기여를 했는지 개발자를 평가 평가에 반영하기 부적절한 Peer Review 결과 Peer .. 더보기
Peer Review를 성공하기 위한 요소들 얼마 전에 "코드리뷰 정착이 어려운 이유"라는 글을 올린 적이 있습니다. 그에 대해서 codeart 님께서 코드리뷰에 대한 일반적인 방법론에 대해서 궁금해 하시더군요. 하지만 이런 방법론은 알면 도움이 되지만, 이것을 안다고 코드리뷰를 성공하는데는 별로 도움이 안됩니다. 하지만 몇가지 성공 요소는 생각해 볼 수 있습니다. 이제부터는 코드리뷰보다는 Peer Review라고 하겠습니다. 사실 코드만 리뷰를 하는 것이 아니고 스펙문서부터 소스코드등 개발 관련된 산출물들을 다 리뷰를 합니다. 그리고 동료들간에 검토를 해 준다는 것이 중요한 요소입니다. 그럼 Peer Review를 성공하기 위해서는 어떻게 해야 하는지 한번 보죠. 첫째, 개발자들끼리 으쌰으쌰 해서는 성공하기 힘듭니다. 회사에서 정책적으로 Peer.. 더보기
코드리뷰 정착이 어려운 이유 코드리뷰는 소프트웨어를 개발하는데 있어서 가장 좋은 문화중의 하나이지만 또한 가장 정착시키기 어려운 것 중의 하나입니다. 코드리뷰를 도입하거나 정착하기 어려운 이유는 다음과 같습니다. 공개적으로 망신을 당하거나 자신을 비판하는 것에 대한 두려움 과거의 부정적인 코드리뷰에 대한 경험 자신이 실력이나 약점이 드러나서 평가가 나빠질 것에 대한 두려움 자신의 코드는 완벽하다는 밑도 끝도 없는 확신 및 자신에 대한 너그러움 코드리뷰가 개발 일정을 지연시킨다는 생각 코드리뷰보다는 테스트가 더 효율적이라는 믿음 남을 비평하거나 비평 받는 것을 싫어하는 문화 실제로 준비 없이 코드 리뷰를 시행하면 위와 같은 모든 일이 일어나서 개발자들의 거부감을 불러 일으키게 됩니다. 주기적으로 시간을 정해놓고 끝장 코드리뷰를 하고 .. 더보기
2009년 새해가 밝았습니다. - 개발자에게도 희망의 한해가 됐으면... 소프트웨어 개발자 여러분 무자년동안 수고 많으셨습니다. 기축년에는 하시는 일 모두 잘 되시기 바랍니다. 제가 처음 소프트웨어 개발일에 뛰어 들었을 때는 개발이란 사람들이 잘 모르는 "신기한" 직업 중에 하나였습니다. 재능이 있는 일부 특수한 사람들이 하는 일이 었지요. 그리고 한참 있으니, 20세기 말쯤 되나요? 최고의 선망의 직업이 되었습니다. 꾀죄죄하고 맨날 밤새면서 미래가 불확실해서 결혼을 하려고 해도 여자집에서 반대가 심했는데, 하루 아침에 최고의 신랑감이 되었었지요. 이것도 잠깐, 이제는 3D 직업 중 하나로 인식이 되어서 대학의 학과 중에서도 점점 인기 없는 학과가 되어가고 있는 것이 우리 S/W 업계의 현실입니다. 모든 것에 밝은 곳이 있으면 어두운 곳이 있지만, 20년도 안되는 시간에 참 .. 더보기
공든 탑을 쌓는 것은 수년, 무너지는 것은 한 순간 소프트웨어 개발 문화가 한 회사에서 제대로 정착하려면 수년이 걸립니다. 3년이 걸리기도 하고 5년이 걸리기도 합니다. 하지만 이것이 무너지는 데는 불과 몇 개월이 걸리지 않습니다. 손바닥에 올려 놓은 모래가 손가락 사이로 줄줄 빠져나가는 것처럼 허물어지는 것은 순식간입니다. 대부분의 이러한 개발 문화 와해는 경영층에서부터 시작됩니다. CTO를 잃거나, 회사의 경영방침이 완전히 단기적인 매출지향으로 바뀌면서 이러한 일들이 일어나곤 합니다. 수년간 키워온 남녀간의 사랑이 한 순간의 실수로 깨져버릴 수 있고, 이를 다시 회복하는 데는 오랜 시간이 걸리듯이 이렇게 와해된 개발 문화는 다시 일으키기가 쉽지 않습니다. 그만큼 소프트웨어 회사에서 경영층의 마인드가 미치는 영향은 큽니다. 개발을 이해하지 못하거나, 이.. 더보기
고객중심의 서비스 마인드가 소프트웨어 산업을 망친다. 부제 : Global mind를 가져라. 우리나라의 Customer Service(A/S) 정신은 정말로 환타스틱합니다. TV가 고장나서 전화하면 수리기사가 바로 달려와서 고쳐주고 갑니다. 핸드폰이 고장나서 서비스센터에 가면 바로 고쳐줍니다. 뭐든지 바로바로 해결이 되죠. 하지만 미국에서는 좀 다릅니다. 노트북이 고장나면 바로 해결이 안됩니다. 서비스센터에 맡겨도 서비스센터는 단순히 포장만해서 수리공장으로 보내는 경우가 대부분이고 오래 걸리면 한달이 걸리기도 하고 재수 좋으면 그보다는 빨리 받아 볼 수 있죠. 미국은 땅덩어리가 워낙 커서 가 도시마다 전문서비스기사를 둘 수도 없습니다. 부른다고 쪼르륵 달려갈 수도 없습니다. 비행기타고 몇시간 날아가서 차 랜트해서 또 한참 가야지만 고객을 만날 수 있거든요.. 더보기
책(소프트웨어개발의 모든것)을 미국에 있는 친구에게 보냈다. 며칠 전에 책(소프트웨어개발의 모든것)을 미국에 있는 친구부부에게 보냈습니다. 오늘 받았다고 연락이 와서 잠시 얘기를 했습니다. 그 친구들은 과거 나와 같이 일을 했었던 친구인데, 버클리(UC Berkeley)에서 Computer Science를 전공을 했고, 십여년간 실리콘 벨리에서 소프트웨어 개발자로 일을 하고 있는 친구입니다. 그 친구가 책을 본 소감은 다음과 같더군요. "책의 내용이 매우 친숙하다. 미국의 개발자들이 당연히 따른 것들이다." 사실 그렇습니다. "소프트웨어개발의 모든것"이라는 책은 소프트웨어 회사라면 당연히 갖춰야할 기초를 다루는 것으로 미국에서는 당연히 되는 것들이 우리나라에서는 너무나도 낯선 것이 많더군요. Peer Review, SCM, BugTrack, Technical Pa.. 더보기
내부 세미나 영회님의 공감이 가는 글(http://younghoe.info/994#footnote_link_994_1)을 보고 의견을 남겨보려고 합니다. 소프트웨어를 개발하는 회사라면 당연히 갖추고 있어야 할 개발 문화는 여러가지가 있지요. Peer Review, Sharing, 규칙 준수 ... 이 중에서 좋은 문화 중의 하나가 일상화된 내부세미나입니다. 유수의 소프트웨어 회사들을 보면 회사에 늘상 세미나 공지가 있습니다. 누구나 세미나를 진행할 수 있고, 대부분 직원들이 관심을 가질 만한 주제들이고, 누구나 부담없이 참여를 합니다. 오다가다 들려서 보기도 하고, 관심이 많으면 준비를 해와서 발표자와 토론도 하기도 하기도 합니다. 누가 시켜서 의무적으로 하는 세미나는 아니지요. 그러한 과정에서 발표자에게도 지식을 .. 더보기
안다는 것과 모른 다는 것 사람들은 어떤 지식에 대해서 아래 3가지의 모습을 보이는 것 같습니다. 1. 모르는 것을 안다고 생각하는 것 2. 아는 것을 안다고 생각하는 것 3. 모르는 것은 모른다고 생각하는 것 여기서 모르는 것을 모른다고 생각할 수 있는 자세야 말로 엔지니어에게 꼭 필요하지만, 의외로 모른 것을 안다고 착각하거나 아주 조금만 아는 것을 전체를 안다고 생각하거나 자신이 아닌 범위가 전체인줄 아는 경우가 많습니다. 자신이 모르는 것이 무엇인지 아는 사람이 가장 많이 아는 사람이라고 생각합니다. 하지만 자신이 모르는 것을 정확하게 알고 인정하는 것은 대단히 어려운 일인것 같습니다. 모르는 것을 안다고 생각하는 사람들은 사고를 많이 치고, 모르는 것을 모른다고 생각하는 사람에게는 지속적인 발전이 있다고 생각합니다. 더보기

티스토리툴바