태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

Search results for 'CTO'

한국에는 가짜 CTO가 많다

2014.07.01 23:08 by 전규현


잠시 후 Google blogger로 이동됩니다.





소프트웨어 회사에서 가장 중요한 한 사람을 꼽으라고 하면 단연 CTO다. 회사 전체 기술의 총 책임자이며 기술 비전과 로드맵을 이끄는 핵심이다. 회사 비즈니스 전략을 기술에 녹여내는 중추 역할을 한다. 회사 기술을 속속들이 알며 개발에 관련된 프로세스와 문화를 발전시켜나가는 사람이다. 

 

뛰어난 CTO가 없는 소프트웨어 회사는 기술의 바다에서 선장 없이 헤매는 배와 같다.소프트웨어 회사가 아니어도 요즘 웬만한 회사는 소프트웨어 분야가 상당히 중요하기 때문에 소프트웨어 부문 CTO가 필요하다. 자동차 회사나 전자 회사도 소프트웨어를 이끌기 위해서는 소프트웨어 CTO가 필요하다. 

 

그러나 한국에서 뛰어난 소프트웨어 CTO을 접하기란 하늘에 별따기와 같다. 많은 회사들은 CTO가 아예 없다. CTO의 필요성을 모르거나 CTO를 할 만한 사람이 없는 경우가 많다. CTO가 정확하게 무슨 역할을 해야 하는지 모르는 경우도 있다. 이런 회사는 개발팀장이나 연구소장이 이런 저런 기술 이슈에 관여를 하기는 하지만 CTO의 역할을 대체하지는 못한다. 

 

회사에 CTO가 있어도 하는 일은 CTO가 아닌 경우가 많다. 즉, 가짜 CTO인 경우다. 명함을 받아보면 CTO라고 되어 있는데 하는 일을 보면 CTO가 아니고 연구소장 등 관리자의 역할을 하는 경우다. 주로 하는 일은 전체 개발 조직을 관리하고 여러 프로젝트의 진행을 챙기는 등의 관리 일을 많이 한다. 또 경영자에게 보고를 하기 위한 보고서를 만드는데 시간을 쓰기도 한다. 이런 일을 하면서 기술을 챙기기란 시간적으로도 불가능하다. 

 

원래 CTO를 할 수 없는 사람이 회사의 권유로 CTO를 하는 경우도 많다. CTO가 되려면 Technical career path에서 벗어나지 않고 꾸준히 개발자로 성장을 해왔어야 한다. 또한 아키텍트 역할을 꾸준히 해서 회사의 최고 아키텍트가 되어 있어야 한다.

 

그러나 우리나라에서 개발자의 경력을 꾸준히 유지하기란 여간 어려운 일이 아니다. 우리나라에서 개발자 경력을 보장해주는 회사는 몇% 안된다. 설령 개발자 경력을 보장해 주는 회사도 진짜로 개발자 경력 보장의 의미를 알고 보장해 주는 회사는 또 몇% 안된다. 그러다 보니 진짜 개발자로서 경력을 보장 받으면서 꾸준히 성장하는 비율은 내 생각에 1%도 안된다. 

 

이런 환경에서 진짜 CTO의 자격과 실력을 갖춘 개발자가 나오기란 거의 기적과도 같은 일이다. 

 

B사는 CTO의 필요성을 인지하고 C사의 연구소장을 CTO로 모셔왔다. 하지만 C사에서 연구소장의 역할은 관리자였던 것이다. 그러다보니 B사에서 CTO가 제대로 CTO 역할을 하기란 어려웠다. 그 뒤에 CTO를 다시 바꿨지만 새로운 CTO도 경영자 출신으로서 진짜 CTO역할을 하기에는 적합하지 않았다. 

 

