태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.

Search results for '프로젝트/설계'

개발자 100명을 더 투입한다면?

2012.06.04 06:03 by 전규현


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






소프트웨어 회사에서 프로젝트를 진행할 때 흔히 벌어지는 문제가 "개발자가 부족해서 프로젝트가 늦어진다"는 것이다.


그럼 거꾸로 애플에서 날고 기는 개발자 100명을 투입시켜 줄테니 프로젝트를 제대로 끝낼 수 있냐고 물어보면 대부분 대답은 "글쎄요"다.


벽돌을 쌓거나 땅을 팔때는 사람을 2배 투입하면 대부분 시간이 반으로 줄어든다.


그런데 소프트웨어를 개발하는 프로젝트에서는 왜 그렇게 잘 안될까?


그 이유는 "스펙과 설계"에 있다.

빌딩을 세울 때는 설계가 명확하게 있다. 이 세상에 설계 없이 만드는 빌딩은 없을 것이다. 그리고 협업이 가능하도록 일이 세분화 되어 있고 전문화 되어 있다.


그런데 유독 소프트웨어(특히 우리나라)에서는 스펙과 설계가 땅파고 벽돌 쌓는 것보다 시원찮다. 그런 상태에서 개발을 하다보니 건설현장에서 빌딩 올라가듯이 개발이 되는 것이 아니고 뒤죽박죽이 된다. 이런 환경에 익숙해진 개발자는 뭐가 문제인지 인지하지 못하는 경우가 대부분이다.


스펙과 설계가 제대로 작성되어야 협업이 가능하다. 


여기서 핵심은 컴포넌트다. 컴포넌트가 일을 깔끔하게 나눠서 일할 수 있을 만큼 깨끗하게 나눠져 있어야 한다. 그래서 부서별, 개발자별로 일을 나눠서 할 수 있고 서로 인터페이스 맞추느라고 시간을 허비하지 않는다. 


스펙과 설계가 제대로 되지 않은 상태에서 개발을 하면 컴포넌트 단위로 일을 나눠서 할 수 없기 때문에 "화면"단위로 일을 나눠서 하기도 하고, 적당히 일을 나눠서 하다가 서로 겹치기도 하고 나중에 통합에 엄청난 시간이 걸리게 된다. 또한 어떻게 소프트웨어가 동작은 한다고 하더라도 그 아키텍처는 뒤죽박죽이 되어서 나중에 유지보수도 엄청나게 어렵게 된다.


그럼 스펙/설계 단계에서 어느 정도까지 설계가 이루어져야 할까?


대답은 의외로 간단하다.  스펙/설계의 결과를 가지고 소프트웨어 개발자들이 충분히 구현을 할 수 있을 정도면 된다. 여기서 "충분히"라는 단어는 몹시 애매하다.


문서만 보고 서로 전혀 대화를 하지 않고도 구현을 할 수 있으면 너무 자세히 적은 것이다. 이렇게 자세히 적으면 시간 낭비이고, 개발자에게 너무 자유도를 없앤 것이다. 


그럼 "충분히"는 어느 정도 일까?  개발자가 설계대로 구현을 하면서 약 5% 정도의 내용은 설계자나 관련된 컴포넌트 개발자와 서로 의논하면서 개발할 수 있을 정도면 적당하다고 할 수 있다. 너무 많은 내용을 의논하면서 구현시 결정해야 한다면 적은 내용이 너무 부족한 것이다. 따라서 "충분히"는 상황에 따라 다른 것이다.


설계가 부족하다면 프로젝트리더(테크니컬리더)는 여러 개발자에게 설명하느라고 시간을 보내고 자신이 담당한 개발을 할 시간이 부족해지고, 개발자들에게 설명을 소홀히 하면 개발자들이 제 멋대로 개발을 해와서 문제가 생기곤 한다. 나중에 이를 고치느라고 시간이 몇배로 낭비된다.


설계는 스펙을 작성할 때부터 시작이 되고 설계 단계에서는 컴포넌트가 다 구분되고 인터페이스가 정의가 되어서 소스코드 상에 모두 적히고 컴파일이 가능하도록 해야 한다.


그러기 위해서는 파일이름, Class이름, Public 함수 이름과 parameter, return값이 모두 정해져야 한다. 그리고 그 설명을 문서에 다는 것은 중복이기 때문에 Doxygen이나 Javadoc을 이용해서 소스코드에 주석으로 설명을 하면 효율적으로 설계 정보를 관리할 수 있다.


이렇게 설계가 완료되면 바로 Daily Build가 가능하며 구현 첫날부터 개발자들은 빌드가 가능한 소스코드에 자신이 맡은 컴포넌트의 내용을 채워나가면 되는 것이다. 즉, 첫날부터 이미 통합이 된 상태에서 개발을 하는 것이다.


이렇게 스펙과 설계를 작성하면 일정 산정의 정확도도 훨씬 올라가고 개발자를 더 투입하더라도 도움이 된다. 또한 외주로 개발하는 것도 가능하다.


물론 외주를 줄 경우에는 "설계"도 외주를 주는 경우가 많으므로 이런 경우는 "스펙"까지를 제대로 작성하면 된다.


이렇게 일을 효과적으로 나눠서 할 수 없다면 스펙/설계를 제대로 작성한 것이 아니다. 개발 시간과 비용도 줄일 수 있다. 가장 중요한 것은 프로젝트가 관리 가능한 상태가 된다는 것이다. 일정과 비용이 상당히 정확하게 예측 가능해지고 일정이 지연 상태를 빠르게 파악할 수 있고 대처를 할 수 있다.  스펙과 설계를 제대로 작성할 수 없다면 온갖 프로젝트 관리 기법은 다 소용없다. 결국 야근 밖에 남지 않는다.


"일을 나눠서 할 수 있다."는 것은 결국 개발자가 행복하게 일할 수 있도록 해준다.


image by linus_art






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

