사건 사고가 끊이없었던 2005년이였습니다.
각종 테러와 자연재해로 많은 사람들이 죽었으며 고통을 당하고 있습니다.
사진을 통해 그 날의 일들을 다시 떠올려 봅니다.
로이터에서 뽑은 올해의 사진..
타임에서 뽑은 올해의 사진
2005년 12월 19일 월요일
[Professional 소프트웨어 개발] 변하지 않는 핵심 잡기
소프트웨어 개발자는 공부를 많이 해야 한다. 새로운 기술이 늘 쏟아지다 보니 지금 유행하는 기술도 어느새 최신 기술에 밀려 찬밥 신세가 되고 만다.
모뎀으로 겨우 통신이 가능하던 시절에는 대부분의 개발자가 단독으로 실행되는 프로그램을 개발했지만 인터넷이 등장하고 웹이 일반화되면서 웹개발이라는 새로운 영역이 생겨나기 했다.
C, C++이 보편적으로 쓰이던 때에 갑자가 Java, C#이 이라는 언어가 나타나서 개발자들에게 배울거리는 던져주기도 했다.
그러고 보면 그 옛날 열심히 공부했던 VB, Win32API, MFC는 최근 2년간 거의 사용하지 않고 C, C++ 기본 라이브러리로만 개발을 해왔었다.
툴과 언어는 계속 진화하고 또 사라진다. 특히 10여년전에 만들어진 언어는 지금도 버전업하면서 더 복잡해지고 있다. 특히 툴이나 특정 프레임웍 또는 API에 의존적으로 개발을 하다 보면 변화에 둔감해 질 수 있다. 당장 MFC는 앞으로 거의 사용되지 않을 전망이고 Win32 API 미래도 그리 밝아보이지 않는다. 새롭게 출시될 롱혼에서는 이 들을 가지고는 롱혼 전용 애플리케이션 개발은 불가능할 것이다.
그래도 우리가 배우고 익힌 소프트웨어 기술 가운데 변하지 않는 핵심은 분명 존재한다. 하지만 바쁘게 개발을 하다보면 이런 것들을 잘 못느끼고 엉뚱한 것들에 가치를 두는 경우가 많다. 대표적인 것이 툴과 언어에 대한 집착이다.
그렇다면 변하지 않는 것은 무엇이 있을까?
"Professional 소프트웨어 개발"이란 책에서는 SWEBOK에서 식별한 전문 소프트웨어 엔지니어가 갖추어야 할 능력을 구성하는 지식 영역을 다음과 같이 소개하였다.
* 소프트웨어 요구사항(Software Requiremenet)
* 소프트웨어 설계(Software Design)
* 소프트웨어 구축(Software Construction)
(상세설계, 코딩, 디버깅, 단위시험, 코드리뷰, 최적화)
* 소프트웨어 시험(Software Testing)
* 소프트웨어 유지보수(Software Maintenance)
* 소프트웨어 형상관리(Software Configuration Management)
* 소프트웨어 품질(Software Quality)
* 소프트웨어공학 관리(Software Engineering Management)
* 소프트웨어공학 툴과 방법론(Software Engineering Tools and Method)
(CASE 도구, 재사용 코드 라이브러리, 정형 방법론 같은 도구와 방법론의 지원, 조직 내에서 도구와 방법론 채택, 전파하는 기법)
* 소프트웨어공학 프로세스(Software Engineering Process)
(소프트웨어 개발 품질, 일정, 생산성 및 프로젝트와 제품의 특성을 향상시키기 위한 활동)
사실 여기서 많은 개발자들이 앞부분의 2-3개 분야가 모든 것인양 알고 공부해왔을 것이다. 오직 코딩이라는 측면만 보면 그 말도 맞긴 하다. 하지만 우리가 생각하는 것외에 더 많은 지식 영역이 존재하고 이는 더 좋은 소프트웨어를 개발하는데 필수적인 지식이다. 그럼에도 불구하고 많은 개발자들이 품질이나 프로세스와 같은 SE측면을 간과하고 있는 것은 안타까운 부분이다.
나만 좋은 소프트웨어를 개발하는데는 많은 지식이 필요하지 않지만 남이 좋아하는 소프트웨어를 개발하기 위해서는 몇배의 지식이 필요하다.
오늘도 나만을 위한 개발을 위해 엷은 지식에 만족하고 있는지 되묻고 싶다.
참고문헌
* Professional 소프트웨어 개발, 스티브 맥코넬, 2003
* SWEBOK (http://www.swebok.org)
읽을거리
* 프로그래머가 알아야할 것
모뎀으로 겨우 통신이 가능하던 시절에는 대부분의 개발자가 단독으로 실행되는 프로그램을 개발했지만 인터넷이 등장하고 웹이 일반화되면서 웹개발이라는 새로운 영역이 생겨나기 했다.
C, C++이 보편적으로 쓰이던 때에 갑자가 Java, C#이 이라는 언어가 나타나서 개발자들에게 배울거리는 던져주기도 했다.
그러고 보면 그 옛날 열심히 공부했던 VB, Win32API, MFC는 최근 2년간 거의 사용하지 않고 C, C++ 기본 라이브러리로만 개발을 해왔었다.
툴과 언어는 계속 진화하고 또 사라진다. 특히 10여년전에 만들어진 언어는 지금도 버전업하면서 더 복잡해지고 있다. 특히 툴이나 특정 프레임웍 또는 API에 의존적으로 개발을 하다 보면 변화에 둔감해 질 수 있다. 당장 MFC는 앞으로 거의 사용되지 않을 전망이고 Win32 API 미래도 그리 밝아보이지 않는다. 새롭게 출시될 롱혼에서는 이 들을 가지고는 롱혼 전용 애플리케이션 개발은 불가능할 것이다.
그래도 우리가 배우고 익힌 소프트웨어 기술 가운데 변하지 않는 핵심은 분명 존재한다. 하지만 바쁘게 개발을 하다보면 이런 것들을 잘 못느끼고 엉뚱한 것들에 가치를 두는 경우가 많다. 대표적인 것이 툴과 언어에 대한 집착이다.
그렇다면 변하지 않는 것은 무엇이 있을까?
"Professional 소프트웨어 개발"이란 책에서는 SWEBOK에서 식별한 전문 소프트웨어 엔지니어가 갖추어야 할 능력을 구성하는 지식 영역을 다음과 같이 소개하였다.
* 소프트웨어 요구사항(Software Requiremenet)
* 소프트웨어 설계(Software Design)
* 소프트웨어 구축(Software Construction)
(상세설계, 코딩, 디버깅, 단위시험, 코드리뷰, 최적화)
* 소프트웨어 시험(Software Testing)
* 소프트웨어 유지보수(Software Maintenance)
* 소프트웨어 형상관리(Software Configuration Management)
* 소프트웨어 품질(Software Quality)
* 소프트웨어공학 관리(Software Engineering Management)
* 소프트웨어공학 툴과 방법론(Software Engineering Tools and Method)
(CASE 도구, 재사용 코드 라이브러리, 정형 방법론 같은 도구와 방법론의 지원, 조직 내에서 도구와 방법론 채택, 전파하는 기법)
* 소프트웨어공학 프로세스(Software Engineering Process)
(소프트웨어 개발 품질, 일정, 생산성 및 프로젝트와 제품의 특성을 향상시키기 위한 활동)
사실 여기서 많은 개발자들이 앞부분의 2-3개 분야가 모든 것인양 알고 공부해왔을 것이다. 오직 코딩이라는 측면만 보면 그 말도 맞긴 하다. 하지만 우리가 생각하는 것외에 더 많은 지식 영역이 존재하고 이는 더 좋은 소프트웨어를 개발하는데 필수적인 지식이다. 그럼에도 불구하고 많은 개발자들이 품질이나 프로세스와 같은 SE측면을 간과하고 있는 것은 안타까운 부분이다.
나만 좋은 소프트웨어를 개발하는데는 많은 지식이 필요하지 않지만 남이 좋아하는 소프트웨어를 개발하기 위해서는 몇배의 지식이 필요하다.
오늘도 나만을 위한 개발을 위해 엷은 지식에 만족하고 있는지 되묻고 싶다.
참고문헌
* Professional 소프트웨어 개발, 스티브 맥코넬, 2003
* SWEBOK (http://www.swebok.org)
읽을거리
* 프로그래머가 알아야할 것
2005년 12월 13일 화요일
[Professional 소프트웨어 개발] 소프트웨어의 특성
"Professional 소프트웨어 개발"을 읽고
소프트웨어업계에 몸을 담은지도 거의 10년이 다 되가는 것 같다. 대학 졸업하기전부터 업계에 투신(?)했기 때문에 오랜 경력을 쌓고 있으나 그것이 진정한 경력이라고 말하기는 힘든 것 같다. 적어도 이 책을 읽고 나면 그런 생각이 든다.
Software Engineering의 중요성을 알게 된 것은 그리 오래되지 않았다. 2003년 PDA용 웹브라우저를 개발하면서 마감기간을 지키기 위해 몇날을 밤새웠고 잘못된 아키텍쳐 선정으로 몇주를 그냥 날려버리고 개발보다 테스트에 많은 시간을 들이는 등 총체적인 문제에 직면했었다. 물론 프로젝트는 성공적으로 마무리가 되었다. 하지만 부작용은 심각했다. 크리스마스와 새해를 회사에서 보냈고 결국 무리하게 개발을 진행하다가 핵심 개발자 두 명이 회사를 그만두고 말았다.
무엇이 문제였을까?
* 우선은 너무 짧은 개발기간이 문제였다.
사실 이것이 모든 문제의 원인 같다. 이로 인해 프로젝트에 대한 검토 기간이 적어 잘못된 아키텍쳐를 적용했고 몇가지 요구분석이 제대로 이루어지지 않아(이보다는 요구분석이 공유되지 않아)중요한 기능들을 나중에 적용하느라 많은 부분에서 수정이 이루어졌다.
* 자동화된 테스트를 시도하지 않았다.
브라우저 특성상 여러 웹페이지를 테스트해야 하는데, 이를 모두 사람이 하나하나 테스트를 했다. 기능하나 추가할 때 마다 여러 기종으로 모든 웹페이지를 다 테스트했다.
* 개발초기에 Code Review가 없었다.
각자 모듈을 어느정도 개발하고 통합하려고 보니 심각한 문제가 발생했다. 중요한 통신 모듈 코드가 생각보다 복잡하고 확장하기 힘들게 개발된 것이다. 그 분야에 개발경험이 없는 개발자에게 무턱대고 일을 시킨 결과 원하는 품질의 코드가 나오지 않은 것이다. 미리 미리 코드 리뷰를 거쳤다면 초기에 해결될 문제를 결국 거의 다시 개발할 수 밖에 없었다.
이 책을 보면 위와 같은 문제에 관해 이미 잘 나와있었다. 아마 소규모 개발업체의 많은 개발자가 이런 문제에 직면하고 있을 것이다.
아래와 같이 소프트웨어의 특성을 안다면 위와 같은 실수는 되풀이하지 않을 것이다.
소프트웨어의 특성
1. 프로젝트의 성공은 초기에 얼마나 빨리 코딩하는기에 달려있지 않다.
2. 결함수를 비용과 일정과 맞바꿀 수 없다.
품질에 집중하라. 이를 위해 테스트 & review를 통해초기 버그를 줄여라
3. 은빛 총알은 프로젝트에 유해하다
방법론(CMM, RUP)이나 기술을 너무 믿지 마라. 모든 것을 해결해주지는 않는다.
4. 건성으로 프로세스를 개선하는 것은 유해하다
5. 소프트웨어는 소프트하지 않다. 소프트웨어를 소프트하게 만들기 위해서는 비용이 더 든다.
다음에 계속...
참고문헌
* Professional 소프트웨어 개발, 스티브 맥코넬, 2003
소프트웨어업계에 몸을 담은지도 거의 10년이 다 되가는 것 같다. 대학 졸업하기전부터 업계에 투신(?)했기 때문에 오랜 경력을 쌓고 있으나 그것이 진정한 경력이라고 말하기는 힘든 것 같다. 적어도 이 책을 읽고 나면 그런 생각이 든다.
Software Engineering의 중요성을 알게 된 것은 그리 오래되지 않았다. 2003년 PDA용 웹브라우저를 개발하면서 마감기간을 지키기 위해 몇날을 밤새웠고 잘못된 아키텍쳐 선정으로 몇주를 그냥 날려버리고 개발보다 테스트에 많은 시간을 들이는 등 총체적인 문제에 직면했었다. 물론 프로젝트는 성공적으로 마무리가 되었다. 하지만 부작용은 심각했다. 크리스마스와 새해를 회사에서 보냈고 결국 무리하게 개발을 진행하다가 핵심 개발자 두 명이 회사를 그만두고 말았다.
무엇이 문제였을까?
* 우선은 너무 짧은 개발기간이 문제였다.
사실 이것이 모든 문제의 원인 같다. 이로 인해 프로젝트에 대한 검토 기간이 적어 잘못된 아키텍쳐를 적용했고 몇가지 요구분석이 제대로 이루어지지 않아(이보다는 요구분석이 공유되지 않아)중요한 기능들을 나중에 적용하느라 많은 부분에서 수정이 이루어졌다.
* 자동화된 테스트를 시도하지 않았다.
브라우저 특성상 여러 웹페이지를 테스트해야 하는데, 이를 모두 사람이 하나하나 테스트를 했다. 기능하나 추가할 때 마다 여러 기종으로 모든 웹페이지를 다 테스트했다.
* 개발초기에 Code Review가 없었다.
각자 모듈을 어느정도 개발하고 통합하려고 보니 심각한 문제가 발생했다. 중요한 통신 모듈 코드가 생각보다 복잡하고 확장하기 힘들게 개발된 것이다. 그 분야에 개발경험이 없는 개발자에게 무턱대고 일을 시킨 결과 원하는 품질의 코드가 나오지 않은 것이다. 미리 미리 코드 리뷰를 거쳤다면 초기에 해결될 문제를 결국 거의 다시 개발할 수 밖에 없었다.
이 책을 보면 위와 같은 문제에 관해 이미 잘 나와있었다. 아마 소규모 개발업체의 많은 개발자가 이런 문제에 직면하고 있을 것이다.
아래와 같이 소프트웨어의 특성을 안다면 위와 같은 실수는 되풀이하지 않을 것이다.
소프트웨어의 특성
1. 프로젝트의 성공은 초기에 얼마나 빨리 코딩하는기에 달려있지 않다.
2. 결함수를 비용과 일정과 맞바꿀 수 없다.
품질에 집중하라. 이를 위해 테스트 & review를 통해초기 버그를 줄여라
3. 은빛 총알은 프로젝트에 유해하다
방법론(CMM, RUP)이나 기술을 너무 믿지 마라. 모든 것을 해결해주지는 않는다.
4. 건성으로 프로세스를 개선하는 것은 유해하다
5. 소프트웨어는 소프트하지 않다. 소프트웨어를 소프트하게 만들기 위해서는 비용이 더 든다.
다음에 계속...
참고문헌
* Professional 소프트웨어 개발, 스티브 맥코넬, 2003
2005년 12월 6일 화요일
집중력을 높이자
집중력은 우리가 일을 하고 공부하는데, 뭔가를 창작하는데 있어서 기본 동력을 제공하는 역할을 한다. 사실 천재는 그렇게 특별한 존재가 아니라고 생각한다. 단지 집중력에서 그들이 더 뛰어나기 때문에 천재라는 소리를 듣게 되는 것이다.
학생들이 집보다 일부러 도서관이나 돈을 내가면서 독서실에서 공부하는 경우가 많은데, 이것도 다 외부의 간섭과 유혹에서 벗어나 집중력을 높이기 위한 시도라고 볼 수 있다.
그렇다면 어떻게 집중력을 높일 수 있을까?
우선 집중력은 어느 정도 타고 난다고 한다. 성격별로 보면 내성적이고 정서가 안정된 사람이 집중력이 대체로 높다고 한다.
필자도 집중력이 약해서 고생을 하고 있다. 뭔가를 코딩하고 만들때는 집중력이 높지만 공부하거나 어떤 일을 꾸준히 하는데는 문제가 좀 있다. 아무래도 생각이 많고 이것저것 관심을 갖다 보니 체계적으로 계획을 세워 일을 진행하는 것이 아니라 이것저것 손에 닿는대로 하다보니 집중을 잘 못했던 것 같다.
이럴 때는 한가지 일에 전념하고 맡았던 일이 끝나기전에 다른 새로운 분야에 손을 대어 대충하기보다 한가지 분야에 목표를 세워 진행하는 것이 도움이 된다.
그렇다면 어떻게 하면 집중력을 향상 시킬 수 있을까? 참고문헌에 소개한 책을 보면 아래와 같이 나와있다. 공감이 가는 부분이다.
* 한가지일에 전념하라
* 방해자극이 눈에 띄지 않게 한다
* 관련자극을 눈에 띄게 한다
* 희망과 목표를 세워라
* 데드라인 효과를 이용한다
* 휴식을 취하라
* 스트레스를 해소하다
* 평삼심 유지하라(요가나 선을 이용 불안공포 제거한다)
* 물리적 환경 구축한다.
1. 소음차단
2. BGM효과
3. 쾌적한 실내 온도
3. 조명연출
4. 식물과 향기 효용
* 평소 건강관리에 힘쓴다.
* 바이오리듬을 고려하거나 수면주기를 깨지 않는다(늦게자도 제시간에 일어나기)
집중력이 없다고 불평하지 말고 평소 생활습관 잘 개선한다면 좀 더 높은 집중력으로 빠르게 일을 처리할 수 있지 않을까?
지금부터라도 방 잘 치우고 동시에 여러가지 일을 하기보다 한가지를 일에 몰두하는 습관을 가져야겠다.
참고문헌
집중력을 기른다, 모리 토시아키 지음, 지식공작소
학생들이 집보다 일부러 도서관이나 돈을 내가면서 독서실에서 공부하는 경우가 많은데, 이것도 다 외부의 간섭과 유혹에서 벗어나 집중력을 높이기 위한 시도라고 볼 수 있다.
그렇다면 어떻게 집중력을 높일 수 있을까?
우선 집중력은 어느 정도 타고 난다고 한다. 성격별로 보면 내성적이고 정서가 안정된 사람이 집중력이 대체로 높다고 한다.
필자도 집중력이 약해서 고생을 하고 있다. 뭔가를 코딩하고 만들때는 집중력이 높지만 공부하거나 어떤 일을 꾸준히 하는데는 문제가 좀 있다. 아무래도 생각이 많고 이것저것 관심을 갖다 보니 체계적으로 계획을 세워 일을 진행하는 것이 아니라 이것저것 손에 닿는대로 하다보니 집중을 잘 못했던 것 같다.
이럴 때는 한가지 일에 전념하고 맡았던 일이 끝나기전에 다른 새로운 분야에 손을 대어 대충하기보다 한가지 분야에 목표를 세워 진행하는 것이 도움이 된다.
그렇다면 어떻게 하면 집중력을 향상 시킬 수 있을까? 참고문헌에 소개한 책을 보면 아래와 같이 나와있다. 공감이 가는 부분이다.
* 한가지일에 전념하라
* 방해자극이 눈에 띄지 않게 한다
* 관련자극을 눈에 띄게 한다
* 희망과 목표를 세워라
* 데드라인 효과를 이용한다
* 휴식을 취하라
* 스트레스를 해소하다
* 평삼심 유지하라(요가나 선을 이용 불안공포 제거한다)
* 물리적 환경 구축한다.
1. 소음차단
2. BGM효과
3. 쾌적한 실내 온도
3. 조명연출
4. 식물과 향기 효용
* 평소 건강관리에 힘쓴다.
* 바이오리듬을 고려하거나 수면주기를 깨지 않는다(늦게자도 제시간에 일어나기)
집중력이 없다고 불평하지 말고 평소 생활습관 잘 개선한다면 좀 더 높은 집중력으로 빠르게 일을 처리할 수 있지 않을까?
지금부터라도 방 잘 치우고 동시에 여러가지 일을 하기보다 한가지를 일에 몰두하는 습관을 가져야겠다.
참고문헌
집중력을 기른다, 모리 토시아키 지음, 지식공작소
피드 구독하기:
글 (Atom)