가짜 CTO들은 회사의 기술을 속속들이 모른다. 개발자 출신인 경우도 있지만 관리와 개발을 넘나들다 보니 이제는 기술을 속속들이 모르고 피상적인 결정밖에 못하는 경우가 많다. 이 정도의 기술 리더십으로 본인이 CTO인줄 착각하는 경우도 있다. 역할은 CTO인데 실제로는 관리를 시키는 회사도 많다. 관리란 대단히 많은 시간과 노력을 필요로 하기 때문에 관리를 하면서 기술을 제대로 챙기기란 쉽지 않다. 

 

한국에서 뛰어난 CTO를 만나보기 힘든 현실은 한국 소프트웨어 개발 환경이 이렇게 열악한 이유 중 중요한 하나다. 소프트웨어를 제대로 개발하기 위해서 개발 문화의 발전보다는 프로세스의 강화로 접근하는 이유도 CTO의 부재인 경우가 많다. 

 

소프트웨어를 잘 모르는 경영자나 관리자는 문서화를 잘하고 엄격한 프로세스를 철저히 지키면 소프트웨어가 제대로 개발 될 것으로 착각한다. 공장에서 제품 조립하는 것처럼 생각하는 것이다. 뛰어난 소프트웨어 CTO가 있다면 회사에 어떤 프로세스와 문화를 도입해야 회사의 현실에서 가장 소프트웨어를 효율적으로 개발할 수 있을지 판단하고 이끌어갈 수 있다. 

 

CTO가 필요하고 지금 당장 아무나 CTO로 임명을 할 수는 없다. 외부에서 뛰어난 CTO 후보를 찾는 것도 한 방법이지만 한국에서 개발자로 20~30년 꾸준히 성장한 개발자를 찾기란 매우 어렵기 때문에 이 또한 쉽지 않다. 시간이 걸리더라도 회사 내부에서 개발자들의 경력을 보장해주고 뛰어난 개발자일수록 관리로 시간을 빼앗기지 않고 개발자로서 성장을 해서 미래의 CTO가 될 수 있도록 여건을 만들어 줘야 한다. 외국에서 CTO를 데려오는 방법도 있지만 언어적인 장벽과 문화적인 괴리 때문에 적응하기 쉽지는 한다. 

 

벤처투자자들도 소프트웨어 회사에 투자를 할 때 가장 중요하게 보는 인력은 CTO다. 뛰어난 CTO는 회사의 성공에 중요한 열쇠다. 지금이라도 회사에서 가장 뛰어난 개발자들이 개발팀장이다 연구소장이다 해서 관리에 메어 있다면 이들이 미래와 기술 조타수가 없는 회사의 미래를 걱정해 봐야 한다. 


이글은 ZDNet Korea에 기고한 칼럼입니다.


저작자 표시 비영리 변경 금지
신고

전규현 소프트웨어이야기 CTO

  1. 기고한 글을 읽다보니 역할이 CTO가 아니라 TA (Technical Architect)가 맞는 듯 하다.
    CTO의 정의를 논하지 않는다고 가정하면 한국에서는 CTO라면 TA+CISO+PMO+ITSM+AA+DA 외에 전략과 영업이 기본이 되어야 한다.
    다양한 경험과 비즈니스 마인드가 있어야 회사의 기준에 부합해야 충분한 역량이 있다고 생각한다.

SW업계에는 망치를 만드는 사람이 많다

2014.06.06 11:54 by 전규현


잠시 후 Google blogger로 이동됩니다.





누군가 빌딩을 만드는데 망치도 못도 다 만들어 쓴다고 하면 어떤 생각이 드는가? 빌딩을 만드는 사람은 망치와 못은 사다가 쓰는 것이 훨씬 낫다는 것을 누구나 알고 있다. 하지만 소프트웨어 업계에서는 망치와 못을 직접 만들어서 쓰는 사람들이 매우 많다. 소프트웨어 업계에도 망치와 못을 전문적으로 만드는 회사가 꽤 많지만 우리나라에서는 장사가 잘 안 되는 것이 현실이다. 

 

