태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.

Search results for '조직'

스타트업을 위한 조직론

2012.10.18 11:07 by 전규현


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





스타트업의 젊은 경영자 중에는 관리 경험이 부족하여 조직관리에 취약한 사람이 많다. 반대로 관리 경험이 많거나 특히 조직관리가 아주 철저한 대기업 출신들은 종종 스타트업에 걸맞지 않은 부담스런 관리 기법을 적용하여 효율성을 떨어뜨리곤 한다.

그럼 스타트업은 어떤 조직관리가 적합할까?

일반 기업에 적합한 조직관리 기법은 소프트웨어 회사와 맞지 않는다. 특히 작은 조직에는 적합하지 않다. 반대로 취미생활 하듯 조직을 관리하면 평생 구멍가게를 못 벗어난다. 전혀 준비가 안된 상태에서 비즈니스가 잘되면 조직은 커지고 회사가 급속도로 비효율적으로 변하게 마련이다. 비즈니스는 잘 되는데 이런 문제로 어려워진 회사를 많이들 알고 있을 것이다.

일반적인 소프트웨어 조직도 마찬가지지만 효율적인 소프트웨어 개발을 위해서는 특히 스타트업이라면 외형적인 조직관리는 Zero에 가까워야 한다. 대신에 몇 가지 필요한 요소가 있다.


첫째 기반시스템 활용


소프트웨어 회사에 필수적인 기반 시스템 두 가지는 SCM(소스코드관리시스템)과 ITS(이슈트랙시스템 또는 버그관리시스템)이다. 추가로 Wiki를 쓰기도 한다. 일반관리를 제외한 거의 모든 관리 부담은 기반시스템이 다 흡수를 한다.

이를 통해 별도 지시, 보고서 작성, 보고에 들어가는 품을 대폭 줄일 수 있다. 잘만 활용하면 10분의 1까지 줄일 수 있다. One-man 컴퍼니라면 시스템 대신 공책이나 엑셀을 쓰기도 하는데 회사가 커지면 문제가 된다. 혼자 일해도 기반시스템을 활용하는 것이 더 효율적이다. 시스템을 구축하는 비용과 관리부담을 걱정하곤 하는데 호스팅을 이용하면 된다.

Atlassian에서는 이슈트랙시스템인 Jira를 10명까지는 한 달에 만원이면 이용할 수 있다. Git나 Murcurial을 5명까지는 무료로 10명이면 한 달에 만원으로 무제한 용량을 사용할 수 있다. Wiki도 마찬가지다. Github를 이용할 수도 있다. 여기에 관한 자세한 내용은 추후 다시 다루겠다.

회사가 웬만큼 성장할 때까지는 이런 저렴한 호스팅을 사용하는 것이 효과적이다. 추후에 Migration도 문제없다. 보안문제를 걱정하곤 하는데 이는 기우이다.


둘째 문서다.


흔히 혼자서 또는 2,3명이 개발을 하면 문서가 필요 없다고 생각한다. 이는 사실이 아니다. 문서를 잘 작성하지 못하거나 제대로 작성해본 경험이 없거나 작성하기 싫어서 대는 핑계일 뿐이다. 문서를 작성하면서 개발을 하는 것이 더 빠르고 효율적이다.

좀더 정확하게 말하면 상황에 맞게 적절하게 작성해야 한다. 스펙을 작성할 때도 정말 간단하게 적을 수도 있고 Unit test가 일부를 대신하기도 하고 설계는 종이에 해도 된다. 또한 상당부분을 기반시스템이 보완하므로 정작 필요한 문서 양은 많지 않다. 조직이 적다고 변변한 문서도 없이 개발을 한다면 그 자체로 비효율적이고 조직이 커질수록 커뮤니케이션 비용이 급속도로 늘어나고 커뮤니케이션 오류로 인한 재작업 비용이 크게 증가한다.


셋째 역할구분이다.