전규현 프로젝트/설계

  1. 매번 좋은글 잘 읽고 있습니다. 감사합니다^^
    작년 외주하면서 안 사실인데 대기업 조차도 설계할 능력을 가진 인력이 없다시피 하고요....
    경영진은 설계하는 시간을 '노는 시간'으로 보는게 큰 문제인것 같습니다.

    시간에 쫓겨서 요식행위로 한 설계서가 제대로 될리가 없지요..
    결국 화면단위의 주먹구구식 개발로 인해 생긴 문제는 고스란히 개발자에게로 넘어갔죠.

    그런데 또 그것때문에 다음에 설계를 제대로 하자하면 핑계대지 말래요...
    악순환이에요..

  2. Black_H님 안녕하세요.

    그래도 흔히 설계를 열심히 한다고 한 결과물을 보면 대규모 방법론을 흉내내서 Template이나 채우는 정도라서 시간만 많이 들어가고 구현시에는 보지도 않는 문서를 잔뜩 만들어냅니다.

    제대로 하는 것을 한번도 본적이 없고 한번도 해본적이 없기 때문에 벌어지는 일들입니다.

    그럴려면 차라리 주먹구구가 더 낫습니다.

  3. Blog Icon
    이경희

    항상 머리속에서만 맴도는 부분을 명확히 해주셔서 감사하다는 말씀드립니다.

    빠른 아웃풋을 요구하는 경우 스펙/설계에 시간을 많이 투자하지 못해 결국은 "일단은 이렇게 가자" 라는 경우가 많은데 이럴땐 어떻게 해야 하는지가 참 답답합니다.

  4. 안녕하세요. 이경희님

    개발자들도 시간을 줘도 스펙을 잘 작성하지 못한다는 문제가 있습니다.

    경영자가 스펙을 작성할 시간을 주지 않는다면 스펙을 몰래라도 작성하는 것이 더 낫습니다. 그런 것도 안될 경우는 어차피 문제가 있는 프로젝트를 진행하는 겁니다. 결국 지연되고 난리를 피는 거죠.

  5. Blog Icon
    사자카로스

    안녕하세요.

    코딩은 프로그램 짜다보면 실력은 좋아진다고 보는데요.(익숙해 진다가 맞는 표현이겠죠.)
    설계도 하다보면 늘까요?
    아니면 체계적인 훈련을 할 수 있는 커리큘럼이 있을까요?
    필드에서 쌓이는 개인 경험만이 답일까요?
    극단적으로 회사를 그만두고 좋은 멘토가 있는 회사를 찾는 것이 답일까요?
    (최대한 지금 있는 회사에서 좋은 개발 방향을 제시하고 싶습니다.)

    책에서 나온 내용 숙지해 가며 설계를 해도 이게 잘하고 있는건지 못하고 있는건지... ^^;;
    우물안 개구리가 우물밖으로 나가기 위해 이리저리 뛰어보는 모습입니다.

    본문 글에 컴포넌트를 구분한다고 되어 있는데요.
    컴포넌트는 어떻게 구분하는 것이 맞을까요?
    저같은 경우 감각적(?)으로 필요할 것 같은 컴포넌트로 짤라서 개발했습니다.
    대부분 혼자하는 프로젝트라 구색만 맞으면 됐거든요.(밤이라도 새면서 일정 맞추면 문제가 없었습니다.)
    하지만 다수의 개발자가 참여한 프로젝트에설계자 입장에서
    컴포넌트를 잘 구분하기 위해서는 어떻게 해야 할까요?
    기존 CBD방법론에서 제시한 문서들이 필요한 것이 아닌가 하는 생각이 들기도 합니다.
    개발자들이 개발할땐 필요없는 문서라도 개발자들이 볼 문서를 만들기 위해서는 필요한것이 아닐까요?

  6. 안녕하세요. 사자카로스님

    설계는 일단 근본 원리를 배워야 하고 경험이 많아야 합니다. 설계는 현재 요구되는 기능뿐만 아니라 미래의 전략까지 담아야 합니다. 또한 설계 결과물을 가지고 많은 개발자들이 나눠서 일을 할 수 있어야 합니다.

    컴포넌트로 나누는 것이 나눠서 일을 할 수 있도록 해줍니다. 혼자 개발을 하더라도 똑같습니다. 대신 혼자개발하면 대충해도 문제가 좀 적겠죠. CBD방법론을 따라야 하는 것은 아닙니다.

    스펙/설계서 외에도 가끔 개발노트와 같이 공유하고 싶은 내용을 남기기도 합니다. 하지만 개발과정에 필요하지 않은 문서를 나중을 위해서 일부러 남길 필요는 없습니다. 그러면 개발문서에 들어가야 할 것이 빠진 경우일 수도 있습니다.

    설계를 학원에 배울 수 있는 과정이 별로 없습니다. 배우는 코스는 많지만 별로 도움이 안됩니다. 그냥 그런 것이 있구나하는 정도입니다. 외부 교육과정에서 배운 설계 방법론을 억지로 실제 프로젝트에 적용했다가 낭패를 볼 가능성이 매우 큽니다.

    경험을 쌓아서 시행착오를 통해 배우거나 제대로 된 회사에서 배우거나 컨설팅을 받아서 배우는 방법이 있습니다.

설계가 필요할까?

2011.12.22 21:09 by 전규현


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






최근에 Software Architect의 정체에 대해서 혼란을 겪고 있는 것 만큼 Software 설계에 대해서도 혼동스러운 것은 마찬가지인 것 같다.


그래서 설계에 대해서도 깔끔하게 정의를 해보자.
흔히 설계에 관한 다음과 같은 궁금증을 가지고 있다.
 

  1. SW를 개발하는데 설계는 과연 필요할까?
  2. 설계서는 작성할 필요가 있을까? SW는 설계서 없이 개발하는 것이 더 빠르지 않나?
  3. 설계는 어떤 기법을 이용하는 것이 좋을까?
  4. 설계툴은 UML을 꼭 이용해야 하나? 


일단, 설계를 하는 행위와 설계서를 작성하는 행위를 분리해서 생각하는 것이 좋다.


첫째, 우리는 설계서를 작성하든 하지 않든 "Hello world"를 제외하고는 설계 없이 개발하기 어렵다. 단지 단순한 것은 설계를 머리 속으로 할 뿐이다.