이같은 상황은 흔히 NIH(Not Invented Here) 신드롬이라고 불리기도 한다. 우리나라의 경우 더 심한 경향을 보이고 있고 이유도 매우 다양하다. 기업간에 협업이 잘되어야 망치회사도 흥하고 망치를 사다 쓰는 회사도 직접 만들어 쓰는 것보다 훨씬 효과적으로 소프트웨어를 개발할 수 있다. 망치 회사가 흥해야 망치를 만드는데 필요한 툴을 만드는 회사도 흥해서 덩달아 여러 회사가 잘되게 된다. 그런데 왜 우리나라에서는 이렇게 기업간의 협업이 잘 안 되는 것일까?

 

나는 여러 소프트웨어 관계자를 만나는데 엔진, 라이브러리 류의 소프트웨어를 개발하는 회사들은 국내 시장의 특수성에 대해서 하소연을 한다. 자신들의 솔루션이 국내 소프트웨어 회사들에게는 별로 인기가 없고 해외에서는 찾는 사람이 많다고 한다. 국내에서는 특히 조심을 하는 것이 기업들은 가격을 후려치려고 하고 데모를 보여주면 그대로 흉내 내서 만들기도 한다는 것이다. 물론 엉터리로 흉내는 내는 것이지만 이런 식으로 국내에서는 별로 비전이 없다고 한다. 

 

기업들은 자신들의 전문 분야에 집중하고 전문 분야를 개발하는데 필요한 툴이나 시스템은 다른 기업과 협력을 하는 것이 좋은데 이런 협력이 잘 안 되는 이유를 한번 살펴보자. 

 

첫째, NIH(Not Invented Here)신드롬이다. 

 

자신들이 최고라고 생각하면서 자신들이 직접 개발하지 않은 것은 배척하는 현상이다. 이런 개발자들을 인터뷰해보면 자신들이 개발하는 것은 너무 어려워서 자신들, 자신의 회사에서 밖에 개발하지 못한다는 얘기를 한다. 이와 똑같은 현상이 여러 기업에서 벌어지고 있으므로 똑똑한 사람들은 여기 저기 많이 있으며 외부의 창의력과 좋은 아이디어도 받아들일 마음가짐이 되어야 한다. 

 

세계적인 3D 설계 소프트웨어를 개발하는 오토데스크(Autodesk) 사는 진작부터 3D그래픽엔진은 테크소프트3D(TechSoft3D)사 엔진을 사용하고 있다. 그래픽관련 부분은 전문업체에 맡기고 자신들은 설계 애플리케이션에 집중하기 위해서다. 

 

둘째, 근시안적으로 비용을 절약하려는 경우다. 

 

요즘은 오픈소스 소프트웨어가 넘쳐나서 외부의 도움을 받을 수 있는 라이브러리, 툴, 컴포넌트 등이 많지만 여전히 상용 소프트웨어의 도움이 필요한 분야도 많다. 때로는 오픈소스와 상용 소프트웨어 사이에서 저울질을 해야할 때도 있다. 라이선스 계약에 따라서 제품을 팔 때마다 몇 % 또는 얼마의 비용이 계속 발생하기 때문에 커다란 결정이 아닐 수 없다. 

 

상용 소프트웨어를 활용하면 라이선스 비용 외에는 커다란 추가 비용이 없이 본연의 개발에 집중할 수 있다. 하지만 라이브러리, 툴, 엔진류를 직접 개발하면 개발 비용이 꾸준히 들어가게 된다. 오픈소스를 이용할 경우에도 이를 학습하고 유지하기 위해서 상당한 비용이 들어간다. 소프트웨어는 아기처럼 한번 탄생하고 나면 먹여주고 재워주고 비용이 계속 들어간다. 

 

초기 개발 비용의 수십배, 수백배가 들기도 한다. 상용 소프트웨어를 구매하는 비용은 명확하게 비용으로 보이지만 직접 개발하는데 들어가는 비용은 초기 개발비용만 고려해서 우습게 보는 경향이 있다. 하지만 대부분의 경우 직접 개발하는데 드는 비용이 상용 소프트웨어를 사다 쓰는 비용보다 훨씬 많이 들어간다. 게다가 더 큰 문제는 회사에서 본연의 제품에 집중하지 못하고 망치 만들고 못 만드는데 노력이 분산 된다는 것이다. 심지어는 망치를 잘못 만들어서 집을 제대로 만들지 못하기도 한다. 

 

