Software Architect를 양성하는 나라
2011/12/19 02:21 by 전규현
All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다.
RSS Feed
우리나라에서는 종종 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
RSS Feed
우리나라에서는 종종 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
'프로젝트 > 설계' 카테고리의 다른 글
| 설계가 필요할까? (4) | 2011/12/22 |
|---|---|
| Software Architect를 양성하는 나라 (10) | 2011/12/19 |
| UML전문가가 설계전문가? (6) | 2009/04/15 |
| 코더(Coder)의 비애 (6) | 2008/11/24 |
Trackback Address: http://allofsoftware.net/trackback/248
좋은 말씀이시네요.
사내에서 역량강화 혁신이랍시고 추진하는 과제에서...
1년차 사원을 SA과정에 내 몰고서는 실적 달성.이라고 써놓은거 보고........
휴..
사장님이라고 SA가 교육으로 만들어지는게 아닌건 아실텐데 말이죠.
안녕하세요. hoony님
사장님이 잘 모르실 가능성이 99%입니다. ^^
잉여가 없어서 그런게 아닐까요? 여유가 있다면 좀 더 좋은, 좀 더 발전적인 결과물이 나올텐데요. ^^
안녕하세요. 미물님
환경과 저변이 척박하기 하죠.
왜들 이렇게 뭐든지 인위적으로 만들려고 하는지 모르겠습니다. 결국 내용은 보지 않고 겉모습만 보고 따라가려고 하는데에 있지 않나 싶네요.
Jake님 오랫만입니다.
CMMI인증이 대표적인 사례중 하나 아닐까요?
줄기차게 SRS의 중요성을 말씀하시네요. 그리고 SRS의 전파는 하루 아침에 이루어지지 않는다. 지속적인 자기혁신이 필요하다. 일부 학교에서 SRS 쓰기과정이 있다고 하는데...
SRS를 잘 쓰는 법 좀 가르켜 주세요.
어떤 문제를 내고 거기에 SRS양식에 맞춰서 보내봐라...그러면 거기에 첨삭을 한다든지 등의....
답답한 마음에 적어봤습니다.
안녕하세요 똥꽃님
SRS 작성은 소프트웨어를 개발하는데 가장 중요하면서 가장 어려운 일입니다.
피아노 잘치는 법, 골프 잘치는 법을 한마디로 가르쳐 줄 수 없듯이, SRS도 마찬가지 입니다.
SRS는 예제가 아닌 실제 프로젝트에서 작성을 해봐야 그 경험이 도움이 됩니다. 가상 프로젝트는 별 도움이 안됩니다. 실제 프로젝트에서 코치가 리뷰를 해주는 것은 도움이 많이 됩니다.
SRS Template를 이용하는 것은 도움이 되지만 Template만 가지고는 절대로 제대로 작성하지 못합니다.
KAIST 소프트웨어 전문가 과정에서 Requirement Engineering 과목에서 SRS 작성법을 가르쳐 줍니다. 국내에서는 거의 유일할 겁니다. 해외에서도 과정은 찾아보기 쉽지 않습니다. 교육과정으로 배우기 어렵기 때문입니다.
점점 더 어렵게 느껴지나요? ^^
결국은 돈주는 갑의 경영자만 만족시키면 끝나는 겁니다.
그들이 엉겁결게 기억하는 특수한 단어(?) 몇 개를 사용해서
이렇게 된다!
라고 말해주고 그들이 이해하면 만사 OK죠.
별로 어려운거 없습니다.
기술? 따위는 필요가 없지요.
코더 몇명 데려다 밤샘시키면서 관리감독만 하면 끝! ㅎㅎ
안녕하세요. 우냐냥님
옳은 말씀입니다. 그것이 우리나라에서 돈버는 좋은 방법입니다. ^^
목표가 뭐냐에 따라서 방법이 달라집니다. 제대로 해볼려고 하면 제대로 된 방법이 필요하죠.