(공공 부문) SW사업 대가산정 가이드 (2015년 개정판) 재공표

한국소프트웨어산업협회(www.sw.or.kr)에서 재공표한 SW사업 대가산정 가이드 (2015년 개정판)을 소개합니다.

올해 5월 4일 공표되었던 'SW사업 대가산정 가이드(2015년 개정판)'에서 일부 명칭을 개정하여 재공표합니다. 그 동안 ’노임 단가‘라는 용어의 부정적인 뉘앙스를 개선하고자 하는 의견이 수렴되어 ‘14년 명칭 공모 후 ‘소프트웨어 기술자 평균 임금’이란 용어로 변경하였습니다. 향후 법 개정을 통하여 해당 명칭을 반영하고자 하오니 참고하시기 바랍니다.

자세히 보기 →

요약기반 대규모 소스 코드 유사성 평가

소프트웨어의 개발이 활발해짐에 따라 소스코드 복제 , 도용이 증가하고 있으며 , 이로 인한 분쟁도 증가하고 있습니다 . 따라서 소스코드 복제에 대한 유사도 검사 또한 매우 중요시되고 있습니다 . 개발 시간 단축 , 성능 향상을 위해 소스코드 복제가 일어나고 다른 기업 , 개인 간의 분쟁을 유도하게 됩니다 . 분쟁을 결정짓거나 사전에 방지하기 위해 소프트웨어 유사도 검사가 필요합니다 .

유사성을 측정하는 기존의 도구는 대부분 텍스트 / 토큰 비교 [1, 2, 3, 4] 방법을 사용합니다 . 텍스트 / 토큰 비교는 소스코드의 텍스트나 토큰을 나열하여 비교하는 방법으로 다른 비교 방법에 비해 수행속도가 빠르다는 장점이 있습니다 . 하지만 기존의 툴들은 불필요한 소스 코드에 대해서 잘못된 유사성을 감정하는 한계가 있습니다 . 예를 들어 프로그램 개발 툴에 의해 자동으로 삽입된 소스코드 , 주석 , 변수 선언문의 위치 등은 유사도 측정에 있어 방해요소가 될 수 있습니다 . 대규모 소프트웨어의 소스코드를 그대로 비교하면 수행시간의 증가로 인해 기존 툴에 직접 사용하기에는 어려움이 있습니다 . 또한 소스코드를 도용 시 소스코드를 의도적으로 변형을 하게 되면 복제한 소스코드이지만 검출도구에서는 유사하지 않다고 판단 할 수 있습니다 .

1. 대규모 소프트웨어의 유사도 검사 방법
2. 소스코드 요약 기법과 유사도 비교 방법
3. 대규모 소프트웨어의 유사성 비교

자세히 보기 →

사용자 경험 (UX) 과 품질 관리 (QA) 에 따른 사용성 확보

- Key Message -
SW 사용성 (usability) 은 SW 사용자 입장에서 원하는 기능과 서비스를 손쉽게 찾아서 활용할 수 있도록 기능을 제공하는지를 의미합니다 . 최근 들어 SW 사용성은 SW 가치의 중심축 역할을 함에 따라 애자일 개발에서는 전체 개발팀이 제품의 사용성을 함께 고려하는 것이 중요합니다 . 따라서 여기서는 사용자 경험 (UX) 와 품질 관리 (QA) 측면에서 사용성 확보를 위한 기획 - 개발 - 테스팅 - 배포 등의 단계별 고려사항을 제시합니다 .

애자일 개발의 네 가지 단계별 고려사항
 1. 기획 (Research)
 2. 개발 (Development)
 3. 테스팅 (Testing)
 4. 배포 (Release)

자세히 보기 →

최적의 클라우드 테스팅 툴을 찾아내는 4가지 Tip

- Key Message -

최근 SW 개발에 있어 클라우드 기반의 테스팅 툴은 이동성 , 확장성 , 유연한 가격정책에 의해 점차 부각되고 있습니다 . 이에 따라 클라우드 테스팅 툴에 대한 투자 이전에 고려해야 할 네 가지 팁을 제공하여 , 각 프로젝트 환경에 적합한 최적의 테스팅 툴을 확보할 수 있도록 도움을 주고자 합니다 .

클라우드 기반의 테스팅 툴은 이동성 , 확장성 , 유연한 가격 모델과 같은 이점을 제공하면서 소프트웨어 개발 산업을 이끌어 왔습니다.
테스트 전문조직들 또한 이러한 흐름에 편승하고 있으나 , 클라우드 테스팅 툴에 투자하기 전에 고려해야 할 네 가지 팁을 살펴보는 것이 유익합니다.

클라우드 테스팅 툴을 찾아내는 4가지 Tip
 1. 위험요소와 문제점 인식하기
 2. 최적의 서비스 선택하기
 3. 퍼블릭 클라우드 또는 프라이빗 클라우드 서비스 선택하기
 4. SLA 이해하기

클라우드 테스팅 툴 7선