물론 무조건 상용 소프트웨어를 써야 한다는 것은 아니다. 직접 개발을 하거나 오픈소스를 활용하는 것이 좋은 경우도 아주 많다. 여기에 들어가는 비용을 절대로 사소하게 생각하면 안된다는 것이다. 상용 소프트웨어라 하더라도 협력하기에 따라서 표준 제시 가격보다 획기적인 라이선스 조건으로 계약을 하는 것은 아주 흔한 일이다. 서로 윈윈할 수 있는 조건만 잘 맞는다면 가격은 그렇게 큰 장애물이 아니다.

 

셋째, 우리는 다르다고 생각하는 것이다. 

 

개발에 필요한 기반시스템을 구축해야 하는데 회사의 프로세스가 다른 회사들과 달라서 사다 쓰지 못하고 직접 개발을 해야 한다고 주장하는 경우를 많이 보았다. 한 예가 이슈관리시스템이다. 버그추적시스템이라고도 한다. 자신들의 회사는 개발 프로세스가 일반적인 경우와 달라서 거기에 맞추느라고 직접 개발을 해서 쓴다고 한다. 

 

하지만 대부분의 경우 우물 안의 개구리 같은 생각이다. 예외적인 몇 가지 경우를 제외하고는 자신들의 프로세스 자체가 잘못되거나 비효율적인 경우다. 그런데 그런 프로세스가 옳고 이에 맞는 시스템이 없다고 착각을 하고 있는 것이다. 시중에는 Mantis, Redmine, Jira 등 좋은 이슈관리, 버그추적 시스템이 많이 있고 이런 툴을 제대로만 사용한다면 좋은 개발 문화도 덤으로 얻을 수 있다. 자신들의 프로세스가 이런 툴과 맞지 않는다면 툴을 직접 개발하기 보다는 프로세스를 툴에 맞추는 것이 나을 가능성이 훨씬 높다. 

 

넷째, 상용 소프트웨어에는 없는 기능이라서 직접 개발해야 한다고 주장하는 경우다. 

 

여러 상용 소프트웨어 또는 오픈 소스를 조사해봐도 99%는 만족하는데 1% 기능이 부족해서 사용하지 못하는 경우도 많다. 그런데 예상외로 상용 소프트웨어를 만드는 회사들은 추가 기능 개발 요청에 상당히 적극적인 경우가 많다. 그런데 그런 시도를 해보지도 않고 그냥 포기를 하고 직접 만든다고 하곤 한다. 

 

당장 오늘 내일 필요한 것이 아니고 기획단계에서부터 검토를 할 경우 수개월의 여유기간이 있고 이 기간 동안에 추가 기능을 개발할 회사는 얼마든지 찾을 수가 있다. 하지만 이렇게 계획적으로 개발을 하지 않고 당장 필요하다고 하면 외부 업체와 협력할 시간적인 여유는 없게 된다. 급하다고 직접 만들기도 하는데 이는 새로운 문제의 시작일 가능성이 높다. 

 

영어 또한 상당히 큰 장벽이다. 이런 것을 조사하고 추가 개발을 요청하고 협력 방안을 조율하려면 어설픈 영어 가지고는 부족하다. 영어도 잘하고 소프트웨어 업계가 어떻게 돌아가는지도 잘 알아야 하기 때문에 그냥 영어만 잘하는 사람 가지고도 안 된다. 그래서 영어 실력이 부족하다 보니 시도도 못해보거나 시도를 해보다가도 매끄럽게 협력이 잘 안되는 경우가 많다.

 

소프트웨어 회사들이 다양한 소프트웨어를 개발하고 서로 협력해서 서로 키워가는 것은 전체 소프트웨어 생태계의 성장에 중요한 역할을 한다. 그런데 빌딩을 만드는데 집중할 업체에서 망치를 만드는데 신경을 쓰고 망치 업체는 망하고 이런 일이 반복되면 소프트웨어 생태계는 점점 쪼그라들고 만다. 

 