스타트업에서는 개발자 한 명이 많은 역할을 한다. 기본적으로 기획, 분석/설계, 구현, 테스트, 디자인(종종), 기술영업, 기술지원 등 이루 말할 수 없는 많은 일을 한다. 그렇게 준비 없이 회사가 성장하면 개발자 인원수는 몇십배로 늘었는데 하는 일을 별반 다르지 않은 경우가 허다하다. 디자인과 테스트를 분리하기도 하지만 제대로 분리가 안되고 나머지 일들은 그대로 수행하는 경우가 많다.

이유는 개발자의 역할을 정확하게 정의를 하지 못해서 발생한다. 많은 경영자들은 이 모든 일들이 개발자가 원래 해야 할 일이라고 착각한다. 이를 방지하려면 조직의 전문성에 대한 이해가 먼저 필요하다.

혼자 일을 해도 기획, 개발, 테스트를 구분해서 일해야 한다. 필요한 문서도 만들어야 한다. 혼자 일해도 그렇게 일하는 것이 더 효율적이다. 그러다가 회사가 커지면 개발자만 N배로 늘리는 것이 아니고 적절한 비율로 전문적인 역할을 분리하고 프로세스를 만들어나가면 된다. 전문적인 조직으로 분리하는 순서와 비율은 회사마다 다르지만 보통의 순서는 테스트, UI디자인, 마케팅, 기술지원, 기술영업 등이다.

혼자 일해도 역할이 잘 구분되면 부족한 부분을 외주로 돌릴 수도 있다. 한두명이 일한다고 역할을 섞어서 일하면 다른 사람이 효과적으로 도와주기도 어려워진다.


지금까지 얘기한 방식은 스타트업에도 해당하지만 일반적인 소프트웨어 회사도 별반 다르지 않다. 처음부터 이런 조직관리를 준비해야 회사가 커져도 효율성을 계속 유지할 수 있다. 일반적인 회사는 인원이 20명, 50명, 100명, 300명을 넘어갈 때 큰 위기를 한번씩 맞는다.

관리 패러다임이 바뀌고 이때마다 여러 가지 관리기법을 추가한다. 이러한 방법은 소프트웨어 회사에는 잘 적용되지 않는다. 오히려 일반적인 회사의 관리 패러다임을 소프트웨어 회사에 적용하면 효율이 더 떨어진다. 소프트웨어 회사에는 소프트웨어 회사에 알맞은 관리가 필요하다.


이글은 Tech it에 기고한 글입니다.


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

전규현 개발조직 스타트업, 조직

  1. 저 앞의 서두는 이쪽은 아니지만 지금 눈앞에서 벌어지는 일이기도 해서 남얘기 같지 않군요.
    정규군엔 정규군다운, 게릴라전에는 게릴라 전에 맞는 인적 구성과 자원활용법, 전술 등이 다른데
    몸에 안맞게 옥죄는 느낌이랄까요...

  2. 안녕하세요. 기반시스템의 활용도를 높여서 관리부담을 좀 줄여보세요. ^^

  3. 으아~ 유익하다..ㅠㅠ

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

우리나라에는 전지전능한 슈퍼 개발자가 있다.

2008.12.04 23:14 by 전규현


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





여러 소프트웨어 회사를 컨설팅하다보면 아주 많은 개발자들을 만나게 됩니다. 
그 중에는 전지전능한 슈퍼 개발자를 만나게 됩니다.

코딩, 설계, 분석, 테스트, 기획, 고객 전화응대, 고객 지원, 프로젝트 관리, 일반 관리, 아키텍처 등등 엄청나게 많은 일을 하는 개발자들을 보게 됩니다.
이들은 대부분 팀장 쯤 됩니다.

어떻게 생각하시나요? 
바람직해 보입니까?
"나도 그런 전지전능한 개발자야 돼야지"라는 생각이 드십니까?
혹시 지금 이렇게 모든 분야의 일을 다 하고 계시나요?

