IT에서 잘못 통용되는 내용(1문 1답)

IT에서 잘못쓰는 표현들에 대하여 1문 1답 형식으로 간단히 작성해본다.

가끔 IT 담당자들하고 이야기 하다보면, 답답하거나 말문이 막히는 경우가 생긴다. 때로는 고객이 때로는 협업 당자사자가 이런 소리를 하면 할만이 없어진다. ㅠㅠ 때로는 그런 사람에게 개념 설명하느냐 힘을 빼는 경우가 생긴다.

밑에 내용은 1문 1답 식으로 작성한 내용이다. 지극히 사견이니 오해는 없길 바란다.

이미지는 문제되면 삭제하겠습니다. 댓글 주세요~

---

CMMI Level 3 인증을 받은 제품일 것 

→ CMMi는 조직의 성숙도를 확인하는 부분이므로 인증받은 제품이라기 보다는 인증받은 조직에서 만들어낸 제품이라는 것이 더 적합하다.

공공기관 납품 시 GS인증 2등급은 가산점이 있다. 

→ GS인증은 당초 등급이 없었으며, TTA 주도로 행정안전망 등록에 대한 사항을 통합하면서 2등급이 생겼다. 2등급에 대한 지원 체계는 다시 확인할 필요가 있다.

PMBOK 5th에는 9개의 지식 영역이 있다. 

→ PMBOK 4th에서 5th으로 이동하면서 이해관계자 관리를 재배치하면서 새롭게 구성했다. 그러므로 5판은 10개 영역으로 구성되어 있다.

SP인증을 받으면 개발 완성도가 높아진다. 

→ 단적으로 보면 그렇다라고 볼 수 있겠지만, 프로세스라는 것이 준수하지 못하면 있으나 마나한 것이다. 표준화나 프로세스를 감사하는 조직이 있어야 어느정도 보증할 수 있다고 보여지나 그렇지 않은 조직은 반드시 실눈 뜨고 봐야 하낟.

CC인증을 획득한 제품을 납품하면 보안으로 안전하다. 

→ CC인증도 EAL이 존재한다. EAL은 해당 제품군이 가져야할 최소한의 가이드를 제시한 부분이므로 보안으로 안전하다는 관점보다는 인증받지 않은 제품 군보다는 취약하지 않다라는 표현이 적합하다.

PMO 조직이 있으면 프로젝트 관리가 수월하다. 

→ PMO의 운영 방법은 3가지로 구분해볼 수 있다. ① Weather station, ②Control Tower, ③Command Central이 있지만, 대개 한국 문화에서는 3번째 방법이 맞다고 한다. 하지만 문화가 바뀌고 전략이 바뀌고 있는 이 시점에 3번 방법이 맞다고 보는 것은 시대의 역행하는 발상이다.

개발 완성도를 높이기 위해서는 확실한 도구가 지원해야 한다. 

→ 일부 맞다. 하지만, 프로세스나 정책, 전략 없이 도구의 도입은 무의미하다. 오히려 독이 될 수 있다. 생산성을 높이는데에는 도움이 될 수 있다. 하지만 소프트웨어에 Silver Bullet은 존재하지 않는 법이다.

Jenkins는 형상관리 도구이다. 

→ 실제 어떤 개발자가 형상관리 도구라는 이름으로 제안서를 쓴 것을 보고 뒷골이 먹먹해지는 기분을 느낀적이 있다. 빌드나 릴리즈에 포커싱되어 있는 도구이고 형상을 수집하여 배포되는 관점이므로 CI에 가깝다고 이해하는 것이 맞다.

개발에 있어 자격증은 필수이다. 

→ 자격증이 단적인 어필용으로는 적합할 수 있으나, 실력 전체를 대변할 수는 없는 것이다. 반드시 자격은 표면으로 이해해야 하며, 실력은 경력에 매핑하여 이애하는 작업이 필요하다.

얼마전 개발된 사이트를 유지보수 하는 것은 개발보다 쉽다. 

→ 만든 사람도 유지보수 하라고 하면 새로운 버그를 찾아낼 것이다. 반대로 이야기 하면 개발자는 시스템 개발 요구사항에 포커싱되어 있으므로, 유지보수의 요구사항과 동일하다고 볼 수 없다. 개발 단가가 100만원인데 실제 유지보수에 대한 비용은 400만원 이상 소요되는 사례들도 있다.