개발자들도 문제다. 기술을 잘 모르는 경영자들은 이런 판단을 직접 할 수는 없다. 개발자들에게 망치를 만드는 것이 좋은가, 사다 쓰는 것이 좋은가 물어볼 때 위에 제시한 이유들을 들어서 직접 개발해야 한다는 주장을 하는 경우가 압도적으로 많다. 잘못된 판단으로 빌딩을 만드는 회사는 망해도 개발자에게는 망치를 만드는 기술이 남았다고 생각할지는 몰라도 망치 전문업체의 기술에 비하면 “새발의 피”에 불과한 기술일 뿐이다. 

 

각 기업에서 이런 잘못된 판단이 이루어지는 이유 중 하나는 CTO의 부재 때문이다. 이런 결정은 회사의 미래에 매우 중요한 결정이기 때문에 개발자 한 명의 의견을 들어서 결정하는 것도 위험하고 회사의 기술을 책임지는 CTO가 결정을 해야 한다. 

 

소프트웨어 개발은 개인간의 협업도 중요하지만 기업간의 협업도 매우 중요하다. 내 것이 최고라는 생각을 버리고 서로 협력을 할 때 전체 소프트웨어 생태계가 좀더 나아질 것이다.



이글은 ZDNet Korea에 기고한 칼럼입니다.

저작자 표시 비영리 변경 금지
신고

전규현 소프트웨어이야기 CTO, NIH, 개발문화

  1. 안녕하세요~ 오랫만에 방문하게 되네요 ^^;
    확실히 개발하다 보면 학습에 대한 부담도 있어서 차라리 만들어서 쓰고 말지 라는 결정을 내리는 경우도 꽤 자주 있는것 같긴 합니다만...
    장기적으로 그 툴에 대한 유지보수나 검증 비용이 더 큰데 그걸 자꾸 잊게 되는것 같습니다.

  2. 안녕하세요. 구차니님 오랫만입니다.

    그동안 잘 계셨죠? ^^ 절대적인 기준은 없으며 직접 해보는 것도 학습이나 경험 차원에서 꼭 필요하고 도움이 많이 됩니다. 물론 직접 해봐야 남을 시킬 수도 있고, 상용 소프트웨어를 고를 때도 필요합니다. 균형을 잘 유지하는게 어렵겠죠.

SW회사, 이런 사장이 문제

2009.11.10 16:07 by 전규현


잠시 후 Google blogger로 이동됩니다.




모든 회사가 마찬가지이지만, SW회사에서 경영자의 중요성에 대해서는 여러 번 얘기를 했습니다.

여러 경영자 중에서 어설프게 아는 경영자가 아예 잘 모르는 경영자보다 더 무섭습니다.
많은 SW회사 경영자들을 만나보면, 소시적에 코딩도 좀 해보고 밤새우면 개발도 해봤다고 SW 개발을 아주 잘 이해하고 있다고 착각하는 경우를 자주 접하게 됩니다. 또 본인이 상당한 수준의 전문가라고 착각하기도 합니다.

이런 경영자일수록 자신이 잘 알고 있다고 생각하므로 진짜 전문가인 내부 개발자들이나 외부의 목소리에 귀를 기울이지 않게 됩니다.
이는 마치 바둑 7,8급 정도 두는 실력으로 1,2단 실력을 가진 개발자들 머리 위해서 마음대로 휘두르는 것과 같습니다. 

비록 자신이 모르더라도 전문가를 채용하고 전문가의 의견을 존중하는 경영자가 오히려 낫습니다.

이런 어설픈 전문가 증상개발자 출신 경영자에게서 종종 나타납니다.
이러한 경영자들은 회사가 커지면서 부딪히는 문제들을 자신의 경험을 토대로 해결하려고 하곤 합니다. 그러면서 개발자들이 자신이 왕년에 개발하는 것처럼 열심히 안 한다고 한탄하기도 합니다. 본인은 과거에 꽤 괜찮은 소프트웨어를 개발하여 회사를 이만큼 키워 놓았지만, 잘 개발했던 것은 아닙니다. 회사가 작고 개발 인원이 얼마 안되니 그냥 주먹구구식으로 개발을 했어도 별 문제 없이 개발이 되었던 것일 뿐입니다.

