본문 바로가기

개발프로세스

개발자에게 필요한 중요한 습관, “중복 없애기” 대기업이나 중견 기업들은 소프트웨어 개발 문제를 해결하기 위해서 복잡한 프로세스를 도입하곤 한다. 이 때 “중복”의 함정에 쉽게 빠진다. 문서를 비롯해서 소스코드까지 동일하거나 비슷한 내용이 여기저기 중복해서 작성되게 된다. 처음에는 이런 중복이 별 문제 없어 보이지만 시간이 흐를수록 생산성은 기하급수적으로 떨어지게 된다. 비효율적임에도 중복이 필요한 곳은 원자력 발전소나 우주선을 개발할 때다. 나사 하나만 바뀌어도 여러 문서를 확인하고 문제가 없는지 완벽하게 교체해야 하기 때문이다. 하지만 대부분의 소프트웨어는 적은 비용으로 빨리 개발하는 것이 목적이다. 그러기 위해서 소프트웨어 개발자가 가져야 할 중요한 습관 중 하나는 “중복 없애기”다. 이는 개발자뿐만 아니라 다른 직종에서도 필요하지만 소프트웨어 .. 더보기
주먹구구식 개발이 통하는 이유 우리나라의 많은 소프트웨어 회사들은 주먹구구식 개발에 대한 환상이 있다.특히, 첫번째 시스템을 주먹구구식으로 개발을 해서 성공했는데 지금은 좀더 체계를 갖췄는데 더 개발이 잘 안된다면 과거 진짜 주먹구구식으로 개발할 때를 그리워하고 그 때로 돌아가고 싶어 한다. 여기 이와 관련된 과거 글이 있다. 2012/07/26 - [소프트웨어이야기] - 옛날에는 개발을 더 잘했는데 주먹구구식으로 개발을 하다가 현재 체계를 갖추려고 노력하고 있다면 아직은 불완전할 뿐더러 반쯤은 주먹구구인 것이다. 그럼 주먹구구식 개발은 어떤 것인지 정의를 내려보자. 크게 5가지로 설명할 수 있다. 첫째, 스펙/설계 없이 개발을 하는 것이다. 또는 기능명세서, 시방서 등의 문서에 기능만 정리하여 개발하는 것이다. 이 방법은 프로젝트 .. 더보기
Template과 Sample의 함정 소프트웨어 개발 프로세스나 방법론에 관심을 가지게 되면 Template과 Sample에 눈이 가게 된다. 소프트웨어를 체계적으로 개발해 보겠다는 생각을 하면 가장 먼저 "문서"를 만들어야 겠다는 생각을 하게 된다.그러면서 자연스럽게 선진 Software 회사에서는 어떻게 문서를 만드는지 관심을 가지게 된다. 그래서 인터넷에서 이런 저런 Template을 찾아서 시도를 해보지만 대부분은 만족스러운 성과를 내지 못한다. 가끔은 세계적인 방법론에서 제시하는 수십가지 복잡한 Template를 가져다가 내용채우기를 시도하다 오히려 더 비효율적으로 변하기도 한다. 우리는 흔히 남이 잘 작성해 놓은 Sample이나 Template를 몇개 보면 그대로 따라할 수 있을 것으로 생각하는 경향이 있다. 이 방법은 코딩에서는.. 더보기
한 SI회사의 프로세스에 대한 오해 필자는 업계의 여러 사람과 얘기할 기회가 많다. 최근에 한 대형 SI회사의 한 PM과 얘기를 한 적이 있는데 프로세스 상의 큰 문제가 있었고, 실제 프로젝트팀에서는 잘못된 프로세스로 인해서 어려움을 겪고 있었다. SI회사의 오랜 바람 중의 하나가 "공정분리"이다. 즉, 분석/설계/구현을 분리해서 프로젝트를 진행하는 것이다."공정분리"가 되지 않은 상태에서는 분석/설계/구현이 뒤엉켜서 개발을 진행한다. "공정분리"는 분석을 잘해서 설계자에게 넘겨주면, 설계자는 설계를 잘해서 개발자에게 넘겨주고 개발자들은 설계서 그대로 코딩만 하면 되도록 하려는 것이다. 최근 해외 프로젝트가 증가하면서 분석/설계/구현을 뒤엉켜서 진행할 경우 코딩하는 개발자까지 해외 파견을 해야 한다. 그래서 공정분리는 점점 필수가 되었다... 더보기
문서는 얼마나 적어야 할지? 소프트웨어 개발 프로젝트에서 문서는 적게 적어야 한다. 다시 말하면 "보통의 회사에서는 문서는 필요한만큼만 가장 적게 적어야 한다." 물론 문서를 많이 적으면 여러 각도에서 상세히 적기 때문에 중복은 많이 발생하지만 잘못된 가능성을 충분히 줄여준다. 예를 들어서 스펙문서를 제대로 하나를 효과적으로 적으면 95%를 커버하는데 이를 99.9%까지 커버하도록 적으려면 10배의 비용을 더들여서 수십개의 문서를 만들어야 한다. 절대 문제가 생기면 안되는 원자력 발전소, 우주선, 생명유지장치는 이렇게 할 수도 있다. 실제로는 이런 경우도 다 그렇게 하는 것은 아니다. 문서를 아무리 많이 적어도 완벽을 기해야 하는 경우는 여러 문서를 적어야 하지만 보통의 SW 개발 프로젝트에서 이러한 경우는 거의 없다. 대부분의 S.. 더보기
획일화된 프로세스의 함정 SW를 개발하는데 있어서 체계화된 프로세스가 필요하다는 것은 당연하다. 대부분의 SW회사가 최소한의 프로세스도 없이 주먹구구식으로 SW를 개발한다. 작은 회사들은 문제가 안되는 것처럼 보이지만 회사가 조금만 커져도 여기저기서 문제가 발생하다. 이런 문제에 시달리다보면 프로세스와 문서화가 이 문제를 해결해 줄것이라고 너무 믿게 된다. 그래서 엄격한 프로세스를 만들고 각 프로세스마다 문서를 꼭 만들게 하고 검사를 하기도 한다. 물론 프로젝트의 종류에 따라서 만드는 필수문서를 다르게 하기도 하지만, 이러한 규정은 개발자들이 요리조리 프로세스를 피해가는데 활용이 되곤 한다. 프로젝트에서 꼭 필요한 문서를 획일적으로 정하는 것은 매우 어렵다. 프로젝트 팀에서 결정하고 이를 존중하는 것이 좋다. 하지만 아직 개발팀.. 더보기
이번 프로젝트 내일 끝나? SW개발 프로젝트가 언제 끝날지 정확하게 모르는 경우가 허다하다. 프로젝트를 진행하고 있는 개발자나 PM도 이 프로젝트가 언제 끝날지 전혀 감이 안잡히는 경우가 많다. 하지만 분명한 것은 이 프로젝트가 예정된 종료일까지는 끝나지 않을 것이라는 것은 아주 잘 알고 있다. 이것을 알고 있다면 일정을 연기해야 하는데 언제로 연기를 해야 하는지 알 수 없으니 일정 연기를 요청하기도 어렵다. 일정을 연기 했으면 그 일정은 지켜야 하는데 연기된 일정도 전혀 근거가 없이 그냥 감으로 생각한 일정이기 때문이다. 이런 일정은 또 연기되기 마련이다. 그래서 Due date이 되어서어 끝나지 않음을 알고 일정 연기를 요청하고 한다. 이렇게 촉박하게 일정이 자주 연기가 되면 영업이나 마케팅 부서에서는 도저히 개발팀의 일정을 .. 더보기
소프트웨어 관료화 "공무원 수는 해야 할 일의 경중이나 업무 유무에 관계없이 일정한 비율로 증가한다", "공무원은 서로를 위하여 서로 일을 만들어 낸다", "유능하지 못한 사람은 공무원이 된다." 이는 그 유명한 파킨슨의 법칙입니다. 소프트웨어를 개발할 때도 이와 같은 함정이 도사리고 있습니다. 주먹구구식으로 소프트웨어를 개발하다가 체계적으로 개발하고 싶은 요구가 생길 때 프로세스팀을 구축하고 개발 프로세스를 정립하다 보면 파킨슨의 법칙에 빠지기 쉽습니다. 프로세스팀의 구성원들은 진짜 소프트웨어 전문가로 구성되는 경우가 드믑니다. 여기서 말하는 소프트웨어 전문가란 코딩만 잘하는 개발자가 아니고, 구축, 설계, 테스트, 형상관리, 버그 추적, 빌드, 릴리즈, 방법론 등 소프트웨어 관련 여러 분야의 지식과 경험을 두루 갖추고.. 더보기
프로세스가 창의성을 저해한다고? 개발 프로세스가 창의성을 저해한다고 싫어하는 개발자, 관리자, 경영자를 종종 만나게 됩니다. 이들이 프로세스를 싫어하는 이유는 과거에 개발 프로세스 도입에 대한 실패의 경험이 있거나 그런 얘기를 종종 전해 듣기 때문입니다. 이렇게 개발 프로세스 도입에 실패하는 이유는 현실성이 없는 이론적인 프로세스를 도입하거나 회사의 역량 수준에 맞지 않는 프로세스를 시도한 경우가 많습니다. 또 인터넷이나 책을 통해서 배우게 된 프로세스를 따라 하다 보면 그 Context를 다 알지 못하고 형태만 비슷하게 흉내 내다가 실패하기도 합니다. 그럼, 그렇다고 프로세스가 없다면 창의성이 샘솟을까요? 개발프로세스가 제대로 갖춰지지 않은 회사는 대부분 각 개발자들의 개인 역량에 따라서 적절히 개발이 이루어지며 개발자들은 역할의 구.. 더보기
소프트웨어 개발의 극과 극 꽤 오래 전에 TV에서 "비교체험 극과 극"이라는 프로그램을 방영한 적이 있습니다. 어떤 아이템을 정해서 가장 비싼 것과 가장 싼 것을 비교하는 프로그램이었는데 꽤 재미있게 본 기억이 납니다. 소프트웨어를 개발하는 현장에서도 극과 극 현상은 드물지 않게 발생합니다. 여러 회사를 분석해보면 완전 주먹구구이거나 또는 너무 무거운 방법론을 도입해서 오히려 부담이 되는 경우가 많습니다. 적당히 중간인 회사를 찾기가 더 어렵습니다. 완전 주먹구구식 가내수공업 형태의 개발방식도 문제가 있지만, 몸집과 역량에 걸맞지 않은 거대한 방법론을 무조건 따라하는 것은 더 문제가 큽니다. 그럴 바에는 차라리 주먹구구가 낫습니다. 그런 주먹구구회사가 문제를 깨닫고 거대 방법론들을 스스로 연구해서 도입을 하면 그 핵심은 모르고 형.. 더보기