자세히 보기 →

빅데이터를 적극 활용하게 만드는 7가지 툴

거대하고 다양한 정보가 축적되는 빅데이터는 비즈니스 인텔리전스분야에서 그 중요성이 더욱더 크게 부각되고 있음. 오픈소스 하둡이나 NoSQL기술을 기반으로 한 제품을 공급하는 업체들의 기술은 빅데이터를 수집하고 관리하는데 용이하게 하며, 유저가 원하는 정보를 보다 쉽게 생성할 수 있도록 해줍니다.

　　

특히, 하둡은 빅데이터 활용에 있어 안정적이고 확장이 용이한 분산컴퓨팅 환경으로 현재 널리 사용되고 있습니다. 기업의 정보를 최대한 활용하여 비즈니스를 향상 시킬 수 있는 빅데이터 리포팅, 분석, 시각화, 통합 등을 구현하는 하둡을 적극적으로 활용할 수 있게 만드는 7가지 툴을 소개합니다.

재스퍼소프트 BI 스위트(Jaspersoft BI Suite) 

• 재스퍼소프트 패키지는 데이터베이스로부터 리포팅(Reporting)을 생성하기 위한 오픈소스 비즈니스 인텔리전스 분석 툴 중 하나임

펜타호 비즈니스 애널리틱스(Pentaho Business Analytics)

• 재스퍼소프트처럼 펜타호는 리포팅 생성 엔진으로 시작한 오픈소스 비즈니스 인텔리전스 툴임

카르마스피어 스튜디오와 애널리스트(Karmasphere Studio and Analyst)

• 카르마스피어 스튜디오는 이클립스(Eclipse) 상위 레이어에 구축된 플러그인으로, 하둡 작업 수행에 특화된 솔루션임

탈렌드 오픈 스튜디오(Talend Open Studio)

• 탈렌드는 하둡의 데이터 처리 작업을 위한 이클립스(Eclipse) 기반의 그래픽 유저 환경을 제공하며, 탈렌드의 툴들은 데이터 통합, 데이터 품질 관리들을 원활하게 처리하기 위해 설계됨

스카이트리 서버(Skytree Server)

• 스카이트리 서버는 더욱 정교한 기계학습(machine-learning) 알고리즘을 수행하는 번들을 제공함

타블로 데스크톱과 서버(Tableau Desktop and Server)

• 타블로 데스크톱은 유저가 새로운 방식으로 데이터를 처리할 수 있게 하는 시각화 툴로 이 툴은 유저가 자신의 데이터와 다른 데이터를 합쳐 또 다른 관점에서 기존의 데이터를 검토해 볼 수 있는 장점을 지니고 있음

스플렁크(Splunk)

• 스플렁크는 엄밀하게 말하자면 리포팅 생성 툴이 아니라 데이터를 분석, 인덱싱하는 솔루션으로 방식은 텍스트 검색 프로세스에 더 가까움

자세히 보기 →

다중 SW개발 프로젝트 관리를 위해 갖추어야 할 9가지 테크닉

SW개발 PM들은 보통 2가지 이상의 프로젝트를 책임지고 있습니다. 여러 SW개발 프로젝트를 효과적으로 관리하는데 도움이 될 관리기술로 4가지 비공식적인 기법과 5가지 공식적인 기법을 살펴보도록 하겠습니다. 이러한 기법들은 기존에 모두 존재해 왔고 관리자 대부분이 잘 알고 있으나, 이의 실제 활용을 통해 크고 복잡한 프로젝트를 리드할 경험을 지니는 데 조금이나마 도움이 되고자 합니다.

비공식적인 기법

1. 신뢰할 수 있는 정보원을 가질 것
2. 고객에게 우선권이 있다는 것을 명심할 것
3. 상호 의존하는 것을 배울 것
4. 시간 관리를 철저히 할 것

공식적인 기법

1. 표준화된 공용 보고서를 사용할 것
2. 비용관련 수치들을 주시할 것
3. 프로젝트 주요 진행사항은 문서화 할 것
4. 지속적으로 의사소통할 것
5. 결정은 신속하게 할 것

동시에 다중 프로젝트를 관리하는 것을 통해 향후 크고 복잡한 프로그램 프로젝트를 이끄는데 필요한 경험과 지혜를 발전시킬 수 있다는 긍정적인 측면에서 접근하는 자세가 매우 중요함에 따라 상기 제시된 여러 가지 방법을 활용하여 프로젝트를 성공적으로 이끌 것으로 기대합니다.

자세히 보기 →

12명의 Architect에게 물어 본 “아키텍트의 길” part 1

요구사항분석 , 프로세스와 팀 빌딩 , 설계 시 고려사항

요구사항

모든 요구 사항을 수렴하는 소프트웨어는 존재하지 않는다 . - Mark Richards

전 프로젝트를 시작할 때 항상 꺼내는 이야기가 있습니다 . 소프트웨어 아키텍트 들이라면 알아야 하고 , 이해해야 하며 , 그리고 고객 , 동료와 함께 꼭 프로젝트 시작 전 나눠야 하는 이야기가 있습니다 .

