sosa0sa.com

자신의 S/W 블럭이 죽은 후

• A 블럭이 엉뚱한 메시지를 잘못 줬어요
• A 블럭이 보낸 메시지에서 이 필드에 이런 값이 있으면 안되요.

약속된 인터페이스대로 동작하지 않은 상대방 블럭의 책임도 있지만 그렇다도 예상하지 않은 값을 받았다고 죽어버리는 블럭을 작성한 개발자도 50%의 책임이 있다. 항상 외부와의 인터페이스에는 message length check, value range check를 수행해서 죽지 않도록 해야 한다.

“The practice of an Agile developer”를 보면 Architect가 설계만 하면 안된다고 했다. 전적으로 동감하는 말이다. 회사에서 일을 하다면 “현실”을 알지 못하고 이론만 아는 설계팀과 충돌할 때가 많다.

책에서 보면, 다른 회사의 feature를 보면 그리고 혼자서 생각을 하면 A라는 기능은 이 제품에 꼭 필요한 기능이다. 그래서 말한다. “A라는 기능이 없는 제품은 본 적이 없다고”

그럴 때 S/W 개발자는 말한다. “와서 만들어 놓고 가라” 어찌보면 개발자 입장에서 “못한다”라고 말하는 것은 무척 자존심 상하는 일이다. 왜냐하면 S/W 개발자가 못한다고 하는 것은 다른 이유가 아니라 실력/능력이 부족해서 못한다고 생각하는 사람이 대부분이기 때문이다.

하지만 S/W 개발자에게 자원들이 무한정 주어진 것이 아니다. CPU power 그리고 메모리등. 한정된 자원을 주고 게다가 한정된 개발 시간을 주면서 모든 일을 하라고 하니 어떤 일을 할 수 있는 것도 있고, 또 어떤 일을 할 수 없게 되는 것이다.

그리고 Agile에서는 S/W에서 요구사항의 변경은 피할 수 없는 것이므로 어쩔 수 없는 그 상황에도 잘 대처할 수 있도록 하라고 한다. 하나의 water fall 구조가 아니라 잦은 iteration을 이용하라는. 아쉽지만 현실이 그렇지 못할때가 많다. 여러 사람이 함께 개발을 하다 보면 블럭간의 인터페이스를 함께 바꿔야 하는데 이때는 아쉬지만 기술적인 이슈보다는 정치적인 이슈가 개입될때가 많다 -_- (Agile 책을 보면 큰 프로젝트일 수록 water fall이 실패한다고 했는데 정말로 Agile 방법론을 사용할 수가 있는 걸까 늘 궁금하다. 이해 당사자가 무척 많을 텐데)

