이런저런 이유로 발표할 기회가 많은 편이다.
대체로 간단하게 나를 소개한 다음 발표를 시작한다. 이름, 회사, 분야, 주요 경력과 같은 내용을 소개한다. 참여하신 분들의 이해도 돕고 발표내용 관련 컨텍스트도 나누기 위해서이다. 적어도 내가 무엇을 했으며 무엇을 하고 있는 지를 전달하고 나면 발표가 한결 편하다. 다음은 자기 소개자료 페이지의 한 부분이다.
그런데, 다른 소개자료에는 없는 정보가 하나있다. 소개할 때 이 내용을 빼지 않고 설명을 한다. 하지만 여유가 없을 경우, 이 내용은 그냥 지나친다. 그럴 경우, 발표가 끝나면 누군가는 꼭 물어온다.
“아까 소개자료에 있던 Ver 4.6은 무엇을 의미하죠?”
(Ver은 Version을 줄여놓은 단어이다. 우리말로 판(版)이라고 해야하나 엔지니어 동네에서는 버전이라는 용어가 익숙해져 있어 그냥 버전이라고 한다.)
소프트웨어 엔지니어는 소프트웨어 개발에 참여하는 사람들이다. 소프트웨어, 즉 애플리케이션을 만들면 두 가지 구분 정보인 이름과 버전(판) 정보를 부여한다. 우리는 이름으로 애플리케이션을 다른 애플리케이션과 구분하고, 버전으로 이전 애플리케이션과 구분한다. 대개 처음 출시하는 애플리케이션은 버전 1.0이다. 버전 5.0은 버전 1.0 보다는 훨씬 뒤에 나온 것임을 알 수 있다. 하지만, 버전에는 그런 시간의 흐름보다 더 중요한 의미가 담겨있다.
새로운 버전은 이전 버전보다 더 성숙한 버전이며 더 신뢰할 수 있는 버전을 뜻한다. 더 안정적이며, 더 좋은 기능을 제공함을 의미한다. 따라서 새로운 버전은 구매가치가 더 높여 시장에 나온다. 새로운 버전이 나올 때까지 기다리는 경우도 있다. 버전이 주는 무게감은 이름이 가지는 무게감 못지 않다. 천하의 오라클도 1.0 시절이 있었다. 그때는 시장에서 1.0만큼의 신뢰를 주고 1.0만큼의 주목 밖에 받지 못했다. 하지만, 오라클 11.0 버전은 11.0만큼의 신뢰와 11.0만큼의 기능으로 천하를 호령하고 있다.
소프트웨어가 고객에게 필요한 기능을 제공하듯이, 소프트웨어 엔지니어는 고객에게 필요한 서비스를 제공한다. 엔지니어가 만드는 소프트웨어도 시간의 흐름에 따라 나아지듯이, 엔지니어 자신도 시간의 흐름에 따라 나아져야 한다. 그래야 더 나은 엔지니어링 서비스가 가능하다. 소프트웨어 제품에 버전번호를 붙여 성숙정도를 가늠하듯이 엔지니어게도 버전 번호를 붙여보기로 한다. “홍길동 Ver4.6”이라는 번호를 붙이는 순간 묘한 긴장감 같은 것이 느껴진다.
엔지니어에게 무엇을 기준으로 버전 번호를 붙여야 할까 고민한다. 엔지니어 인생을 시작한 날을 기준으로 잡아야할까 아니면 스스로 버전 업그레이드 일정을 잡아야 할까? 고민의 끝은 단순하다. 그냥 나이를 버전번호로 삼자. 본의 아니게 매년 반복적으로(iteratively) 업그레이드를 해야 하고 모든 사람에게 공평하니까. 하지만, 개인정보 노출이라는 문제가 약간 걸리긴 한다. 만약 그게 문제가 되는 경우 나름의 방식으로 버전을 올리세요라고 말할 수 밖에.
혹시 버전이라는 용어때문에 터미네이터가 생각나시는 분도 있을 것 같다. 잠시 과거 터미네이터 포스터를 한 번 보고 넘어가자. 이런 의미의 무서운 버전은 절대로 아니다.
새로운 버전의 소프트웨어를 구매하면서 고객이 기대하는 것이 있듯이, 새로운 버전의 엔지니어를 대하면서 고객이 기대하는 것이 있을 것이다. 기대에 부응하는 소프트웨어가 살아남듯이, 기대에 부응하는 엔지니어가 생존할 수 있다. 따라서 훌륭한 새 버전 출시는 엔지니어에게 절대절명의 과제이다. 고객이 묻는다. “지난 해 보다 잘 하실 수 있는 것이 무엇이죠?” 우리는 이 질문에 대해 자신있게 대답할 수 있어야 한다.
“일 년 전의 저를 생각하면 웃음이 나옵니다. 그 땐 보지 못한 것도 많고 깨닫지 못한 것도 많았죠. 올해는 좀 더 잘 할 수 있습니다. 조금 더 넓게 보이네요. 새로운 아이디어도 많구요.“
연말이 다가오면 새로운 버전을 준비해야 한다. 그것은 엔지니어의 운명과도 같은 것이다. 올 한해는 얼마나 많은 노력을 했는가? 그 속에서 무엇을 배우고 깨달았는가? 내가 부족한 것은 무엇이며 어떻게 채워 나갈 것인가? 기술의 흐름과 어떻게 타고갈 것인가? 보다 넓고 높은 곳에서 문제를 바라볼 수는 없을까?
엔지니어링 중에서 특히 소프트웨어 엔지니어링은 적응을 넘어 끝없는 성장을 요구한다. 그 속에서 제 때에 제대로 된 버전을 출시하여야 한다. 엔지니어는 세월이 달아주는 버전번호를 떼고, 스스로 노력으로 새긴 자랑스러운 버전번호를 붙여야 한다. 그러한 엔지니어가 많을 때, 고객은 버전을 올릴 기회를 계속 준다. 이전 버전과 다른 것을 보여주지 못할 때, 높은 버전의 가치는 떨어진다. 이는 곧 높은 버전의 엔지니어가 시장에 설자리가 없음을 의미한다.
"소프트웨어 엔지니어 여러분, 우리 모두 버전 한 번 제대로 올려봅시다."
엔지니어링 중에서 특히 소프트웨어 엔지니어링은 적응을 넘어 끝없는 성장을 요구한다. 그 속에서 제 때에 제대로 된 버전을 출시하여야 한다. 엔지니어는 세월이 달아주는 버전번호를 떼고, 스스로 노력으로 새긴 자랑스러운 버전번호를 붙여야 한다. 그러한 엔지니어가 많을 때, 고객은 버전을 올릴 기회를 계속 준다. 이전 버전과 다른 것을 보여주지 못할 때, 높은 버전의 가치는 떨어진다. 이는 곧 높은 버전의 엔지니어가 시장에 설자리가 없음을 의미한다.
"소프트웨어 엔지니어 여러분, 우리 모두 버전 한 번 제대로 올려봅시다."
엔지니어 버전 6.5 까지 릴리즈하는 세상을 향해...
[마흔살 엔지니어]
'SW 현장통신' 카테고리의 다른 글
훌륭한 아키텍처란 (2010 버전)? (1) | 2011.07.19 |
---|---|
1인 개발자의 꿈 (4) | 2011.07.01 |
개발자, 그대는 영원한 TF (0) | 2011.07.01 |
목표 대비 진척률 98% (3) | 2011.06.29 |
소프트웨어 프로젝트에 대한 또다른 메타포 (3) | 2011.06.23 |