01/02/03은 몇년 몇월 며칠일까? 우리나라 사람들은 2001년 2월 3일로 읽지만 미국사람들은 2003년 1월 2일로 읽는다. 이것이 다 일까? 호주사람들은 2003년 2월 1일로 읽는다. 이렇듯 나라마다 날짜를 쓰는 방식이 다를 뿐만 아니라 번역, 날짜, 숫자, 화폐, 단수/복수, 어순, 쓰기 방향, 키보드배치, 폰트, 띄어쓰기 여부, 쉼표, 온도, 문장정렬, 이름, 주소, 색깔의 의미, 섬머타임, 종이 크기 등 지역,
우리나라는 고객이 소프트웨어와 개발사를 망치는 경우가 많다. 외국 소프트웨어 회사와는 다른 잣대로 우리 소프트웨어 회사를 대하는 이중성 때문에 우리나라 소프트웨어 회사는 더욱 어려움을 겪는다. 물론 이런 현상이 꼭 고객 탓만은 아니다. 우리나라 소프트웨어 회사들이 미래는 생각하지 않고 당장 눈앞의 이익만 쫓다 보니 고객들은 여기에 길들여진 측면도 있다. 이렇게 고객이 소프트웨어 환경을 망치고 있는 실제 사례들을
필자는 국내외 다양한 소프트웨어 회사에 다니는 여러 개발자를 만날 기회가 자주 있고 각 회사의 개발 이야기를 종종 듣는다. 그 중에서 3가지를 소개할까 한다. 우리나라 개발자들이 다양한 일을 하지 못하고 하던 일만 계속하게 되는 현상에 관한 것으로, 이것이 왜 문제가 되는지 생각해 볼 수 있는 사례이지 싶다. 국내 A사는 소프트웨어 개발자만 100명이 넘는 업계 1위 중견기업이다.
필자는 최근 소프트웨어와 시스템 공학 역량의 성숙도를 평가하는 CMMI(Capability Maturity Model Integration)를 적용하여 오히려 어려워진 H사 직원 S씨를 만났다. 그동안 SI회사 등 여러 곳에서 CMMI를 적용하였던 회사의 직원들을 많이 만나봤지만 SI회사도 아닌 이 회사의 사례는 독특해 칼럼에서 소개할까 한다. CMMI를 폄훼하려는 의도가 있는 것은 전혀 아니니 오해는 하지 말아주기 바란다. CMMI에 대한 오해와 서투른 기대를
얼마 전 실리콘밸리의 한 개발자 B씨를 만나서 소프트웨어 개발에 대해 많은 얘기를 나눴다. 과거에 같이 일했던 친구인데 미국에서 태어난 중국인으로 미국 대학을 나와 실리콘밸리에서 20여년간 개발자로 일을 했으며 10여년간은 몇몇 회사에서 CTO로 있었던 친구다. B씨는 최근에 한국 소프트웨어 회사(가칭 A사)와 많은 교류를 한 모양이다. 한국 회사에 자사 기술을 전수하기 위해서 실리콘밸리와 한국을 오가며 수개월간 한국
소프트웨어를 효율적으로 개발하는 비법 아닌 비법은 개발 프로세스와 개발 문화의 적절한 균형에 있다. 김치를 담그는 레시피처럼 확실한 비율을 정하기는 어렵다. 개발 프로세스는 양날의 칼이다. 적절히 사용하면 개발 효율은 올라가지만 조금만 잘못 써도 개발 생산성이 떨어질 뿐만 아니라 개발자 성장까지 저해하여 회사와 개발자 모두의 미래를 어둡게 만든다. 다른 산업 분야에서는 외국에서 몇백년동안 쌓아온 것을 우리는 몇십년만에