1620 년대에 스웨덴과 폴란드의 전쟁에서 나온 ‘Vasa 호 ’ 라는 배 이야기입니다 . 스웨덴 국왕은 전쟁을 빨리 끝내기 위해 Vasa 호라는 특별한 배를 만들라고 주문했습니다 . 이 배가 갖춰야 했던 조건 ( 요구사항 ) 들은 그 당시의 어떤 배와도 비교할 수 없었습니다 . 선체가 200 피트 정도 더 길고 , 2 개의 갑판에 64 개의 총을 적재할 수 있고 , 300 명의 군사를 안전하게 태워 폴란드로 가는 바다를 가로지를 수 있는 수송 능력을 가져야 했습니다 . 배를 건조하는 데드라인 ( 시간 ) 을 엄수해야 했으며 , 재정 ( 자금 ) 적으로도 여유롭지 않았습니다 . 또한 배 설계자 ( 아키텍트 ) 는 이렇게 생긴 배를 이전까지는 설계한 적이 없었습니다 . 크기가 작고 총을 실을 수 있는 갑판이 한 개만 있는 배를 만드는 것이 그가 주로 한 일이었습니다 . 그럼에도 불구하고 , 설계자는 그의 예전 경험을 기반으로 추정하고 Vasa 를 설계하고 건조하기 시작했습니다 . 그 배는 결국 설계대로 건조되었고 마침내 배를 출항하는 날이 왔습니다 . 어떻게 되었을까요 ? Vasa 호는 위풍당당하게 항구를 출항했지만 예포를 쏘고 난 뒤 바로 바다 저 밑으로 가라앉고 말았습니다 .

Vasa 호의 문제는 명확합니다 . 그 어느 누구도 1600~1700 년에 큰 전투함에서 갑판을 본적이 없었고 이러한 배의 갑판은 특히 전쟁 중에 붐비고 안전하지 않다는 것을 알았습니다 . 전투함과 운송선 2 개의 역할을 다하는 하나의 배를 건조하는 것은 큰 실수였죠 .

국왕의 모든 소원을 충족하려고 한 배 설계자는 균형이 맞지 않고 , 불완전한 배를 만들 수밖에 없었던 것입니다 . 저희 소프트웨어 설계자들은 Vasa 호로부터 많은 것을 배울 수 있습니다 . 이와 같은 불행한 사건을 소프트웨어 아키텍처의 설계에 적용할 수도 있겠죠 . 하지만 Vasa 호와 같이 모든 요구사항을 충족시키려는 시도는 궁극적으로 아무것도 수행할 수 없는 불완전한 아키텍처를 만들게 됩니다 .

프로세스와 팀 빌딩

가장 큰 문제는 기술이 아니라 기회를 잡을 수 있느냐 이다. - Mark Ramm4)

대부분의 프로젝트들은 사람에 의해 만들어지며, 사람들은 성공과 실패에 대한 기반이 됩니다. 따라서, 사람들을 성공할 수 있게 만드는데 도움이 되는 것에 대해 생각해 볼 필요가 있습니다. 한편으로는, “단지 일을 올바로 하지 않고” 프로젝트를 어렵게 하는 누군가가 있다는 가망성에 대해 충분히 생각해 볼 수 있습니다. 이러한 경우들에서 문제를 해결하는데 필요한 기술은 매우 오래되었지만 정말 잘 입증되었습니다. 사실 이 기술은 인류의 역사에서 가장 중요한 기술 혁신일 것입니다. 여러분에게 필요한 것은 대화입니다. 기교로써 대화에 단지 익숙해지는 것만으로 충분하지 않습니다. 존경심을 가지고 사람을 대하는 것을 배우고, 사람에 대한 성급한 판단을 버리는 것을 배우는 것이 영리한 아키텍트가 유능한 아키텍트로 변하는 핵심 기술 중에 하나입니다.

설계

불확실성을 설계의 지표로 사용해라! - Kevlin Henny7)

여러분이 설계 시 둘 중 하나를 선택해야 한다면 대부분은 중요한 것을 선택합니다. 하지만 설계(소프트웨어 또는 다른 것들) 시에는 그렇게 해선 안 됩니다. 두 가지 선택사항이 존재한다는 것은 설계 시 불확실성을 고려할 필요가 있다는 것은 알려주는 지표(indicator)입니다. A와 B 두 가지 중 하나를 결정하려고 시도하는 것보다는 A와 B 사이의 결정을 덜 중요하게 만들기 위해 어떻게 설계해야 할지를 고민해야 합니다. 흥미로운 것은 A와 B 사이의 (적절한) 선택이 존재한다는 것입니다. 설계 시 변경되는 결정을 쉽게 수용할 수 있는 분할(separation) 또는 캡슐화 기법을 고민할 필요가 있습니다.

자세히 보기 →