복잡하거나 여러 사람들이 서로 나눠서 개발을 해야 하는 경우는 머리 속으로만 설계를 하기란 거의 불가능하다. 천재라도 복잡한 시스템을 머리로 설계를 할 수 있지만 두뇌를 꺼내서 다른 사람에게 보여줄 수는 없는 일이다. 그래서 설계서를 작성하게 된다.

설계서 없이 개발이 가능한 경우는 극소수일 뿐이다.

그럼 주변에서 보는 설계서 없이 개발하는 수많은 프로젝트는 무엇인가? 

대충 머리 속으로 설계를 해서 코딩을 하면서 서로 맞춰가는 것이다. 이런 식으로라면 재작업하는 일이 여러번 발생하게 되어서 오히려 시간이 더 많이 걸린다. 재작업 문제만 있는 것이 아니다.

설계는 필요한 만큼 해야 하고 거의 대부분은 문서화를 해야 한다.

즉, "Hello world"보다 복잡하거나 다른 사람과 나눠서 일을 하거나 다른 시스템과 인터페이스가 있을 경우는 설계를 적어야 한다.

설계 없이 만들어보려고 하는 것은 Software밖에 없을 것이다. 집, 빌딩, 전자부품, 애들 장난감 모두 설계가 있다. 



둘째, 설계는 어디에 적히는 것일까?

많은 설계는 소스코드와 중복이 되게 된다. 소프트웨어를 개발하는데 있어서 중복은 2배가 아니라 10배의 문제를 야기한다.  따라서 최대한 중복은 피해야 한다.

일단, 설계의 시작 부분은 스펙(SRS)에 적히게 된다. 시스템의 조망과 구조는 스펙의 가장 중요한 부분 중 하나이다. 이렇게 스펙에 설계를 적기 시작하면 스펙과 설계의 경계가 모호해지게 된다. 스펙과 설계의 경계는 따로 정해져 있는 것이 아니고 상황에 맞게 판단하면 된다.

라이브러리를 개발하는냐,  웹서비스를 개발하느냐,  게임을 개발하느냐에 따라서 그 경계는 달라질 수 있다.

보통의 경의 스펙에는 상위 설계 언저리 까지 적히는데 많은 프로젝트에서 설계는 이 정도만 적혀도 충분하다.

설계가 충분하지 아닌지 판단은 이 설계를 가지고 다른 개발자들이 나눠서 각자 개발을 할 수 있는지 생각해보면 된다. 그렇다면 스펙에도 어느 정도로 적히는지를 상상할 수 있을 것이다.

따라서 시스템의 크다고 하더라도 설계서가 별도로 없이 UI만 있어도 개발이 가능 Web 등의 시스템은 스펙에 적히는 정도만 가지고도 개발이 가능하다.

이것으로도 부족하면 별도의 설계 문서를 만들기도 한다. 개발자가 수십명이상 참여하는 프로젝트에서는 대부분 별도의 설계서가 따로 있어야 할 만큼 시스템이 크다.  그런 경우는 설계서를 따로 만드는 것이 좋다.


셋째, 설계는 어떻게 해야 하는가? 무엇을 고려해야 하고 무엇을 적어야 하는가?

설계를 하는 방법에 대해서 고민을 하는 개발자는 매우 많다. 막상 회사에서 설계서를 만들라고 하면 막막하고 많은 경우 코딩을 다 하고 형식적으로 만드는 경우가 많다.

이런 경우는 설계도 제대로 한 것이 아니고 설계서도 엉망이다. 거의 쓸모 없는 문서를 시간을 더 들여서 만든 것이다. 나중에 유지보수에 필요하다고 하는데 유지보수에서 가장 많이 필요한 것은 소스코드와 스펙이다.

설계는 해당 프로젝트를 제대로 짧은 시간 안에 끝내기 위해서 하는 것이다. 또한 잘 된 설계는 미래에 발생할 여러가지 환경을 반영해야 한다. 이렇게 작성된 설계서라야 시스템과 일치를 하며 유지보수 시에도 유용하다.

설계의 기준이 되는 것은 스펙이다. 즉, 스펙이 제대로 적히지 않으면 좋은 설계가 나올 수 없다.

스펙이 없거나 기껏해야 기능명세만 적었다면, 설계는 아무리 잘해도 현재의 요구 기능이 동작하는 것에만 머물 것이다.

이 부분이 가장 중요하다. 수많은 회사들이 여기서 다 망쳐서 지금 그 고생들을 하고 있는 것이다.
스펙에 기능명세 뿐만 아니라 미래의 비즈니스 전략과 비기능 요구사항들이 모두 적혀야 있고 이를 설계에 반영해야 한다.


스펙이 이러한 내용들이 누락이 되어 있으면 설계가 어떻게 될지 상상해보라.

  • 지금은 고객이 10개 회사인데 5년 안에 1,000개의 고객사를 확보할 것이다.
  • 지금은 국내 판매를 대상으로 하는데 1년 후 부터는 세계 200개 회사를 대상으로 마케팅을 할 것이다.
  • 현재의 시스템은 내년에 회사의 다른 시스템들과 통합하는 작업이 진행 될 것이다.
  • 현재는 C/S 구조인데 2년 안에 Web을 지원해야 한다.
  • 현재는 Windows만 지원하는데 1년 안에 MacOS, 2년 안에 iPhone과 Android 폰을 지원해야 한다.
  • 지금은 모델이 3개지만 내년까지 100개의 모델이 5년 안에 5,000개의 모델이 생산될 것으로 예상된다. (사업이 잘 될 경우)
  • 지금은 카메라 모듈을 한 가지만 지원하지만 5년 안에 100개 이상의 카메라 모듈을 지원해야 할 가능성이 80%이다.
  • 현재 만든 Framework로 2년 안에 사내의 모든 TV의 Firmware를 교체할 예정이다.

위 예는 실제 현장에서 발생할 수 있는 수백만개 경우 중 몇 개일 뿐이다.