이것은 One man company 얘기가 아닙니다. 
개발자가 100명이 넘는 회사도 이러한 경우를 여럿 봤습니다.
대부분은 회사가 성장과정에서 적당한 때에 조직을 변화시키지 못하고 그냥 달려온 경우입니다.
이런 경우 전지전능한 개발자가 대부분의 기술과 이슈를 꽤 뚫고 있어서 조직이 그럭저럭 굴러갑니다. (개발자들은 몰라도 사장님은 고민 많으실 겁니다.)
모든 길은 로마로 통하듯 모든 기술적인 이슈도 이 전지전능한 개발자를 통해야 해결됩니다.
이런 개발자가 나가면 회사는 망할 것만 같습니다.

이러한 상황이 정상일까요?

어떤 사람도 서로 완전히 다른 Skill set들을 필요로 하는 일들을 동시에 다 잘 수행해 낸다는 것은 불가능합니다. 아주 작은 회사라면 그렇게 해야지요. 다른 대안이 없으니까요.

이렇게 모든 일을 다하는 전지전능한 개발자는 그 모든 업무를 다 잘 못하고 있다고 봐야 합니다. 그건 애초에 불가능합니다.
이들은 예전에는 뛰어난 개발자였습니다. 하지만, 개발 이외의 일들을 하나씩 떠 맡으면서 각 분야의 일들의 전문성이 점점 떨어지게 됩니다. 그리고 각 일의 Switching cost가 만만치가 않습니다. 이일하다 저일하다하면 그냥 시간이 지나가버리지요. 톰 디마르코는 몰입에는 15분의 시간이 필요하다고 했습니다. 전화한번만 받아도 15분은 그냥 추가로 까먹는거죠.

심지어는 테스트, 고객 전화응대, 고객 지원까지 한다는 것은 100원의 돈을 받으면서 20원짜리 일을 하는 것과 같습니다. 그런 일은 싸게 고용할 수 있는 사람을 시켜야지요. 그리고 기획 같은 일은 전문성이 부족하여 제대로 수행하지도 못합니다. 

결국 이 개발자는 다른 소프트웨어 회사에 가면 별로 가치 없는 개발자가 되고 맙니다. 분야가 달라지면 Domain Knowledge에 의한 경쟁력을 잃고, 개발 실력도 경력에 걸맞지 않게 떨어지고 어느 것 하나 특출난게 없게 됩니다. 관리자로 가야 할까요? 그래서 회사에 꼭 붙어 있으려고 하고, 정치를 하면서 세력을 키우고, 회사의 개혁이나 변화를 반대하고, 골치덩어리 영웅이 되고 맙니다.

회사는 이들에 의존도가 커져서 리스크를 감당할 수 없는 수준에 이르게 됩니다.
이들이 등돌리면 회사는 휘청합니다. 

이것이 개발자 탓일까요? 아니면 회사 탓일까요? 
네, 회사 탓입니다. 회사는 개발자가 실력을 발휘할 수 있도록 여건을 조성해주고 훈련도 시켜줘야죠.
그런데 맨땅에 개발자가 북치고 장구치고 다 하다 보니까, 어쩌다보니 그렇게 된 것이지요.

그럼 어떻게 해야 할까요?

조직이 작을 때부터 나중에 커질 때를 대비해야 합니다.
조직이 커지면 언제든지 분리하기 쉬운 업무부터 띄어낼 수 있도록 말입니다.
이렇게 하려면 갖춰야 할 것이 3가지 있습니다.

이는 "프로세스"와 "기반시스템" 그리고 "문서"입니다.

이 3가지가 있어야 개발 조직이 전문적으로 움직일 수 있습니다.
단 제대로 갖춰야지요. (제대로의 의미는 너무 많이 설명해야 하니 앞으로 계속 올리는 글에서 설명하도록 하죠, 그리고 사실 문서는 프로세스에 포함된 것입니다.)

