All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다.
RSS Feed
안녕하세요, 다시 CC인증에 대해서 이야기를 시작하려고 합니다. 제가 마지막 포스트를 한 것이 2008년 11월 이니까 거의 1년 반을 쉬게된 셈이네요.
다시 한번 심기일전하여 포스트를 해보록 하겠습니다.
마지막 포스트 이후 그간 많은 것들이 변했지만 4/30(금)에 열린
품질인증 컨퍼런스를 통해 국내 CC인증 평가 제도가 많이 변경이 된 것을 알 수 있었습니다. 오셔서 직접 듣고 보신 분들도 계시겠지만 그 변경된 제도를 다시 한번 정리해보고 실제적으로 어떤 의미가 있는지, 앞으로는 어떻게 예상이 되는지를 한번 알아보려고 합니다. (이 포스트는 평가기관 어떠한 관계도 없음을 알려드립니다.)
변경 승인 절차 간소화
이전에는 CC인증을 받은 평가 제품이 변경이 일어나 인증 효력을 유지하기 위해 변경 승인을 신청할 때 인증기관(
국정원 IT보안인증사무국)으로 연락(전화)하여 필요한 서류와 제출물들을 준비하여 제출하면 인증기관이 해당 제품을 평가한 평가기관으로 평가 의뢰를 하는 식으로 진행이 되었었습니다.
그러므로 인해서 업체에서는 하루라도 빨리 변경 승인을 받은 후 제품을 배포해야 하는데 인증기관이나 평가기관의 다른 많은 업무들로 인해서 지연되는 경우가 있을 수 있었습니다.
그러나 이번에 변경되어 현재 시행하고 있는 "변경 승인 절차의 간소화"는
변경 승인 신청을 평가를 받은 평가기관으로 하게되어 중간 인증기관으로 했던 절차를 없애버린 것입니다. 평가기관은 변경 승인 신청을 받아 가능하면 해당 평가 제품을 평가한 평가자에게 직접 변경 승인 평가를 담당하도록 합니다. 해당 평가자가 다른 제품 평가를 진행 중에 있어도 변경 승인을 동시에 평가 진행하여 신청 업체는 바로 변경 승인 절차(평가)에 들어 갈 수가 있는 것입니다.
★ 요즘에는 민간 평가 기관들이 많이 있기 때문에 한 회사에서도 여러 평가 기관과 평가 계약을 맺고 평가를 진행하는데, 평가 신청 업체에서는 향후 이러한 변경 승인까지 고려한 제품의 유지보수를 계획해야만 시장에 발빠르게 인증 제품을 유지 할 수 있을 것입니다.
EAL2 평가자 간소화: 2명 -> 1명
이전에는 평가 제품에 따라 다르기는 하지만 보통 2명의 평가자가 배정되어 4-8개월 평가를 진행했었습니다. 그러다가 평가기관의 평가자가 평가 수요에 미치지 못하자 "3인 2평가반" 이라고 해서 1명의 "선임평가자"는 2개의 평가반에 걸쳐 각 평가반에 있는 1명의 평가자와 함께 평가를 진행하도록 개선안이 나왔었습니다. 그러는 가운데 1-2개의 민간 평가기관이 더 생기면서 이 제도가 아예 없어진 것은 아니지만 크게 영향을 미치지는 못했습니다.
그리고 근래에는 평가 등급이 EAL2 이상으로 다양한 등급으로 평가를 받는 제품들이 늘고 있습니다. 이것은 공공기관에 도입되는 제품은 EAL2 이상이면 된다는 정책으로 인한 것인데요, 현재 방화벽은 보호프로파일의 의도와 같이 공공 기관의 중요한 장비인 만큼 EAL4로 받고 있고, 그와 같은 중요 장비라고 판단되는 것은 수요 기관에서도 EAL4 정도의 등급을 원하고 있습니다만, 그 외 제품들은 시장 상황에 맞추어 EAL3 부터 EAL2 도 점차 많아지고 있는 추세 입니다.
보통, 국내 평가 제도인 경우 (제품에 따라, 평가 기관에 따라 다르지만) EAL4인 경우 5개월, EAL3는 4개월, EAL2인 경우는 약 3개월 정도 잡았었습니다. 물론 대강 그렇다는 것이고, EAL2 였어도 평가자 2명이 3개월은 족히 걸렸습니다. 물론 제품의 복잡도에 따라 다른 것은 당연하고요.
그러는 가운데
EAL2 등급의 평가 담당자를 2명에서 1명으로 줄인 다는 것은 기간을 줄인다기 보다는 평가 비용(수수료)를 줄인다는 의미로 받아들여집니다. 그렇다고 수수료 비용이 1/2로 줄어드는 것은 아닐 것입니다. 그렇다면 평가자 인건비 정도해서 수수료가 줄어들 것 같습니다. 이날 KISA 이강석팀장의 발표에 있어서도 27%의 비용이 감소할 것이라고 하는데 그것은 최소 순수 평가 수수료에 해당하는 것 같습니다. 물론, 앞으로 설명할 평가 제도가 변경되었기에 1인 평가가 가능할 것이고요.
★ 그렇다면, 평가 신청 업체의 비용은 수수료 외에 비용이 절감 되는 것은 없을까요? 실제로 업체가 느끼는 비용의 감소가 있을까요? (평가 수수료가 기간에 비례하기 때문에) 오히려 평가자가 1명이면 기간이 늘어나서 평가 수수료도 같이 늘어나지 않을까요? 2명이 하던 일을 1명이 해야 하니까요. 그러나 앞서 말씀드렸듯이 이것은 평가 제도가 변경이 되었기 때문에 가능한 것이라 생각됩니다. 실제로 평가 기간과 EAL2 등급의 평가 신청을 했는데 3개월이 넘지 않는 것으로 이야기가 되어 가고 있는 것을 보면 어느정도 비용 감소 부분은 반영이 되고 있는 것 같습니다. 그러나 이는 철저히 평가 제품의 복잡도 측면에서도 고려가 되어야 합니다.
제출물 간소화
가장 즁요한 변경 사항입니다. 이 부분이 아직까지는 변경된 평가 제도로 평가를 진행해 보지 않아서 정확히 실제적으로 얼마나 간소화가 되어 준비하는 업체가 피부에 느낄 수 있는 제도 개선인지 알수는 없습니다만 어떤 부분이 변경이 되었는지 간략히 살펴보겠습니다.
우선 개념은, 기존에 제출했던 보증 문서들을 평가하는 것이 주였다면
변경된 제도에서는 기능/취약성 중심의 평가로 제출물을 간소화 하겠다는 것입니다. 다음은 EAL4 기준으로 제도 개선 후의 제출물의 변경 사항입니다.
출처: 2010 품질인증 컨퍼런스 발표 자료 (KISA)
보안목표명세서(ASE_*):
- 제출/평가 동일
- TOE의 범위가 모든 제품으로 확대 서술
- 비보안기능과 보안기능 연관 인터페이스도 포함
설명서(AGD_*):
기능명세서(ADV_FSP.4)
- 제출 안함
- 보안목표명세서(TSS: TOE 요약 명세)와 설명서도 대체
TOE 설계서(ADV_TDS.3)
- 제출 하지만 평가 안함
- 제출은 CC인증 문서가 아니가 신청 업체 자체 문서 가능
- 평가시 (취약성 분석 등) 제품 파악을 위한 참고
- 참고를 위해 추가 제출 요청이 있을 수 있음
구현검증명세서(ADV_IMP.1)
- 제출/평가 동일
- 기존 처럼 EAL4 경우 일부 제출
보안구조서(ADV_ARC.1)
- 제출 안함
- 취약성분석서로 대체 (추가 제출분)
시험서(ATE_*)
- ATE_COV.2(범위) 나 ATE_DPT.2(깊이) 같은 분석서는 제출하지 않고 평가자 직접 수행
- ATE_FUN.1에서 요구하는 시험서(기능/모듈) 제출/평가
- 대신 내용 중에 "예상 결과"와 "실제 결과" 중 "실제 결과"는 생략 가능 (화면 캡처 필요 없음)
형상관리문서(ALC_CM*)
배포문서(ALC_DEL.1)
개발보안문서(ALC_DVS.1)
생명주기정의문서(ALC_LCD.1)
개발도구문서(ALC_TAT.1)
* 개발환경 보안 점검의 유효 기관은 이전과 동일 2년 (그간 환경의 변화가 없을 시)
개발자 취약성분석 서(AVA_VAN.3)
- 제출/평가
- 이전 제도에는 제출하지 않고 평가만 했으나 제출하는 것으로 변경
- 위 "보안구조서"에 취약성 항목 추가하여 제출
- 분석의 범위는 EAL4 경우 소스코드 까지
제출물들만 보자면 분명히 간소화가 된 부분이 있습니다. 실제 평가 계획도 문서 평가 보다는 시험위주로 하는 것으로 보아 신청 업체로서는 문서에 대한 부담이 줄었습니다.
신청 업체가 준비하는 문서 중 가장 많은 비중을 차지 할 수 밖에 없는 (그래서 시간이 많이 걸렸던) "설계서"는 평가를 하지 않지만 제출(내부 설계서를 그대로라도)을 하므로, 이것은 신청 업체의 개발 문화에 따라 많이 차이가 날 것으로 판단이 됩니다. 기존에 개발 문서가 잘 되어 있는 회사에서는 이를 인증 문서로 "재작성" 하지 않아서 확실히 제출 문서 작업의 양이 줄겠지만 그마저 없는 회사의 경우는 회사 전체로 보았을 때 준비해야 하는 문서는 그리 차이가 나지 않을 것입니다. 물론 평가 시, 보완 요청(OR: Observation Report)을 받지 않는 것은 개발 문서가 있던지 없던지 상관 없이 문서에 대한 부담이 준 것은 사실이고요.
그러나 설계서 또한 평가자가 평가의 이해를 위해 얼마든지 추가 요청을 할 수 있어 이 또한 평가 시 업체의
개발 문서를 작성하는 개발 문화에 따라 업무량이 많이 판가름이 날 것 같습니다.
★ 그렇다고 한다면 예상 하셨듯이,
개발 프로세스(문화)가 역시 국내에서 CC인증을 받을 때 더 지대한 영향을 주 수 밖에 없습니다.
국내 CC 인증 평가가 기능/취약성 시험 위주로 간다는 것은 그만큼 제품의 보안성/안정성이 큰 문제가 될 수 있게 되고 이것의 결과는 개발 문화의 차이가 벌여 놓을 것이기 때문입니다.
그리고 한가지 평가의 경향이 기능/취약성 시험 위주로 간다고 하지만 거꾸로 평가를 통해 공개되는 문서인 "보안목표명세서"와 "설명서"는 더욱 더 세밀하게 평가하고 보완요청을 하고 있으니 더 잘 준비해야 할 것입니다.
보안성 강화
이것은 기존에 CC의 개념에서 제공하고 있는 것 중 TOE(평가 대상)의 범위를 개발 업체가 지정할 수 있었던 것을 아예 없애고 "TOE = 제품" 이라는 논리로 개발 업체가 임의로 선택할 수 없음을 의미합니다. 즉, 사용자에게 제공되는 제품 (더 정확히는 패키지, 설치본, 장비) 그대로 모두 다 평가를 받아야만 한다는 것입니다.
게다가, 보안 기능 뿐만 아니라 비보안 기능 까지도 기능/취약성 위주의 평가를 해야 하기 때문에 제품이 제공하는 모든 기능을 시험해야 하며, 추가적으로 (여기에 대해서는 상황도 다양하고 논의가 되어야 할 부분이 많은데) 비/보안 기능의 외부 3'rd party 프로그램 (혹은 같은 회사의 제품) 간의 인터페이스 또한 어떤 식으로든 시험이 되어야 한다는 것입니다.
★
요즘 보안 제품의 특성은 융합/연동이기 때문에 이 부분은 잘못하다가는 배보다 배꼽이 더 커지는 불상사가 발생할 수도 있을 것입니다. 그리고
실제 취약성의 경우 이러한 인터페이스에서 주로 일어나고 있기 때문에 더욱 관심이 가는 부분이 아닐 수 없습니다. 그래서 이날 발표한 KISA의 선임평가자는 이러한 인터페이스의 SQL Injection과 같은 취약성 분석을 위해서 소스 코드 제출도 요청할 수 있다고 합니다.
이런 저런 측면을 다 고려한다면, 평가를 위해 제출해야 하는 제출물의 개수는 줄어 들 수 있겠지만 각각의 제출물의 양은 늘어서 비슷해지지 않을까 모르겠습니다.
CC 버전 호환성 강화
KiSA 홈페이지에 공지된 바와 같이 CC v2.3은 올해 6월 30일이면, CCv2.3으로는 평가 신청을 할 수 없었습니다. (기존 인증서는 계속 유지 가능) 변경승인은 그렇지 않은 것으로 알고 있었는데, 재평가도 신청을 하려면 모두 다 CC v3.1로 다시 신청을 해야 해서 자동으로 신규 평가가 됩니다.
그러나 변경된 제도에서는
이 둘 모두(변경 승인, 재평가 신청) CC v3.1로 재평가/변경승인을 그대로 할 수 있도록 그 호환성이 강화 되었다는 것입니다.
★ 그래도 문서의 CCv3.1로의 변경은 불가피한데, 이는 평가기관에서 발표하기로는 최소한으로 할 수 있도록 한다는 코멘트를 했습니다. 적어도 "보안목표명세서"는 수정이 완벽하게 되어야 하겠고 그 변경의 정도에 따라 (보안영향분석) 평가시 요청을 하겠지요.
그렇다면 이러한 제도가 재평가/변경승인 시에 어떻게 되는지도 궁금합니다.
적용 실행
전면 시행(반듯이)은 올해 7월 1일 부터 입니다. 그 전까지는 업체의 선택으로 할 수 있다고 합니다. 그리고 이날 발표에 의하면 "인증효력유지신청" 시 기 적용된 기준을 적용한다고 했는데 - 그렇게 된다면 기존에 개발 업체가 임의로 정한 TOE의 범위를 그대로 적용한다는 것인데 - 매우 관대하다 생각이 되어 한번더 문의를 했습니다.
기존 제도로 인증 받은 제품의 경우 재평가나 변경 승인 신청 시에는 TOE를 임의로 선택할 수 없다고 합니다. 그러니까 변경 된 후의 제도를 반듯이 (7월 1일 이후) 따라야 하는 것이지요. 제출 문서의 경우 기존의 것을 그대로 수용 한다는 취지로 그런 것이라고 하는데, TOE의 범위가 변경되면 "보안목표명세서"는 분명히 바뀔 것이고, 바꾸어야만 하는 것은 명백하고, 그리고 나머지 문서들은 변경된 제도에 의해서 제출하지 않는 것이 많은데 오히려 더 혼돈되는 것이 많을 것 같습니다. (제출하는 문서가 있고, 그렇지 않은 문서가 있고... 등) 아무튼 보안성 강화 측면에서의 재평가/변경승인은 어쩔 수 없는 것 같습니다. 이번 개선의 주요 변경 사항이니 말입니다.
그래서 이번 제도 개선이 문서의 측면 보다는 TOE 범위의 확대(전체)에 따른 보안성 개선이 개발 업체에게 더욱 큰 부담으로 돌아오지 않을까 합니다. 문서 위주 였던 이전 보다 더욱 실제적인 부담이기를 바라고 또 시장의 요구사항과의 충돌이 아니라,
전체 사용자 측면의 개선도 같이 이루어 지면서 개선되는 보안성 측면이라면 발전 가능성이 있어 보이기도 합니다.
굵게
★ 사용자의 보안 측면과의 충돌에 대해서는 다음에 더욱 자세히 알아보도록 준비하겠습니다. 이것이 중요한 이유는 보안이라는 것은 개발 업체만 "완벽한" 보안 기능 제품을 만든다고 이루어 지지 않기 때문이라는 점을 누구나 다 알기 때문입니다. 수요측(사용자)와 그리고 또 정책 기관 또한 못지 않게 중요하기 때문입니다. 특히 이러한 인증 시장에서는 오히려
사용자에게 교육이나 정책으로 가이드하고 개발 업체에게는 자육성과 창의성을 주어서 혁신적인 제품을 만들도록 하는것이 장기적인 국가 보안과 경쟁력에 도움이 되지 않을까 합니다.
평가 수수료 할인 계속
KISA는 평가 신청 업체가 중소기업법 제2조에 따른 중소기업이면 년 1회 50% 할인하는 정책은 유지할 것이라고 합니다.
현재는 3차년도로 올해 8월부터 201년 7월까지 인증 받는 것은 50% 할인이 됩니다. 한 회사에서 2차년도로 7월에 할인 받고 또 8월에 할인 받을 수 있는 것입니다.
★ 그러나 KISA는 정책적으로 국내 평가반을 줄이고 정책 연구나 고등급/국제 인증에 비중을 더욱 두므로 얼마나 많은 중소 기업이 이러한 혜택을 받을지는 모르겠습니다. 현재 국내 평가의 경우 대기기간(평가 신청 후, 평가 착수까지의 시간)은 민간 평가 업체들이나 KISA나 비슷한 것으로 알고 있습니다.
마치며
이번 제도 개선은 그간의 중복작업이니, 효용 없는 문서 작업이니 하면서 소위 "쓸 데 없는 짓"으로 치부 되었던 국내 CC인증 제도의 한 부분이었던
문서 평가 보다는 실제적으로 기능/취약성 시험 평가로 개선이 된 점은 보안성 측면에서는 더욱 좋아진 것은 사실입니다.
그러므로
평가자의 자질과 능력이 더욱 중요시 될 것입니다. 그래서 평가 기술 위원회가 이를 조정 할 것이라고 합니다만 이미 평가를 몇년간 진행해 왔고 인증 시장이 성숙해 있는 시점에서 어떻게 바꾸어 갈 수 있을지 귀추가 주목이 되는 부분입니다. 그리도 또한 평가를 하는 평가기관과 평가 받는 개발 업체에 대해서만 개선할 것이 아니라
사용자 측면에 있어서도 제도/정책적으로 개발 업체가 좀 더 혁신적인 방법으로 경쟁력을 갖도록 가이드 하는 것이 필요 할 것 같습니다.
그리고 국내에서는 CC 인증이 더 이상 공통평가기준(ISO/IEC 15408)과 멀어져 사용자-평가자-개발자가 공통의 기준으로 사용하고 평가하고 개발하는데 그 중요한 목적이 달성되지 않아 보안성 평가 측면에 있어서 퇴보를 하지 않을까 하는 우려점도 남습니다. 우리나라가 이 국제 공통평가기준을 도입하고 또한 그렇게 빠르게 CCRA(Common Criteria Recognition Arrangement)에 가입하는 노력이 허사로 돌아가지 않고 국내 제품들이 계속적으로 글로벌하게 해외 시장에 진출하는데 있어 일관된 기준이 적용되어야 경쟁력이 쌓이지 않을까 합니다.
막상 정리하다보니, 매우 긴~ 글이 되고 말았습니다. 여기까지 읽어주셔서 너무도 감사드립니다. 의문 사항이 있거나 잘못된 내용이 있다면 언제든지 관심어린 지적을 부탁드립니다.
davideung
인증
CC,
인증,
제도,
컨퍼런스,
평가,
품질
글 잘 읽고 갑니다. :D
안녕하세요. 우울한 딱따구리님...
요즘 워낙 바빠서 블로그 포스팅이 뜸해지네요.
그래도 언제나 글을 읽어주셔서 감사합니다.
개발과 관리를 둘 다 잘 하는 사람이 있으면 관리를 시키는 것이 낫지 않을까 싶습니다.
관리 잘 하는 사람이 많은 것 같아도 사실 개발자와 프로젝트를 관리 할 수 있는 관리자는 정말 뛰어난 개발자보다 더 소수가 아닐까 싶거든요.
이런 관리자가 있어주어야 그 밑에서 정말 개발만 잘 하는 사람들이 편하고 효율적으로 일 할 수 있지 않을까 싶기도 하구요.
안녕하세요. bookworm님
우리는 흔히 팀장과 PM을 혼동하곤 하는데, 위에서 언급한 내용은 팀장, 즉 일반관리자 역할입니다.
팀장은 관리자트랙인데 비해서 PM은 특수한 영역으로서 개발자와 관리자의 중간쯤에 있는 트랙입니다. 즉 개발도 잘 이해하고 관리도 잘할 수 있는 사람들의 영역입니다.
일반적인 작은 회사나 작은 개발팀은 전문적인 PM이 필요하지도 않고 관리도 그렇게 많이 필요하지 않습니다. 그냥 선임 개발자가 대춤 겸업을 해도 큰 문제가 발생하지 않습니다.
그래도 우리는 보통 마구 혼동해서 사용합니다. 하지만 규모가 커지기 시작하면 모든 영역이 매우 전문화가 되어야 합니다.
말씀하신 내용은 PM에 가까운것 같습니다. 프로젝트가 커지면 PM의 역할이 정말로 중요하고 뛰어난 PM이 프로젝트 성공에 가장 큰 역할을 하며 책임도 큽니다. 개발자중에서 PM 트랙을 선택하는 것도 좋은 선택중 하나라고 생각합니다. 단, 우리나라에서는 PM의 역할에 대해서 제대로 정의가 안된 회사가 많기 때문에 자칫 이직시 애매해지는 경우가 많은 것 같습니다.
아무튼, 아직 개발자, PM, 관리자에 대한 전문성에 대한 이해가 전반적으로 부족한 분위기는 차츰 바꿔나가야 하겠습니다.
말씀하신 부분에 공감합니다.
우리나라는 아직 일반 관리자, PM, 개발자 등의 역할이 전문화가 안 된 것 같습니다.
개인적으로 개발자로 하고 싶은 것이 많은데 일반 관리부터 PM까지 겸업하려니 고민과 갈등이 많습니다.
관리자라고 한다면 피플매니징이 주요 업무여야 한다고 봅니다. PM은 말 그대로 프로젝트만을 관리해야 하는 거구요.
예전까지는 팀장 = 관리자 = PM이었는데(종종 프로젝트에 따라서 PM이 아닌 경우는 있었지만), 외국계는 이 매니저와 PM이 확실하게 다른 캐리어 트랙을 타더군요.
안타까운 현실에 우울하죠.
몇 년 뒤면 이제 40이 되는데, 등 떠밀려 선택을 하게 되겠죠? ㅡ,.ㅡ;;
whiterock님 안녕하세요.
계속 개발을 하고 싶은 개발자들이 등떠밀려 관리자가 되는 것은 개인이나 회사에 모두 손해입니다.
본인의 의지를 회사에 피력을 해보시죠. 회사 사정은 정확하게 모르지만 시도를 해보시는 것이 어떨가요?
앞으로의 진로를 고민하는 사람으로 말씀하신 것처럼 문화가 바뀌기를 바라고 있지만, 현실적으로 한국 기업문화에서는 쉬운 부분은 아니라고 생각합니다. 저 또한 그렇게 만들고 싶고 그러기 위해서는 힘(?)이 있어야 하고, 힘을 가지려면 관리자가 되어야하니까요..아쉬운 현실입니다.
님께서 가지고 계신 가치관이 많이 전파되었으면 하는 바램입니다. 글 감사합니다.
꼬부가빠님 안녕하세요.
기업이 생존을 위해서는 어쩔 수 없이 이렇게 하지 않으면 안됩니다. 한국의 기업문화 그대로 따라서는 살아남을 확률이 너무 많이 떨어집니다.
변화는 선택의 문제가 아니고 생존하느냐 죽느냐의 문제입니다.
Postion 이라고 쓰신 부분이 Position 맞죠?
안녕하세요. godway님
당연히 오타죠. - -; 바로 수정했습니다.
외국에서는 10년 정도 개발하면 이제 조금 하는 구나
하는데 우리나라는 5년정도 개발하고 관리자로
빠지니 관리도 못하고 기술도 잘 모릅니다.
그러면서 기술은 중요하지 않다라고 하죠.
beyondj2ee님 안녕하세요.
10년차와 20년차가 또 다르죠.
그런데 우리나라 대부분의 SW 개발자들은 그 차이가 별로 없는 경우가 많습니다. 고참 개발자들이 신참과는 다르게 무슨 일을 어떻게 해야 하는지 모르는 경우가 대부분입니다.
우리나라의 대부분의 SW업체가 중소기업이지만....
워낙 작은 회사는 모든 구분이 참 애매모호합니다.
또한 회사 업무 내용이나 개발 규모등에 따라서도 많이 틀려지겠죠
우리회사 같은 경우에는 한두사람이 하나의 프로젝트를 개발하고
다수의 기존 프로젝트 유지보수까지 끌고 가는 상황이라
별도의 관리자나 PM등이 있지도 않고요
개발자가 계속 경력을 쌓고 개발을 할 수 있도록 지원할 생각은 하고 있습니다.
개발자에게 힘을 실어주는 제도라는게 구체적으로 어떤 예가 있을까요?
크레브님 안녕하세요.
작은 회사에서는 한사람이 여러 프로젝트를 진행하기도 하고 여러 역할을 겸임하기도 합니다. 아주 일반적인 현상입니다.
단, 여러일을 겸임할 때도 역할의 구분을 하는 것이 좋습니다. 즉 최소화를 해야 좋지만 문서도 만들고 프로세스도 따른 것입니다. 그래야 조직이 조금씩 커지면서 자연스럽게 업무들이 분배됩니다.
혼자 여러일을 한다고 혼자만 알 수 있게 또, 구분없이 일들을 마구 섞어서 하게 되면 인원이 늘어가도 효율적으로 돌아가지 않습니다.
개발자에게 힘을 실어주는 제도 중 하나는 행정적으로 의사결정을 할 수 있는 권한, 예산을 집행 할 수 있는 권한을 부여한는 것입니다. 사실 회사의 의사결정 중에서 기술적인 것들은 개발자들이 해야 하는 것입니다. 특히 회사의 최고 개발자들이 결정을 해야 합니다. 하지만 개발과 관리가 애매한 회사에서는 기술적인 결정임에도 불구하고 관리자들에 의해서 많이 좌지우지 됩니다. 따라서 기술적인 결정이 개발자에 의해서 결정될려면 회사의 최고 기술자가 최고의 임원자리를 차지하고 있어야 합니다. 그래서 CTO가 필요한 법이지요. CTO에는 개발자에게 Role model이 될 수도 있습니다.
그럼에도 많은 회사에서 CTO가 관리자의 역할을 하는 것을 보면 사실 CTO가 아닌것이지요. 그냥 연구소장인 것입니다.
경영자가 기술의 중요성과 전문성을 이해해야만 이 모든 것이 가능합니다.
드물겠지만 개발을 하고 싶은 사람도 있는데 관리직으로 떠밀린다면 우울할꺼 같아요
구차니님 안녕하세요.
개발자도 고참이 되어도 개발자로서 계속 가치를 부여하기 위해서는 달라져야 합니다.
경력이 많아지는 것만 가지고는 부족합니다.
뷰도 넓어져야 하고, 비즈니스도 잘 알아야 하고, 많은 프로젝트와 후배들에게 영향을 많이 줘야 합니다.
그러기 위해서는 회사의 프로세스와 시스템이 잘 갖춰져 있어야 하며 문서화와 리뷰가 잘 이루어져야 합니다.
공감합니다.
아직 개발을 더 하고 싶은데 관리자로 되면 힘들것같아요;;
아직 저는 신입 개발자이지만
관리자로서 준비를 해두어야 할지
개발자로서 살길을 찾아야할지 고민입니다.
acude님
대한민국에서는 어려운 결정입니다.
아직 신입이시니까 더 좋은 여건입니다. 이미 머리가 굳은 경력이 많은 개발자들은 쉽게 마인드를 바꾸기가 어렵습니다.
지금부터 꾸준히 소프트웨어 공학에도 관심을 가지고 경력을 쌓아보세요.
안녕하세요. 오랜만에 들려봅니다. ( 그동안 병원생활하느라;;
여전히 깨어있는 글. 무척이나 공감합니다.
얼마전 해외에서 일하는 후배와 이야기를 하다가,
암담한 한국의 소프트웨어 업계와, 그래도 캐리어를 꾸준히 보장해 주는 해외 소프트웨어 업계를 비교해 보고 참.. 한국의 기업들이 개선해야할 부분이 너무 많은것 같아서 답답하기까지 하더라구요.
물론 해외기업과 한국기업이 문화태생부터 다른 것은 사실이지만 같은 소프트웨어를 다룬다는 입장에서는 똑같을 듯 싶은데.. 왜 한국 기업은 공학인들에게 당연히 보장해 줘야 될 부분들을 그렇게 늘~~ 그늘에 놔두려고 하는지..참 안타깝기 까지 했습니다.
그리고 기술밥먹는 사람들은 기술밥먹는 사람끼리 뭉쳐서 타 도메인에 대한 상생을 좀 무시하는 경향이 있는것도 같구요.
또, 말씀하신것처럼 개발자도 소프트웨어공학에 대한 지식을 꾸준히 연마해야 한다고 봅니다. 기업에 프로젝트를 하러 다니면 소프트웨어공학에 대해 관심도 없고, 배우려고 하지 않는 곳이 꽤 많았습니다. 단지 API의 어떤 기술만 외쳐댈뿐이었지요. (숲을보는 인재가 별로 없는 듯) 어디서부터 잘못된 문화인지... 그 원인을 분석하고 개선할 수 있다면 정말 좋겠지만.. 아직까지 먼 세상이라고 느껴집니다.
부디 깨어있는 분들이 계속 개선점을 고치고 알리어 꾸준히 바뀌어 나가길 희망합니다.
안녕하세요. moova님
오랫만입니다. 그동안 쾌차하셨는지요?
그래도 저와 저의 회사에서는 그동안 여러 회사를 컨설팅하면서 마이드를 많이 바꾸고 있습니다. 그래서 점점 이러한 것들이 파급되고 있다고 생각합니다. 그 일환으로 책도 쓰고 블로그도 하는 것입니다.
이땅에서 소프트웨어 개발자가 최고의 직업이 되는 날까지 저는 뜁니다. ^^
안녕하세요, 이전에 'SVN' 이란 것을 검색하다가 게시된 글들에 흥미를 느껴 간간이 들리고 있는 IT분야 취업 준비생입니다. 간단히, 저의 소개를 하자면 국내 컴퓨터공학과를 졸업했으며 오는 하반기에 국내취업을 목표로 하고있는 젊은 청년입니다. 또한, 현재 Wipro라고 하는 인도 SI업체에서 프로젝트를 맡아 수행중이기도 합니다.
앞으로 저보다 앞서서, 미래를 그려나가는 선배님들께 좋은 말씀도 들었으면 합니다.
잘 부탁 드리겠습니다 : )
Keyvin님 안녕하세요.
새술은 새부대에 보관해야죠...
경력이 오래된 개발자들은 마인드가 쉽게 바뀌지 않습니다. 그동안 이룩해 놓은 것들과 몸에 밴 습관을 버릴 수가 없기 때문에 그렇습니다.
그래서 kevin님과 같은 신진들이 더욱 중요합니다.
처음부터 올바르게 시작해야 합니다. 하지만 현장에서 실제로 일을 하다보면 반대된는 도전에 수없이 직면할 것입니다. 그것이 지금 우리나라의 현실입니다. 여기에 좌절말고 꾸준히 정도를 걸어나가면 뛰어난 개발자가 될 수 있을 겁니다.
요소 기술만 신경 쓰지 마시고 소프트웨어 공학고 꾸준히 공부를 하고 경험을 하는 것이 중요합니다. 소프트웨어 공학은 공부만 해서는 절대로 익힐 수 없는 것이고 제대로된 경험을 하는 것이 익히는 유일한 방법이며 시간도 많이 걸립니다.
현장에서 여러 도전에 부딪힐 때 저를 비롯한 선배들이 도움을 줄 수 있기를 바랍니다.