이러한 내용들이 설계에 적절히 고려되지 않는다면 미래에 큰 댓가를 치루게 된다. 이러한 것을 설게에 잘 반영하도록 설계를 하는 사람들을 Architect라고 부른다.

이런 것을 고려하지 않고 마구 어질러 놓고 인력만 많이 투입해서 엄청 비효율적으로 일을 하고 있으면 그 원인과 방법도 모른체 계속 똑같은 시행착오를 계속 반복할 가능성이 99%이다.


넷째, 특별한 툴을 이용하는 것이 좋은가?

 나는 설계를 위해서 특별한 툴이나 방법론을 선호하지 않는다. 하지만 툴가 방법론을 팔아먹는 사람들이 만병통치약처럼 선전을 한다.

좋은 워드프로세스를 쓴다고 좋은 소설이 안나오고 비싼 붓 쓴다고 그림 잘 그리는 것이 아니듯이 설계를 가장 잘 표현할 수 있는 툴을 알아서 쓰면 된다. 혼자만 이상한 것을 써서 다른 동료들이 편집하지 못하게 해서도 안된다.

설계의 핵심은 컴포넌트와 인터페이스를 적절히 나누고 표현하는 것이기 때문에 이것을 그릴 수 있으면 된다. 그냥 워드프로세스로 정리를 하는 경우가 많다.

하지만 설계를 하는 중간 과정에는 툴을 가지고 깔끔하게 정리를 하는 것은 시간 낭비이다. 설계가 끝날 때까지 설계는 전체를 뒤엎는 과정을 수차례 겪으므로 정리를 해 놓은 낭비이다.  큰 종이나 칠판에 적고 지우고를 반복하는 것이 좋다. 그렇게 거의 완성이 되면 옮겨 적으면 된다.

심지어는 사진을 찍어서 이미지를 문서에 첨부하기도 한다. 이런 경우는 나중에 편집이 안되므로 적절히 사용해야 한다.

그 외에 필요한 것은 설계자가 적절히 판단해서 시스템을 표현할 수 있는 그림이나 다이어그램을 그리거나 글로 적기도 한다. 여기서 창의성을 발휘해야지 규칙을 정해 놓고 따라하면 오히려 비효율적으로 변하게 된다.

디자인패턴 하나 배워서 모든 곳에 써먹는 것은 태권도 정권지르기 하나 배워서 그걸로만 싸우는 격이다. 분명히 도움은 되지만 상황에 맞게 적절한 방법을 창의적으로 생각해 내는 것이 가장 좋다. 그러기 위해서는 먼저 많이 알아야 하고 경험도 많아야 한다.

하위 설계는 소스코드와 중복이 되므로 그냥 소스코드로 작성하는 것이 좋다. Doxygen이나 JavaDoc을 이용하면 소스코드에서 필요한 설계 문서를 거꾸로 만들어 낼 수 있다.

 결론

설계는 필요한 만큼 적절하게 꼭 해야 한다.

하지만 흔히들 문서화의 부담 때문에 아예 안하거나 적는 방법을 몰라서 너무 많이 적는다.
설계문서는 꼭 필요한 만큼만 적절하게 적어야 한다. 가장 어려운 말이지만 이 이상으로 표현하기는 어렵다.

설계서는 한 페이지가 될 수도 있고 수천 페이지가 될 수도 있다. 스펙이 이를 결정한다.

만약 제대로 된 스펙이 없다면 차라리 스펙을 제대로 적는데 먼저 신경을 써야 한다. 설계는 스펙 다음이다.


image by John E. Lester

 


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

전규현 프로젝트/설계

  1. Blog Icon
    Realbj

    좋은글 잘 읽었습니다...

    기본을 중시한

    보양식 같은 글이네요 ^^

  2. 안녕하세요. Realbj님

    감사합니다.

  3. Blog Icon

    비밀댓글입니다

  4. 감사합니다.

Software Architect를 양성하는 나라

2011.12.19 02:21 by 전규현


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






우리나라에서는 종종 SW Architect를 양성한다고 한다. 
정부에서 막대한 예산이 지원도 되며 SW Architect를 양성하는 학원도 생기고 야단법석이다.

그럼 도대체 SW Architect는 무엇인가?

 SW Architect 교육을 받아야 Archtect인가? 설계 방법론을 알아야 하는가? 설계 툴을 다룰 수 있어야 하는가?
이런 접근은 SW Architect에 대한 왜곡된 시각을 유발할 수 있다.

SW Architect는 "고참 개발자"이다. 외국에서 SW Architect 양성 학원이 있나 물어보라. 개발자들이 스스로 SW Architect라고 강조하는지 알아봐라. 

그냥
Software를 오래 개발하면서 경험이 쌓이고 고참 개발자가 되면 그냥 SW Architect인 것이다.

그런데 왜 우리나라는 SW Architect에 대해서 열을 올리고 있는 것일까?

아마, 많은 고참 개발자들이 일반적인 기준의 SW Architect에 미치지 못해서 쓸만한 사람이 부족하기 때문일 것이다. 물론, 그 원인이 개발자에게 있다고 전적으로 말할 수는 없다. 환경적인 요소가 크고 그런 환경에서 자란 개발자들은 피해자라고 볼 수도 있다.

그럼, SW Architect라고 말할 수 있으려면 어떤 일을 해야 할까?

SW Architect는 한마디로 Software 설계를 할 줄 아는 사람이다. 물론 설계만 하는 것이 아니고 코딩도 한다. 때로는 스펙도 적는다.

SW Architect라고 불리려면 설계를 제대로 해야 한다. 제대로 된 설계는 현재 뿐만 아니라 미래에 발생할 수많은 요구사항을 유기적으로 고려하여 가장 합리적인 구조를 만드는 것이다.
그리고 설계를 머리 속으로만 하는 것이 아니고
문서로 만들 수 있어야 한다. 이렇게 작성된 설계 산출물을 가지고 설계자 본인이 아닌 다른 사람들이 코딩을 할 수 있어야 한다.

내가 설계한 것을 내가 코딩 할 밖에 없다면 빌딩을 설계한 사람이 벽돌도 쌓는 격이다. 비용적으로 비효율적일 뿐만 아니라 벽돌은 더 잘 쌓는 사람에게 맡기는 것이 낫다.