혼자 일을 하더라도 "스펙"을 작성하고 "설계문서"도 작성하고 "Test Case"도 만들어 놓습니다. 물론 남에게 일을 시키는 것보다는 간소화 할 수 있습니다.
인도에 외주를 줄만큼 자세히 작성하는 것은 낭비죠.
그리고 적절한 개발 프로세스를 만들어서 조직이 커질 때마다 그에 알맞게 계속 발전시켜나가야 합니다.
그리고 "소스코드관리시스템""버그(이슈)관리시스템"은 무조건 제대로 갖추고 있어야 합니다.
이 모든 것은 혼자 소프트웨어 회사를 한다고 해도 갖추고 있어야 합니다.

프로세스, 문서 얘기가 나오니까 오히려 개발이 늦어질 것 같은가요?
혼자 개발을 해도 이것들은 꼭 필요합니다. 개발이 더 빨라지고, 제품의 품질도 올라가죠.

왜?

지금 이해가 가지 않는 분이라면, 여기서 납득을 시켜드릴 수는 없습니다. 
제 책(소프트웨어개발의 모든 것)을 읽어보시거나 저를 찾아오시면 친절하게 설명드리겠습니다.
각설하고..

그렇게 준비가 되고 나면 회사 커지면 직무를 하나씩 전문화시켜야 합니다.
우선 "테스트팀"을 만드십시오. 회사가 작다면 이들이 Technical Support(고객지원)도 병행할 수 있을 겁니다. 
물론 테스트 직무도 전문화를 시키십시오. Random Test가 아닌 제대로 된 절차에 의한 테스트를 할 수 있도록 훈련시켜야 합니다. 그 방법은 제 책을 포함해서 시중에 좋은 책들이 얼마든지 있습니다.

그리고 개발자가 많아지면 관리자를 나누고, 기획, 프로젝트 관리자, 빌드/릴리즈 역할을 나눠 나갈 수 있을 겁니다. 

아직 "프로세스", "기반시스템", "문서", 이런 것들을 갖추고 있지 않은 회사라면은 조직을 어떻게 바꿔도 결국 그 전지전능개발자에게 커뮤니케이션이 다 몰리고 리스크는 여전할 것입니다.

이렇게 회사를 바꾸려면 개발자나 회사나 모두 "성장통"을 감내해야 합니다.
개발자는 현재 자신이 하는 일에만 가치가 있다고 생각하면 안됩니다. 좀더 큰일을 하기 위해서 과감하게 현재의 일을 버리고 자신이 가장 잘하는 일에 집중해서 더욱 가치를 높여야 합니다.
회사는 이 과정에서 임시적을 생산성이 떨어집니다. 이 기간이 짧게는 5,6개월에서 길게는 1년이 갈 수도 있습니다. 부작용을 최소화 하기 위해서 점진적인 변화를 할 수도 있고, 전문가를 영입하여 한번에 바꾸는 방법도 있습니다.

회사 안에 있으면 경영자나 개발자나 이러한 상황을 잘 느끼지 못하는 경우가 많습니다.
개구리를 냄비 안의 찬물에 넣고 서서히 데우면 뜨거워서 견지디 못하는 순간이 될 때까지 잘 느끼지 못하는 것과 같은 거죠.
그냥 익숙해지는 겁니다.
이런 경우 외부의 전문가가 회사를 분석하는 것이 효과적일 때가 많습니다.
궁금하신 내용이 있으면 언제든지 E-mail(gracegyu@abcswcon.com)으로 연락주세요. 궁금증을 시원하게 풀어드리지요. 

장문의 글을 읽어주셔서 감사합니다.


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