다른 사업의 RFP를 차용해서 우리 시스템을 개발하면 완성도가 높을 것이다. 

→ 공공사업을 잘 살펴보면 RFP를 옮겨 자기것화 하려는 경향이 있다. 물론 RFP를 작성하면서 고민하고 정교하게 작업을 해놓은 것이 도움이 될 수 있다. 하지만, 적용 기술이 시스템마다 동일할 수 없다. 막연한 요구사항은 프로젝트에 악영향을 끼친다.

웹접근성 및 호환성, 크로스 브라우징을 준수하면 모든 디바이스에서 잘 표시된다. 

→ 일부 맞다. 하지만, 전체를 담보할 수 없다. 시스템의 완성도가 준수율로 가늠하기 어려운 것과 같이 현존하는 모든 것에 완벽하게 대응한다고 말하기 어렵다.

프로젝트에서 감리를 받아서 우리 프로젝트는 완성도가 있다. 

→ 감리가 프로젝트 투입되면 주로 하는 일이 사업관리, 데이터베이스, 아키텍처, 테스트 영역을 살피는데 이럴 경우 테스트는 전체를 대상으로 하지 않는다. 실제 감리가 끝난 프로젝트도 사용자들의 불만이 폭주하는건 완성도가 높다고 볼 수 없다는 이야기이다.

개발 및 테스트 지원도구의 구매는 사치다. 

→ 툴을 무작정, 단방향적으로 구매하는 것은 잘못된 일이다. 하지만, 필요성에 대한 충분한 검토가 일어난다면 필요한 툴이 있다. 보안이나 성능적인 측면은 오픈소스로 확인함에 한계가 있다. 반대로 spot성 SI의 경우 테스트 자동화는 불필요한 작업일 수도 있다. 잘 가늠해야 한다.

회사에 타이거팀이 있어서 우린 무슨 일이든 해결할 수 있다. 

→ 타이거 팀의 제대로된 개념을 살펴보자. 제대로 프로젝트 구성원으로 돌아가고 있다면 타이거팀은 필요없다. 뭔가 문제가 있고 느리고 지연되고 있으니 타이거 팀이 투입되는 것이다. 프로젝트 발주자 관점으로 이해하면 투입인력을 살펴보자. 꼭 슈퍼맨이 투입되는 경우가 있다.

우리회사는 FP로 공수를 산정하고 있어 견적 유사도가 높다. 

→ 폐쇄적인 RFP를 보고 기능점수를 도출하는 것이 오히려 맞지 않는 이야기일 수도 있다. legacy가 존재하는데 보안사항으로 보여줄 수 없지만, 이번에 수행하는 시스템은 legacy의 모든 기능을 포팅해야 한다고 한다. 그런 RFP에 얼마나 정확한 FP가 나올까? 단언컨데 100번 바뀔 수 있는 사항이다.

우리는 아키텍트와 QA가 프로젝트에 비상주로 투입한다. 

→ 아키텍트가 비상주 투입된다는 것은 말그대로 겉핥다가 나올 것을 예언하는 일이고, QA가 비상주로 투입된다는 이야기는 spot 성으로 확인한다는 소리다. QA와 test를 구분하지 못하는 누군가는 그래도 되는 줄 알고 넘어간다. 그게 맞고 통상적이라 생각할 것이다.

시스템에 다양한 도구를 구현하면 사용성이 올라간다. 

→ 사용성과 도구의 구현과는 반하는 일이되거나 관계 없는 일이 될수도 있다. 리포팅툴로 간단한 화면을 모두 표시한다면, 1초에 표시되는 화면을 3~4초에 표시하는데 이런 결과가 의도된 결과라고 볼 수 없다. 3rd party tool은 시스템의 속성을 따라가지 못하는 경우가 많다. 시스템 전반에 웹 접근성을 감안했으나 3rd party tool을 그렇게 되지 않은 가능성이 높다.

제안서에 우리회사의 인력의 70%이상은 개발인원이다.라고 쓴다. 

→ 투입인력을 살펴볼 필요가 있다. 특히 SI의 경우에는 GAP을 많이 둔다. 개인에게는 초급을 중급으로, 할수 없는 일을 했다고 쓰는 경우가 많다. 분명히 옳지 않다. 근데 그런것이 관행이고 우리의 수준이다.

Written By 밤의카사노바