설계를 잘하려면 우선 분석이 잘되어야 한다. 즉 SRS가 잘 작성되어야 한다. 분석이 대충 되는 환경에서는 좋은 설계가 나올 수도 없다. 또한 우리나라 대부분의 고참 개발자들은 설계서를 잘 작성해서 다른 개발자들이 개발할 수 있도록 넘기는데 아주 취약한다. 그런 식으로 개발을 안 해봤기 때문에 방법을 잘 모른다.

수많은 설계 방법론이나 툴이 이를 해결해주지 않는다. 설계는 형식에 구애받지 않고 가장 효과적으로 기술하는 것이 좋다. 이러한 역량은 따로 배울 수 있는 것이 아니고 좋은 환경에서 경험과 협업에서 저절로 익히는 것이다.

그럼에도 불구하고 많은 SW Architect 교육이 툴과 방법론이 주류를 이루는 것은 이것 외에는 마땅히 전파할 것이 없기 때문이다.

즉, 단시간 SW Architect 교육을 받는다고 설계 역량이 향상되는 것은 아니다. 지식을 아는 것은 도움이 될 수 있지만, 오히려 위험한 경우가 더 많다.

경험과 실력에 걸맞지 않게 지식들이 들어오면 현실성의 판단이 흐려져서 무리한 적용으로 오히려 낭패를 볼 수도 있다. SW Architecture는 적절해야 하는데 그 적절함을 판단하지 못하는 것이다.

정부에서 SW Architect를 양성하는 것 자체를 반대하지 않는다. 그렇게 효율적이지는 않지만 안하는 것보다는 나을 것이다. 하지만 그런다고 단기적으로 많은 SW Architect가 생겨나는 것은 아니다. 그러니 큰 기대는 하지 말자.

본인이 SW Architect가 되고 싶은 사람은 이런 교육에 기웃거리는 것보다는 스펙을 잘 쓰고, 설계를 해서 다른 팀원들에게 개발을 맡겨보는 일에 좀 더 집중하는 것이 좋다. 이것이 처음부터 잘 될리는 만무하다. 하지만 경험을 여러차례 해보면 점점 나아질 것이다. 

그때서야 외부에서 접하는 여러 지식들이 도움이 될 것이다.

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

전규현 프로젝트/설계

  1. Blog Icon
    hoony

    좋은 말씀이시네요.

    사내에서 역량강화 혁신이랍시고 추진하는 과제에서...
    1년차 사원을 SA과정에 내 몰고서는 실적 달성.이라고 써놓은거 보고........

    휴..

    사장님이라고 SA가 교육으로 만들어지는게 아닌건 아실텐데 말이죠.

  2. 안녕하세요. hoony님

    사장님이 잘 모르실 가능성이 99%입니다. ^^

  3. 잉여가 없어서 그런게 아닐까요? 여유가 있다면 좀 더 좋은, 좀 더 발전적인 결과물이 나올텐데요. ^^

  4. 안녕하세요. 미물님

    환경과 저변이 척박하기 하죠.

  5. Blog Icon
    Jake Kim

    왜들 이렇게 뭐든지 인위적으로 만들려고 하는지 모르겠습니다. 결국 내용은 보지 않고 겉모습만 보고 따라가려고 하는데에 있지 않나 싶네요.

  6. Jake님 오랫만입니다.

    CMMI인증이 대표적인 사례중 하나 아닐까요?

  7. Blog Icon
    똥꽃

    줄기차게 SRS의 중요성을 말씀하시네요. 그리고 SRS의 전파는 하루 아침에 이루어지지 않는다. 지속적인 자기혁신이 필요하다. 일부 학교에서 SRS 쓰기과정이 있다고 하는데...

    SRS를 잘 쓰는 법 좀 가르켜 주세요.

    어떤 문제를 내고 거기에 SRS양식에 맞춰서 보내봐라...그러면 거기에 첨삭을 한다든지 등의....

    답답한 마음에 적어봤습니다.

  8. 안녕하세요 똥꽃님

    SRS 작성은 소프트웨어를 개발하는데 가장 중요하면서 가장 어려운 일입니다.

    피아노 잘치는 법, 골프 잘치는 법을 한마디로 가르쳐 줄 수 없듯이, SRS도 마찬가지 입니다.

    SRS는 예제가 아닌 실제 프로젝트에서 작성을 해봐야 그 경험이 도움이 됩니다. 가상 프로젝트는 별 도움이 안됩니다. 실제 프로젝트에서 코치가 리뷰를 해주는 것은 도움이 많이 됩니다.
    SRS Template를 이용하는 것은 도움이 되지만 Template만 가지고는 절대로 제대로 작성하지 못합니다.

    KAIST 소프트웨어 전문가 과정에서 Requirement Engineering 과목에서 SRS 작성법을 가르쳐 줍니다. 국내에서는 거의 유일할 겁니다. 해외에서도 과정은 찾아보기 쉽지 않습니다. 교육과정으로 배우기 어렵기 때문입니다.

    점점 더 어렵게 느껴지나요? ^^

  9. Blog Icon
    우냐냥

    결국은 돈주는 갑의 경영자만 만족시키면 끝나는 겁니다.
    그들이 엉겁결게 기억하는 특수한 단어(?) 몇 개를 사용해서
    이렇게 된다!
    라고 말해주고 그들이 이해하면 만사 OK죠.
    별로 어려운거 없습니다.
    기술? 따위는 필요가 없지요.
    코더 몇명 데려다 밤샘시키면서 관리감독만 하면 끝! ㅎㅎ

  10. 안녕하세요. 우냐냥님

    옳은 말씀입니다. 그것이 우리나라에서 돈버는 좋은 방법입니다. ^^
    목표가 뭐냐에 따라서 방법이 달라집니다. 제대로 해볼려고 하면 제대로 된 방법이 필요하죠.

  11. Blog Icon
    햇빛

    고참 개발자가 SW 아키텍쳐라는 말씀은 너무나 공감이 됩니다.
    매번 좋은 글 감사드립니다.

  12. 햇빛님 감사합니다.

