본문 바로가기

분류 전체보기

소프트웨어공학은 실전이다. 이 전글에 댓글을 달려다가 좀더 정리를 해야 할 것 같아서 본글로 올린다. 2013/02/27 - [프로젝트/품질관리] - 거의 다 만들었어요. 알파, 베타의 정의를 가지고 이렇게 강하게 주장하는 경우는 처음봐서 약간 당황스러웠다. 독자들은 알아서 판단하겠지만 혼란이 있을 수도 있어서 다시 한번 내 의견을 밝힌다. 나는 20년간 한국, 미국, 대기업, 벤처기업을 다 경험하고 이론과 실전을 다 경험하고 온 국민이 쓰는 소프트웨어 개발에도 다수 참여하고 수많은 소프트웨어 프로젝트를 성공시켰고 여러 소프트웨어의 회사의 역량 개선을 시키고 있고 이런 경험을 책(소프트웨어 개발의 모든 것)으로 쓰고 블로그를 통해서 공유하고 있다. 소프트웨어 공학은 실전이다. 이론적으로 먼저 정립된 것이 아니라 실전적인 발전을 거.. 더보기
거의 다 만들었어요. "거의 다 만들어서 2주후에 개발이 끝나요" 이 말을 이해할 수 있는가? 우리 주변에서 소프트웨어를 개발할 때 흔히 들을 수 있는 말이다.개발자들도 이렇게 얘기하고 관리자나 경영자도 대충 알아듣는다. 하지만 이런 대화는 여러 오해를 양산한다. 영업 담당자는 2주후면 고객에게 소프트웨어를 제공할 수 있는 것으로 착각하기도 하고, 경험이 좀 있는 관리자는 아직 충분히 안정적이지 않거나 테스트가 남아 있다는 것도 알기도 한다. 하지만 정확하게 언제 고객이 쓸 수 있는 제품이 나오는지는 알 수가 없다. 그래서 우리는 좀더 전문적으로 제대로된 용어를 사용해서 커뮤니케이션을 할 필요가 있다. 우선 개발 단계별로 정확한 용어를 사용하는 것이 필요하다. "개발"이라는 말은 너무나 모호하다. 사실 스펙을 쓰는 일부터 유.. 더보기
고쳤으니 테스트 해주세요. 여기 두가지 테스트 방법이 있다. 우리 회사는 어떤 방법을 사용하고 있나 생각해보자. 첫째, 테스트 도중에 버그를 고쳐서 좀더 안정된 버전을 테스트팀에 계속 전달하는 방식이다.테스트 한사이클을 도는데 2주일이 걸린다고 생각해보자. 테스트 기간내내 테스트 팀은 버그를 지속적으로 발견하여 보고를 할 것이다. 개발팀은 동시에 버그를 수정한다. 그리고 다음날 개발팀은 테스트팀이 보고한 버그를 많이 수정한 새버전을 테스트팀에 전달한다. 테스트 팀은 새버전을 가지고 어제 테스트한 시점의 다음 단계부터 또 테스트를 진행한다. 이렇게 테스트 기간 내내 여러번 새버전을 받는다. 두번째 방법은 다음과 같다. 테스트가 2주가 걸리면 2주 동안 테스트 팀은 새버전을 절대로 받지 않고 한 버전을 가지고 테스트를 완전히 종료한다.. 더보기
인해전술이 오히려 프로젝트를 망친다. 일정이 촉박하다고 프로젝트를 빨리 끝내고 싶은 마음에 프로젝트 초기부터 대거 인력을 투입하면 오히려 프로젝트를 망칠 가능성이 더 높아진다. 프로젝트 초기에 분석/설계 단계에는 그렇게 많은 인력이 필요하지 않다. 많은 인력을 분석도 안된 프로젝트에 투입을 하면 놀 수 없는 개발자들이 인터페이스도 정의가 안된 모듈이나 라이브러리를 만들기 시작한다. 이것들 중 대부분은 나중에 다시 만들어야 하고, 이것들을 버리기 아까워서 어떻게든 활용하려고 버티다보면 소프트웨어의 아키텍처가 점점 이상하게 된다. 많은 인력이 투입되는 단계는 구현단계이며 핵심 구현 인력들이 분석/설계 단계에 리뷰어로 참석할 수는 있다. 일정이 촉박하면 분석/설계를 최대한 빨리 끝내고 할일의 범위와 아키텍처를 명확히 한 후에 인력을 투입해야 한다.. 더보기
1:10:100 rule 소프트웨어를 개발하는데 있어서 꼭 알아야 할 규칙이 하나 있다. 바로 "1:10:100 rule"이다. 성숙한 개발문화를 가지고 있는 회사는 전 직원들이 진정으로 그 의미를 알고 있고 실행하고 있다. 하지만 우리나라의 크고 작은 대부분의 소프트웨어 회사 임직원들은 그 의미를 모르거나 알고 있어도 단어의 의미로만 알고 있고 진정으로 깨우치고 있지는 못하다. 소프트웨어를 개발하면서 발생하는 많은 비효율과 문제들이 바로 여기서 출발하는 것이다. 그 1:10:100 rule을 설명한 그래프가 아래에 있다. 요구사항이 스펙을 작성하면서 바뀌면 "1"이라는 비용이 들지만 고객에게 전달된 다음에 바뀌면 "368"배의 비용이 들어간다.요구사항이든 설계든 한단계 뒤에서 고치게 될 경우 2~5배의 비용이 들어가서 시간이 .. 더보기
티끌모아 태산 (개발 시간 절약하기) 성숙된 개발문화를 가지고 있는 회사는 개발 절차가 아주 효율적으로 진행된다. 하지만 그렇지 않은 회사들은 불필요하게 낭비하는 시간이 아주 많다. 10초에서 몇십분까지 자잘한 시간을 낭비해서 이것들을 합치면 어마어마한 시간이 낭비된다. 시간을 꼭 사용해야 할 중요한 곳에는 아끼지 말고 시간을 써야 한다. 하지만 자동화를 하거나 시스템이 커버를 할 수 있는데 사람이 반복적으로 하고 있거나 과도한 안전장치를 갖춘 프로세스로 인해서 비효율적으로 시간을 낭비하는 경우가 정말로 많다. 10초, 1분이라고 별것 아닐 것 같은 시간이 모이면 생산성은 10%, 20%, 50% 떨어지게 된다. 소프트웨어 개발은 워낙 복잡하기 때문에 이렇게 10초, 1분씩 낭비되는 시간을 최대한 제거해 나가면서 개발을 지속적으로 효율적으로.. 더보기
재택근무가 가능한가? 우리 주변에는 비효율적인 개발 환경을 가지고 있는 회사들이 매우 많다. 상상외로 많다. 스스로의 회사는 어떤가 생각해 보자. 나름대로 효율적인 개발문화를 가지려고 많은 노력을 해왔을 것이다. 그래서 과연 우리회사가 제대로 효율적인 개발문화와 환경을 가지고 있는지 궁금할 것이다. 이렇게 비교를 해보자. 당장 우리 회사의 개발자들이 모두 재택근무를 하면 어떻게 될까? 그리고 일주일에 딱 하루만 회사에 나와서 필요한 회의를 한다면... 대부분은 그렇게 해서는 회사가 돌아가지 않을 것이라고 생각할 것이다. 그렇다면 아직 먼 것이다. 소프트웨어 회사가 효율적인 프로세스와 시스템을 갖추고 개발 역량과 성숙한 개발문화를 갖추고 있다면 얼굴보고 해야 할 일이 그렇게 많지가 않다. 일주일에 몇시간이면 충분하다. 일단 회.. 더보기
개발자, 회사의 과거인가 미래인가 개발자는 소프트웨어 회사의 가장 중요한 자산이면서 서로 상반된 2가지 가치를 가지고 있다. 첫 번째는 ‘과거의 가치’이고두 번째는 ‘미래의 가치’이다. 나는 과거의 개발자일까? 미래의 개발자일까? 스스로 판단하기는 어려울 것이다. 동료나 경영진에게 내가 퇴사를 하면 어떻게 될까?라는 질문을 해보면 짐작할 수 있다. 내가 퇴사를 하면 과거에 개발해 놓은 제품들을 어떻게 하지?라는 생각이 가장 먼저 들면 ‘과거의 개발자’에 가깝다. 반대로 내가 퇴사를 하면 과거에 개발해 놓은 제품들은 문제가 없는데 미래에 개발할 제품은 누가 개발하지?라는 생각이 들면 ‘미래의 개발자’라고 볼 수 있다. 회사나 개발자 입장에서 권장되는 개발자 타입은 미래 가치를 많이 지닌 “미래의 개발자”이다. 미래의 개발자가 지금은 가치가.. 더보기
전지전능한 슈퍼 개발자의 역설 필자는 여러 소프트웨어 회사에서 많은 개발자를 만난다. 그러면 보통 회사에 한두명씩 전지전능한 슈퍼 개발자가 있는 것을 보게 된다. 이들은 코딩, 설계, 분석, 테스트, 기획, 고객 전화응대, 고객 지원, 프로젝트 관리, 일반관리, 전략 수립 등 엄청나게 많은 일을 한다. 직책은 대부분 팀장이다. 여러분의 회사에도 이런 개발자가 한두명씩은 있을 것이다. 이들이 여러분의 롤모델인가? “나도 그런 전지전능한 개발자가 되어야지”라는 다짐을 하는가? 아니면 혹시 여러분이 이런 전지전능한 개발자인가? 이렇게 많은 일을 하는 개발자가 One man company에만 있는 것이 아니다. 개발자가 수백명이 넘는 회사에서도 드물지 않게 만날 수 있다. 이런 회사에서는 모든 길이 로마로 통하듯이 모든 기술적인 이슈도 이 .. 더보기
지금은 바빠서 못한다. 지금은 바빠서 못하고 나중에 여유가 생기면 할 것이다. 비단 소프트웨어 개발이 아니더라도 우리는 이런 말을 달고 사는 사람들을 자주 본다. 이런 사람들이 특징은 시간적인 여유가 생겨도 거의 대부분 안하기는 마찬가지라는 것이다. 운동, 공부, 다이어트, 취미생활 등 이런 핑계를 대는 대상은 다양하다. 영어 속담에 이런 말이 있다. "A stitch in time saves nine" 직역하면 "필요할 때 한땀이 아홉을 구한다." 소프트웨어 회사도 마찬가지이다. 한땀이 필요한 결정적인 시기들이 수없이 닥친다. 하지만 그 결정적인 시기를 놓치면 10배, 100배의 비용을 지불한다. 코딩만 보더라도 처음에 제대로 해놓지 않으면 나중에 고치기에는 훨씬 많은 노력이 드는 경우가 많다. 소스코드를 너저분하게 어질러 .. 더보기

티스토리툴바