전규현 개발조직 개발자, 소프트웨어 공학, 조직

  1. 마음에 와 닿는 글입니다.
    좋은글 감사합니다^^~

    전지전능한 개발자가 되려면 분배하고 대화하고 교육하는 그런 노하우도 있어야 하겠지요.
    과연 그런 사람이 얼마나 될까요?

  2. 돌이아빠님 안녕하세요.
    진짜 제대로된 전지전능 개발자면 좋겠죠. 말씀대로 이는 거의 불가능합니다.
    그냥 일만 많이 하는 그런 개발자가 회사의 큰 리스크라는 것이 문제죠.

  3. 좋은 글이네요. 일정정도 맥이 통하는 글을 쓴 것이 있어서 트랙백 달고 갑니다.

  4. 하이컨셉님 안녕하세요.
    작성하신 글은 잘 봤습니다.
    공감이 가는 글이더군요. 앞으로도 좋은 의견 많이 주고 받기를 기대합니다.
    감사합니다. ;)

  5. 전문화된 개발자가 대우 받는 여건이 빨리 형성되었으면 좋겠습니다.

    그리고 정치세력이란 이야기 정말 공감갑니다.
    스트럭쳐(구조)화 하기 좋아하는 경향들이 있어서 그런지 사람 관계도 구조화를 잘 하시는 분들이 많더라구요 ;)

    좋은 글 정말 잘 읽었습니다. ;-)

  6. jangsungjin님 안녕하세요.
    개발자의 정치라는 것은 결국 제살 깍아먹는 것 아닐까요?
    개발자가 실력이 경쟁력이 되어야지, 정치로 얼마나 오래 살아남을 수 있을까요?
    이런 개발자는 실력도 립서비스밖에 없는 개발자가 되더군요.

  7. 모든 것을 다 하려는 개발자는 어쩔수 없이 문맥전환 비용을 치러야하겠죠. 그러다보면 결국 업무 효율은 떨어지게 될 테구요. 잘 할 수 있는 일에 집중하는 것이 좋겠습니다.

    트럭 넘버라는 이야기를 어디서 들었는데요. 개발자가 트럭에 치어 일을 못하게 되는 일이 생기게 되면 프로젝트가 정상적으로 굴러갈 수 없는 일이 생기게 되는데요. 이런 사고로 개발자들의 일부가 동시에 업무를 보지 못하게 될 경우, 최대 몇 명 까지는 그래도 감내할 수 있는가 하는 질문에 대한 답이 트럭 넘버더군요.

    한 사람의 달인에게 프로젝트의 성패를 의존하게 되면, 프로젝트 불확실성은 계속 증가하게 되는 것 같습니다. 가급적 모든 사람이 프로젝트에 대해 고르게 잘 알도록 배려하는 것이 중요하겠죠.

  8. 이병준님 안녕하세요.
    트럭넘버이야기 재미있겠는데요. 블로그에 한번 올려주세요.

    소프트웨어 개발에서 특정인의 의존도를 낮추고 프로세스와 시스템에 의해서 많은 부분을 커버하는 것은 매우 중요합니다. 이것이 소프트웨어 엔지니어링의 중요한 요소이죠.
    그런 환경이어야 프로젝트의 리스크도 줄어들고 개발자에게도 전문적으로 성장할 수 있는 기회를 제공하게 됩니다.

  9. 좋은 글 감사합니다.
    또 하나의 생각은, 슈퍼 개발자는 회사의 환경만이 그 요소일까.입니다.
    즉, 회사에서 모든 것을 의존하는 것은 본디 그 개발자의
    성향에 의해서도 좌우될 것 같습니다.
    그러기에,
    슈퍼 개발자가 될 성향을 가진 사람들에 대한 정상적 멘토링과
    그들이 지속적으로 관심을 가질 요소들을 찾아서 균형적인
    성장을 할 수 있도록 배려가 필요할텐데...
    그런 방안중 하나로 Ray님의 블로그와 책을 추천하는 것도 좋겠군요
    context switching. 팀장님께 말씀드려봐야겠습니다.
    감사합니다.

  10. 오리주민님 안녕하세요.
    모든 것이 복합적인 문제라서 하나의 원인만 고를 수는 없는 것 같습니다.
    멘토링 참 중요한 이슈입니다. 아직 활성화가 많이 안되어 있고, 시행하더라도 여건과 준비가 부족하고 형식적인 경우도 많은 것 같습니다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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