UML전문가가 설계전문가?

2009.04.15 23:28 by 전규현


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




종종 "소프트웨어 설계를 잘 하려면 UML을 잘 알아야 합니까?"라는 질문을 받습니다. 

사실 넘치는 기법들이 개발자들을 더 혼란스럽게 하는 것에 종종 화가 날 때가 있습니다.
기법은 기법일 뿐입니다. 내용은 아니죠.

UML은 잘 정리된 모델링, 설계 기법이며 툴이고 많은 장점을 가지고 있다고 생각합니다.
그럼에도 불구하고 소프트웨어 설계라고 하고 UML을 떠올리는 것을 보면 UML이 본의 아니게 나쁜 일도 했다는 생각이 듭니다. 

잘 된 설계는 형식에 구애 받지 않고, 소프트웨어를 구현하기 충분하게 소프트웨어 구조를 잘 설명한 것입니다. UML이 그 중의 하나가 될 수도 있고, 전통적인 Flowchart, DFD, 수도코드나 글로 설명할 수도 있습니다. 설계는 어떠한 다이어그램을 그리고 어떤 툴을 쓰냐에 따라서 잘 되었는지 결정되는 것이 아니고 어떤 식으로 접근해서 설계를 하였고, 리뷰 하였는지가 더 중요하고, 이를 보고 구현을 담당한 개발자(본인일지라도) 충분히 구현할 수 있는 적당한 정도가 좋습니다. 그리고 미래의 비즈니스 비전에 대응할 수 있는 구조여야 합니다.

따라서 나는 설계를 시작할 때 종이와 연필 또는 화이트보드를 가지고 시작합니다. 개발자들이 토론을 하면 깔끔하게 컴포넌트를 나누는 것으로 설계를 시작합니다. 
설계 초기부터 툴을 이용해서 정리를 시작하면 감이 잘 안 오고 잦은 수정 때문에 귀찮을 수가 있습니다.

UML을 아는 것은 좋습니다. 남들이 UML로 작성해 놓은 것을 읽을 수는 있어야 하니까요.

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

전규현 프로젝트/설계 dfd, Flowchart, UML, 기법, 다이어그램, 리뷰, 설계

  1. 좋은 말씀이십니다.
    저도 설계를 최초 시작할때는 역시 볼펜과 종이를 가지고 시작합니다.

    물론 사전 요구사항 분석은 기본이지요. 그리고 나서 전체적인 시스템 구조를 어떻게 가져가야 할까를 종이로 열심히 그림으로 그리죠^^! 툴을 잘 다룬다면 좋겠지만, 꼭 잘 다뤄야만 전문가인건 아니죠^^!

  2. 돌이아버님 안녕하세요. ^^
    연필이 좋으면 글을 더 잘 쓸 수 있다는 것과 비슷합니다. 물론 좋은 연필을 사용하면 전혀 나쁠 것은 없지만, 글을 잘 쓰기위해서는 좋은 연필을 사기보다는 책을 많이 읽고 글쓰는 법도 배우고 글도 많이 써봐야죠.

  3. Blog Icon
    작은악마

    당연한 글인데 읽는 순간 많은 생각이 드네요.

    옛날 UML을 보고 감탄하고 그에 따라 볼려고 애쓰다보니.. 가장 핵심적인 면을 놓친것이 많았다 싶습니다.
    사실 적용한다고 해놓고 막상 한건 -_- 문서만 UML 형식으로 만들곤 했지만 말입니다..

  4. 작은악마님 안녕하세요. 축구 좋아하는 어린이가 멋진 축구화 보고 황홀해하고 축구화 살려고 축구는 안하고 맨날 아르바이트 하는 격이죠. 축구화 신경안쓰고 맨날 연습했으면 훨씬 잘할 것을...

  5. 다들 일정관리 어떻게 하고 있나 몇몇 회사분들게 물어보니
    "이것저것 다써봤지만 결국 비지오와 액셀 그리고 달력으로 돌아왔어 ㅎㅎㅎ"
    이렇게 결론이 나더군요.

    "툴이나 기법이 중요한게 아니고 사람이 중요하구나"
    라는걸 다시 느낀것 같습니다.

  6. 안녕하세요. 당근천국님

    저도 왠만한 프로젝트 일정관리 아직도 엑셀로 합니다. ^^ 그게 더 나아요.

코더(Coder)의 비애

2008.11.24 14:31 by 전규현


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




블로그에서 설계에 대한 몇몇 글들을 의견을 적어보려고 합니다. 

안녕하세요. Ray입니다.
써니님이 지금 하시는 일을 코딩이라고 만 얘기할 수는 없는것 같습니다. 분석, 설계도 다 하고 계시는데, 문서화가 안되어 있거나 부족할 수는 있어도 분석, 설계는 하고 있는 거죠.
적은 인원이나 소규모 프로젝트에서는 설계가 별로 이슈가 되고 있지 않습니다.
이런 상황에서 인도에 외주를 줄만큼 설계를 하는것도 낭비죠.

하지만, 내가 설계를 해서 다른 사람이 내 설계서를 보고 약간만 물어보면서 구현(코딩)을 할 수 있느냐를 따져보면 설계 이슈는 전면으로 부각됩니다.

실제로 제대로 설계를 해서 산출물을 만들어 외부에 코딩(구현) 외주를 줄 수 있는 사람은 많지 않습니다.
하지만 이런 구현 외주는 미국과 인도에서는 흔한 일이죠. 물론 설계를 가르쳐 주는 곳도 없어서 배울 수는 있지만, 애초에 이러한 환경에서 같이 일을 했으면 잘 작성된 설계서를 보고 구현도 하고 아키텍쳐 설계회의에도 참석하고 많이 배우죠.

우리의 예를 보면 소규모 기업에서 좋은 소프트웨어를 히트쳐서 회사가 갑자기 켜지고 2,3명이서 개발하던 개발팀이 수십명으로 늘어나면서 제품은 복잡해지고 켜졌는데, 제품은 이전만 못한 경우를 많이 봤습니다.
여러 다른 이유가 있지만, 설계 방법에 대한 이슈도 그 문제에 한몫을 합니다.

