본문 바로가기

소프트웨어이야기

소프트웨어 공학이 뭔가? 필자가 소프트웨어 공학(소프트웨어 엔지니어링)이란 용어를 안 것은 얼마 되지 않았습니다. 소프트웨어 공학이라는 용어를 접하고 그 내용을 보니 오랫동안 소프트웨어를 개발하면서 해왔던 그 방법 그대로를 적어 놓은 것에 불과했습니다. 물론 소프트웨어 공학에 포함된 전체 내용은 상당히 방대하지만 그 근본 원리와 핵심적인 내용들은 아주 익숙한 내용들이었습니다. 지금 글을 읽고 계신 분께서 소프트웨어를 아주 잘 개발하고 있다면 이들은 이미 소프트웨어 공학의 대가입니다. 단순히 머리가 좋아서 혼자서 잘 개발을 잘하는 것을 제외하고 여러 명의 팀을 이끌고 복잡한 시스템을 짧은 시간에 가장 적은 비용으로 품질 높은 제품을 이미 만들어 내고 있다면 소프트웨어 공학이란 말을 한번도 들어본 적이 없어도 이미 전문가입니다. 대.. 더보기
잔말 말고 시키는 대로 해 소프트웨어를 개발하는 현장에서는 매우 합리적인 척하는 가면을 쓰고 벌어지는 수많은 비 논리적인 판단과 결정을 자주 보게 됩니다. 약장사처럼 "이 약만 먹어봐 끝내줘!"부터 아주 사소한 이슈까지 정말 다양한 문제들이 비효율적으로 의논되고 합리적이지 않은 결정이 이루어 집니다. 물론 PI(Process Innovation)을 하다 보면 "잔말 말고 시키는 대로 해!"라고 하고 싶은 때가 종종 있습니다. 모든 이슈를 모두에게 합리적으로 납득시키고 이끌어가는 것이 오히려 비효율적이고 또는 거의 불가능할 때 이런 생각이 듭니다. 소프트웨어 개발에 관련된 이슈는 상대방과 반대의 생각을 가지고 끝까지 반박을 하면 끝도 없는 논쟁으로 빠뜨리는 것이 그리 어려운 일이 아닙니다. 물론 득도 없죠. C가 좋나? C++이 좋.. 더보기
공사판 프로젝트? 가끔 소프트웨어 프로젝트가 공사판 같다는 얘기를 하는데, "공사판"이 들으면 기분 나쁠 수도 있겠습니다. ^^ 요즘 빌딩 공사현장을 가만히 보면 깜짝 놀랄 때가 많습니다. 엄청난 규모의 빌딩을 만드는데, 사람을 그렇게 많이 보이지 않고 척척 빌딩이 올라가는 것을 보면 놀라움을 금할 수 없습니다. 모듈화된 건축방식, 자동화된 기계들, 전문화된 각각의 전문가들, 상세한 설계, 체계적이 프로젝트관리. 소프트웨어 개발과 사뭇 비슷하면서도 소프트웨어 개발 프로젝트가 공사판 같았으면 좋겠다라는 생각을 해보게 됩니다. PS) 사실 소프트웨어 개발의 용어 중 상당부분은 공사 용어에서 왔습니다. 프로젝트관리의 뿌리도 건축, 건설이죠. 이미지출처 : Microsoft Office Online 더보기
소프트웨어는 소프트하지 않다. 소프트웨어는 손쉽게 수정할 수 있다고 생각하기 쉽습니다. 특히 고객이나 개발을 잘 이해하지 못하는 Sales part에서는 소프트웨어가 대단히 Soft해서 쉽게 주물떡 주물떡 해서 변경이 가능할 것으로 생각합니다. 하지만 무엇이 언제 수정되냐에 따라서 소프트웨어는 절대로 소프트하지 않습니다. 프로젝트 막바지에 요구사항이 변경되면 요구사항 분석 시 반영된 것에 비하여 수십배의 비용을 지불해야 합니다. 소프트웨어가 소프트하다고 생각하는 것은 비단 고객이나 Sales만이 아닙니다. 개발자들도 그런 생각을 하는 것을 종종 볼 수 있습니다. 개발자들은 자신이 뚝딱뚝딱 만들어 보고는 수정이 쉽다고 생각할 수 있습니다. 하지만 이는 간단한 프로토타입에 불과하고 실제 프로젝트나 제품을 만들 때는 사정이 달라집니다. 요.. 더보기
소프트웨어 회사가 기본적으로 갖춰야 할 것 소프트웨어 회사가 처음에 작은 규모에서 시작할 때는 제품도 빨리 만들어 내고, 품질도 좋으며 생산성이 높습니다. 눈빛만 봐도 서로 무슨 생각을 하고 있는지 알고 생산성이 대단히 높습니다. 이런 과정을 거쳐서 회사가 점점 커져나갈 때 그 규모에 알맞은 준비를 하지 않으면 심각한 문제를 겪게 됩니다. 그럼 소프트웨어 회사가 기본적으로 갖춰야 할 것은 무엇일까요? 바로 조직, 프로세스, 기반시스템 그리고 사람과 개발문화입니다. 회사가 작을 때는 달랑 사람만 가지고 시작을 하곤 합니다. 이 때는 사람이 모든 Risk를 다 감당해야 하지만 작은 조직에서는 큰 문제가 되지 않습니다. 커뮤니케이션이 원활하고 모든 이슈들이 핸들링하기에 충분히 작기 때문입니다. 하지만 회사가 커지기 시작하면 상황은 달라집니다. 커뮤니케.. 더보기
소프트웨어 공학이 왜 필요하지? 복잡하기만 한데... 소프트웨어 공학 블로그를 운영하고 있으면서도 전면에는 소프트웨어 공학이라는 말을 사용하고 있지 않습니다. 그 이유는 소프트웨어 공학은 막연하고 왠지 모르게 문서도 많이 만들어야 할 거 같고, 절차도 엄격히 따라야 할 것 같아서 부담스러운 느낌을 줄 수 있기 때문입니다. 이것이 다 소프트웨어 공학에 대한 오해에서 비롯된 것 같습니다. 이미 유행이 한번 쓸고 지나간 CMMI나 외국의 유명한 방법론들을 도입했다가 실패한 경험과 소문들 때문일 겁니다. Naver 백과사전에서 소프트웨어 공학을 찾아봤습니다. 다음과 같이 설명되어 있더군요. 요약 컴퓨터 소프트웨어의 계획·개발·검사·보수·관리 등을 위한 기술과 그것을 연구하는 분야이다. 소프트웨어의 규모가 커지고 복잡해짐에 따라 공학적인 접근으로 구조화 프로그래밍을.. 더보기
티스토리 독립도메인으로 이동 전과정 정리 블로그를 시작한지는 얼마 안되었지만, "독립도메인을 사용해야 하는데"라는 생각만 가지고 있다가 오늘 과감하게 이동을 했습니다. 그러고 나니 할일이 꽤 많더군요. 그래서 독립도메인 설정과정을 한번 주욱 정리를 해봤습니다. 아직 새싹 블로그라서 이동하는데는 큰 문제가 없었지만, 혹시 많은 독자 때문에 이동이 어려운 블로거가 있다면 참조하세요. 1. 도메인 신청(구매) 도메인은 알아서들 구매하시면 되겠죠. ^^ 도메인 설정에 대해서는 다 아시겠지만, 일반 독자를 위해서 조금 설명을 해봅니다. 도메인이라는 것은 소유의 개념이 아니고 사용권을 획득하는 것으로써 매년 사용료를 지불해야 합니다. 제가 구매한 도메인은 allofsoftware.net입니다. 16,500원/년(VAT포함)을 주고 KT호스팅에서 구매를 했.. 더보기
객체지향... 필요한가? 써니님의 "절차지향도 훌륭한데, 왜 객체지향인가?"라는 글을 읽고 객체지향에 대한 견해를 적어봅니다. 먼저 글을 읽고 계신 분이 C언어로 프로그래밍을 하시나요? 그러면 질문이 있습니다. "static 함수를 사용하시나요? 또 static 함수의 용도를 아시나요?" "static 변수가 아닙니다." 사용하고 계시고 정확한 용도를 알고 계시면 C언어로도 객체지향 프로그래밍을 하고 계시는 것일 겁니다. 이 질문에 갸우뚱하시는 분이 계시나요? 그럼 이야기를 시작해보죠. 여기서 이슈를 다음 두 가지로 나눠야 할 것 같습니다. 객체지향 프로그래밍 객체지향 프로그래밍 언어사용 첫째, 객체지향 프로그래밍은 당연히 필요하다고 생각합니다. 우선 몇 만 라인 이하의 소규모 소프트웨어를 개발할 때와 혼자서 소프트웨어를 개발할.. 더보기
개발자 폭행사건을 바라보는 심경 아래 소개된 개발자 폭행사건을 보고 나름대로 생각을 해봅니다. 우리나라 소프트웨어 업계에 만연해 있는 갑과 을의 왜곡된 구도에 대해서 생각해 보지 않을 수 없습니다. 특히 소프트웨어에 있어서는 갑이 을에게 뭐든지 시킬 수 있고, 뭐든지 바꿔달라고 할 수 있고, 어제라도 마음대로 부릴 수 있다는 인식이 깔려 있는 것 같습니다. 이러한 인식을 깨기 위해서는 법적인 보완, 소프트웨어 개발에 대한 인식 변화, 성숙한 소프트웨어 개발 문화 등이 필요할 것입니다. 우리의 소프트웨어 계약을 보면 정말로 모호하고 일방적인 경우가 정말 많습니다. 외국의 예를 보면 소프트웨어 개발 프로젝트는 분석과 설계/구현이 분리가 되어서 개발 계약시는 분석이 완료된 정확한 스펙을 가지고 개발 계약을 하게 되고, 장애해결이나 유지보수는.. 더보기
프로젝트 산출물을 프로젝트 종료 후에 만들고 있나요?  프로젝트가 끝난 후에 산출물을 만드는 일은 SI회사나 용역으로 일을 하고 있는 회사에서 종종 보게 됩니다. 또, 자사 Solution이나 Product를 만드는 회사에서도 이런 일들이 벌어지곤 하죠. 이런 회사에서 그렇게밖에 할 수 없는 이유에 대해서 다음과 같이 말을 하곤 합니다. 우린 프로젝트 일정이 너무 짧아서 프로젝트 기간에는 산출물을 만들 시간이 없어요. 어차피 산출물은 프로젝트에 별 도움이 안돼요. 우리도 시간만 충분히 있으면 산출물을 잘 만들 수 있어요. 고객이 나중에 요구사항을 바꾸기 때문에 산출물을 잘 만들어 놓아도 또 바꿔야 해요. 코드만 바꾸기도 벅찬데 언제 산출물을 바꿔요. 산출물이란 프로젝트가 끝나고 더 이상 바뀔게 없을 때 한꺼번에 만드는 것이 제일 효율적이예요. 문서를 너무.. 더보기

티스토리툴바