차라리 소프트웨어 개발에 대해서 잘 몰라도 전문가의 말에 귀를 기울이고 이해를 하려고 노력하는 경영자가 어설픈 전문가 경영자보다 낫습니다. 물론 진짜 소프트웨어 전문가인 경영자가 있다면 좋겠지만, 이것은 거의 불가능한 일이고 그렇다면 그런 사람은 CEO보다는 CTO역할을 하는 것이 맞겠죠. 이러한 연유로 우리나라 SW회사에는 제 역할을 하는 CTO를 만나는 것이 쉬운 일이 아닙니다.

최고의 SW전문가는 아니더라도 경영자가 적절히 SW개발에 대해서 이해를 하고 있고 내부 개발자들의 의견을 존중하고 전문가의 말에 귀를 기울이고 개발팀에 적극적으로 투자를 해준다면 금상첨화입니다. (물론, 이런 경영자도 많이 만나 봤습니다.)

* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
image by tiarescott
저작자 표시 비영리 변경 금지
신고

전규현 개발조직 CEO, CTO, 경영자, 전문가, 조직

  1. Blog Icon

    비밀댓글입니다

  2. funeasy님 안녕하세요. 오타를 지적해주시다니 감사합니다. 블로그 글은 꼼꼼히 리뷰를 하지 않는 편이어서 가끔 문장도 어색하고 오타가 있기도 하더군요. 어쨋든 황당한 오타 잡아주셔서 감사합니다.

  3. Blog Icon

    비밀댓글입니다

  4. Chanwoo님 안녕하세요.
    오타를 두 분이나 지적해주셨네요. 감사합니다.

  5. Blog Icon

    비밀댓글입니다

  6. 전상수차장님 오랫만이네요.
    잘계시죠? 저는 당연히 잘있죠.

  7. Blog Icon

    지식의 저주를 되새기게 해주는 글이군요
    정작 읽어야봐할 책은 책장이 꽂히지 않다는 지식의 겸손에 대한 움베르토 에코의 반서재의 교훈과 함께요
    오늘도 행복한 하루 되시길...^^

  8. Lee님 안녕하세요.
    공학의 근본은 지식보다는 경험이죠. 실전에서 필요없는 지식은 방해만 되고, 그런 지식을 신봉하는 이론가들은 제발 학교로 돌아가서 연구나 하면 좋겠습니다.

  9. 영업출신 사장이 해보지도 않고 할줄도 모르면서
    어디서 주워들은것만 나열하는거 보다는 그래도 나은 상황이 아닐려나요 ^^;

    사장이라고 해서, 고용주라고 해서
    자신이 고용한 사람들을 믿지 못하는 게 가장 큰 문제 같습니다.
    신뢰를 받지 못하는 사람도 힘들고
    사장도 힘드니 말이죠.

  10. 구차니님 안녕하세요.
    SW회사에서 영업출신 사장도 자칫 위험지기 쉬운 부류중에 하나죠.
    단기적인 이익에만 집착해서 소프트웨어 아키텍쳐를 완전히 망가뜨리는 일을 쉽게 하고 하죠.
    사실 경영자가 무슨 출신이냐보다는 무슨 마인드를 가지고 있느냐가 더 중요하다고 생각합니다.

  11. 완전 공감합니다. 저희 회사 사장님은 잘 모르겠지만 실장님이나 팀장님들중에 그런분들이 조금 있습니다.ㅠㅠ
    사장님도 개발자 출신인데 왜 단기적인 이익만 보시는지 모르겠습니다.ㅠㅠ
    근데 여기 오늘 처음 왔는데 좋은 글이 너무 많아서 행복합니다. 마니 읽고 자주 오겠습니다^^ 감사합니다~