밑에 Cavin님이 말씀하신 것 처럼 설계 컨설턴트는 있을 수 없습니다. 제 직업이 소프트웨어 컨설턴트이지만, 설계자체를 컨설팅 해줄 수는 없습니다.
또 설계를 가르쳐주는 것도 거의 불가능합니다.
설계의 기본 컨셉, 방법, 툴 사용법 등을 가르쳐 줄 수는 있습니다.
하지만 이것들이 설계를 할 수 있게 해주지 않습니다.
그런 것들을 모두 다 알고도 오랜 경험이 또 필요하고, 문서화를 할 수 있는 실력도 필요하죠. 알고 있는 기술 분야도 워낙 다양해서 최고의 설계 컨설턴트가 도와준다는 것도 말이 안되는 얘기고 일부 기술이나 아키텍쳐에 대해서 도움을 받는 정도 이죠.

여기서 "설계는 뭐다"라고 얘기할 것은 하나도 없습니다.
그래도 이렇게 끝나는 글이 되면 너무 썰렁하니 설계의 시작과 끝 정도 정의하고 그 속은 워낙 다양하니 차차 여러 가지 의견을 글로 남겨보도록 하겠습니다.

설계의 시작은 우선 인터페이스을 찾아내는 것입니다. 그래서 인터페이스와 컴포넌트들을 구분하면서 시작이 됩니다. 이 개념은 OOP에서 출발한 것도 아니고 가장 전통적인 방법입니다. 소프트웨어의 분야는 수없이 바뀌어 왔지만, 설계의 원리는 크게 변하지 않았습니다. 코볼로 만들던, 자바로 만들던 소프트웨어를 만드는 철학은 기본적으로 많이 다르지 않습다. 설계의 기본은 시스템의 단위를 좀 더 작은 단위로 분할해 가면서 아키텍처를 설계하는 것입니다. 설계는 시스템을 잘게 나눠서 컴포넌트와 모듈을 정의하고 그 인터페이스를 정하는 작업입니다. 수많은 설계 방법들이 있지만 그 기본은 바뀌지 않았습니다카네기-멜론 소프트웨어 엔지니어링 인스트튜트에서 주창한 ADD(Attribute-Driven Design, 속성 주도 설계) 방법이든, 다른 여러 아키텍처 수립 방법론들은 결국 이 방법을 체계화 한 것입니다.

UML과 같은 도구는 설계를 하는데 일부 도움은 될 수 있지만 설계에 꼭 필요한 것은 아닙니다. 설계한 결과를 적는 하나의 도구일 뿐입니다. 설계라는 작업은 소프트웨어 개발에 있어서 가장 자유도가 높고 창의성이 요구되는 작업입니다. 설계 기간은 선임 개발자들의 실력이 가장 많이 드러날 수 있는 기회이기도 합니다. 소소의 사람만이 쓸 수 있는 능력을 가지고 있는 SRS와는 달리 설계는 모든 선임개발자가 가져야 하는 필수적인 역량입니다. 설계에 대해서 너무 많은 제약을 가한다면, 좋은 설계가 나오기는 어려울 것입니다

그럼 설계의 끝은 어디일까요. 적어도 어느 정도까지 설계가 되어야 구현이 진행될 수 있을 까요?
설계가 끝나면 빌드(Build)가 시작되는 것이 기본 원칙입니다.
Class나 수많은 Public함수들의 Prototype이 모두 정의 되어 있고, Build Script까지 완성이 되어서 Daily Build가 시작됩니다. 그러면 Coder는 함수들의 내용과 Sub-function을 만들게 됩니다. Coder에게 함수와 Class를 어떻게 작성해야 하는지 설계서를 작성하는 것은 여기서 설명하기는 어렵겠죠.
여기서 말하려고 하는 것은 이정도까지 설계 단계에서 진행이 되지 않으면 Coder에게 일을 시키는 것은 사실 상 어렵습니다. 
설계를 중점적으로 담당하는 선임 엔지니어들은 지루한 코딩 작업은 가능하면 하지 않을려고 하죠. 설계가 훨씬 재미고 창의적인 작업이기 때문이죠. 그래서 코딩 작업은 신입사원이나 초급 개발자를 시키는 거죠.

이글을 보고 개발자들이 설계를 하는데 일말의 도움이 될 것이라고 생각하지 않습니다.
그냥 주변에서 돌아다는 Software Engineer, Archict, Coder등의 용어들에 너무 구애 받지 말고 자신의 일을 했으면 하는 바랍입니다.

물론 설계 능력 향상을 위한 노력은 매우 중요하죠. 수많은 책을 봤다는 분도 계시는데, 분명 도움이 될 것입니다. 그동안 쌓아온 많은 경험도 필수고요.

앞으로 계속 이에 대한 글들을 써보도록 하겠습니다.
위 글중의 일부는 제 책(소프트웨어 개발의 모든것)에서 인용했습니다.


각 블로그들의 인용문입니다.

저는 여전히 코더(coder)입니다~ by 써니
 하지만, 분명하게 이야기 하고 싶은 것은 제가 매일 하고 있는 일은 코딩이지 설계가 아니라는 것입니다. 그 근거로서 말씀드리지요. 저희 회사에 개발자가 저 혼자 뿐입니다. 누구에게 지시를 내리고 할 위치가 아니라는 것입니다. 또한 코더와 아키텍트, 고수와 하수를 나누고 그들 사이에 편가르기를 시도하려고 하지도 않습니다. 편가르기를 하려면 어느 한 편에 서야만 하는데 저는 양쪽 위치에 다 서 있는 입장입니다. 개발을 하면서 프로젝트 매니저의 역할을 맡은 적도 몇번 있지만 그런 상황에서도 한번도 코딩을 손에서 놓은 적이 없습니다. 그러니까 지금도 코딩을 할 수 있는 것이죠.
