본문 바로가기

분류 전체보기

국제화 시 고려해야 할 49가지 소프트웨어를 국제화해야 하기 위해서는 고려해야 할 것이 한두가지가 아니다. 그런데 많은 회사들은 메시지나 번역하면 되는 것으로 안다. 그렇게 쉽게 접근하다가는 해외 진출을 하면할 수록 문제가 커지고 비용이 늘어서 점점 어려워진다. 실제 만나본 거의 대부분의 회사가 국제화를 제대로 적용하지 못해서 낭패를 보고나 해외에서 크게 실패를 하였다. 비효율성이 높고 문제가 많아도 제품의 크기가 작거나 고객수가 적다면 그럭저럭 버티지만 큰 제품이나 대규모 서비스는 타격이 엄청나다. 심지어는 회사가 휘청할 정도의 문제를 야기 시키기도 한다. 국제화 기술은 알아야 할 지식도 많고 경험도 많이 필요하다. 기본적으로 국제화(i18n)과 지역화(L10N)으로 나뉜다. 국제화(i18n)은 소프트웨어가 여러 Locale을 지원할.. 더보기
Agile이 우리 회사 문제를 해결해 줄 수 있을까? 소프트웨어 공학이라는 용어는 사용하기가 상당히 꺼려진다. 소프트웨어 공학이라는 용어를 듣는 사람들이 많은 오해를 하기 때문이다. 일단 듣는 순간 거부감을 가지는 사람들도 상당히 많다. 소프트웨어 공학이 무엇인지 사람마다 서로 다르게 생각하고 있다. 그럼 스스로 소프트웨어 공학을 어떻게 생각하고 있는지 골라보자. 소프트웨어 공학이란? 1. 소프트웨어를 체계적으로 개발하기 위한 방법이다.2. 고객이 만족하는 소프트웨어를 개발하는 방법이다.3. 소프트웨어를 여러 사람이 효과적으로 개발하기 위한 방법이다.4. 유지보수가 용이한 소프트웨어를 개발하기 위한 방법이다.5. 프로세스를 따라서 소프트웨어를 개발하기 위한 방법이다.6. 품질이 좋은 소프트웨어를 개발하기 위한 방법이다.7. 성능이 좋은 소프트웨어를 개발하기.. 더보기
바람직한 스타트업 SW 개발문화의 조건 우리나라 소프트웨어 회사들의 가장 큰 취약점 하나만 꼽으라고 하면 나는 개발문화를 꼽겠다. 문화란 오랫동안 습득된 구성원들의 공통된 행동 양식이기 때문에 개인이 전체의 문화를 짧은 시간에 바꾸기가 매우 어렵다. 특히 조직이 크면 클수록 문화를 바꾸는데 엄청난 시간과 비용이 필요하다. 하지만 개발문화의 개선 없이는 소프트웨어 개발 역량을 얘기하기가 어렵다. 소프트웨어 개발은 너무 복잡하기 때문에 획일화된 프로세스대로 따라 한다고 잘 할 수 없다. 하나 하나는 완벽해 보이지 않는 문화적인 활동들이 모여서 개발을 효과적으로 이끄는 것이다. 효과적인 개발문화의 필요성을 먼저 깨달은 많은 개발자들도 조직 내에서 접목을 시도하다가 쓴맛을 봐온 것이 사실이다. 그만큼 집단을 바꾸는 것은 쉬운 일이 아니다. 조직 문화.. 더보기
만남 나는 책과 블로그을 통해서 수많은 독자를 만난다. 그 중의 몇명은 Email이나 Facebook을 통해 교류를 하고 소수는 Offline에 만난다.어제 블로그의 독자 한명을 만나서 소프트웨어 개발에 대한 즐거운 대화를 나누었다.Offline에서는 Online이나 책을 통해서 전달할 수 없는 많은 것을 공유할 수 있다. 일반론이 아니고 현재 닥친 상황에 대해서 얘기를 하기 때문에 좀더 도움이 되는 대화가 오간다.독자를 만나면 내가 도움을 주기도 하지만 나도 많이 배운다. 수많은 도메인 지식에 대해서 배우고 각 회사들의 사례를 익힌다. 내가 책을 쓰고 블로그를 꾸준히 운영하는 주된 목적은 독자들과 소프트웨어 개발에 대한 경험을 공유하여 좀더 좋은 개발환경을 만들어 나가는 것이다. 물론, 좋은 개발환경에서 뛰.. 더보기
고객이 전문가 우리나라의 소프트웨어 환경의 문제점 중 하나가 고객이 잘 모른다는 것이다. 예를 들어 공공 SI 프로젝트의 경우 발주처인 공공기관의 담당자가 SI회사의 개발자들보다 업무를 잘 모르는 경우가 종종 있다. 공무원들은 몇년만다 한번씩 자리를 옮기기 때문에 자신의 업무를 빠삭하게 알지 못하고 SI회사에 많이 의지하게 된다. SI회사에서는 해당 분야의 업무만 오랫동안 개발해온 개발자들이 있어서 현업 담당자보다 더 잘 알곤 한다. 외국의 경우 몇십년씩 한자리에서 공무원이 최고의 전문가가 되는 경우와는 사뭇 다르다. 그래서 공공프로젝트를 진행할 때 SI회사가 많이 주도를 한다. 심지어는 발주처에서 해야 할 일도 다 SI회사가 해주곤 한다. 어떻게 보면 SI회사에 좋기도 하지만 문제도 많다. 요구사항 분석 때 충분한 .. 더보기
회의록 작성 문화를 보면... 회의를 하면서 회의록을 작성하는 문화를 가지고 있는 회사들이 매우 많다. 회의록을 아예 작성하지 않는 회사도 있고, 작성을 해도 전혀 뒷처리가 안되는 회사도 있다. 회의는 회사의 가장 중요한 업무 중 하나이며 중요한 결정을 하고 부서간의 의견을 조정하고 업무를 나누고 서로 협업을 하기 위한 수단이다. 그런데 회의는 회의대로 진행하고 후속 조치를 제대로 하지 않는다면 반쪽 짜리 회의가 된다. 하지만 많은 회사들이 아직 회의 문화와 회의록 작성 문화가 아직 부족한 것이 현실이다. 아래 회의록에 관련된 질문 중에 우리 회사는 어디쯤 와 있을까? 회의록은 따로 작성하지 않는다. 그냥 알아서 처리한다.회의 참석자 중에 우연히 꼼꼼한 사람이 있으면 작성하기도 한다. 하지만 대대분 작성하지 않는다.회의 시작전에 회의.. 더보기
Technical Career Path를 보장하는 방법 그 동안 개발자 경력에 대한 글들을 여러 건 작성했다. 많은 독자들이 문제 인식에 공감을 했지만 여전히 해결책은 쉽지 않다. 그래서 여기 방법을 제시하고자 한다. 소프트웨어 회사들이 어떻게 하면 Technical Career Path를 보장할 수 있을까? 첫째, 경영자 의식의 변화이다. 경영자가 개발자의 경력을 보장하는 것이 회사에 얼마나 큰 이득이 되는지 깨닫지 못한다면 개발자가 꾸준히 개발만 할 수 있도록 노력할 리가 없다. 축구는 체력이 떨어지는 30대 중후반이면 더 이상 선수로 뛰기 어렵지만, 소프트웨어 개발자는 체력과 상관없이 평생 시간이 흐를수록 점점 더 뛰어난 개발자로 일할 수 있다. 이렇게 뛰어난 선수로 일할 수 있는 개발자들을 관리나 하라고 낭비하지 않고 계속 선수로 뛸 수 있도록 회사에.. 더보기
요구사항이 계속 바뀌기 때문에 스펙을 적을 수 없다. 소프트웨어 개발 프로젝트에서 스펙을 제대로 적지 않는 회사들에게 그 이유를 들어보면 여러가지가 있다. 1. 프로젝트 기간이 너무 짧아서 스펙을 적을 시간이 없다.2. 프로젝트가 너무 복잡해서 적어야 할 것이 너무 많아서 적을 수 없다.3. 요구사항을 계속 바꿔서 스펙을 적을 수가 없다. 위의 어떠한 이유도 적절한 이유가 되지는 않는다. 오직 한가지 이유가 될 수 있다면 다음과 같은 것이 있을 수 있다."우리는 분석역량이 떨어져서 스펙을 적을려고 해도 제대로 적을 수 없다. 그래서 그냥 개발한다." 위 1,2,3번의 이유 때문에라도 스펙을 적어야 하는 것이다.이중에서 3번 "요구사항이 계속 바뀌기 때문에 스펙을 적을 수 없다"에 대해서 얘기를 해보고자 한다. 99%의 소프트웨어 프로젝트는 분석 기간은 당연.. 더보기
주먹구구식 개발이 통하는 이유 우리나라의 많은 소프트웨어 회사들은 주먹구구식 개발에 대한 환상이 있다.특히, 첫번째 시스템을 주먹구구식으로 개발을 해서 성공했는데 지금은 좀더 체계를 갖췄는데 더 개발이 잘 안된다면 과거 진짜 주먹구구식으로 개발할 때를 그리워하고 그 때로 돌아가고 싶어 한다. 여기 이와 관련된 과거 글이 있다. 2012/07/26 - [소프트웨어이야기] - 옛날에는 개발을 더 잘했는데 주먹구구식으로 개발을 하다가 현재 체계를 갖추려고 노력하고 있다면 아직은 불완전할 뿐더러 반쯤은 주먹구구인 것이다. 그럼 주먹구구식 개발은 어떤 것인지 정의를 내려보자. 크게 5가지로 설명할 수 있다. 첫째, 스펙/설계 없이 개발을 하는 것이다. 또는 기능명세서, 시방서 등의 문서에 기능만 정리하여 개발하는 것이다. 이 방법은 프로젝트 .. 더보기
소프트웨어 회사에서의 관리란? 소프트웨어 회사가 경쟁력을 가지려면 전통적인 관리와는 좀 다른 관리 방법이 필요하다. 첫째, 상하관계 탈피이다. 전통적으로 관리자는 윗사람이고 팀원들은 관리자의 지시를 따르고 관리자가 거의 모든 것의 결정권을 가지고 있다. 하지만 소프트웨어 회사에서 관리자는 기술적인 결정을 할 수 없다. 개발자 출신이라고 기술적인 결정도 하려 하는 경우도 있지만, 기술적인 결정은 개발자의 몫이다. 그리고 전사적인 중요한 기술적인 결정은 CTO나 회사의 최고 개발자들이 하는 것이다. 관리자는 위에서 지시하는 사람이 아니고 개발자들이 개발에 매진할 수 있도록 회의, 보고서 작성, 보고, 의견 조정 등 힘든 일을 도와주는 역할을 해야 한다. 물론 경험이 많은 사람들이 잘할 수 있는 일이기 때문에 평균 개발자보다는 나이가 더 .. 더보기