블로그 호스팅을 Google Blogger로 이전합니다.

최근에 블로그에 보안 문제가 발생하여 좀더 안정적으로 블로그를 운영하기 위해서 Google Blogger로 이전합니다. 기존에 http://allofsoftware.net 과 http://www.allofsoftware.net..

한국어(한글) 코드 이야기 (8)

유니코드에 대해서 좀더 알아보기 전에 한국어 코드(문자세트)와 인코딩에 대해서 좀더 알아보자. 1991년에 유니코드가 탄생한 후에 유니코드는 점점 많은 개발자들이 사용하기 시작해서 영역을 넓혀가고 있다. 물론 언젠가는 유니코..

유니코드 영토 전쟁의 승리자는? (7)

이번에는 유니코드의 코드 체계에 대해서 간단하게 알아보고자 한다. 소프트웨어 국제화를 필요로 하는 개발자라면 자주는 아니지만 유니코드 내부 코드 체계를 알아야 할 때가 있다. 다양한 플랫폼에서 개발을 할 때 폰트 등과 관련하..

유니코드는 어떻게 탄생했을까? (6)

소프트웨어 국제화를 이해하기 위해서는 유니코드에 대해서 필수적으로 잘 알아야 한다. 유니코드란 말을 들어보지 않은 개발자는 없지만 관련 용어가 매우 많아서 종종 헷갈린다. 게다가 유니코드가 탄생한지 20년도 더 넘었지만 아직..

직원을 잠재적인 도둑 취급하는 회사

필자는 몇 년 전 A그룹에 강연을 하러 갔다가 곤란한 일을 겪은 적이 있다. 한국 대부분의 대기업이 그렇듯이 보안이 매우 엄격한 회사였다. 나는 직원들의 안내대로 메모리, 외장하드를 모두 빼놓고 회사로 들어갔다. 하지만 강연..

외국에서 팔리는 소프트웨어의 아키텍처 디자인 원칙 (5)

김과장은 그 동안 한국어만 지원하는 소프트웨어 A를 개발해 왔는데 최근에 사장님이 A의 일본어 버전을 만들라고 했다. 그리고 개발 기간도 한달 밖에 주어지지 않았다. 그래서 기존 소스코드를 복사해서 한국어가 들어 있는 모든 ..

소프트웨어 개발자 성장에 꼭 필요한 리뷰

우리나라 개발자들은 프로그래밍은 잘 하는데 대접을 못 받는다는 얘기가 있다. 또, 머리는 좋은데 환경이 나쁘다는 얘기도 있다. 젊은 개발자들은 외국의 개발자들에 전혀 뒤지지 않는데 나이를 먹을수록 실력이 떨어진다는 얘기도 있..

외국에 출시한 소프트웨어가 날짜 때문에 낭패 본 사연 (4)

10년차 개발자인 김과장(가상의 인물)은 최근에 소프트웨어를 영어를 지원하도록 만들었다. 어플리케이션에서 표시되는 모든 메시지(메뉴, 버튼, 다이얼로그 등)를 영어로 번역했다. 그렇게 해서 영어버전을 출시했는데 얼마 안 가서..

독일어 버전 소프트웨어란 말이 잘못된 이유 (3)

본 시리즈는 차례대로 읽으면 소프트웨어 국제화가 전체적으로 이해가 되어서 소프트웨어 개발자에게 도움이 되는 방향으로 진행하려고 하고 있다. 개발자마다 지식과 경험이 천차만별이라서 초급 개발자를 기준으로 작성하고 있다. 경영자..

소프트웨어를 외국에 출시 하면서 흔히 빠지는 함정 (2)

우리나라 소프트웨어 중에서 외국에서 크게 성공했다고 하는 소프트웨어가 있는가? 온라인 게임을 제외하고는 거의 없다. 사실 게임은 국제화, 지역화를 잘 못하더라도 큰 흉이 안 된다. 하지만 그 외의 많은 소프트웨어들은 제품이든..

티스토리 툴바