본문 바로가기

분류 전체보기

Waterfall과 Agile 주변에서 Waterfall이 좋다 Agile이 좋다 등의 논쟁을 가끔 보게 됩니다. 하지만 Waterfall을 비교 대상으로 삼기에는 적당하지 못한 것 같습니다. 즉, 너무 극과 극의 비교입니다. 이미 Waterfall 방식은 너무 느리고 비용이 많이 들어서 대부분의 소프트웨어 프로제트에서는 사용하지 않습니다. 하지만 Waterfall 방식은 소프트웨어 개발의 기본 원리를 이해하는데 가장 중요한 모델이고 다른 모든 개발 모델들은 Waterfall에서 파생해 나온 것들이기 때문에 Waterfall 방식을 이해하는 것은 소프트웨어 개발 기본 원리를 이해하는 것처럼 중요합니다. 순수한 Waterfall 모델은 다음 단계로 진행하기 위해 전 단계가 완벽하게 끝나야 하고 모든 결과가 문서로 작성되어야 합니다. 폭.. 더보기
달콤한 유혹에 중독되어 있는 고객들 (SW 저가수주) 5throck님의 "프로젝트 저가수주의 폐해"라는 글을 읽고 의견을 적어봅니다. 그리고 "이 문제를 해결할 좋은 방법은 정말 존재하지 않는 것일까요? "라는 질문에 대한 나름 답변을 해볼까 합니다. 우리나라 소프트웨어 산업구조는 정말 기형적이라고 하지 않을 수 없습니다. 대형 SI업체가 시장을 지배하고 있고, 성공한 팩키지, 솔루션 회사는 거의 찾아보기 힘들고 과거에 성공했던 회사들도 그리 오래가지 못하고 쓰러져왔습니다. 그 이유야 여러가지가 있겠지만, 그 많은 이유 중에서 대형 SI업체가 지배하고 있는 시장구조에 대해서 의견을 적어보고자 합니다. 외국에서 유래를 찾아보기 힘든 대형 SI업체 구조는 우리나라 고객들에 입맛에는 맞는 것 같습니다. 대충의 요구사항만 가지고 있으면 대형SI업체에서 모든 것을 .. 더보기
Second System Syndrome (뭐 이따위로 만들었어?) 프레드 브룩스가 얘기한 "Second System Syndrome"은 주변에서 흔하게 접할 수 있습니다. 현재의 개발자들이 과거에 선배들이 만들어 놓은 First System의 문제 요소를 지적하며 Second System을 만들어야 한다고 주장합니다. 이러한 현상은 정말로 지겹게 봐왔습니다. 즉, 선배들이 만든 시스템을 "뭐 이따위로 만들었어? "하고 생각하면서 Second System을 만들어야 하는 온갖 이유를 대면서 경영자를 현혹시킵니다. 이렇게 주장하는 개발자들은 어리고 경험도 부족하기 때문에 First System이 얼마나 어려운 문제를 다루고 있었는지 제대로 이해하지 못합니다. 또 자신들이 문제로 지적하고 있는 요소들 외에 얼마나 많은 복잡한 이슈들을 First System에서 해결하고 있는.. 더보기
깨끗한 개발 환경, 빌드 환경, 테스트 환경 개발, 빌드, 테스트 환경을 별도로 두지 않고 그냥 개발자 PC에서 수행하는 경우들이 많습니다. 이렇게 되면 자칫 빌드 시 개발 환경에 영향을 받아서 의도하지 않는 문제가 발생할 수 있습니다. 따라서 개발, 빌드, 테스트 환경은 각각 어떻게 구성을 해야 할지 미리 정하고, 그에 따라야 합니다. 일반적인 경우 빌드는 깨끗한 환경에서 항상 원하는 빌드를 만들어 낼 수 있도록 하며, 테스트는 스펙에서 요구하는 테스트 요구사항에 따라서 각각의 테스트 환경을 구축해야 합니다. 여러 플랫폼을 지원하는 경우 테스트 환경 구축이 아주 복잡하고 비용이 많이 들기도 합니다. 테스트 환경에 대한 이해는 많이들 하고 있다고 가정하고, 빌드 환경에 대해서 조금 더 얘기를 해보고자 합니다. 빌드가 무엇인지 먼저 얘기를 해보죠. .. 더보기
소프트웨어 개발 단계에서 가장 중요하다고 생각하는 것은? 그동안 약 2달에 걸쳐서 제 블로그에서 Poll을 실시하여 이와 같은 결과가 나왔습니다. 이런데 이상하게 제가 현장에서 만나는 여러사람들의 의견과 다른 결과가 나왔습니다. 그래서 그 이유를 2가지 정도로 추측해보고 있습니다. 첫째, 블로그 방문자들(주로 블로거)은 비 방문자보다 소프트웨어 공학에 더 많은 지식과 경험을 을 가지고 있다. 둘째, 실제 자신의 경험에 의한 생각보다는 정답이라고 생각하는 것에 투표를 하였다. 물론 첫째 이유겠죠 ^^ 아래 목록을 보면 각 항목의 득표 비율이 나오는데, 제 생각과 크게 다르지 않습니다. 하지만, 유난히 유지보수에 대해서 작게 나온 것은 대부분의 방문자들이 유지보수가 그렇게 중요하지 않은 프로젝트들을 수행하고 있는 것이 아닌가 추측해 봅니다. 다음 투표로는 SCM .. 더보기
Daily Build를 하십니까? Daily Build는 많은 혜택을 줍니다. 소프트웨어가 항상 빌드 가능한 상태를 유지할 수 있도록 해주며 모든 소스코드가 매일 통합되므로 통합의 혼란을 줄여주며 개발자들의 개발진척도를 피부로 느끼게 해줍니다. 또 유닛테스트를 자동으로 매번 시행하여 기본적인 테스트를 해줍니다. 요즘은 Daily가 아니고 CI툴을 이용하여 빌드 주기를 조절하고 추가적인 작업들도 하지만 개념은 Daily Build와 크게 다르지 않습니다. CI툴은 이를 좀더 편하게 UI와 몇몇 기능을 제공하고 있습니다. 여기까지는 대부분의 개발자들이 알고 있는 내용이기도 합니다. 하지만 Daily Build를 언제부터 시작하느냐에 대해서는 의견이 명확하지 않더군요. 저는 Daily Build는 설계가 끝나고 구현 첫날부터 Daily Bui.. 더보기
서로 맞물려서 돌아가야 하는 기반시스템(Infrastructure System) 소프트웨어를 개발하고 있는데, 필수적인 기반시스템에 대해서는 이미 설명한 바가 있습니다. 이 기반시스템은 서로 연동이 되어서 맞물려 돌아갑니다. 만약에 이 기반시스템들을 사용하고 있지 않다면 기적적으로 개발을 하고 계시거나 정말 쓸데 없는 고생을 하고 계신 겁니다. 어떠한 방법론을 쓰더라도 이 기반시스템을 쓰는 것은 거의 다르지 않습니다. 우선적으로 시급하게 기반시스템들을 도입을 해야합니다. 기반시스템을 써보려고 하는데 어려움이 있거나 궁금한 점은 제가 도와드릴 수 있습니다. 그리고 각 기반시스템이 서로 연동되지 않고 따로 돌고 있다면 최대한 활용하고 있는 것이 아닙니다. 각 기반시스템들은 서로 연동이 되고 최대한 자동화를 해야 효율이 높아집니다. 각 기반시스템들이 기본적으로 어떤 것들을 교환하는지 간단.. 더보기
소프트웨어 개발이 즐거운가요? 나는 소프트웨어가 대학 전공이 아닙니다. 그럼에도 지금 소프트웨어 일을 하고 있는 이유는 소프트웨어를 개발하는 것이 즐거웠기 때문입니다. 처음부터 즐거웠고, 지금도 즐겁습니다. 옛날에는 아침에 눈을 뜨면 오늘 개발할 것들이 머리 속을 스치고 지나가면서 엔도르핀이 나왔었습니다. 이러한 이유 때문에 소프트웨어 개발에 종사하시는 분이 정말 많을 겁니다. 하지만 현실에 치여서, 즉 SI나 용역을 수행하면서 무리한 일정과 말도 안되는 요구사항, 수시로 바꾸는 요구사항 피곤한 사람들에 치여서 개발 일이 점점 즐겁지 않게 된다고 합니다. 그런데 가만히 보면 개발이 즐겁지 않은 것이 아니라 사람과 자신에게 주어진 무리한 요구가 싫은 것입니다. 이는 소프트웨어 필드뿐만 아니라 정도는 다르겠지만 모든 필드에 다 있는 현상.. 더보기
소프트웨어 프로젝트 성공이란? 소프트웨어 프로젝트 성공을 한마디로 말하면 다음과 같습니다. "주어진 시간에 주어진 비용으로 요구된 품질의 제품을 만들어 내는 것" 여기서 가장 중요한 것은 시간과 비용입니다. 어차피 품질도 시간과 비용에 귀결됩니다. 소프트웨어 공학은 이 둘을 충족시키기 위해서 즉, 최소비용으로 최소시간에 소프트웨어를 개발하기 위해서 40년간 연구되어온 실전 학문입니다. 즉 연구소에서 연구만 한 것이 아니라 실제 프로젝트에 적용이 되면서 계속 발전해 온 것입니다. 이 문장에는 많은 함축적인 의미가 있습니다. 고객과 합의한 스펙은 만족했으나 최종 제품이 고객의 요구를 만족시키지 못하면 분석부터 잘못된 것이므로 진정한 성공으로 보기 어렵고, 개발과정에서 개발자를 너무 밤낮, 주말 가리지 않고 혹사해서 개발자가 몇몇 퇴사를 .. 더보기
개발자는 일자리 구하기 힘들고 회사는 개발자 구하기 힘들고 개발자는 일자리 구하기 힘들고 회사는 개발자 구하기 힘든 현상은 오래된 현상이지만, 요즘 들어서는 더 심해지는 것 같습니다. 이러한 고충을 얘기하는 주변 분들이 많아진 것으로 봐서 확실히 채용 문제가 점점 어려워 지는 것 같습니다. 이와 같은 불일치가 일어나는 원인이야 뻔하죠. 서로의 눈높이가 높기 때문입니다. 개발자는 좋은 직장을 구하기가 어려운 것이고, 회사는 좋은 개발자를 구하기가 어렵습니다. 이중에서 회사의 채용활동에 포커스를 해보려고 합니다. 과거에 한창 거품일 때는 개발자의 "개"자만 붙어도 일단 뽑아갔는데, 쓴맛을 좀 봤죠. 개발자가 다 같은 개발자가 아니라는 것을 알게 되었습니다. 개발자들의 퍼포먼스 차이는 최대 28배까지 난다는 조사도 있듯이 어설픈 개발자 뽑아봤자 해고도 못하고 골치덩어.. 더보기

티스토리툴바