Software Design은 결코 쉬운 일이 아닙니다. 10년 20년을 개발했다고 해도, UML을 철저히 공부했다고 해도 여전히 어려운 것이 소프트웨어 디자인입니다. 실용주의 프로그래머, GoF의 디자인 패턴, Head First 시리즈, 아무도 가르쳐주지 않는 프로그래밍 설계 기법, XP 방법론, 리팩토링, Test Driven Development... 온갖 좋은 책을 다 읽어도 구구단을 쉽게 설계하는 법은 아무 책에도 나와 있지 않습니다. 즉, 현실 문제는 책에서 다루는 이상과는 달리 그 변화와 종류가 너무나 방대하기 때문에 정답을 얻기가 어려운 것입니다. 앞서 언급한 기술들과 그 기술들을 저술한 분들은 분명히 손꼽히는 대가인데도 말입니다.
  
꼭 그래야만 하는 이유
 사실 Coder를 거치지 않는 Programmer, Architect는 존재하지 않는다고 봐도 무방합니다. 기본적인 Code에 대한 이해를 가지지 않고 그 일을 한다는 건(현실에서 ‘종종’ 있는 일입니다만..) 배재하고 이야기 해보겠습니다. Coder와 Programmer, Architect의 차이는 뭘까요? 남들 모르는 몇가지 알고리즘을 더 아는 것? 남들 모르는 지식 몇가지를 더 알고 있는 것? 그런 사소한 차이는 같은 Coder,Programmer 사이에 비일비재한 일입니다. 그런 것들로 Coder, Programmer, Architect 는 구분되지 않습니다. 그럼 (나름)구분 할 방법은 무엇일까요? 아니 사람들은 대체!! 어떤 기준으로 너는 Coder, 나는 Programmer! 이런 이야기를 하는 걸까요? 사실 저도 잘 모르겠습니다만… 위의 컨설팅 과정 중에 나온 여러가지 이야기들과 그간의 사람들과 대화를 나누며 격어본 경험들에 비추어 (여러가지로 표현가능하지만) 문제 인식의 차이라고 표현하고 싶습니다.
  
납득할 수 있는 설계를 어디서 배울 수 있을까?
 업계에 설계전문 컨설턴트란 롤은 들어보지 못했다. 예로, 최근 설계에 대한 이슈를 안고 있는 대형 프로젝트가 두 개가 있는데.. 이례적으로 아키텍처가 상세하게 분화되서 분야별 아키텍트가 컨설턴트로 투입되었고, 솔루션 기반의 implementation consulting이라는 롤도 별도로 존재하고 투입되었다. 하지만 이런 환경임에도 설계 컨설팅은 없다. 별도 롤로 구분하지 않고 기술관련된 전반적인 문제들을 아키텍처 팀이나 그룹에 위임을 하는게 일반적인 프로젝트들의 전략이기 때문. 실제로 대형 프로젝트 아키텍처 팀이나 그룹은 그러한 이유로 팀사이즈가 꽤 큰 편.
 그렇다면 프로젝트에서 누가 설계를 가이드해야 할까? 설계는 다분히 전략에 대한 내용들도 많고, 영향을 미치거나 받는 부분이 많다. 시간적으로도 일정 'phase'에 국한되지 않고, 특정 'discipine'에 한정되지도 않는다. 전략들을 설계로 모으고 드라이브 하는 사람은 방법론과 아키텍트. 아키텍처 적용이전은 방법론, 적용되는 시점부터는 아키텍트. 따라서 방법론, 아키텍트 둘의 긴밀한 협조로 설계를 일궈나가야 한다. 그렇지만, 200억, 500억대 프로젝트에서 아키텍트, 방법론 둘 다 빵꾸내기도 하는 이 현실은 완전 시궁창이지만서도..(먼산~)
  
 꼭 그래야만 하는 걸까요?
너희 같은 하수는 평생 그렇게 코딩만 해라 나는 아키텍트의 길로 가련다... 하는 분들도 있을것 같네요. 예, 저는 하수 입니다. 당장 MFC나 위저드의 도움 없이는 Window도 제대로 생성하지 못하는 바보일 뿐이죠. 당장 개발해야 할 당면 과제는 COM 이나 CORBA 컴포넌트 제작이 아닌 제공되는 컴포넌트와 API를 이용한 어플리케이션 제작 입니다. 그렇다고 해서 삽질이나 하는 바보 개발자로 취급 받아도 좋은 걸까요? 훌륭하신 여러분들이 그렇게 무시하는 코더들은 그야말로 코드를 생산하는 위자드 보다도 못한 그런 사람들 일까요? 저는 잘 모르겠습니다. 그렇게 자기가 정한 기준에 맞지 않는 다른 사람들을 무시하는 풍토가 IT 업종의 3D화를 이뤄냈다고는 생각해본적 없으신가요?


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

전규현 프로젝트/설계

  1. 우리는 모두 개발자입니다. 즉 소프트웨어를 만드는 사람들이죠.
    좀 거창하고 넓은 범위에서 이야기하면 창조자입니다.

  2. 김현남님 반갑습니다.
    컨설턴트시군요. 반갑습니다. Justine님의 블로그에 들어가서 둘러 봤는데, 흥미로운 내용이 많더군요. 앞으로 좋은 정보 많이 나눠요.

  3. 많은 공감이 가는 글입니다.. ㅜㅜ

  4. kkommy님 안녕하세요.
    소프트웨어 개발자인신가보죠? kkommy님 블로그를 주욱 둘러 봤는데, 뭐하시는 분인지 알기가 어렵네요.- -;
    만나서 반갑습니다.
    앞으로 자주 뵈요. ;)

  5. 전기관련분야의 컨트롤러의 펌웨어와 소프트웨어를 개발하고 있습니다.. ^^;
    블로그는 거의 개인 이야기다보니 회사랑은 잘 연관이 안되지요~ ㅋㅋ
    저도 만나서 반갑고요~ 자주 뵈어요~ +_+

  6. 아, 그러시군요.
    펌웨어도 중요한 소프트웨어 분야의 하나죠. 소중한 경험 많이 나누면 좋겠네요.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

티스토리 툴바