2010년 4월 19일 월요일
2010년 4월 14일 수요일
실용적인 심각도 선정 가이드
심각도를 정의 하던중 검색해서 찾은 글이다.
-----------------------------------------------------------------------------------------------
최근 필자가 재직하고 있는 품질관리 팀 내에서 심각도(Severity)에 대한 기준을 다시 정리하는 작업을 진행했다. 국내에서 테스트 엔지니어들이 그들의 현업에서 바로 적용할 수 있을 정도의 심각도에 관한 기준이 세세하게 기록된 문서를 가지고 있는 회사가 과연 얼마나 많을지 의문이다. 아무리 테스트 업무를 오랫동안 진행한 부서라고 하더라도 결함의 심각도를 판단하는 유일한 기준이 오직 개별 테스트 엔지니어의 경험과 주관뿐인 경우가 허다한 것이 현실이다. 상 황이 이러하다 보니 당연히 심각도 선정에 대한 객관성이 보장되지 않았고, 이로 인해 개발자와 테스트 엔지니어 사이에 결함의 심각도에 대한 의견 차이가 빈번하게 발생했을 뿐만 아니라, 테스트 팀 내에서도 동일한 결함에 대해 서로 다른 의견이 제시되고는 했다.
이런 문제들을 조금이라도 줄여보고자 심각도 선정에 대한 기준을 마련하는 작업을 진행하게 된 것인데, 생 각보다 그 과정이 쉽지 않았다. 최근 이와 관련된 일들을 진행하면서 필자가 경험하고 느낀 심각도 설정에 팁이 될만한 몇 가지를 추려 공유하고자 한다. 일반적으로 흔히 통용되는 심각도의 기준은 다음과 같다.
1. 치명적 결함(Critical Defects): 하드 웨어 또는 소프트웨어 장애, 시스템 중지, 시스 템 잠김(접근 불가),
데이터 손실 또는 변조
2. 주요 결함(Major Defects): 기능 상실, 잘못된 기능, 주요 기능 오작동
3. 일반 결함(Average Defects): 불완전 한 기능, 사소한 기능 오작동, 잘못 된 인터페이스
4. 사소한 결함(Minor Defects): 타이핑 에러, 사용자 불편, 스크 린 표준의 위반, 좋지 않은 인터페이스
5. 개선 사항(Enhancement): 에러는 아니지만 개선이 필요한 사항
<출처: 개발자도 알아야 할 소프트웨어 테스팅 실무 제2판>
흔히 심각도의 수준을 위와 같은 3 ~ 5단계로 설정하는 것이 일반적이다. 상황에 따라 더욱 많은 단계를 설정할 수도 있겠지만, 개 인적인 경험으로 볼 때 최소한 3단계의 수준이라면 충분히 통용될 수 있으리라 생각된다. 중요한 것은 심각도를 몇 단계로 설정하느냐가 아니라, 발견된 결함에 대에 얼마나 객관적인 심각도를 부여할 수 있느냐 하는 것이다. 위에서 제시된 것과 같은 범용적인 기준만 가지고는 명확하게 이 결함이 어느 정도의 심각도를 가지고 있는지 판단하기 모호한 경우가 무척 많다. 이런 경우, 아래의 사항들을 참조한다면 좀 더 객관적인 심각도 선정에 도움이 될 것이라 생각된다.
■ 테스트의 목적을 고려하라
동일한 텍스트 오류라고 하더라도 단순히 텍스트 오류를 검증하는 목적의 테스트 중에 발견되었느냐, 아 니면 기능 테스트를 수행하다가 발견된 부수적인 결함이냐에 따라 그 심각도가 달라질 수 있다. 단 순히 사용자에게 메시지 전달이 충실히 되느냐를 검증하는 목적의 테스트라면, 다른 테스트에서는 사소한 문제로 간주될 수 있는 텍스트 오류도 심각한 문제가 될 수 있다. 이 처럼 동일한 증상의 결함이라고 하더라도 테스트의 목적과 얼마나 깊은 관계를 가지고 있느냐에 따라 상대적인 심각도가 달라질 수 있다.
■ 노출 빈도를 고려하지 마라
결함이 얼마나 자주 재현되느냐, 즉 결함의 노출 빈도는 심각도와 동등한 위상을 가지는 결함의 또 다른 속성이라고 할 수 있다. 일반적으로 노출 빈도는 결함의 우선순위(Priority)와 더 깊은 관련을 가진다(절 대적인 관계가 있는 것은 아니다). 심각도가 높으면서 사용자에게 적게 노출되는 문제도 있으며, 심각도가 낮지만 사용자가 쉽게 찾아낼 수 있는 결함도 존재한다. 또한 노출 빈도가 높다고 해서 그것이 바로 심각도가 높은 문제라고 판단할 수 있는 것은 아니며, 노출 빈도가 낮다고 해서 심각하지 않은 문제라고 규정하는 것은 섣부른 판단이다. 노출 빈도와 심각도의 정도가 정비례하는 절대적인 규칙은 존재하지 않는다. 이 두 개념은 서로 관련이 없는 별개의 속성으로 판단해야 한다.
객관적인 심각도 부여를 위해서는 결함의 재현과정 보다는 결함의 증상에 집중해야 한다. 재현이 잘 되지 않는다고 해서 결함의 심각도를 낮춰서는 안 된다. 수정하는 우선순위를 미루더라도 결함 자체의 심각도는 영향을 받아서는 안 된다.
■ 사용자에 집중하라
심각도 판단의 기준을 제품을 사용할 사용자에 두느냐, 아니면 제품 자체(테스트의 대상)에 두느냐에 따라 동일한 증상이라도 심각도가 달라질 수 있다. 제품에서 나타나는 단순한 기능 상의 오류라고 하더라도 사용자에게는 심각한 영향을 끼칠 수 있는 것이다. 예를 들어, 아이템을 구매한 내용을 계산해 아라비아 숫자로 총액을 표시하는 기능을 테스트한다고 가정해 보자. 계산된 값이 출력되는 창에는 디폴트로 “0”이라는 값이 기록되어 있다고 가정하자. 구매 내역을 계산하는 기능은 정상적으로 동작하나 기본 출력값인 ‘0’이 사라지지 않아 계산된 금액에 ‘0’이 하나 더 붙는 오류가 발생했다고 할 경우, 이 를 기능 자체의 관점에서 본다면 기능은 정상적으로 작동하고 출력값의 표시와 관련된 문제라 심각도가 낮아질 수 있는 문제다. 하지만 사용자의 관점에서 본다면 이는 정당하게 지불해야 할 금액의 10배를 지불해야 하는 문제가 되므로, 치명적 인 문제로 간주되어야 한다.
■ 회피 수단이 존재하는지 살펴보라
사용자가 어떤 목적을 달성하려는 도중에 발생한 결함이라면 결함이 발생하는 시점에서 사용자의 목적을 달성시킬 수 있는 우회 경로나 결함을 회피할 수 있는 방법이 존재하는지 여부를 살펴보아야 한다. 해당 결함으로 인해 사용자가 자신의 목적을 정상적으로 달성할 수 있는 방법이 사라지게 된다면 이는 심각한 결함으로 간주되어야 한다. 반면에 해당 결함으로 인해 목적을 달성할 수 있는 방법이 비록 제한되기는 하지만 결함에 영향을 받지 않는 정상적인 다른 방법으로 달성할 수 있다면 이는 전자보다는 상대적으로 심각도가 가볍다고 할 수 있을 것이다.
애플리케이션을 종료하려는 사용자에게 메인 메뉴 상에서 등장하는 프로그램 종료 버튼이 작동하지 않는 결함이 발생했다고 가정해 보자. 이 경우 메인 메뉴를 제외한 기타 옵션에서 프로그램을 종료하는 옵션을 제공한다면, 프로그램을 종료하는 경우가 메인 메뉴 상의 종료 버튼을 통해서만 가능한 경우보다는 상대적으로 가벼운 심각도를 가진 결함으로 판단할 수 있을 것이다.
■ 얼마나 많은 사람이 당신의 심각도에 동의할 지 생각해보라
앞서 살펴본 바와 같이, 기준을 무엇으로 삼느냐에 따라 동일한 이슈에 대해서도 심각도는 여러 가지로 달라질 수 밖에 없다. 프로젝트의 모든 이해당사자들이 동의할 수 있는 심각도가 부여된다면 가장 이상적이겠지만, 현실적으로는 개발팀과 테스트 팀간의 합의 조차 힘든 경우도 부지기수다. 개발팀과 테스트 팀이 합의하더라도, 동일한 이슈에 대해 사업 혹은 영업 관련 부서가 판단한 심각도는 또 다를 수 있다.
사용자의 입장을 대변하는 테스트 엔지니어가 제안하는 심각도가 가장 객관적인 심각도로 판명되어야만 한다. 프 로젝트와 관련된 이해당사자들이 가장 존중해야 할 기준은 제품을 구매하고 직접 사용할 사용자가 될 수 밖에 없다. 테스트 엔지니어 역시 개인의 감성적인 판단이나 경험에 의존하는 것이 아니라, 해당 결함이 실제 사용자에게 어떤 영향을 끼칠 수 있을지를 객관적으로 판단하고 적합한 심각도를 부여해야만 많은 사람들이 당신이 부여한 심각도에 동의할 것이다.
원주율 값은 소수점 이하 무한대로 확장될 수 있지만 일반적으로 소수점 2자리 이하의 값들을 버린 3.14 라는 값이 널리 통용된다. 이와 같이 심각도를 선정하는 작업에서도 고려해야 할 수많은 사항들을 얼마나 깊이 고려할 것인가라는 문제도 무척 중요하다. 이를테면, 엔드 유저 대상의 소프트웨어에서 발생한 결함이 사용자에게 어떤 영향을 끼칠 것인가를 고려할 때, 가상의 사용자를 연령별 혹은 직업별로 분류해 각각의 사용자에게 끼칠 영향을 별도로 설정한다던가 하는 것은 경우에 따라 투자한 노력 대비 얻을 수 있는 효과가 미미할 수도 있다. 즉, 배 보다 배꼽이 더 큰 작업이 될 수 있는 것이다. 의료나 군사 분야와 같이 안전(Safety)이 가장 우선시 되는 분야가 아닌 이상, 가 장 일반적인 사용자를 가정하되, 그 ‘일 반적인’ 사용자가 어떤 사람인가를 분석하는 것도 어느 정도의 리소스를 어떻게 투입해서 진행할지를 고민해 보아야 한다.
심각도를 선정하는 기준은 앞서 제시된 기준들 뿐만 아니라 훨씬 더 다양한 기준이 제시될 수 있다. 우 선순위나 결함의 원인, 그리고 해당 결함을 개선하는 데 필요한 시간 및 인력 등을 파악하고 이 요소들을 심각도와 함께 관리한다면 결함을 통한 품질평가라는 측면에서 좀 더 의미있는 지표가 될 수 있을 것이다.
심각도를 판단하는 절대적인 기준은 있을 수 없다. 때에 따라서는 앞서 제시한 기준들이 서로 모순되게 나타날 수도 있고, 제시되지 않은 기준이 더 중요하게 작용할 수도 있다. 결함의 심각도를 판단하는 데 있어 무엇보다 중요한 것은 발견된 결함을 객관적으로 판단하되 사용자의 입장을 충분히 반영할 수 있어야 한다는 것이다. 결함의 심각도를 판단할 때 사용자의 편을 들어줄 수 있는 사람은 오직 테스트 엔지니어 뿐이라는 사실을 잊지 말아야 한다.
훌륭한 테스트 팀을 만들고 유지하기
서핑중 좋은글이 있어서..
------------------------------------------------------------------------------------------------
소프트웨어 엔지니어는 테스터의 역할 중에서 소프트웨어 개발자 역할을 수행한다. 이들은 소프트웨어 개발자들과 동일한 교육을 받고, 동일한 백그라운드 및 기술들을 보유하고 있다; 단 지 다른 것은 그러한 기술들을 사용하는 애플리케이션일 뿐이다.
즉, 개발자로서의 소프트웨어 엔지니어는 테스트 중인 애플리케이션을 만든다. 테스터로서의 소프트웨어 엔지니어는 애플리케이션의 기능성을 검증하기 위한 시스템을 개발하고 이를 무력화하려고 시도해 본다.[3]
이러한 기술들은 테스트 엔지니어에게 제품이 테스트 용이성에 적합하게 디자인되었는지, 그리고 적합하게 유닛 테스트를 수행했는지 확인하기 위해 개발 담당 팀과 같이 일할 수 있도록 해준다. 테 스트 엔지니어가 비록 개발자와 유사한 일련의 스킬과 단어를 사용한다고 하더라도, 테 스트 엔지니어는 (개발 담당 엔지니어에 비해) 제 품을 더 잘 평가하고 제품의 테스트 용이성이 개선될 수 있는 부분을 더 잘 지적할 수 있다. 이 러한 테스터는 단지 사용자가 키보드 앞에 앉아있는 것을 흉내 내는 것[4]과는 다른 수준의 테스트 자동화를 디자인하고 만들어 낼 수 있다. 그 대신 그는 훌륭하게 설계되고 테스트 중인 시스템만큼이나 정교한 자동화 프로그램을 만들어 낼 수 있을 것이다. 덧붙여, 소 프트웨어 엔지니어는 고객이나 실제 환경을 더 밀접하게 시뮬레이션 하거나 모델링 하기 위해 적절한 소양을 갖추어야 하며, 이러한 소프트웨어 엔지니어가 작성하는 자동화 프로그램은 스스로 에러를 복구할 수 있어야 한다.
Recruiting Software Engineers
어떻게 팀을 꾸릴 것인가? 대부분의 개발자들은 단지 개발만을 하고 어떤 대가를 치르더라도 테스트를 피하고 싶어하는 것이 현실이다. 아마도 테스트 조직에서 소프트웨어 엔지니어를 채용하는 데 있어 가장 큰 장애물은 테스트 엔지니어링에 대한 인식일 것이다. 테 스트 컨퍼런스에 참가하는 도중, 나는 많은 테스트 엔지니어와 그들의 매니저로부터 개발자들이 그들에 대해 어떻게 말하는지를 들려달라는 요청을 받았다. 그 말들 중 가장 날카로운 것들 몇 가지는 다음과 같다: “테스터들은 멍청이들이야”, “테스팅은 지루하고, 수동적이고 반복적이야”, “테스팅은 창조적이지 못하고 혁신할 기회가 부족해”, “테스팅은 전문직이 아니야”, “테스트 엔지니어들은 프로세스가 품질에 공헌하던, 그렇지 않던지 간에 맹목적으로 프로세스를 따라가려고 해” 등등이다. 그리고 물론, 내가 개발을 할 때 가졌던 태도도 “테스트는 나의 훌륭한 창작 행위와 사용자 사이에 서있는 필요악이다” 였다.
이런 말들을 얼마나 많이 들었는가? 당신은 더 나쁜 경험도 가지고 있지 않은가? 우리가 뛰어난 성과를 발휘하는 테스트 팀을 만들기 위해 직면한 하나의 장애물이 바로 이러한 개념을 극복하는 것이다.
자, 이쯤에서, 아마 당신은 개발분야의 직업을 구하고 있는 후보자에게 소프트웨어 엔지니어가 테스팅 부서에서 어떤 일을 해야 하는지를 어떻게 설명해야 할지 궁금해 할 것이다. 이 한 마디로 당신은 설명을 시작할 수 있을 것이다:
“우리 테스트 팀의 소프트웨어 엔지니어는 시스템의 기능성을 검증하고, 성능을 보장하고 요구사항의 범위를 설정하며 신뢰성과 에러로부터 복구되는 것을 증명하기 위한 정교한 소프트웨어를 디자인한다.”
만약 그 후보자가 당신이 위의 문장을 다 말하기 전에 전화를 끊지 않았다면, 더 자세한 논의를 해보면 된다. 사실, 내가 모집하는 이 포지션은 개발직과 동일할 뿐만 아니라, 오히려 더 많은 것을 요구하는 것이다. 여기에 그 이유가 있다:
정교한 소프트웨어(Sophisticated software). 당신은 아주 기술적이고, 정교하고, 에 러에서 복구가 가능한 소프트웨어를 디자인하고 개발할 것이다. 단지 소프트웨어의 목적이 다를 뿐이다. 작은 규모의 애플리케이션을 만드는 대신, 당신은 기능성, 확장성(Scalability), 신뢰성을 검증할 수 있는 완벽한 시스템을 개발해야 하는 것이다. 여기에 더해, 당신의 소프트웨어는 사실상 수동으로 구동되지 않으면서도 각 제품 빌드를 다시 만드는데 많은 시간을 소모하지 않는 방법과 기술을 사용하며, 아울러 이러한 테스트 환경에서 시험중인 시스템을 파괴하는 창조적인 방식도 포함하고 있어야 한다.
당신은 무엇을 만들지를 결정해야 한다(You decide what to build). 대부분의 “소프트웨어 개발자”들 이 마케팅 부서나 혹은 제품관리 부서에서 만든 요구사항에 충족하는 시스템을 만들려고 한다. 새 로운 기능과 특성은 제품에서 구현되기 이전에 제품 관리자의 마음을 제일 먼저 사로잡아야 한다(New features and capabilities must first be sold to the product managers before they can be put into a product). 마케팅 팀은 그들이 이미 마음 속에 가지고 있던 기능에 대해 개발자가 제안한 기능의 비용을 측정해 어떤 것을 탈락시킬지 결정할 필요가 있다. 테스팅에 있어서, 당신은 당신의 보스에게 어떻게 소프트웨어가 생산성을 향상시키고, 품질 확인을 도와주고, 더 많은 버그를 찾게 해주는지를 보여줌으로써, 보스가 당신에게 그 기능이나 시스템을 만들기 시작하라고 지시하도록 할 것이다. 마케팅 회의, 조사 그룹(Survey groups) 혹은 비용 분석은 없다.
소규모 팀(Small Teams). 테스트 팀은 그들의 파트너인 개발 파트보다 규모가 작기 때문에, 당신은 프로젝트에서 일부분이 아니라 무척이나 많은 부분(혹은 어쩌면 프로젝트 전체일수도)을 담당하고 있을 것이다. 여기에 더해, 당신은 당신의 측정 부분이 어떻게 구현되는지에 대한 깊이 있는 이해보다는 제품 전체의 더 많은 기능을 이해함으로써 “큰 그림(big picture)”에 대한 더 나은 인식을 가져야 한다.
창조성(Creativity). 개발자들은 전형적으로 관리자가 기술한 제품을 만들기 때문에, 그들의 창조성은 일반적으로 기능 구현에만 제한되기 마련이다. 즉, 어떻게 이러한 기능들을 최대한의 성능과 품질을 발휘하도록 구현하는 가만을 고민하게 된다. 이와는 반대로, 테스트 엔지니어는 어떤 기능의 구현 방법에서뿐만 아니라 그들이 만들어 내는 기능 자체에 대해서도 창조적이라고 할 수 있다.
창조성의 일반적인 두 가지 영역은 테스팅을 위해 어떤 툴을 사용할 것인가와, 얼마나 새롭고 창조적인 방식으로 테스팅을 수행할 것인가 이다. 여기에는 아마도 시스템에 스트레스를 주거나, 모델-베이스 테스팅을 수행하는 것과 같은 새로운 방식과, 애플리케이션의 품질을 자동적으로 측정하는 다양한 방법과 자동화 자체도 포함된다.
당신은 당신 동료의 코드를 파괴할 필요도 있다(You get to break your buddy’s code). 더 이상의 설명이 필요 없다(No explanation required).
혁신(Innovation). 테스트 자동화 – 특히 기술적으로 고도화된 자동화의 경우 – 는 순수한 소프트웨어 개발에 비해 더 새롭고, 덜 탐구된 영역인 경향이 있다. 이는 혁신할 여지를 더 많이 남겨두는 것이다. 이는 창조성과 겹치는 부분도 있지만, 여기 에서 강조하고자 하는 것은 (테스트 자동화가) 여 전히 개발되고 있는 단계이며 새로운 단계라는 것이다. 높은 품질의 소프트웨어를 개발하는 방법에 중점을 두는 산업에서는 새로운 테스팅 기법과 방법론이 끊임없이 개발되고, 전 파되고 정제된다. 팀에 이러한 혁신을 도입하고 이를 특정한 제품에 적용하는 것은 제품의 품질과 팀의 생산성을 증대시키면서도 한편으로는 (이를 도입한) 엔지니어에 대한 보상이 될 수도 있다.
고객 상호작용/비즈니스 지식(Customer interaction / Business Knowledge). 가장 효과적인 테스트 엔지니어 – 그들이 고전적이거나 스크립터이거나, 혹은 소프트웨어 엔지니어라고 할지라도 – 는 제품에 대한 총체적인 이해를 하는 것이 필요하다. 이러한 총체적인 이해는 (개발자보다는) 테스터에게 있어 좀 더 보편적인데, 그 이유는 테스터들이 특정한 기능의 구현에 덜 관련되어 있고 소프트웨어 검사에 좀 더 연관이 되어 있기 때문이다. 우리는 종종 우리의 테스트 팀을 제품의 한 영역에서부터 새로운 기능이 구현되었거나, 혹은 현존하는 기능이 강화되거나, 버그가 수정된 또 다른 영역으로 전환하기도 한다. 여 기에 더해, 고객이 찾아내는 버그들은 우리에게 어디에 문제가 있는지에 대한 단서를 제공해 주는 것이므로, 우리는 고객들이 어떻게 제품을 사용하는지를 스스로 분석해야 하고 그러한 정보들이 다음 릴리즈를 위해 어떻게 사용되는지를 분석해야 한다. 테스트 엔지니어들은 종종 외부 테스트가 시행되는 동안 고객과의 상호작용을 하는 데에도 무척 적합한데, 이는 고객들이 아마도 제품에 대해 전반적인 이해를 가진 사람의 도움이 필요하기 때문일 것이다. 많은 엔지니어들이 고객과의 상호작용과 종종 이를 동반한 사업적인 여행을 즐긴다. 만약 이 경우가 당신에게도 해당이 된다면, 이 것은 매우 적합한 구인(Recruiting) 포인트가 된다.
모든 엔지니어가 영원히 엔지니어로 남는 것을 바라지 않는다는 것을 명심하는 것도 도움이 된다. 나 는 많은 개발자 및 테스터들이 마침내는 더 중요한 사업적인 역할을 수행하는 자리로 이동하는 것을 수없이 보아왔다. 대다수의 경우, 테스터 직으로부터 이러한 변환이 더 쉽다: 제품에 대한 훌륭한 이해, 비 즈니스 이슈를 해결하는 능력 및 고객과의 상호작용과 같은 경험 등이 이러한 변환을 도와줄 것이다.
실망한 사람들을 채용하기(Recruiting Disappointments)
만약 당신이 여기에서 주어진 모든 가이드 라인을 따르고 당신 스스로 겪었던 다른(혹은 더 나은)문제를 제시한다고 하더라도, 당신이 대화를 나누는 모든 후보자들을 이길 수는 없다. 어쩌면 대부분을 이기지 못할지도 모른다. 그렇다고 실망하지는 마라. 우리가 개발자에게 테스팅을 고려하게 하는 것은 언덕 아래에서 위로 올라가는 힘겨운 싸움을 하고 있는 것과 마찬가지이다. 훌륭한 엔지니어가 한 번 테스팅에 관한 가능성을 생각하기 시작하면, 그것이 점점 커져간다는 것을 기억하라. 나는 여러 가지 이유에서 테스팅을 시작하고 결국엔 그것을 즐기게 되는 많은 엔지니어들과 이야기를 나누어봤다. 그리고 또한 개발부서만이 모든 훌륭한 엔지니어들을 끌어들이는 것은 아니라는 것도 명심하라. 개발 엔지니어 후보들은 그들이 인터뷰하는 팀이 너무 크거나, 너무 작거나, 너무 젊거나(junior) 너무 나이 들었다고(senior) 생 각할 수도 있다: 혹은 프로젝트나, 개 발 부서나 회사가 자신들의 목적에 맞지 않는다고 생각할 수도 있다. 테스팅에 종사하는 우리들처럼, 개발부서의 관리자들도 인원 채용에 있어 어느 정도의 영업 정신이 필요한 것이다.
대안적인 접근방법(Alternative Approaches)
후보자를 끌어들이는 상호 보완적인 접근법이 있다: 인턴, 내 부적인 후보자와 “먼저 테스트를 하게 하고 나중에 개발하도록 하는” 전략이 있다.
인턴(Interns). 내 경험상 고용된 인턴(졸업이 가까워진 소프트웨어 엔지니어링을 공부하는 학생들)들 은 지극히 효과적인 고용 기술이다. 인턴들은 학기 중의(전문대학이나 대학교가 당신의 직장 가까이에 있다고 가정할 경우) 여름이나 일부 기간 동안 풀 타임으로 근무하며, 확 장된 두 가지 방식[5]의 인터뷰를 통해 프로젝트에 종사하는 두 가지 역할을 모두 고려해 볼 수 있다.
대부분의 경우, 인턴들은 종종 그들이 첫 “실질적인” 직업을 가졌다는 기쁨 때문에 열심히 일하곤 한다. 그 들은 경험 있는 프로그래머나 이제 갓 학교를 졸업해 소프트웨어 개발자로서의 역할 모델을 가지지 못한 신입 사원들보다 덜 걱정하는 편이다. 내가 기억하는 가장 행복했던 날은, 가 스 주유소를 그만두고 그 다음날부터 진짜 사무실에서 이전보다 두 배의 임금을 받으며 프로그래머 인턴으로서 일을 시작한 날이다. 비록 아직 대학에 몸을 담은 상태고, 실질 적으로 새로운 위치에서 행한 일들이 그렇게 중요하지는 않았지만, 결국엔 내가 고되게 행한 일들이 회사에 이익을 가져다 줄 것이라고 믿었었다. 나는 요즘의 인턴들이 나와 그렇게 틀리리라고는 생각하지 않는다.
이렇듯 인턴을 통해 양성되고 있는 엔지니어들은 조직에 신선하고, 새롭고, 틀에 박히지 않은 아이디어를 가져다 줄 수 있다. 그 들이 한 번 당신의 테스트 그룹에서 몇 달 혹은 일 년씩 근무하고 나면 그들은 테스트의 장점을 절대적으로 이해하게 되고 졸업 이후에는 풀 타임 근무자로 전환이 가능할 것이다.
내부적인 지원자(Internal Candidates). 때때로 당신은 변화를 준비하거나, 혹은 그들의 리더십 역할을 수행할 곳을 찾거나 혹은 발전을 위해 다른 기회를 찾고 있는 개발 조직의 엔지니어들을 만날지도 모른다. 상 대적으로 더 많은 경험을 가진 상급 소프트웨어 개발자일수록 테스트 부서의 훌륭한 리더가 될 수 있다. 이것은 엔지니어들의 성장과 함께 잠재적인 리더십의 성장을 이끌어 낸다는 두 가지 장점을 제공한다.
-----------------------------------------------------------------------------------------
전문은 원본출처에서 : http://angel927.tistory.com/75
Linux Performance Metrics
리눅스의 성능을 모니터링 할려고 검색하니 좋은 자료가 있어서..
http://support.uptimesoftware.com/article.php?id=117#6
http://tael.egloos.com/3669592
https://www.ibm.com/developerworks/kr/library/au-analyze_aix/
http://blog.daum.net/_blog/BlogView.do?blogid=0Mdzp&articleno=7186366#
http://www.itmoa.co.kr/gzboard.php?code=study&mode=gz_read&Page=&no=797
젠투 리눅스에서 NAT 설정
젠투 리눅스에서 NAT(Network Address Translation) 을 사용하는 방법입니다.
NAT을 사용하기 위해서는 커널에 MASQUERADE가 활성화 되어있어야 합니다만.. 커널에 기본적으로 모듈로 올라와 있습니다.
- 네트워크 설정
외부, 내부 네트워크 설정을 해줍니다.
ruo91 ~ # nano /etc/conf.d/net
config_eth0="dhcp"
config_eth1="192.168.0.1 netmask 255.255.255.0"
런레벨에 eth0, eth1 인터페이스를 부팅시 자동 시작 하도록 설정 해줍니다.
ruo91 ~ # rc-update add net.eth0 default
ruo91 ~ # rc-update add net.eth1 default
- iptables 설정
트래픽 정책 설정을 해줍니다.
ruo91 ~ # iptables -P INPUT ACCEPT
ruo91 ~ # iptables -P OUTPUT ACCEPT
ruo91 ~ # iptables -P FORWARD DROP
외부와 내부 인터페이스를 지정합니다.
ruo91 ~ # export WAN=eth0
ruo91 ~ # export LAN=eth1
LAN 설정
ruo91 ~ # iptables -I INPUT 1 -i ${LAN} -j ACCEPT
ruo91 ~ # iptables -I INPUT 1 -i lo -j ACCEPT
ruo91 ~ # iptables -A INPUT -p UDP --dport bootps ! -i ${LAN} -j REJECT
ruo91 ~ # iptables -A INPUT -p UDP --dport domain ! -i ${LAN} -j REJECT
외부에서 SSH 접속 허용
ruo91 ~ # iptables -A INPUT -p TCP --dport ssh -i ${WAN} -j ACCEPT
포워딩과 마스커레이드를 설정 합니다.
ruo91 ~ # iptables -I FORWARD -i ${LAN} -d 192.168.0.0/255.255.255.0 -j DROP
ruo91 ~ # iptables -A FORWARD -i ${LAN} -s 192.168.0.0/255.255.255.0 -j ACCEPT
ruo91 ~ # iptables -A FORWARD -i ${WAN} -d 192.168.0.0/255.255.255.0 -j ACCEPT
ruo91 ~ # iptables -t nat -A POSTROUTING -o ${WAN} -j MASQUERADE
커널에서 아이피 포워딩을 사용 하도록 설정합니다.
ruo91 ~ # echo 1 > /proc/sys/net/ipv4/ip_forward
ruo91 ~ # for f in /proc/sys/net/ipv4/conf/*/rp_filter ; do echo 1 > $f ; done
iptables 룰을 저장하고 부팅시 자동으로 실행 하도록 런레벨에 등록합니다.
ruo91 ~ # /etc/init.d/iptables save
ruo91 ~ # rc-update add iptables default
sysctl.conf 에 아이피 포워딩 설정을 활성화 해줍니다.
ruo91 ~ # nano /etc/sysctl.conf
#net.ipv4.ip_forward = 0
net.ipv4.ip_forward = 1
내부 LAN 인터페이스를 시작 합니다.
ruo91 ~ # /etc/init.d/net.eth1 start또는 재부팅 하면 됩니다.
ruo91 ~ # shutdown -r now
속도 측정 해본 결과 만족한 결과가 나오네요!! 역시 젠투인듯.. (-ㅅ-)/
프로세스 메모리볼때
ps -elf | awk '{print $10" "$4" "$20}' | sort -n | tail -5 | sort -r
(프로세스중에서 메모리 사용량 큰거부터 내림차순으로 정렬 5개) - 확인해봅세~
리눅스는 실행중인 어플리케이션에서 요구하는 메모리를 제외한 대부분의 메모리를 디스크 캐쉬로 활용한다. 이러한 사실을 모르고 있다면, 메모리 현황 조회시 왜 free 메모리가 부족한지를 이해할 수 없을 것이다.
사실은 내가 그랬다. ^^;
Linux 에서는 메모리 사용 현황을 top 명령으로 조회할 수 있으며, 아래는 top 결과 샘플이고 샘플 내의 여러 항목들 중에서 free 와 cached 의 값이 이번 주제에서 중요 항목이다.
top - 09:40:42 up 74 days, 16:47, 3 users, load average: 0.00, 0.02, 0.08
Tasks: 212 total, 1 running, 210 sleeping, 0 stopped, 1 zombie
Cpu(s): 0.0% us, 0.0% sy, 0.0% ni, 99.9% id, 0.0% wa, 0.0% hi, 0.0% si
Mem: 16630888k total, 16559108k used, 71780k free, 100516k buffers
Swap: 16771776k total, 31920k used, 16739856k free, 16034200k cached
free 메모리가 작지만, cached 메모리는 어플리케이션이 메모리를 필요로 할 때 바로 반환될 수 있으므로 cached 메모리를 실질적으로는 free 메모리로 보아도 무방하다.
따라서 리눅스에서 가용 메모리 계산은 free + buffers + cached 로 할 수 있다.
위의 top 명령 결과로 메모리 용량을 분석해 본다면,
- 전체 Pyhsical 메모리 : 16630888k total
- 실질적으로 사용중인 메모리 : 16559108k used - 16034200k cached - 100516k buffers = 424392k
- 실질적으로 가용한 메모리 : 71780k free + 100516k buffers + 16034200k cached = 16206496k
아래는 free -m 명령으로 조회한 결과이다. (m 옵션으 MB 단위 표시임)
total used free shared buffers cached
Mem: 16241 16188 52 0 98 15669
-/+ buffers/cache: 419 15821
Swap: 16378 31 16347
Mem: 라인에서의 free + buffers + cached 의 값은 -/+ buffers/cache: 라인의 free 값과 비슷하다
[출처] 프로세스 메모리 사용량 볼때|작성자 꽁