그래서 대개 설계인력은 S/W나 H/W 개발 경력이 최소한 얼마정도는 있는 사람으로 구성하기 나름이다(물론 늘 그런 것은 아니다. 박사인력인 경우 대부분 S/W 개발보다는 바로 설계 업무를 배정하는 경우가 대부분이다. 누군가 말한 것처럼 박사과정이 하나의 토픽에 대해 전문성을 갖는 것보다 문제를 풀어가는 방법을 배우는 과정을 배운 것이 더 의미가 있다고 하는 것처럼 대부분 실무적인 S/W 개발 경험이 없더라도 잘 하는 경우가 많다(혹은 석/박사과정에서 산학 협력등의 경험을 한 경우도 많고)

다만 그렇지 못한 고급인력(박사로 한정하는 것은 아니다)들이 다른 사람을 힘들게 하는 것이다. 머리는 똑똑하고 나름대로 정보 습득 능력은 높기때문에 보고 들은 것은 많은 데 그것을 자기가 가진(자기가 속한 회사가 만드는) 제품군에 무조건적으로 적용하려다 보니 실무자인 개발자와 충돌하는 경우가 많다.

갑자기 이런 글을 적는 이유는 아침에(토요일이니 새벽이군) 블로그 뉴스를 보다 보니 이런 내용이 있어서이다.

그는 알만한 이들만 아는 회사인 ‘마이크로소프트’라는 회사에 근무하고 있고, 하는 일은 마이크로소프트 개발자 사업부 총괄책임자(전무)다. 소프트웨어를 만들 때 사용하는 개발 툴인 비주얼 스튜디오(Visual Studio) 제품과 닷넷(.Net) 프레임워크 기술 개발을 책임지고 있다. 그가 이끄는 팀은 총 620명. 그는 개발자 사업부 총괄 책임자지만 여전히 매일 서너시간은 코딩을 한다. 그가 하는 코딩은 이미 제품화 된 것보다는 대부분 새로운 아이디어를 시도하는 프로토타입으로 그치는 경우가 많지만 끊임없이 새로운 시도를 추구하고 있다.

와우. 정말 말로만 듣던 코딩하는(프로토타입이라는데 당연히 그래야 하는 것 아닌가? 620명을 총괄하는 살마이 문제점 해결하겠다고 코드 리뷰하는 것도 우스운 일이니-우리 회사엔 그런 사람이 있다고 하는데) Architect(심지어는 project manager) 아닌가. 난 주변에서 코딩한다는 architect를 본적도, 있다는 소문을 들은 적도 없다. 대부분의 사람들이 모두 엑셀이나 파워포인트만 다루고 있다.

너무나도 다른 사람, 회사 분위기가 놀라울 따름이다.

그 외에도 기억하고 싶은 글은

그는 국내 개발자들과의 대화에서 ‘초기 평개발자로서 새로운 시도가 쉽지 않았지 않았느냐’는 질문에 “마이크로소프트에서는 ‘Code wins’라는 말이 있습니다. 개발자라면 직급이 아니라 코드를 통해 해결책을 내놓는 것으로 인정받는다는 것입니다“라고 밝혔다. 그는 또 “ASP.NET도 처음에 나 혼자 프로토타입을 개발하고 나서 그 이후 3-4명의 작은 팀이 생겼습니다. 서버를 통해 코드를 관리하는 것이 효율적이라는 것을 스스로 믿고 강하게 주변 사람들을 설득하는 것이 중요했습니다”라고 조언을 아끼지 않았다. “목표한 바는 결과로 반드시 만들어 내는 것도 중요합니다. 개발자들은 코드로 보상을 받는 것이라고 생각합니다. ‘개발 작업’을 하는 것이 아닌 ‘좋은 제품’을 만들어 내는 것이 중요합니다”라고 관리자로서의 개발자 역할도 강조했다. 스콧 구슬리는 “블로깅은 4년여 전에 시작했는데, 약 2년 전부터 심층적 기술문서들을 올리면서 많은 개발자들이 조회하고 참고하는 정보소스가 됐습니다. 한 달에 보통 10-15회 문서를 올립니다. 이 과정을 통해 우리 기술팀이 개발한 기능들을 더 잘 이해하게 되기도 합니다”라고 밝혔다 스콧 구슬리 전무는 “항상 고객을 염두에 두는 개발자가 되십시오”라는 말로 이번 방한을 마무리 했다

그의 블로그 주소는 http://weblogs.asp.net/Scottgu 이다

꼬랑지) 당연한 이야기지만 설계인력이 늘 현실을 무시하고 과하게 요구하고, 늘 S/W 개발자가 맞는 말만 하는 것은 아니다. 또 많은 경우에는 S/W 개발자의 능력 부족이나 게으름, 혹은 잘못된 태도때문에 타당한 요구사항을 수용하지 못하겠다고 거부한다. 결국 답은 서로가 서로를 좀 더 이해(알기도 하고, 배려/인정도 하고) 서로 지식을 공유하고 많은 대화를 가져야 한다. 누구나 아는 답이 아닐까? 누구나가 다 하는 것이 아니기때문에 문제지만.