2010년 2월 25일 목요일

[펌] 고객접점에 CS(고객만족)교육을 정말 잘해야 하는 이유

clip_image002

HRD REPORT HOT 100 vol. 23 (09.06.17)

고객접점에 CS(고객만족)교육을 정말 잘해야 하는 이유

정진호

현대경제연구원 인재개발원

(상황 설정)

K씨는 올해 1월 50만원을 들여 핸드폰을 구입했다. K씨는 10여 년 A사 핸드폰을 주로 사용했는데, 최근 경제사정을 고려하여 가격이 조금 싼 후발 B사 핸드폰을 구입하였다. 핸드폰은 최신 기종을 구입하였다. 구입 후 1개월 즘 되었을 때, 메모리 이상이 있어 서비스센터에서 간단한 수리를 받은 바 있다. 그리고 5개월이 지나, 갑자기 핸드폰 수신과 발신이 안 되는 고장이 있어, 점심시간을 이용하여, 서비스센터에 방문했다. 서비스센터에는 많은 사람이 대기 중이었고, 30분을 기다려 AS 담당자와 마주 앉게 되었다.

고객접점에 있는 영업대표나 AS담당자의 말 한마디, 행동 하나가 기업 이미지와 브랜드, 영업 실적에 큰 영향을 미친다. 본 고는 핸드폰 제조사 서비스센터에서 발생한 고객과 데스크 담당자와의 대화록이다. 고객접점에 있는 AS담당자의 고객응대가 회사의 브랜드와 매출 실적에 어떤 악영향을 미치는지에 대한 시사점이 있어 공유하고자 한다.[편집자 주, 볼드체는 필자의 의견임]

회사AS담당 : 어서 오십시오. 고객님! 불편을 끼쳐 드려 죄송합니다.

불만고객에 대한 처음 응대 멘트는 잘 교육이 되어 있다.

회사 AS담당 : 핸드폰에 메인보드가 고장이 난 상태입니다. 언제부터 이런 일이 있었나요?

고객 : 주말부터 핸드폰의 수발신이 안 되었다. 핸드폰 구입한 후 1개월 만에 고장이 나서 수리하고, 이번이 두 번째다. 고장이 왜 이렇게 많나?

회사 AS담당 : 혹시 핸드폰을 충전기에 오래 꽂아 놓았나요?

고객 : 이틀 동안 계속 꽂아 놨다.

회사 AS담당 : 충전기에 과부하가 걸려서 메인보드가 고장이 났습니다. 메인보드를 교체해야 하고, 비용이 발생할 것 같습니다. 충전기는 제조사가 제공하는 것이 아니라, 판매업체가 서비스로 제공하는 품목입니다.

고객 : 말이 되지 않는다. 핸드폰을 구입하면 당연히 충전기가 필요한데, 그러면 당연히 핸드폰에 맞는 충전기가 제공되도록 해야 하는 것 아니냐? 그리고 우리 집에 귀사 핸드폰 4개를 같은 충전기에 꽂아서 사용하는데, 왜 최근에 산 내 핸드폰만 고장이 나는가? 그리고 그 비용을 왜 내가 부담해야 하는가?

회사 AS담당 : (묵묵부답) 우선 핸드폰 메인보드를 교체해 드리고, 비용은 고객님께 부담시키지 않겠습니다.

문제점의 원인 규명 없이, 회사가 비용부담 하겠다고 하여 신뢰를 잃는다.

고객 : 원인이 대체 무엇인가? 수리를 하더라도 이유는 알아야겠다. 다른 회사 제품은 10여 년을 사용해도 아무 문제가 없었는데, 귀사의 제품은 구입한지 1개월 만에 고장이 나고, 5개월도 안되, 메인보드는 바꾸는 게 말이 되는가? 제품을 똑 바로 만들어서 팔아야지 이게 뭔가?

회사 AS담당 : (묵묵부답) 책임지고 메인보드를 교체해 드리겠습니다.

회사에 대한 비난성 발언에 대처하지 않는다. 경쟁사보다 나쁘다는 얘기를 수용한다.

고객 : 책임자가 누군가? 서비스센터 책임자와 얘기하고 싶다. 권한이 없으면 빠지라.

회사 AS담당 : 제가 책임자입니다. 제가 다 해결해 드리겠습니다.

고객 : 수리시간이 얼마나 걸리는가? 수리기간에 핸드폰을 사용방법을 알려달라.

회사 AS담당 : 수리시간은 하루가 걸립니다. 수리기간 중에 임대핸드폰을 빌려 드리는 제도가 있습니다. (유선으로 타 부서에 확인을 해보더니) 현재 임대핸드폰을 보관하고 있지 않습니다. 가까운 대리점이 있는데, 직접 가셔서 임대를 하십시오.

고객 : 고장의 책임이 제조사에 있는데, 고객이 직접 가서 임대를 하라는 것이 말이 되는가? 직접 핸드폰을 가져다 주는 서비스가 있다고 들었는데, 너무 한 것이 아닌가?

회사 AS담당 : 확인을 해 보겠습니다. 댁이 어디십니까? (여기저기에 전화를 걸더니, 갑자기 전화를 바꿔준다.)

회사 콜센터 : 고객님 핸드폰이 있는데, 직접 내방해서 가져가시겠습니까? 아니면 계신 곳으로 보내드릴까요?

고객 : 무슨 차이가 있는가? 당연히 가져다 주는 게 낫지 않는가?

회사 콜센터 : 직접 고객님께 가져다 드리면 비용이 발생합니다.

고객 : 내 잘못도 아닌 일로 핸드폰이 고장이 났는데, 왜 그 비용을 내가 지불하는가? 전화 바꿔 준 담당자와 직접 통화해라. (회사 AS 담당자에게 수화기를 전달해 줌)

고객상태에 대한 설명 없이, 회사의 다른 담당자에게 연결을 해 줘 더 큰 컴플레인 받는다.

회사 AS담당 : 원래 비용이 발생하는데, 당사에서 책임을 지겠습니다. 댁 주소가 어디십니까? (주소를 불러줌) 오후 4시 즘 댁으로 방문해도 될까요?

고객 : (어이없이 웃으며) 회사 다니는 직장인에게 집에 가서 핸드폰을 받으라는 얘기인가? 정말 어이가 없다.

현장에서 고객에 대한 대응력이 매우 취약하다.

회사 AS담당 : 죄송합니다. 책임지고 처리해 드리겠습니다.

고객 : (불쾌한 마음으로 서비스센터를 나옴)

(1시간 후 서비스센터 콜센터에서 고객에게 전화가 옴)

회사 콜센터 : 안녕하십니까. 고객님. 오늘 핸드폰 고장 관련한 서비스는 만족하십니까? 담당자는 친절했습니까? 이번 서비스에 대해 점수를 주시면 얼마를 주시겠습니까?

고객 : (전화를 끊어버림 그리고 다시는 이 회사 핸드폰은 물론 가전제품은 절대로 사지 않겠다고 결심함)

(이 고객은 이후 어떻게 했을까?) 친한 사람에게 이 회사의 AS 사례를 얘기함. 이 회사의 모든 제품이 질이 낮은 제품이라고 얘기함. 나중에 제품 구입시 경쟁사에 이 회사의 문제점을 얘기함.

회사 AS담당자가 고객과의 문제사항을 보고하지 않았고, 회사 콜센터는 고객 특이사항에 맞는 대응을 하지 못하다.

※ 본 자료는 개인적으로 작성한 리서치 결과물입니다. 자료 사용시 출처 인용하시고,

자유롭게 활용하시기 바랍니다. HRI 정진호연구위원 jjhland@paran.com

2010년 2월 24일 수요일

[펌] SQL Server 진단을 위한 주요 성능카운트

 

Posted by 건방진연이 Posted in " MS SQL SERVER/MSSQL 성능관련 "

성능베이스라인을 만들기 위해 최모군이 SSIS를 이용해서 자동화를 시키고 있는 중입니다. 해당 SSIS를 이용하여 자동화시키는 강좌는 SQLLEADER.COM에 가면 잘 정리되어 있습니다. 많은 시행착오를 거쳐 SSIS는 거의 완성단계에 왔고, 이제 어떤 성능카운터를 넣을지만 결정하면 되는 이 시점에서 SQL Server 성능 진단을 위해서는 어떤 성능 카운터를 수집을 해야 하는지에 대해서 정리를 해볼까 합니다.

Processor\%Processor Time : % Processor Time
이 성능카운터는 프로세서가 비유휴 스레드를 실행하는데 소비하는 시간의 백분율입니다. 이것은 프로세서가 각 샘플 간격 동안 유휴 스레드를 실행하는데 소비한 시간을 측정하여 간격 기간에서 그 값을 뺀 것입니다. 각 프로세서에는 유휴 스레디가 있는데 이것은 다른 어떤 스레드도 실행되지 않을 때 사이클을 소비하는 스레드입니다. 이 카운터는 프로세서 동작의 주요 표시기이며 샘플 간격 동안 관찰되는 사용 시간의 평균 백분율을 표시합니다. 이것은 서비스가 비활성인 시간을 모니터링하여 100%에서 그 값을 뺀 것입니다. 즉, 쉽게 말해서, 1시간동안 CPU상태를 관찰하였고, 1시간중에 30분간 CPU가 일을 하였다면, %Processor Time은 50% 입니다. 일반적으로 %Processor Time가 80%이상 사용되고 있으면, 관심을 가지고 사용량의 변화를 모니터링 하셔야 합니다.
Processor\%Privileged Time : % Privildged Time
이 성능카운터는 프로세스 스레드가 특권 모드에서 명령을 실행하면서 경과된 시간을 백분율로 표시한 것 입니다. Windows 시스템 서비스가 호출되면, 서비스는 시스템 전용 데이터를 액세스하기 위해 흔히 특권 모드에서 실행됩니다. 그러한 데이터는 사용자 모드에서 실행되는 스레드가 액세스하지 못하도록 보호됩니다. 시스템 호출은 페이지 오류 또는 인터럽트가 발생할 때처럼 명시적이거나 암시적입니다. 일부 초기 운영 체제와는 달리 Windows는 사용자 및 특권모드의 일반적인 보호뿐만 아니라 하위 시스템을 보호하기 위해 프로세스 경계를 사용합니다. 응용 프로그램을 대신하여 Windows에서 수행한 일부 작업은 프로세스의 특권 시간 및 다른 하위 시스템 프로세스에서도 나타납니다. 쉽게 말해서, 운영체제가 사용한 시간의 백분율 값 입니다.
Memory\Available Bytes : Available Bytes
이 성능카운터는 컴퓨터에서 실행되는 프로세스에 사용할 수 있는 실제 메모리의 양(byte)입니다. 이것은 0으로 채워 있거나 비어 있거나 대기 중인 메모리 목록에 있는 공간을 합해 계산합니다. 빈 메모리는 사용할 준비가 된 메모리이고, 0으로 채워진 메모리는 다음 프로세스가 이전 프로세스에서 사용된 데이터를 보지 못하도록 0으로 채운 메모리 페이지로 구성되며, 대기 메모리는 프로세스의 작업 집합(실제 메모리)에서 제거되어 디스크로 라우트되었지만 다시 호출되어 사용될 수 있는 메모리를 말합니다. 이 카운터는 최근에 관찰된 값만 표시하며 평균값은 아닙니다. 사용 가능한 여유 메모리는 많이 있으면 좋겠지만, 그렇지 않다면, 최소한 5Mbyte이상은 남아 있어야 합니다.
Memory\Page Faults/sec : Page Faults/sec
이 성능카운터는 프로세스가 사용하는 메모리 공간(Working set)에 존재하는 않는 코드나, 데이터를 요청할 경우에 발생합니다. 이 때 요청된 코드나 데이터를 다른 메모리 공간에서 찾으면 Soft Page Fault라고 하면, 디스크에서 찾게되면 Hard Page Fault라고 합니다. Page Faults/sec은 초당 발생한 Soft Page Fault와 Hard Page Fault의 합 입니다. Soft Page Fault값은 Page Faults/sec값에서 Pages/sec값을 빼면 됩니다. 따라서, Page Faults/sec의 값을 작을수록 좋다고 말 할 수 있겠으며, 상황에 따라서 그 임계치는 다르므로, 평상시에 모니터하여 적정 값을 파악해 두셔야 합니다.
Memory\Pages/sec : Pages/sec
하드 페이지 부재를 해결하기 위해 디스크에서 읽거나 디스크로 쓴 페이지의 비율입니다. 이것은 Memory\\Pages Input/sec과 Memory\\Pages Output/sec의 합 입니다. 메모리 공간이 부족하게 되면, 디스크의 페이징 파일로 메모리의 내용을 옮겨서 메모리의 여유공간을 확보하여 사용하게 되며, 또 필요시 페이징 파일에서 데이터를 메모리로 로드하여 처리하는 과정을 반복하게 되므로 성능이 저하되게 됩니다. Pages/sec 카운터 값이 20이상 지속되면 메모리 이상을 의심해야 합니다.
PhysicalDisk\%Disk Read Time
디스크가 읽기 작업을 수행한 시간의 백분율 입니다.
PhysicalDisk\%Disk Write Time
디스크가 쓰기 작업을 수행한 시간의 백분율 입니다.
PhysicalDisk\%Disk Time
디스크가 읽기 및 쓰기 작업을 수행한 시간의 백분율이며, 이 값은 Disk Read Time와 Disk Write Time의 합 입니다.
PhysicalDisk\Avg. Disk Queue Length
디스크의 읽기 및 쓰기 작업을 위해 대기중인 실제 디스크 큐 길이 입니다. 이 값은 디스크당 2를 초과하게 되면, 디스크 쪽 부하를 점검해야 합니다.
PhysicalDisk\Current Disk Queue Length
현재 시점의 디스크 읽기 및 쓰기 작업을 위해 대기중인 디스크 큐 길이 입니다. 이 값 역시 2를 초과하면, 디스크 쪽 부하를 점검해야 합니다.
Network Interface\Current Bandwidth
네트워크 인터페이스의 현재 대역폭입니다. 사용하는 네트워크 어댑터 카드의 지원 가능 대역이 100Mbps인 경우에 Current Bandwidth 값이 10Mbps이라면 네트워크 어댑터 카드의 속성 세팅이 잘 못 되었을 가능성이 큽니다.
Network Interface\Packets Outbound Errors
이 항목은 오류로 인해서 외부로 반출할 수 없는 패킷의 수를 나타냅니다.
Network Interface\Packets Received Errors
이 항목은 상위 계층의 프로토콜로 전달되지 못하도록 하는 오류를 포함하고 있는 외부로부터 유입되는 패키의 수를 나타냅니다.
Server\Bytes Total/sec
이 항목은 초당 서버가 네트워크에서 주고 받은 바이트 수 입니다. 동일 네트워크에 존재하는 서버들의 각각의 Bytes/sec 합이 네트워크 대역폭보다 크다면, 네트워크 분리를 고려하셔야 합니다.
SQLServer:Buffer Manager\Buffer cache hit ratio
SQL Server가 데이터를 디스크에서 읽지 않고 버퍼 풀에서 찾은 페이지의 비율입니다. 이 값의 높은 수치는 SQL Server가 데이터를 가져오기 위해서 하드디스크에 아주 가끔 액세스한다는 것이며, 이는 SQL 성능을 극대화 시킵니다.
SQL Server를 모니터하는 다른 카운터들과는 달리, 이 카운터는 SQL Server가 다시 시작한 시점 이후부터의 버퍼 캐시 히트율의 평균값 입니다. 즉, 이 카운터는 현재 시점의 측정 값이 아닌 SQL Server가 시작된 이후의 모든 날들의 평균값입니다. 현재 시점의 버퍼캐시가 어떤일을 하고 있는지에 대한 정확한 자료를 얻기 원한다면, SQL Server를 중지했다가 다시 시작해야만 하고, 정확한 버퍼캐시 히트율을 확인 하기 위해 SQL Server를 여러시간 동안 일반적인 활동을 하게 내버려 둬야 합니다.
만약, 최근에 SQL 서버를 재 시작 하지 않았다면, 여러분이 보고 있는 버퍼 캐시 히트율은 아마도 정확한 정보가 아닐 것 입니다. 또한, 버퍼캐시 히트율이 좋아 보일지라도, 오랜 시간의 평균값으로 계산되기 때문에 실제로는 좋지 않을 지도 모릅니다.
OLTP 응용프로그램 환경에서 이 수치는 통상 90%~95% 이상이어야 합니다. 그렇지 않다면, 여러분은 성능 향상을 위해서 서버에 RAM을 추가할 필요가 있습니다. OLAP 응용프로그램 환경에서는, OLAP작동하는 기본특성 때문에 이 수치는 OLTP보다 더 작을 수 있습니다. 어떤 경우라도, 더 많은 RAM은 SQL Server의 OLAP활동의 성능을 증가 시킬 것 입니다.
SQLServer:Buffer Manager\
디스크로 부터 데이터를 읽는 대신에 버퍼 캐시로부터 데이터를 가져온다면 SQL Server는 보다 적은 작원으로 보다 훨씬 더 빠르게 수행합니다. 몇몇 경우에, 메모리 집중적인 명령들로 인해 데이터 페이지들이 이상적으로 플러시 되기 전에 캐시 밖으로 밀려 나기도 합니다. 이는 버퍼캐시가 충분히 크지 않거나 메모리 집중적인 명령의 작업을 위한 더 많은 버퍼 공간 요구에 의해 발생할 수 있습니다. 이런 경우에는 버퍼에 추가 적인 공간을 만들기 위해서 플러시 된 데이터 페이지들은 버퍼가 아닌 디스크로부터 읽혀지게 되며 SQL Server 성능에 안 좋은 영향을 미치게 됩니다. SQL Server가 이러한 문제를 가지고 있는지 확인 하기 위한 3개의 SQL Server 카운터가 있습니다.
SQLServer:Buffer Manager\Page life expectancy
이 성능 카운터는 데이터 페이지가 얼마나 오랫동안 버퍼에 머무르는지를 평균적으로 초 단위로 나타내 줍니다. 만약 이 값이 300초 보다 작은 값을 보인다면, SQL Server의 성능 극대화를 위해서 추가적인 메모리가 필요함을 잠재적으로 나타내는 것 입니다.
SQLServer:Buffer Manager\Lazy Writes/Sec
이 성능 카운터는 버퍼공간을 비우기 위해서 지연기록기(LaxyWriter) 프로세스가 더티페이지들을 버퍼공간에서 디스크로 초당 얼마나 많이 옮겼는지 나타냅니다. 즉, 이 항목은 높은 값(초당 20정도)이어서는 안됩니다. 이성적으로는 0에 가까워야 합니다. 만약 이 값이 0이라면 여러분의 SQL Server는 아주 큰 버퍼 공간을 가지고 있고, 일정한 체크포인트가 발생하여 더티페이지가 반환되기를 기다리는 대신에, 더피페이지 반환을 하지 않아도 됨을 나타냅니다. 만약 이 값이 높다면 보다 많은 메모리가 필요함을 나타냅니다.
SQLServer:Buffer Manager\Checkpoint Pages/Sec
일반적으로 체크포이트가 발생하게 되면 모든 더티페이지들으 디스크에 쓰여지게 됩니다. 이것이 일반적인 절차이며, 체크포인트가 처리되는 동안 이 카운터가 증가하게 됩니다. 여러분은 이 카운터가 오랜 시간에 걸쳐서 카운터가 높아 지는걸 원치 않으실 것 입니다. 이는 SQL Server의 귀중한 자원을 많이 사용할 수 있는 체크포인트 프로세스가 보다 더 자주 실행됨을 나타냅니다. 만약 이 값이 높은 값을 가진다면, 빈번한 체크 포인트 발생을 줄이기 위해서 더 많은 RAM을 추가할 것을 고려하시거나, SQL Server의 구성옵션 중에 ‘복구 간격(recovery interval)’ 옵션 값을 늘려주십시오.
[관련글] Transaction 과 CheckPoint
SQLServer:Buffer Manager\Page reads/sec
모든 데이터베이스에 대해서 발생한 물리적 데이터 페이지의 초당 읽기 수를 나타냅니다. 물리적 I/O는 상대적으로 비용이 많이 발생하므로, 더 큰 데이터 캐시를 사용하거나, 인덱스 및 쿼리를 효율적으로 작성하거나, 데이터베이스 모델링을 다시하여 물리적 I/O비용을 줄여야 합니다.
SQLServer:Buffer Manager\Stolen Page
Windows 시스템이 SQL Server가 아닌 다른 응용프로그램의 요구를 충족시키기 위하여 얼마나 많은 페이지들이 SQL Server 데이터 캐시로부터 제거되었는지를 나타냅니다. Min Server Momory를 지정하여 SQL Server가 지정한 만큼의 SQL Server 전용으로 메모리를 할당하게 할 수 있지만, 그 만큼 다른 프로그램이 적은 메모리로 운영되게 되므로 페이징이 발생하게 됩니다. 따라서 메모리증설을 고려해야 합니다. (역주 : 보통 SQL Server가 운영되고 있는 하드웨어는 SQL Server만을 위해서 존재해야 합니다. 한가지 예를들자면, WEB 서비스를 하기 위해서 한 서버에 IIS 서비스와 SQL Server을 같이 돌리는 것은 좋지 않은 예 입니다. 즉, SQL Server에서 Min Server Momory를 지정하여 윈도우에서 SQL Server 메모리를 사용하지 못하게 하는게 좋습니다.)
SQLServer:Databases\Log Flushes/sec

이 카운터는 초당 플러쉬 된 로그 수를 나타냅니다. 하나의 로그플러쉬는 하나의 트랜잭션이 커밋되어 로그파일에 기록되는 것을 의미 합니다. 이 카운터는 데이터베이스 별로 측정 되거나, 단일 SQL Server의 전체 데이터베이스에 대한 값으로 측정 될 수 있습니다.
여러분은 로그캐시에 대해서 한번도 들어보지 못했을지도 모르겠습니다. 이것은 SQL Server서버가 로그파일에 쓰여질 로그데이터를 기록하는 메모리의 한 영역입니다. 로그캐시의 목적은 트랜잭션이 커밋되기 전에 특정상황이 발생하여 롤백 해야 하는 상황에서 트랜잭션을 롤백 하는 용도로 사용되기 때문에 매우 중요합니다. 그러나, 트랜잭션이 완료되면(완료되면 절대 롤백되지 않음) 로그캐시는 즉시 물리적인 로그파일로 플러시 됩니다. 이것이 정상적인 절차입니다. SELECT쿼리는 데이터를 수정하지도 않고 트랜잭션을 생성하지도 않고 로그플러쉬를 발생하게 하지도 않음을 명심하십시오.
본질적으로, 로그캐시에 있는 데이터가 물리적인 로그파일로 쓰여질 때 하나의 로그플러쉬가 발생합니다. 따라서, 하나의 트랜잭션이 완료될 때마다, 로그플러쉬는 발생을 하며, 많은 수의 로그플러쉬 발생은 SQL Server로부터 수행되는 많은 수의 트랜잭션과 관련이 있습니다. 그리고, 짐작하시는 것처럼 로그플러쉬(얼마나 많은 데이터가 로그캐시로부터 디스크에 기록이 되어졌는가?)의 크기는 트랜잭션에 따라 다릅니다.
우리가 디스크 I/O 병목현상을 격고 있고, 그 원인을 확신하지 못하고 있다고 가정합시다. 디스크 I/O에 대한 병목을 해결하기 위한 하나의 방법은 Log Flushes/sec 카운터 데이터를 수집하고, 이 과정을 처리하는데 얼마나 바쁜지 보는 것 입니다. 여러분의 서버에 많은 트랜잭션이 발생하고 있다면 로그플러쉬의 양은 당연히 많을 것 입니다. 따라서, 이 카운터 항목으로 보는 값은 트랜잭션을 발생하는 활동 형 쿼리가 얼마나 바쁜가에 따라 서버마다 다양할 것 입니다. 이 카운터 정보로써 여러분은 초당 발생하는 로그플러쉬 수가 운영하는 서버에서 예상되는 트랜잭션의 수 보다 확연하게 높은가에 대한 상황 판단에 도움을 줄 것입니다.
예를 들어, 매일 1,000,000행을 한 테이블로 삽입하는 작업을 한다고 가정합시다. 이 행들이 삽입되어질 수 있는 방법은 다양합니다.
첫째, 각 행은 따로따로 삽입되어 질 수 있습니다. 각 INSERT는 단일 트랜잭션 내부에 감싸집니다.
둘째, 모든 INSERTS는 단일 트랜잭션 내에서 수행되어 질 수 있습니다.
마지막으로, INSERTS는 1과 1,000,000사이의 어딘가에 여러 개의 트랜잭션으로 나누어 질 수 있습니다.
각 형태의 처리는 다르며, SQL서버와 초당 플러시 되는 로그 수에 매우 다른 영향을 미칩니다. 더구나, 프로세스가 멀티 트랜잭션으로 처리되고 있는데, 단일 트랜잭션으로 처리되고 있다고 착각할 수 도 있다. 많은 사람들이 단일 프로세스를 단일 트랜잭션으로 생각하고 있는 경향이 있습니다.
첫째의 경우에서, 만일 1,000,000행이 1,000,000개의 트랜잭션으로 삽입되어진다면, 1,000,000번의 로그 플러시가 발생할 것입니다.그러나, 두 번째 경우에는, 단일 트랜잭션에서 1,000,000행이 삽입되어 질 것이고, 단지 하나의 로그 플러시가 발생할 것입니다. 그리고, 세 번째  경우 에는 플러시 되는 로그의 수는 트랜잭션의 수와 같을 것입니다. 명백히, 로그 플러시의 크기는 1,000,000트랜잭션이 1트랜잭션보다 훨씬 클 것입니다, 그러나, 대개의 경우 성능의 관점에서 여기서 언급한 내용은 그다지 중요하지 않습니다.
어떤 옵션이 가장 좋은가요? 모든 경우에서, 많은 디스크 I/O를 유발할 것입니다. 1,000,000행을 핸들링 할 경우에는 I/O양을 줄일 묘안이 없습니다. 그러나, 하나 혹은 적은 수의 트랜잭션을 사용함으로써 로그 플러시 양을 많이 줄일 수 있을 것이고, 이는 디스크I/O양을 줄이게 되어, I/O병목 감소와 성능을 높여줄 것입니다. 우리는 두 가지 포인트를 배웠습니다. 첫째는, 여러분이 플러시 되는 로그 양을 가능한 많이 줄이길 원할 것이라는 것과, 둘째, 여러분의 서버에서 발생하는 트랜잭션의 수를 줄이는 것 입니다.

SQLServer:Databases\Transactions/sec
선택한 데이터베이스에서 발생한 초당 발생하는 트랜잭션 수를 나타냅니다.
SQLServer:General Statistics\User Connections

SQL Server를 사용하는 사용자 수가 많음에 따라 SQL Server 성능에 영향을 미치기 때문에 여러분은 SQL Server General Statistics Object : User Connections 카운터에 관심을 가질것 입니다. 이 카운터는 사용자 수가 아닌, SQL Server에 연결된 사용자 연결 수를 나타냅니다. 이 수치를 해석할 때, 하나의 단일 사용자는 여러 개의 연결들로 열릴 수 있음을 유념하십시오. 그리고 또한, 여러 명의 사람이 하나의 단일 사용자 연결을 공유할 수 도 있습니다. 이 수가 실제 사용자수를 나타낸다고 가정하지 마십시오. 대신에, 서버가 얼마나 바쁜가에 대한 상대적 척도로 사용하십시오. 여러 시간에 걸쳐서 이 수치를 모니터 해보시면, 서버가 많이 사용되고 있는지, 적게 사용되고 있는지 느낄 수 있을 것 입니다.

SQL Server:Latches\
래치는 본질적으로 “경량 잠금” 입니다. 기술적인 관점에서, 래치는 가볍고, 짧은 동기화 개체입니다. 래치는 마치 잠금 처럼 동작하고, 예상치 않은 변화로부터 데이터를 보호하기 위한 목적을 가지고 있습니다. 예를 들면, 하나의 행이 버퍼로부터 SQL서버의 저장소 엔진으로 이동될 때, 이 매우 짧은 시간 동안의 이동 중에 행 내부의 데이터 변형을 방지하기 위해서 SQL서버에 의해서 래치가 사용되어 집니다.마치 잠금과 같이, 래치는 데이터베이스의 행들에 대해 접근하지 못하게 SQL서버를 방해 할 수 있고, 이는 성능에 안 좋은 영향을 줍니다. 이러한 이유 때문에 여러분은 래치 시간을 최소화하길 원하실 것입니다. SQL서버는 래치의 활동을 측정하기 위한 3가지 다른 방법을 제공합니다.
SQL Server:Latches\Average Latch Wait Time(ms)
래치 요청들을 위해 대기해야 하는 시간입니다. 이는 오직 대기해야 하는 래치 요청들에 대한 측정값입니다. 대부분의 경우에 대기가 없습니다. 따라서, 이 값은 모든 래치에 대한 것이 아니라, 대기 해야 하는 래치에 대해서만 적용된 값임을 유념하십시오.
SQL Server:Latches\Latch Waits/sec
이 값은 즉시 승인 받지 못한 래치 요청수입니다. 다시 말해서, 1초 동안에 대기 해야 했던 총 래치의 수입니다. 따라서, 이는 Average Latch Wait Time으로 부터 측정된 래치들 입니다.
SQL Server:Latches\Total Latch Wait Time (ms)

이는 지난 초 동안의 총 래치 대기 시간 (ms) 입니다.
이 값을 읽을 때, 성능카운터에서 배율을 정확히 읽었는지 확인하십시오. 배율은 카운터 값마다 다르게 표시될 수 있습니다. 제 경험에 비추어 볼 때, Average Latch Wait Rime 카운터는 거의 변함이 없습니다. 반면에 다른 두 개의 카운터(Latch Waits/sec , Total Latch Wait Time (ms)) 는 SQL서버가 뭘 하느냐에 따라서 큰 변동폭을 보일 수 있습니다.
각각의 서버가 약간씩 다르기 때문에, 래치 활동도 각 서버마다 다릅니다. 전형적인 작업부하가 있을 때, 이 카운터에 대한 기준 값을 확보해 두시는 것은 아주 좋은 생각입니다. 이는 현재 어떤 일이 발생하고 있는가에 대해서 래치 활동이 평상시 보다 많은지 적은지에 대한 비교자료가 될 것입니다.
래치 활동이 기대치 보다 높다면, 이는 종종 하나 혹은 두 개의 잠재적인 문제점들을 나타냅니다. 첫째, 여러분의 SQL서버가 보다 많은 메모리를 사용할 수 있음을 의미할지도 모릅니다. 래치 활동이 높다면, 버퍼 캐시 히트 비율이 어떤지 확인하십시오. 이 값이99% 이하라면, 보다 더 많은 양의 메모리가 서버의 성능에 도움을 줄 것입니다. 만약 99% 이상이라면, 문제를 유발하는 것은 IO시스템일수도 있습니다. 빠른 IO시스템은 서버 성능에 유리합니다. 래치에 대해서 보다 더 많이 배우고, 실험해보고 싶으시면, 여기 두 개의 명령이 있습니다.
SELECT * FROM SYSPROCESSES WHERE waittime>0 and spid>50
이 쿼리는 현재 대기상태에 있는 waittype, waittime, lastwaittype, waitresource, SPID들을 표시해 줍니다. lastwaittype은 래치 종류를, waitresource는 SPID가 어떤 개체를 위해 대기 중인지를 알려줍니다. 이 쿼리를 실행하게 되면, 실행 시점에 대기가 발생하고 있지 않다면, 아무런 결과도 얻지 못 할 지도 모릅니다. 그러나 계속해서 실행하다 보면, 결국 몇몇 결과를 얻게 될 것입니다.
DBCC SQLPerf (waitstats, clear) --대기 통계초기화
DBCC SQLPerf (waitstats) -- SQL서버 재시작(대기 통계 초기화) 이후의 대기 통계정보
이 쿼리는 대기유형, 대기시간과 함께 현재의 래치들을 나타내줍니다. 여러분은 아마도 통계정보를 초기화하길 원할 겁니다. 그런 다음에는 어떤 래치가 가장 많은 시간을 차지하는지 알기 위하여, DBCC SQLPerf(waitstats)명령을 짧은 시간에 걸쳐서 정기적으로 실행하십시오.

SQL Server: Locks\Average Wait Time(ms)
만약에, 사용자들이 트랜잭션의 완료를 위한 대기시간 때문에 불만을 나타낸다면, 여러분은 개체 잠금이 이 문제가 되고 있는지 찾고 싶을 것 입니다. 문제점을 찾기 위해서, SQL Server Locks Object: Average Wait Time (ms) 카운터를 사용하십시오. 이 카운터는 database, extent, key, paLock Timeouts/secge, RID, table의 다양한 잠금에 대한 평균 대기 시간 정보를 측정합니다. DBA로써, 여러분은 평균 대기 시간이 얼마 정도까지 허용될 수 있는지 결정해야 합니다. 한가지 방법으로써, 개별 잠금 종류에 대해서 장시간 동안 이 카운터 항목을 모니터 하시고, 각 잠금 별 평균을 파악하시는 겁니다. 그리고 그 평균값을 참고 자료로 활용 하시는 거죠. 예를 들어, RID의 평균 잠금 대기시간이 500ms 라면, 500보다 큰 대기시간을 가지는 개체들은 , 잠재적인 문제점을 가지고 있다고 판단할 수 있을 것입니다. 특히 500보다 훨씬 크거나, 장시간 동안 연장되는 개체들은 더 쉽게 판단할 수 있습니다.

여러분이 트랜잭션 지연에 의한 단일 혹은 다양한 종류의 잠금을 확인 할 수 있다면, 어떤 트랜잭션들이 잠금의 원인이 되었는지 확인할 수 있는지 알기 위해서 조사하길 원할 것 입니다.

SQL Server: Locks\Lock Timeouts/sec

리소스에 잠금을 걸기 위해 대기하면서 타임 아웃된 잠금 요청 횟수를 나타냅니다.

SQL Server: Locks\Lock Waits/sec
즉시 충족시킬 수 없고, 잠금을 허가하기 위해서 호출자가 기다려야 하는 잠금 요청의 수
SQL Server: Locks\Number of Deadlocks/sec
만약 여러분들의 데이터베이스들이 데드락 문제로 괴로워하고 있다면, SQL Server Locks Object: Number of Deadlocks/sec 카운터를 통해서 추적할 수 있습니다. 그러나, 이 값이 상대적으로 높지 않다면, 이 값은 초단위로 측정되기 때문에 여러분은 더 많이 보기 원할 것입니다. 그리고, 눈에 띄게 보여지기 위해서는 다량의 데드락이 있어야 합니다. 그러나, 여전히 이 카운터는 여러분이 데드락 문제를 가지고 있는지 확인하기 위해서 가치있는 항목입니다. 차라리, 데드락을 추적하기 위해서 프로필러를 이용하십시오. 이는 보다 상세한 정보를 제공할 것입니다. 데드락 문제를 발견하기 위해서 Number of Deadlocks/sec 카운터를 활용하시고, 좀 더 세부적인 분석을 위해서 프로필러를 사용하십시오.
SQL Server: Memory Manager\Memory Grants Pending

작업 영역 메모리 허가를 위해 대기하고 있는 현재의 프로세스 수

SQL Server: Memory Manager\Target Server Memory(KB) & Total Server Memory(KB)

이 두 카운터를 관측하는걸 고려하십시요. SQLServer:Memory Manager: Total Server Memory (KB) and SQLServer:Memory Manager: Target Server Memory (KB). 첫번째 카운터 SQLServer:Memory Manager: Total Server Memory (KB) 는mssqlserver서비스가 메모리를 얼마나 사용하고 있는가를 말해줍니다. 이것은 SQL서버 Bpool영역으로 커밋된 전체 버퍼수를 포함하고, ‘OS in Use’ 로 표시되는 OS버퍼들도 포함합니다. 두번째 카운터, SQLServer:Memory Manager: Target Server Memory (KB)는 SQL서버가 얼마나 많은 메모리를 가용할 수 있는가를 나타냅니다. 이는 SQL서버가 시작시에 예약한 버퍼수에 기초합니다. 만약, Total Server Memory (KB)이 Target Server Memory (KB)보다 작다면, 이는 SQL서버가 충분한 메모리를 가졌고, 효율적으로 사용하고 있다는 것을 의미합니다. 반면에 Total Server Memory (KB)이 Target Server Memory (KB)보다 크거나 같다면, 이는SQL서버가 메모리 압박을 받고 있고, 더 많은 물리적 메모리에 액세스 하고 있음을 나타냅니다.

SQL Server: SQL Statistics\Batch Requests/sec
SQL서버가 얼마나 바쁜지 알기 위해서, SQLServer: SQL Statistics: Batch Requests/Sec 카운터를 모니터 하십시오. 이 카운터는 초당 SQL서버가 받는 배치 요청 수를 측정하고, 일반적으로 서버의 CPU들이 얼마나 바쁜지 나타냅니다. 말하자면, 초당 1000배치가 넘어서면, SQL서버가 매우 바쁘다는 것을 나타내며, CPU병목 현상이 아직 나타나지 않고 있다면,조만간 CPU병목 현상이 나타날 것임을 알 수 있습니다. 물론 이 수치는 상대적인 것이며, 여러분의 하드웨어가 고 사양이라면, 보다 더 많은 초당 배치요청 수를 커버할 수 있을 것입니다. 네트워크 병목의 관점에서 보자면, 100Mbps 네트워크 카드는 초당 3000 배치 요청을 처리 할 수 있습니다. 만일 네트워크 병목이 심한 서버를 운영하고 계시다면, 네트워크 카드를 2개이상 늘리거나, 1Gbps 네트워크 카드로 교체 할 필요가 있을 것입니다.

몇몇 DBA들은 전체 SQL서버활동량을 측정하기 위해서 SQLServer: Databases: Transaction/Sec: _Total 카운터를 모니터 하는데, 이는 좋은 방법이 아닙니다. Transaction/Sec 카운터는 전체 활동량이 아닌 한 트랜잭션의 내부활동을 측정하며, 왜곡된 값을 나타냅니다. 대신에, SQL서버의 전체 활동량을 측정하는 SQLServer: SQL Statistics: Batch Requests/Sec 카운터를 사용하시기 바랍니다

SQL Server: SQL Statistics\SQL Compilations/sec
TSQL코드의 컴파일은 SQL서버의 일반적인 동작입니다. 그러나, 이 컴파일이 CPU와 다른 리소스들을 많이 잡아 먹기 때문에, SQL서버는 가능한 많은 실행계획을 캐시에 저장해서 실행계획이 컴파일 되지 않고 재사용되도록 시도합니다(실행계획은 컴파일이 발생할 때 생성됩니다). 보다 더 많은 실행계획이 재 사용 되어지면, 서버에 대한 부담은 더 적어지게 되며, 전체적인 성능은 더욱 더 향상 됩니다.

SQL서버가 얼마나 많은 컴파일을 하고 있는지 확인 하려면, SQLServer: SQL Statistics: SQL Compilations/Sec 카운터를 모니터 하십시오. 여러분이 기대하시는 것처럼, 이 카운터는 초당 얼마나 많은 컴파일이 SQL서버에 의해서 실행되었는지를 측정합니다.

말하자면, 이 카운터의 수치가 초당 100을 넘어서면, 불필요한 컴파일 오버헤드를 경험하고 계신 것 입니다. 이러한 높은 수치는 여러분의 서버가 매우 바쁨을 나타내거나, 불필요한 컴파일들이 실행되고 있다고 볼 수 있겠습니다. 예를 들어, 오브젝트의 스키마가 변경되거나, 병렬로 실행계획이 잡혀있던 것이 직렬로 실행되어야 하거나, 통계가 다시 계산되었다거나 하는 등의 이유로 SQL서버로부터 재 컴파일 하라는 지시를 받았을 수도 있습니다. 어떤 경우에는, 불필요한 컴파일을 줄이기 위해서 여러분의 노력이 필요할 수 도 있습니다. 만약, 여러분의 서버가 초당 100회 이상의 컴파일을 수행한다면, 이 원인이 여러분이 조절할 수 있는 것인지 아닌지 찾기 위해 애 쓰셔야 합니다. 너무 많은 컴파일은 SQL서버의 성능에 악영향을 끼칩니다.

SQL Server: SQL Statistics\Re-Compilations/sec
초당 SQL문이 재 컴파일 되는 수 (역주 : 컴파일이 되어서 버퍼에 올라가 있으면 SQL Server는 다시 컴파일을 하지 않고 버퍼에 있는 컴파일된 것을 사용하게 됩니다.. 하지만 어떠한 특정 이유로 그 SQL문들은 재컴파일을 하게 되는데, 앞서 컴파일 카운트를 보셨듯이 컴파일 자체가 Server의 리소스를 사용하는 것 이기 때문에 되도록이면 재 컴파일 이슈가 없는것이 좋습니다. 해당 카운트가 너무 높다면 프로파일러나 DMV로 일일이 살펴볼 필요가 있습니다.)
SQL Server Access Methods Object: Full Scans/sec
그런데 가끔 인덱스 탐색보다 테이블 스캔이 빠른 경우에, 일반적으로 적은 테이블 스캔이 보다 많은 테이블 스캔 보다 좋다. 여러분의 서버에서 얼마나 많은 테이블 스캔이 발생하는지 알아보기 위해서, SQL Server Access Methods Object: Full Scans/sec 카운터를 사용하십시오.이 카운터는 단일 데이터베이스가 아닌 전체 서버에 대한 값이라는 사실을 염두에 두셔야 합니다. 이 카운터 값으로 알게 될 사실 하나는 가끔씩 예측이 가능한 스캔 형태를 나타낸다는 것 입니다. 대부분의 경우에 이 값들은SQL서버가 내부적으로 사용하는 것 들입니다.

여러분의 응용프로그램에서 나타나는 불규칙적인 테이블 스캔들을 파악하길 원하실 것입니다. 과도한 테이블 스캔이 발생될지를 고려하기 위해서 프로필러 데이터를 수집하고 인덱스 튜닝 마법사를 통해서, 어떤 것이 원인이 되는지 결정 할 수 있게 도움을 받을 수 있습니다. 그리고 몇몇 인덱스를 추가함으로써 테이블 스캔을 줄일 수 있을 것 입니다. 물론 SQL서버는 이 작업을 훌륭하게 수행할 것이고, 더 효율적이라면, 인덱스를 사용하는 것 대신에 테이블 스캔을 수행 할 것입니다. 그러나 내부적으로 어떤 일이 발생하는지 찾아 보지 않는 한 여러분은 알지 못 할 것입니다.
해당 정보들은 아래 블로그에서 "펌"하여 정리한 것 입니다.
[출처] http://cid-f08341357ef26d93.spaces.live.com/blog/cns!F08341357EF26D93!166.entry
[출처] http://ceusee.springnote.com/pages/260330
[원문] http://www.sql-server-performance.com/performance_monitor_counters_sql_server.asp
[번역] 김종균 (jkkim@techdata.co.kr)

2010년 2월 22일 월요일

개발자에 대처하는 우리의 자세

CBT가 코앞으로 다가오면서 바빠지고 있다. 중요한 마일스톤을 넘어갈 때마다, QA가 해야할 일이 별로 없다면 얼마나 행복한 상황인가. 하지만 역시 현실은 시궁창.

늘 그렇듯이 크리티컬한 이슈는 하루가 멀다하고 터지고 심지어는 가장 기본적인 컴포넌트에서조차 빵구가 나기 시작한다. 덕분에 마무리 작업은 순조롭지 못하다. 빌드가 매일매일 릴리즈되고 테스트도 거의 매일 수행된다. 그저께도 밤늦게까지 테스트를 수행했지만 결과는 그리 신통하지 못했다.

나쁜 일이 만성이 되는 것처럼 무서운 일이 있을까.

아무렇지도 않게 시험 실패 보고서를 날리고 피곤한 몸을 이끌고 자정이 다되어서야 집으로 들어갔다.

다음날 아침, 출근해보니 몇몇 핵심 개발자들이 이미 출근해 있었다. 보고서를 날리기 전에 크리티컬 이슈가 터질 때마다 개발관리 팀에 그 사실을 알려주었더니, 시일은 촉박한데 생각보다 빌드 상태가 심각하다고 생각한 것인지 정시보다 한 두 시간 먼저 출근해서 버그를 수정해 달라고 한 모양이다.

새벽부터 출근해 쉽지 않은 문제들과 씨름하고 있는 개발자들에게 웬지 미안한 마음이 들었다.

하지만 출근 시간을 전후해 다른 개발자들이 출근하면서 그들끼리 나누는 이야기를 듣고 있자니, 미안한 마음이 싹 가셔버렸다.

마치 우리 때문에 하지 않아도 될 일을 새벽같이 등 떠밀려서 나와서 하는 것처럼 툴툴거리는 소리들이 들린다. 패널 하나를 마주하고 앉아있는 QA팀에게 들으라는 것처럼, 평소보다 더 크고 씩씩한 목소리로 “아침 7시부터 나와서 누구 때문에 버그 수정하고 있는데 죽겠다”라고 얘기한다...

이봐, 우리는 우리 일을 열심히 한 거고, 당신들은 당신들 일을 열심히 하지 못한 거 아냐.

당신들이 열심히 코드를 잘 만들었으면 이런 일이 없었을 거 아냐!

… 라는 말이 목구멍까지 나왔지만… 나는 소심하므로 그냥 꾹 참았다.

그리고 또 이렇게 생각했다.

이봐, 우리가 밤새 버그를 찾은 덕분에 당신이 잘리지 않은 줄 알아.

만약 그 버그가 살아남아서 사용자가 보고했으면 당신은 잘릴 수도 있었어.

그러니 밤늦게까지 버그를 찾아준 우리에게 고마워 해야 해. 안그래?

… 라고.
하지만 어떻게 생각해보니, 프로젝트 뒤치닥거리 하느라 눈코뜰새 없는 우리 개발자들이 좀 불쌍하기도 하다.

생각해보니, 내가 열심히 하면 당신들이 힘들겠구료.

그래도 어쩔 수 없다오.

그래야 나도 살고, 당신도 살고, 프로젝트도 살아남을테니 말이오.


그냥 고생 좀 하시구랴.
허허허.


<QA를 대하는 경영진들의 자세>

출처 :http://angel927.tistory.com/62

리스크 기반 테스팅에 대한 몇 가지 단상

1. 사용성 측정을 어떻게 할 것인가?

o 메트릭을 정해놓고 1부터 5까지의 점수를 줘서 평균내는 방법

o QA나 개발자가 평가하는 것은 의미가 없다

o UX(User eXperience) 과 같은 전문가가 있어야 한다(특히 게임과 같은 Customer Target 도메인에서)

2. 테스트 계획 단계에서 리스크 분석이 수행되고 그 결과는 프로젝트의 이해당사자들에게 공유 및 승인되어야 한다.

3. 잔존 리스크(Residual Risk): 테스트 종료 시점에서 아직 해결되지 않은 버그들 역시 잔존 리스크로 봐야한다. -> These should be reported through test result report!

4. Severity Integrity Level(안전 무결성 수준)

5. 위험에 대한 추적성(Tracebilty for risk)

6. 프로젝트 리스크와 요구사항 자체의 결함(일반적으로 명확하게 제시되지 않으므로...)

7. 항상 모든 항목의 매핑이 중요!!!

 

출처 :http://angel927.tistory.com/64

동등분할(등가분할)기법에 대한 몇 가지 단상

렉스 블랙이 쓴 책에서 동등분할(혹은 등가분할)에 관한 부분을 읽으면서 느낀 몇 가지를 적어보면 다음과 같다. 이 양반이 글은 좀 어렵게 쓰는 경향이 있지만 그래도 경력이 경력인지라 생각할 거리를 꽤 많이 던져준다.

1. 명세 기반 테스트는 요구사항에 기반하고 있다(Specification-based tests are requirement-based).

: 명세 기반 기법, 그리고 블랙박스 기법 중의 대표적인 기법이 동등분할이다 보니 그 얘기하면서 다시 리뉴얼해주는 부분임. 명세는 요구사항을 반영하고 있어야 한다. 당연한 이야기.

2. 등가분할을 통해 나누어진 각 클래스 간에는 교집합 영역이 없어야 한다.

: 등가분할은 동일한 메타 태그 아래 동일한 성격을 가지는 데이터(무엇에 관한 것이라도 상관없다)로 분류되는 것이다. 나누어진 각 데이터 집합 간에는 서로 겹치는 값이 있어서는 안 된다. 동등분할로 나뉘어진 입력 데이터 값에서 임의의 한 값을 취했을 때, 2개 이상의 클래스에 속한다면 그것은 데이터를 잘못 분할한 것이다.

3. 등가분할의 값들은 서로 독립적이어야 한다(종속적이라면 수행할 수 없다)

: 예를 들어, OS 항목과 일반 애플리케이션 항목을 등가분할 한다고 가정해보자. OS를 크게 MAC과 윈도로 나누었다. 애플리케이션은 A, B, C로 나누었는데, 이중 C가 MAC에서만 돌아가고 윈도에서는 돌아가지 않는 애플리케이션이라고 가정해보자. 이럴 경우 일반 애플리케이션 항목의 값이 OS 값에 따라 Valid가 결정되므로 등가분할을 사용할 수 없다.

4. 유효하지 않은 값들도 테스트해서 예외 처리되어야 하는지를 확인해야 한다.

: 개인적으로 등가분할 기법에서 가장 중요한 부분 중의 하나라고 생각한다. 등가분할의 본래 목적은 등가분할되는 데이터 입력값들의 유효한 출력값을 검증하는 것과 함께, 유효하지 않은 입력값이 앞서 검증된 유효한 입력값의 유효한 출력값과 동일한 출력값을 내는지 검증하는 것도 포함된다.

5. 등가분할을 사용해도 동등한 값이 나와야 하는 결과도 있고, 다른 결과가 나와야 하는데 동등한 결과가 나올 때도 있다.

: 등가분할을 사용한다고 하더라도 다른 속성의 결과값은 동일할 수 있다. 즉, 서로 다른 동등분할 클래스의 입력값을 사용한다고 하더라도, 다른 속성은 동일한 출력값을 낼 수 있다는 것이다. 예를 들어, 노인과 청소년으로 분류하는 것(나이에 따른 동등분할)은 정상이나 실행속도(애플리케이션의 속도, 즉 다른 속성)에는 차이가 없어야 한다. 이와 함께 데이터 입력 이후 출력값을 내는 과정에서 작용하는 환경 변수나 기타 프로세스 역시 고려해야 하는 대상이다. 예를 들어, 청소년으로 분류되었지만 (필터링과 같은 환경 변수를 조작해서) 노인이 들어갈 수 있는 성인 사이트로 들어갈 수도 있다. 

출처 :http://angel927.tistory.com/65

만약 당신이 새로 부임한 QA 매니저라면&hellip;&rdquo;

만약 당신이 새로 부임한 QA 매니저라면…”

By James A. Whittaker

오늘 아침, 나는 한 독자로부터 아래 내용의 메일을 수신했다.

나는 테스트 관리자(Test supervisor)로 일하다가 어제부로 QA 관리직(QA Management position)으로 임명되었습니다. 한편 흥분되기도 하지만 한편으로는 두렵기도 하네요. 이런 마음을 어떻게 정리해야 할 지 잘 모르겠습니다. 스타웨스트(StarWest)에 참가하고 나서, 그리고 또 당신의 블로그를 팔로잉하고 나서부터 나는 당신의 의견에 무척 흥미를 가지게 되었습니다.

만약 당신이 새롭게 QA 매니저가 되었다면, 그리고 당신이 지금 알고 있는 것들을 모두 알고 있다고 가정한다면, 가장 중점을 두어야 할 일 5 ~ 10 가지는 무엇일까요?”

나는 이 독자가 내개 보낸 신뢰로 인해 우쭐해지기는 했지만, 이런 질문을 나에게만 물어보는 것은 부적절하다고 생각했다. 나는 이 질문에 대해서 공개적으로 답변해, 독자 여러분들의 경험을 여기에 더 활용하고 싶다. 덧붙여 나 역시 매일 이런 흥분과 공포를 느껴봤었고, 나 스스로도 여러분의 의견을 활용할 수 있기 때문에 다른 사람들의 의견이 어떨지 더욱 궁금하다. 먼저 나의 의견 몇 가지를 여기에 제시하고, 추후의 포스트에서 몇 가지를 더하기로 한다(그렇지 않다면 다른 사람들이 먼저 포스팅을 해도 좋다).

당신의 제품을 직접 사용해보고 애착을 가져라

(Start living with your product, get passionate about it)

당신의 제품을 직접 구매해보라.[1] 그리고 제품의 광고 문구(Sales pitch)를 연상해보라. 당신 제품이 타사 제품과의 경쟁에서 이길 수 있는 장점을 생각해보라. 하지만 늘 테스터로서 갖춰야 할 회의론(skepticism)은 유지해야 한다. 테스트/QA 매니저들 역시 개발 관리자와 마찬가지로 제품에 대한 열정을 가지고 있어야 하지만, 그들과 달리 우리는 제품에 열정을 가질 만한 “증거(Proof)”를 가지고 있어야 한다는 것이 그들과 틀린 점이다. 테스트 팀은 광고 문구에 대응하는 제품의 기능성에 대한 테스팅을 멈추지 말아야 한다는 것을 기억하라.

여기에 더해, 스스로 당신 제품을 열성적으로 사용하는 사용자가 되어 실제 생활 속에서 당신의 제품을 사용해보라.

최근 나는 노트북 대신 크롬 OS가 설치된 넷북만을 사용해 나의 주된 업무 대부분을 처리하고 있다. 사람들이 복도에서 크롬 OS 넷북을 들고 다니면서 업무를 보는 나의 모습을 볼 때마다, 나는 사람들에게 매일 크롬 OS의 광고 문구를 떠올리게 하는 것이다. 훌륭한 사례다. 나는 또한 크롬 OS와 넷북 환경의 부족한 부분에 대해서도 잘알게 되었고, 이에 대해서 아직도 충족되지 않은 부족한 부분들은 기록으로 남기기도 한다. 이러한 기록들은 개발자나 다른 이해 당사자들과 논의할 만한 훌륭한 소재를 제공해 주며, 경쟁사 제품은 이런 부분을 어떻게 커버하고 있는지 궁금증을 유발하게 하기도 한다. 크롬 OS 넷북에서 어떤 중요한 일을 처리하지 못할 때, 경쟁사 제품을 사용해 봄으로써 사용자들이 우리 제품의 단점을 어떻게 받아들일지 알 수 있을 것이다. 아울러 우리 제품에 대해서 불평을 제기하는 고객들과 어떻게 진심으로 대화할 수 있을지에 대해서도 알게 될 것이다. 매일 매일 실제 사용자로서 내가 만든 제품에 깊이 빠져보라. 이는 새로운 제품을 만들기 시작하는 훌륭한 방법이 될 것이다.

테스트 계획에 집중하고 그 우선 순위를 높여라

(Really focus on the test plan, make it an early priority)

만약 당신이 현존하는 제품의 현존하는 테스트 매니저 직을 인계받았다면, 이미 기존의 테스트 계획이 존재하고 있을 것이다. 물론 그 계획이 충분하지 않을 가능성도 많다. 내가 당신의 전임자를 데려와 왜 그런지에 대해서 꼬치꼬치 캐물을 정도로 잔인한 사람은 아니다. 하지만 나는 대부분의 테스트 계획은 일시적인 것에 지나지 않는다는 것을 인정할 정도로 진실에 충실한 사람이기는 하다.

자, 이제 내가 말하려던 바를 좀 더 자세하게 알아보자. 테스터들은 불명확하게 디자인된 문서에 대해서 쉽게 불평을 쏟아내기 마련이다. 개발자들은 코딩을 시작하면서 급하게 디자인 문서를 만들기 시작하거나 다이어그램을 그리기 시작하고, 이렇게 시작한 설계는 코드가 생명을 가지기 시작하는 시점에서부터 부실해지기 십상이다. 곧 이어서 코드가 설계와 부합하지 않게 되고, 이로 인해 문서는 신뢰를 잃게 된다. 당신이 이런 경우를 겪어보지 않았다면 이는 정말로 축하할만한 일이다. 하지만 내 경험상, 문서가 지속적으로 업데이트 되는 경우보다 이런 경우가 더 일반적이었다.

이런 상황은 테스터들이 불평을 토해내기 딱 좋은 상황이다. “제품이 어떻게 동작하는지에 대해서 충분하게 설명되지도 않은 명세를 가지고 어떻게 제품을 테스트 할 수 있나요?” 라고 말이다. 그러나 우리 테스터들도 테스트 계획에 대해서 똑 같은 행동을 하고 있지 않는가? 우리 역시 급하게 테스트 계획을 작성하며, 테스트 케이스(자동이던 수동이던)는 작성을 시작하는 순간부터 테스트 계획과는 전혀 관계가 없는 나름대로의 새로운 생명을 가지게 된다. 우리가 새로운 개발 내용을 추적하고 우리가 경험한 것을 통해 테스팅에 대한 새로운 시각을 가지게 되면서 테스트 케이스는 기존의 테스트 계획으로부터 멀어지게 된다. 이 단계에서 테스트 계획은 바로 디자인 문서와 같아진다. 이미 완성되어버린, 과거 시점의 문서가 되어버리는 것이다.

만약 당신이 지금 새롭게 부임한 테스트 매니저라면, 이러한 문서들을 수정하는 것을 최우선 업무로 설정하라. 그럼으로써 당신은 당신 제품의 기능을 파악할 수 있을 뿐만 아니라, 현재의 테스트 인프라스트럭쳐에서 어느 부분이 보강이 필요한 지에 대해서도 알게 될 것이다. 여기에 더해, 이 작업은 당신이 개발 관리자들과 의사소통하게 되는 계기를 만들어 줄 것이며, 그들은 또한 이 작업을 통해 당신이 품질에 매우 열정적인 자세를 가지고 있다는 것을 알게 될 것이다. 구글의 개발 관리자들은 잘 짜여진 테스트 계획을 선호한다. 이렇듯 훌륭하게 짜여진 테스트 계획은 개발 관리자들에게 당신이 지금 하고 있는 일을 잘 파악하고 있다는 확신을 심어주게 된다.

당신이 속한 조직의 릴리즈 프로세스와 우선순위에 대해 이해하라

(Understand your orgs release process and priorities)

사이클 후반부의 프리-릴리즈 테스팅(Pre-release testing)은 전체 개발 사이클에서도 가장 신경쓰이는 부분 중의 하나다. 테스트 관리자는 적합한 테스팅을 수행하는 것과 릴리즈 일정을 준수하는 것 사이에서 균형을 유지해야 한다. 나는 모든 개발 회의에 테스트 관리자가 참석하는 것, 특히 릴리즈 일정이 다가올수록 하나의 회의도 빠짐없이 참석해야만 한다는 것을 권장한다. 개발자들이 걱정하고 근심하는 것들에 대해서 깊은 관심을 가져야만 한다. 악몽같은 시나리오는 늘 프로세스의 마지막 부분에서 무대에 등장하기 마련이다. 이러한 시나리오가 발생하지 않도록, 아무리 늦은 시점이라도 빌드 검증을 위한 테스트 스위트에 테스트 케이스를 추가하는 것을 두려워하지 마라.

여기서 핵심은 사이클 후반부의 프리-릴리즈 테스팅을 다른 사람들이 거부감없이 받아들이도록 해 장애없이 테스트가 진행되도록 하는 것이다. 개발자들은 그들이 노력을 쏟아부은 성과물이 허사가 될까봐 이러한 “최종” 테스트에 대해 겁먹을 수 있으므로, 당신의 프리-릴리즈 테스팅 계획이 가장 마지막 테스트 업무라고 이해시켜라. 어떻게 릴리즈 테스팅이 수행되었는지에 따라 개발팀이 움직이도록 하는 것이 아니라, 그들 자체를 아예 당신의 프리 릴리즈 테스팅 계획 속에 포함시켜 생각하라. 나는 구글에서 테스트 팀이 점점 수동 테스팅에 역량을 집중하는 것에 대해 개발자들이 이를 전폭적으로 환영하고 있다는 것을 알게 됐다. 당신의 개발팀이 안심할 수 있는 영역을 찾아내고, 충분한 시간을 가지고 적합한 수준의 테스팅을 수행하는 것과, 가능한한 마지막 몇 시간 혹은 며칠 동안을 걱정거리 없도록 만들어주는 것과의 사이에서 균형을 잡아야 한다.

당신의 테스팅 프로세스에 대해 의문을 가져보라

(Question your testing process)

모든 테스트 케이스를 읽어보고 모든 자동화 테스트를 리뷰하는 것에서부터 시작해보라. 테스트 케이스로부터 테스트 계획을 매핑시킬 수 있는가? 각 컴퍼넌트 당 얼마나 많은 테스트를 수행하는가? 기능에 대해서는? 테스팅 프로세스 외부에서 버그가 발견되었을 때 이를 위한 테스트 케이스를 추가하는가?

테스트 매니저로서 테스트가 어느 정도의 완성도와 철저함을 가지고 있는지에 대해 책임을 지는 것은 바로 당신의 몫이다. 비록 당신이 많은 테스트를 작성하거나 수행하지는 않더라도, 그들 모두를 머리 속에 담아두고 있어야 하며 변경 내역이나 현실과의 괴리를 인식할 수 있는 제일 첫 번째 사람이어야 한다. 아마도 이 일이 새로운 매니저가 부임했을 때 가장 먼저 달려들어야 할 일일 것이며 또한 오랫동안 시간을 소비해야 할 일일 것이다.

혁신할 수 있는 방법을 찾아라(Look for ways to innovate)

개발자들에게 좋은 평가를 받는 가장 쉬운 방법은 현상을 유지하는 것이다. 많은 개발 관리자들이 유순하고 그들에게 굴종하는 테스트 팀을 선호한다. 하지만 그들 역시 예측 가능하고 쉽게 이해할 수 있는 테스팅 사례를 좋아한다. 이로써 걱정거리 하나는 줄어든 셈이다(비록 명백하게 비효율적이기는 하지만, 익숙한 현재의 방법을 계속 사용하면 되니까).

새로운 매니저로서, 그렇게 쉽게 되도록 놓아두지 않는 것 또한 당신이 할 일이다! 당신은 당신이나 당신의 팀이 수행하기에 힘들거나 비효율적이라고 생각되는 프로세스의 부분들을 목록으로 만들어야 한다. 여기가 혁신을 적용해야 하는 지점이다. 개발자들로부터의 신경질적인 반응에 대비해야 한다. 당신이 직접 이런 업무를 수행하고 좋은 사례를 만듦으로써 테스팅 업계에 도움을 줄 수도 있으니 일정 기간 이 작업에 헌신해보라.

어떻게 최고의 혁신을 수행할 것인가라는 질문에 보편적으로 적용될 수 있는 답은 없다. 내가 사용했던 방법은 당신 팀 안에서 스타를 찾아내고 그 사람이 열정을 쏟아부을 수 있는 부분에 전념할 수 있도록 하는 것이었다. 이것이 관리자로서 생산성을 향상시키고 혁신을 배양하는 가장 중요한 일이라 할 수 있을 것이다.


[1] 역자 주: 원문 표현은 “Drink your product’s kool-aid”라고 되어있다. “Drink kool-aid”라는 표현은 사용자의 주관없이 제조사의 말만 믿고 덥석 제품을 사버리는 것과 같은 경우에 사용된다. 표현의 유래는 여기에서 참조.

 

출처 :http://angel927.tistory.com/70

CentOS에서 yum으로 php5.2설치

공식 저장소에서는 아직까지도 php 5.1.6 버전만을 지원하고 있다, 느려 - - ;
최신의 함수등을 이용하려면 테스팅 저장소를 이용해야 한다.
세줄요약하면 다음과 같다.

wget http://dev.centos.org/centos/5/CentOS-Testing.repo
mv CentOS-Testing.repo /etc/yum.repos.d/
yum --enablerepo=c5-testing update php

출처 :http://movie.somegate.com/topic_new.php?topic_uid=3973

2010년 2월 21일 일요일

통계적 디버깅 @ 마이크로소프트

이전에 회사에서 근무할 때 소프트웨어를 릴리즈하면 테스트 팀에서 버그를 찾아 버그관리 시스템에 등록했었다. 버그관리 시스템에 등록할 때 테스터는 문제의 재현 경로, 심각도, 발생빈도등을 기술해 올리는데 프로젝트 관리자는 이러한 정보를 바탕으로 적절한 인력에게 문제를 할당하고 개발자는 이렇게 할당된 문제를 꼼꼼히 검토하고 실제로 코드를 수정한 후 역시 시스템을 통해 문제해결책을 기술하면 다음번 릴리즈때 테스터가 이를 다시 검토하는 식으로 최종 출시때까지 반복했다.
나름 상당히 선진적인 시스템이라고 할 수 있지만 가장 큰 문제는 테스터의 버그 리포팅이 순수하게 사람에 의해 진행된다는 점이었다. 우선은 테스터의 질에 따라 질좋은(?) 버그의 발견 확률이 크게 달라지고, 버그가 발견되었다 하더라도 문제가 발생한 순간의 스택 덤프라던가, 실제 프로그램의 내부 상태를 알 수 있는 방법이 없었기에 테스터는 단순히 발견 경로에 대한 정보를 손으로 기술할 수 밖에 없었다. 더 큰 문제는, 많은 경우 문제의 재현이 쉽지 않다는 데에 있다. (재현이 어려운 문제와 관해서는 이전의 글에서 기술한 바 있다). 그래도 여기까지는 어쨌든 전문적인 테스터에 의해 진행되므로 사정은 좀 낫다.
우여곡절끝에 버그 추적 시스템에 등록된 모든 문제를 해결하고 나서 출시를 하면 과연 문제가 없을까? 당연히 그렇지 않다. 엄청나게 많은 소비자의 손에 들어가면 잘 드러나지 않았던 오만가지 문제들이 줄줄이 드러나게 마련이다. 출시 후에 고객에 의해 발견된 문제는 인터넷 게시판이나 고객센터등을 통해 수집된다. 이렇게 수집된 정보는 당연히 전문 테스터가 아니므로 그 형식이나 내용 기술이 불충분한 경우가 대부분이다. 이 빈약한 정보를 바탕으로 테스터와 개발자는 필사적으로 문제를 재현하고 문제를 해결한 소프트웨어를 릴리즈한다. 잘 팔리는 제품일수록 버그에 대한 소비자의 불평불만은 그에 비례해서 늘어난다. 여기에 몇번 데이다 보면, 개발자나 PM은 차라리 고과를 잘 못받을 지언정, 안팔리는 모델을 진행하면 좋겠다는 푸념을 하기에 이른다. 사용하는 사람이 적으면 문제가 잘 발견되지 않기 때문이다.
자 그럼 세계에서 가장 많은 사람들이 사용하는 소프트웨어를 만드는 마이크로소프트의 개발자나 PM들은 이러한 문제에 어떻게 대응할까? 물론 그들도 고충이 오죽하겠냐마는 그 고충을 어떻게든 줄여보고자 똑똑한 마이크로소프트는 참 많은 재미난 것들[1,2,3]을 한다. 그중에 하나가 이 글에서 이야기하고자 하는 WER(Window Error Reporting)이라는 시스템이다.
이하 아래의 모든 내용은 [1]의 논문을 참조했음을 먼저 밝힌다. 
누구나 윈도우를 사용하다가 프로그램이 이상 동작을 해서 죽어버리는 경험을 해 봤을 것이다. 그럴 때 나타나는 화면이 바로 아래의 화면이다.

보통 별 생각없이 ok를 하거나, 뭔가를 마이크로소프트에 보낸다는게 께림직한 사람들은 cancel을 눌렀을 터이다. 이 화면에서 ok를 하면 마이크로소프트는 경우에 따라 간단한 프로그램,모듈 이름등의 정보부터 스택덤프등의 상세정보까지 "자동"으로 마이크로소프트내의 WER 서버에 전송한다. 결코 사용자에게 프로그램 버젼이 무언지, 어떻게 하다가 죽었는지 물어보지 않는다. 모든 것은 자동으로 일어난다. 엄청나게 많은 사용자가 엄청나게 다양한 환경에서 프로그램을 사용하다 보니, 당연히 엄청나게 많은수의 버그들이 있을거다. 1999년에 최초로 이 시스템이 도입된 이후로 얼마나 많은 버그들이 이 WER 시스템을 통해 보고되었는지 구체적인 숫자는 나와 있지 않지만, 현재의 WER 시스템은 하루에 1억개의 버그 리포트를 수용할 수 있도록 업그레이드 되었다고 하니 대충 그 규모를 짐작해 볼 수 있다. 
이렇게 서버에 전송된 정보는 다시 프로그램에 의해 자동으로 분류되고 가공되어 개발자에게 제공된다. 이미 해결책이 알려진 버그는 자동으로 사용자에게 버그 수정 패치가 있는 웹사이트의 주소를 넘겨주는 식으로 처리된다. 이렇게 이미 해결책이 있는 버그에 대한 리포트가 전체 리포트의 90%를 상회한다고 한다. 이 단계에서 걸러지지 않은, 그러니까 아직 해결책이 알려지지 않은 버그에 대해서는 라벨을 붙에 시스템에 저장한다. 이때 WER 시스템은 클라이언트로부터 좀더 많은 정보 (stack dump등)의 정보를 요청할 수 있으며 추가적으로 개발자가 해당 버그에 대해 더 알고 싶어하는 추가 정보 (레지스트리 값, 특정 파일 내용)를 설정할 수 있도록 설계되어 있다.
워낙에 수가 많기 때문에 어찌보면 자연스런 결과일 수 있지만, 정보 전송, 분류등의 모든 과정은 자동으로 일어난다. 또한가지 중요한 특징은 워낙에 수가 많다보니 통계적인 추이를 통해 문제의 중요도, 해결책의 유효성 여부등을 확인 가능하다는 점이다. 통계를 배운 사람이라면 파레토 분포에 대해 들어보았을 것이다. 흥미롭게도 버그의 분포는 (어찌보면 당연하게도) 소수의 문제가 전체 불량의 대다수를 차지하는 전형적인 파레토 분포를 따른다고 한다. 논문에 의하면 이와같이 자동으로 수집 분류되고 통계적으로 가공된 정보를 이용해서 버그를 수정하는 것과, 사람에 의해 보고된 버그를 수정하는 것을 비교했을 때 WER을 통한 버그가 4~5배 정도 더 수정될 확률이 높았다고 한다. 왜냐면 사람에 의해 보고된 버그는 외부에 나타나는 현상만을 기술하지만, WER은 시스템의 상세한 내부 정보를 알 수 있고 방대하게 축적된 각종 통계자료를 통해 문제의 원인에 대한 다양한 유추 해석이 가능하기 때문이라고 한다.
문제없는 소프트웨어를 만드는 것은 참 힘든 일이다. 또 발견된 문제의 원인을 찾아 해결하는 것도 어려운 일이다. 하지만 이는 누구에게나 마찬가지다. 같은 문제라도, 머리를 쓰고 조금 더 잘 해볼려고 노력하면 훨씬 효과적으로 덜 마음고생하면서 할 수 있다. 회사에서 늘 같은 괴로움을 접하면서도, 조금 더 머리를 써서 잘 해볼 생각을 하지 못한 혹은 안한 걸 반성해 본다.
Reference
[1] Kirk Glerum et al, Debugging in the (Very) Large: Ten Years of Implementation and Experience, SOSP09'
[2] CHESS project homepage, http://research.microsoft.com/en-us/projects/chess/
[3] SLAM project homepage, http://research.microsoft.com/en-us/projects/slam/

[출처] 통계적 디버깅 @ 마이크로소프트|작성자 덤덤2

역사상 최악의 버그: The Therac 25

도요타 기술의 상징인 하이브리드카 프리우스의 브레이크 시스템에서 소프트웨어 '버그'가 발견되어 소프트웨어 '업그레이드'를 위한 리콜을 검토중이라고 한다 [1]. 자동차에 '업그레이드'라는 말이 왠지 낮설지만 엔진 제어 장치인 ECU를 포함해 자동차의 많은 곳에서 컴퓨터와 소프트웨어가 사용된지는 이미 오래다.

결함없는 소프트웨어를 만드는 것은 어렵다. 그런데 자동차를 포함해 우리의 생명과 직결되는 많은 장치들이 점점 더 컴퓨터와 소프트웨어에 의존해 동작하는 현실은 그리고 미래는 섬뜩하기까지 하다. Window 운영체제로 동작하는 자동차, 비행기를 그리고 원자력 발전소를 상상해 보라.

소프트웨어 버그로 인해 발생한 사고중 최악의 사건 중 하나는 무려 25년 전으로 거슬러 올라간다 [2]. 1985년에 캐나다의 AECL이란 회사는 암 종양 제거를 위한 방사선 치료기인 Therac 25라는 제품을 판매하기 시작했다. 모양은 아래 그림과 같이 생겼다.

(사진 출처: http://idg.bg/test/cwd/2008/7/14/21367-radiation_therapy.JPG )

Therac 25는 전자빔으로 피부 근처의 종양을 제거하는 Electron 모드와 X-ray로 피부 깊숙한 곳의 종양을 제거하는 X-ray 모드의 두가지 동작 모드를 지원했다. 그 전에는 각각이 별도의 장비로 되어 있던 것을 하나로 합쳐 공간과 비용을 혁신적으로 개선한 제품이었다고 한다.

그런데 X-ray 모드는 강한 방사선을 사용하기 때문에 이를 균일하고 안전하게 환자에게 쪼일 수 있게 하는 턴테이블이라고 하는 장치를 환자와 방사선 발사기 사이에 위치하도록 제어해주는 것이 필요했다. 하지만 이 장치는 Electron 모드로 동작할 때는 필요하지 않았다. 때문에 모드에 따라 턴테이블을 움직여 주어야 하는데 이러한 제어를 컴퓨터 소프트웨어가 담당하고 있었다. 불행히도 이 소프트웨어에는 버그가 있어 '간혹' X-ray 모드인 상태에서 턴테이블이 제위치에 있지 않은 경우가 발생했다. 그림으로 보면 아래와 같다.

(출처 : http://radonc.wdfiles.com/local--files/radiation-accident-therac25/Therac25.png)

정상적인 경우라면 왼쪽의 두 그림중 하나의 상태여야 하는데 소프트웨어의 오류로 인해 오른쪽과 같은 상황에서 방사능을 발사했고 이로인해 문제가 완전히 밝혀져서 고쳐지기까지 무려 6건의 사고가 발생해서 3명이 죽고 다른 3명은 심각한 방사능 후유장애에 시달려야 했다. 

이러한 상황을 만들 수 있는 몇가지 오류중 하나를 소개하면 다음과 같다. 오류가 보이는가? 힌트는 in_progress 라는 변수가 8bit 변수라는 점이다.

Thread 1 : // 턴테이블 준비 Thread. 주기적으로 수행 

   if ( system ready )

       in_progress = 0

   else

       in_progress ++

Thread 2 : // X-ray 빔 제어 Thread. 주기적으로 수행.

   if ( start key pressed AND in_progress == 0 )

       start radiation

(*) 이해의 편의를 위해 변형하였음.

컴퓨터 프로그램에 대한 지식이 조금이라도 있는 사람이라면 바로 알 수 있을 것이다. 8bit 변수는 최대 255까지 표현할 수 있기 때문에 Thread 1이 256번 수행되면 256번째 수행할 때 in_progress에 overflow가 발생해서 값이 0으로 변한다. 문제는 바로 그 순간에 start key를 누르면 실제로는 턴테이블을 준비하는 중이지만 방사능을 발사하게 되는 것이다. 어이없을 정도로 간단한 실수지만, 이 문제는 테스트를 통해 발견하기는 사실상 거의 불가능에 가깝다. 왜냐면 256 번째 Thread 1이 수행되서 overflow가 발생한 바로 그 순간에 start 키를 누를 때에만 문제가 생기고 다른 경우에는 모두 정상 동작하기 때문이다.

바로 똑같은 이유로 1996년에는 Arian 5 로켓이 폭팔했다 [3]. 지극히 정상적으로 날고 있던 로켓의 속도를 감지하는 변수가16bit 였는데 속도가 높아지자 overflow가 발생해 컴퓨터가 로켓의 속도를 0으로 인식하게 되었고 로켓에 심각한 문제가 발생했다고 판단한 컴퓨터는 지상에 추락하는 것을 방지하기 위해 자폭을 한 것이다.

일상의 점점 더 많은 부분을 컴퓨터에 의지하는 세상이다. 소프트웨어는 밤새서 만들면 된다라는 사고 방식은 이제 정말로 버려야 할 때다.

Reference

[1] ABC News, 02.04.2010,  http://abclocal.go.com/wjrt/story?section=resources/auto&id=7257751

[2] Nancy Leveson, Medical Devices: The Therac-25, 1995

[3] ARIANE 5 Failure - Full Report, http://www.ima.umn.edu/~arnold/disasters/ariane5rep.html

[출처] 역사상 최악의 버그: The Therac 25|작성자 덤덤2

개발자의 악몽 : &quot;간헐 죽는 문제

소프트웨어를 개발해서 '출시'를 해본 사람에게, 품질부서에서 알려주는 버그들 중 어떤 종류의 버그가 가장 괴로운가 라고 물어본다면 누구나 이구동성으로 "간헐 죽는 문제" 라고 답할 거다. 그 괴로움은 경험해본 사람만이 안다.

"XX 기능을 8시간 동안 테스트 하던 중 1회 S/W 죽는 문제 발생하였음. 재현 불가" 

도대체 어쩌란 말인가. 개발자도 난감하지만 사실 품질 검증하는 사람도 난감하기는 마찬가지다. 그들이라고 왜 어떻게 하면 재현된다고 친절하게 가르쳐 주고 싶지 않겠는가. 정말 아무리 다시 테스트를 해봐도 구체적인 재현 루트가 없어 보이니 저런 식으로 말할 수밖에. 

나는 수년간 가전제품에 들어가는 임베디드 소프트웨어 개발에 종사했었고 저런 문제들을 숱하게 보아왔다. 대체로 출시 일정이 거의 닥쳐서야 저런 문제들이 하나 둘 중요한 이슈가 된다. 개발자들은 쉽게 수정이 가능한 재현 가능한 문제들을 먼저 해결하고, 저런 문제는 뒤로 미루게 마련이다. 결국 그렇게 미루고 미루다 출시 시점이 가까워지면 남는 문제는 저런 문제밖에 없다. 일반 PC프로그램과 달리 전자제품에 탑재되는 임베디드 소프트웨어는 제품을 출시하고 나면 수정하는 것이 쉽지 않기 때문에 그 스트레스는 이루 말할 수 없다.

많은 경우 저런 문제들은 깔끔하게 원인 분석이 되지 않는다. 출시는 해야겠기에 해결책이라고 어떻게든 뭔가 고치긴 하지만 그걸 만든 개발자도, 그걸 검증하는 사람도 누구도 "확신"은 없다. 그쯤되면 거의 하루하루가 기도하는 심정이다. "부디 문제가 생기지 않게 해주세요" 라고. 왜 이런 문제들이 발생하는가?. 컴퓨터란 0/1의 지극히 논리적인 기계가 아니었던가? 항상 같은 결과를 출력해야 할 컴퓨터가 왜 저렇게 애매모호한 문제를 보일 수 있는 걸까?

컴퓨터 프로그램은 아주 단순하게 보면 입력을 받아 결과를 출력하는 일종의 기계이다. 그리고 입력이 완벽하게 같다면 항상 같은 결과를 출력한다. 하지만 프로그램에 주어지는 입력은 기본적으로 완벽하게 같을 수 없다. 왜냐하면 여기서의 입력이란 프로그램 실행할 때 입력하는 입력 파라미터 뿐 아니라, 임의의 시간에 들어오는 외부의 인터럽트 예를 들면 타이머 인터럽트나, 키 입력 인터럽트, 심지어 시간에 OS의 IO buffer 상태등 수많은 요소들을 포함하기 때문이다. 이러한 입력은 비 결정적 (non-deterministic) 이다. 이러한 종류의 비결정적 입력으로 인한 가장 대표적인 문제는 multi thread 프로그램에서 잘 나타난다.

Thread 1

S1: if ( index > 0 )

S2:      memcpy(buf+ index, data, len)        

Thread 2

S3: index += len;

(*) [2] 의 논문에서 수정 인용.

위의 예에서 Thread 1이 S1을 실행한 후 S2를 수행하기 직전에 OS가 설정한 timer interrupt가 발생하고 그로 인해 context switch가 발생해 Thread 2가 수행되는 경우를 생각해 보자. 본래 프로그램의 의도는 S1 -> S2 -> S3 의 순서로 수행되는 것이었으나 중간에 발생한 context switch에 의해 S1 -> S3 -> S2 가 수행이 되고 결과적으로 S2는 엉뚱한 곳에 데이터를 복사해 overflow 등의 오류가 발생하게 된다. 요즘의 Multi core 환경에서는 Thread1과 Thread2 가 context switch 없이 동시에 각기 다른 코어에서 수행되는게 가능하기 때문에 이러한 문제는 더더욱 빈번하게 발생할 수 있다.

이와 같이 보기에는 멀쩡해 보이는 코드지만 thread 간의 수행 순서에 따라 결과가 달라지는 종류의 문제가 대표적인 재현 안됨 현상의 원인이다. 이런 종류의 버그를 heisenbugs라고 한다.  프로그래머는 이런 문제가 발생하지 않게 하기 위해 언제든 다른 thread가 수행될 수 있다는 걸 항상 염두에 두고, lock 등으로 적절한 보호를 해 줘야 한다. 하지만 사람의 머리 구조상 이게 쉽지 않다. 게다가 위와 같이 하나의 lock 만으로 간단히 해결되는 게 아닌 수많은 다양한 종류의 문제들이 존재한다 [3].

이런 괴로움을 잘 알고 있는 나로서는, 공부를 다시 시작하면서 알게된 최근의 연구 결과들을 보고 감동하지 않을 수 없었다. 그중 대표적인 두가지를 들자면 Microsoft의 CHESS [1] 와, UIUC의 CTrigger [2] 가 있다. 근본적으로 thread를 사용하는 한 모든 가능한 수행 조합은 거의 무한대이기 때문에 (exponential) 완벽하게 모든 버그를 잡아내는 것은 불가능하지만, 이들 논문의 결과는 많은 실제적인 문제를 해결하는데 큰 도움을 줄 수 있는 것으로 보인다. 물론 기존에도 valgrind 와 같은 유용한 툴이 있었고 실제 현장에서는 이조차도 널리 쓰이고 있지 않는 현실에서 이러한 최근의 연구 결과가 현장에 반영되기까지는 꽤나 긴 시간이 필요하리라 생각되지만, 개발자의 고충을 아는 한 사람으로서 그 시간이 단축되기를 간절히 희망한다.

내가 만약 이전에 몸담았던 기업의 CTO라면 이러한 연구 결과를 재빨리 수용해서 사내의 개발 환경에 맞도록 툴을 커스터마이즈 해서, 개발자들에게 교육을 시킬 것이다. S/W의 품질이 높아지는 것은 물론이거니와, 검증 기간 단축, 그리고 개발자들의 정신 건강에 엄청난 도움이 될 테니까 말이다.

Reference

[1] M. Musuvathi, S. Qadeer, T. Ball, G. Basler, P. A. Nainar, I. Neamtiu Finding and Reproducing Heisenbugs in Concurrent Programs.In Operating System Design and Implementation (OSDI), 2008.

[2] Soyeon Park, Shan Lu, and Yuanyuan Zhou. CTrigger: Exposing Atomicity Violation Bugs from Their Hiding Places. In the proceedings of the 14th International Conference on Architecture Support for Programming Languages and Operating Systems (ASPLOS'09), March 2009. [PDF]

[3] Shan Lu, Soyeon Park, Eunsoo Seo, Yuanyuan Zhou. Learning from Mistakes --- A Comprehensive Study on Real World Concurrency Bug Characteristics. In the proceedings of the 13th International Conference on Architecture Support for Programming Languages and Operating Systems (ASPLOS'08), March 2008.[PDF]

[출처] 개발자의 악몽 : "간헐 죽는 문제" |작성자 덤덤2

일정예측의 불확정성 원리

추측할 수 밖에 없는 상황에서

정확성을 고집하지 않는 태도는 자식인의 표시다.

- 아리스토 텔레스

고객이 나에게 묻는다.

“그 프로젝트가 얼마나 걸릴까요?”

“요구사항이 전달되기 전까지는 말씀드릴 수가 없습니다.”

“그냥 대략적인 것도 괜찮아요, 금액은 얼마나 책정되나요?”

나는 주머니 속에서 동전을 몇 개 집어서 보이지 않게 한 채로 고객에게 내민다.

“동전이 몇 개나 있을 까요?”

“네? 그걸 어떻게 알아요?”

“그냥 주먹의 크기로 대략적인 것도 괜찮아요.”

그리고 그 계약은 성사되지 않았다. 영업팀은 나에게 비난의 화살을 던지기 시작했다. 그리고, 나는 확신의 목소리로 대답해 준다.

“아무리 배고프더라도 전 독버섯을 삼키지는 않을 겁니다.”

아마도 여러분들도 이러한 상황에 수없이 빠져봤을 것이다. 그리고, 고객이 요구한대로 부족한 정보만으로 대략적인 일정과 금액을 말하고, 영업팀은 고객과의 협상으로 인해 그마저도 삭감되기가 일수이다. 그리고, 이제부터 여러분들은 “일정사수”라는 엄청난 어드벤처를 시작하게 된다.

일정을 예측하는 일은 정말 어렵다. 더구나 고객과 회사의 경영진, 기획팀, 영업팀이 개발 일정이 얼마나 어려우며 부정확할 수 밖에 없는 지를 이해하지 못한다면 상황은 정말로 심각할 수 밖에 없다. 하지만, 현실은 냉엄하다. 회사가 살아남으려면 우리는 어떻게 해서든 일정과 비용을 예측을 해내야 한다. 그러면, 어떻게 해야 일정을 제대로 예측할 수 있을 까?

A. 대원칙

l 일정은 정확하게 예측할 수 없다.

일정 예측은 근본적으로 부정확할 수 밖에 없다는 사실을 경영자와 고객에게 주지 시켜야 한다. 고객과 경영자는 권위 있는 증거 자료에 약하다. 그들은 되지도 않는 상품이나 기술을 권위 있는 품질 보증서만으로 고가로 구입한 후 만족하게 된다. 매우 잘 숙련된 개발조직도 일정추측의 부정확도가 40% 이상이 된다는 점을 주지시켜라. 물론 드물게는 10%이내의 놀라운 정확도를 가진 조직들이 있다. (주로 항공사관련 조직과 NASA 등) 일반적으로 50% 수준만 유지해도 모범적인 조직이라고 할 수 있다.

l 일정 예측은 프로젝트 진행 중에 꾸준히 이루어져야 한다.

대부분 고객의 요구사항은 아무리 유도를 해도 프로젝트가 마무리되어갈 때만큼 세밀한 자료를 얻을 수가 없다. 고객은 프로젝트의 결과물이 나오기 시작할 때부터 보다 본격적이고 구체적인 요구사항을 내놓기 시작한다. 이러한 것은 당연한 것이다. 더구나 고객이 개발에 대한 깊은 이해가 없는 한은 그러한 현상을 미리 막을 수 있는 해결책은 없다. 따라서, 프로젝트가 진행되면서 모든 일정은 재평가되어야 한다는 것을 개발이해관계자 모두가 공감하고 있어야 하는 것이다.

l 아무리 노력해도 더 이상 줄일 수 없는 일정 한계 수준이 존재한다.

일정에 관해서 경영자에게서 듣는 가장 짜증나는 말 중에 하나는 “필요하면 인원을 더 늘려줄 테니까, 빨리만 끝내”이다. 프로젝트 중간에 개발인원을 늘린다고 도움이 되기는커녕 골치거리만 생기는 것을 모르는 것이다. 이밖에도 갖가지 의견을 통해서 일정에 대한 압박을 시작한다. 프로젝트의 중요도가 높을 수록 이 압박은 높아지게 된다. 한계상황에 대한 인식, 개발조직의 현재 능력에 대한 객관적인 평가를 통해 처음부터 무리한 일정은 모험이 아니라 도박임을 명심해야 한다. 적정 일정보다 짧은 일정계획은 오히려 기간과 비용의 심각한 증가를 불러온다.

B. 일정 예측의 기본 수칙

l 즉흥적인 예측을 피하라.

l 예측에 충분한 시간을 할당한 후 계발계획을 수립하라.

l 과거 유사 프로젝트의 자료를 이용하라.

l 담당 개발자가 도출한 예측 값을 활용하라.

l 검토회의를 통하여 충분히 검증하라.

l 상세한 수준에서 예측하라.

l 평범한 업무라도 빠트리지 마라.

l 소프트웨어 개발 예측 도구를 사용하라.

l 여러 가지 예측 기법을 사용하고, 결과를 비교하라.

l 프로젝트를 진행하면서 예측 기법을 바꿔라.

C. WBS(Work Breakdown Sheet)에 의한 일정 예측

WBS는 본인이 주로 사용하는 일정 예측 방법이다. 우선 모든 일을 트리 구조로 쪼개어 나간다. Top-Down 방식으로 분류를 세분화 시키는 것이다.

 

최대한 세밀하게 쪼개어 나가야 한다. 이 작업이 모두 끝나면 마지막에 있는 박스(업무)들을 리스트로 작성한다. [그림 1]에서는 “…”으로 표시된 박스들이다. 그리고 각 박스에 대하여 예상되는 시간을 최적(Best), 최악(Worst), 예상(Estimated) 세 가지의 예측 기간을 적는다. 이제 모든 업무에 대한 최적의 상태로 프로젝트가 진행되었을 경우에 걸리는 시간 B와 최악의 경우 W, 그리고 보통의 경우 E를 가지고 아래와 같은 공식에 의해 예측 기간을 설정하는 것이다.

프로젝트 예측 일정 = (a*B + b*E + c*W) / (a + b + c)

a, b, c는 상수로 해당 업체의 경험에 따라 가중치를 조절한다. 만약 최적으로 계산한 것이 그런대로 맞는 업체의 경우에는,

프로젝트 예측 일정 = (2*B + 4*E + 1*W) / 7

또는 최악의 경우가 너무 잘 맞는 업체의 경우에는,

프로젝트 예측 일정 = (1*B + 3*E + 4*W) / 8

와 같이 가중치를 이동해 가면서 업체에 맞는 공식을 유도해 나가는 것이다. 또한 기존의 유사 프로젝트의 가중치가 어느 정도 적중했는지를 근거로 해서 작성하기도 한다.

출처 :http://cafe.naver.com/codeway.cafe?iframe_url=/ArticleRead.nhn%3Farticleid=142

무료 PDF 편집기

요즘 수강중인 강의 자료가 PDF로 배포 되어 필기를 위해 출력하자니 양이 너무 많고,

따로 메모를 하자니 교육자료와 연결이 잘 되지 않고..

해서, PDF 편집 Tool을 찾아 보기로 했다.

구글링을 통해 찾아낸 것이 다음 두개의 무료 PDF Editor.

                                  [PDF-Pro]                                                                      [PDF-XChange Viewer]

PDF-Pro는 국내 이파피루스(http://pdfpro.co.kr)의 제품이고, PDF-XChange Viewer는 외국의 Tracker Software Products(http://www.docu-track.com)라는 회사의 제품이다.

1. 메뉴 및 기능

[PDF-Pro의 주 메뉴]

첫째 줄 : 파일, 편집, 보기 등등

둘째 줄 : 열기, PDF 만들기, 저장 등 기본 기능

세째 줄 : 스탬프, 노트, 형광펜, 밑줄, 취소선, 연필, 지우개, 파일첨부, 선택, 텍스트 상자, 텍스트 선택(PDF 편집)

[PDF-XChange Viewer의 주 메뉴]

첫째 줄 : 파일, 편집, 보기 등등

둘째 줄 : 열기, PDF 만들기, 저장 등 기본 기능

세째 줄 : 메모, 텍스트 추가, 텍스트 상자, Callout, 형광펜, 취소선, 밑줄, 각종 도형들.., 파일첨부, 연필, 지우개, 스탬프 등

언듯 봐도 XChange Viewer의 기능이 더 많아 보이고 사용하기에도 편하게 구성이 되어 있고, 실제로도 XChange Viewer가 사용이 편하다.

그러나 두 Tool의 결정적인 차이가 있는데, 그것이 PDF 편집 기능 이다.

PDF-Pro의 경우 PDF 본문을 수정 할 수 있는 강력한 기능이 있다.

일반적으로 PDF를 만들 경우 다른 워드, 파워포인트 등 다른 편집 툴을 이용해서 문서를 작성 한 후 PDF 변환 툴을 이용해서 PDF를 생성 하는 과정을 거치고, 그렇게 만들어진 PDF에 수정 사항이 발생 할 경우 다시 편집 툴을 이용해서 수정을 하고, PDF로 변환 하는 과정을 반복 하게 되나, PDF-Pro를 사용 할 경우 간단한 수정은 PDF-Pro에서 직접 해결 할 수 있다.

XChange Viewer는 텍스트를 추가 하거나 XChange Viewer에서 추가한 텍스트 및 도형을 편집 할 수는 있으나, 기존 PDF파일의 본문을 직접 수정 하는 기능은 없다.

2. 사용성

결론 부터 말하자면, PDF-Pro는 PDF 본문 편집이라는 강력한 기능을 가지고 있으나, 아쉽게도 사용이 너무 불편하여 곧 삭제 예정에 있다.

PDF-Pro의 개발자들이 스스로 사용을 해 봤을까? 라는 생각이 들 정도로 사용이 불편하다. 심지어 국산 프로그램임에도 불구하고

한글 입력에 있어서도 XChange Viewer보다 나은 점이 없다.

[PDF-Pro의 텍스트 입력 화면]


텍스트 입력시 입력창이 자동으로 늘어 나지 않아 텍스트 입력창 바깥의 글자가 보이질 않는다.

글 입력이 완료 된 후(또는 도중에) 텍스트 상자의 크기를 조절 해 주어야 비로서 입력한 내용을 확인 할 수 있다.

PDF-Pro의 텍스트 입력창의 특이한 기능으로는 텍스트 입력창의 크기를 조절하면 폰트의 크기까지 같이 조정이 되는 기능이 있다.

입력창을 가로로 늘이면 창의 크기만 늘어 나지만, 창의 높이를 조정하면 폰트의 크기가 창의 높이에 맞춰서 조정 된다.

그러나, 줄바꿈이 되질 않는다. 텍스트 입력(추가)은 무조건 한 줄 씩만 입력이 가능 하다. (저엉말로 불편하다.!!!)

[PDF-XChange Viewer의 텍스트 입력 화면]


텍스트 상자 및 일반 텍스트 입력 화면이다. 파워포인트 등 일반적인 윈도우 응용 프로그램들과 사용법이 같다.

따로 사용법을 생각할 필요도 없고 익숙한 방법 그대로 사용 하면 된다. 그래서.. 편하다!!

3. 결론

앞서 얘기한 바와 같이 PDF-ProPDF 편집이라는 강력한 기능을 가지고 있지만, 낮설고 불편한 사용성으로 인해 이 글의 작성이 끝나는 즉시 삭제될 예정이다.

혹시나 언젠가 PDF 파일의 수정이 필요한 날이 온다면 다시 설치를 할 가능성도 있겠지만, 아무래도 그 때 즈음에는 PDF-Pro라는 이름을 기억하지 못할 수도 있겠다.

응용 프로그램에 있어서 기능 및 성능도 중요 하지만 무엇보다 사용자를 위한 편의성(Interface)이 우선 되어야 한다고 생각 한다.

UI개발이란 단순히 이쁜 화면을 만드는 것이 아니고 사용하기 편한, 쉽게 접근 가능한 Interface를 만드는 것이며, 사용자는 사용이 쉬운 제품에 먼저 손을 내밀며 그렇게 익숙해 지기 마련이다.

-- 추가 --

PDF-Pro를 삭제하려 했더니, 시작 -> 프로그램 그룹에 'Uninstall' 메뉴가 없다. 정말 불친절한 프로그램이다.

[출처] 무료 PDF 편집기|작성자 레쥐

테스팅 관련 매거진

테스팅 + 영어 + 해외 전문가 네트워킹
겸사겸사 토끼잡기 시리즈 1탄:
"해외 온라인 테스팅 관련 잡지 활용"

- 권 선 이 (KTB: Korean Testing Board)

매번 새해를 맞을 때마다 내년 계획의 한가지에 “영어공부”가 빠진 적이 몇 번이나 있었을까?
그렇게 영어공부를 하겠다는 맘은 한 해에도 수십 번씩 먹지만 실제로 그 얄미운 영어는 좀체 먹어지지 않는다.
업무 하랴, 블로깅 하랴, 관심분야 트랜드 찾아 쫒아 다니랴……
정말 할 일은 너무나 많고 주어진 24시간은 1분도 늘어나지 않는다.

여기에 하나의 해결 아이디어가 있다. 그 많은 일들 중에 두 세가지를 패키지로 묶어 하루에 일정시간 투자하는 것이다. 일명 “겸사겸사 토끼잡기”로 이름 붙인(내가 ^^) 방법인데 말대로 한가지 이상의 일을 겸사겸사 같이하는 것이다. 지인이 벌써 오래 전에 한 말이기도 하지만 이제 한가지 목적만을 가지고 움직이는 건 낭비인 시대일지도 모르겠다. 한가지만 하는데 두 세가지 결과가 동시에 얻어진다면 한 시간이 두 세시간 분량의 ROI를 가져다 줄 테니 시도해서 손해 볼 일은 없을 것이다.

오늘은 겸사겸사 토끼잡지 시리즈의 첫 번째 방법을 소개해 보고자 한다. 앞으로 소개할 유용한 웹사이트들을 찾아 저장해 놓고 자신이 가장 훌륭하고 쉽다고 생각되는 사이트를 골라 매일 일정시간 투자해보자.  영어와 테스팅 공부 및 글로벌 테스팅 트랜드 쫓아가기는 기본이고 여기에 해외 전문가들과의 네트워킹도 덤으로 얻을 수 있다.

실천하지도 못할 거대한 계획에 짓눌려 스트레스만 받지 말고 가벼운 마음과 손으로 시작하자. 이제 곧 “겸사겸사 토끼잡기”가 의외로 쉽고 효율적이란 사실에 놀라게 될 것이다.


겸사겸사 토끼잡기 방법 1:
해외 온라인 테스팅 관련 잡지 활용

현재 영문으로 발간되는 테스팅 전문잡지는 주로 유럽 쪽에서 다수 발간되고 있다.
보통은 프린트 버전과 온라인 웹버전으로 출간되며 웹잡지의 구독은 보통 무료지만 프린트 버전의 구입이나 구독은 약 50유로 정도의 비용이 든다. 유럽지역 외의 국가로 배송시는 국제 배송료가 포함되어 이보다 더 비싼 것이 일반적이며 유럽 외의 국가에는 아예 배송하지 않는 잡지도 더러 있다. 무료 온라인 잡지구독은 해당 사이트에 접속하여 각 사이트 별로 등록을 해야하는 번거로움이 있지만 공짜 잡지를 보는 혜택을 생각하면 상당히 쉽고 매력적인 영어+테스팅 공부법이다.
여기에 덤으로 얻을 수 있는 것들이 또 있다. 이 잡지사이트에는 보통 각종 다양한 글로벌 테스팅 트렌드, 행사, 관련 뉴스들 및 새로운 테스팅 관련 도서들을 소개하는 코너가 마련되어 있으며 지속적으로 업데이트 되고 있다. 더불어 블로그 포함, 테스팅 커뮤니티들을 지원하는 코너 또한 서비스되고 있어 각국의 테스팅계에 몸담고 있는 테스트 엔지니어들이나 관련자들과의 소통이 가능하다. 아티클을 읽고 의견을 나누거나, 편집자에게 피드백을 직접 사이트에서 보낼 수 있고 자신이 작성한 기사를 보내어 실어달라고 요청하는 것도 물론 가능하다.
자, 그러니 당신이 테스터이거나 관련자라면 꼭 한 두개의 잡지를 구독하고 일정량 읽고 경향을 쫓아가는 자세가 필요한 것이 당연하지 않겠는가? 아직 시작하지 않았다면 당장 시작하도록 하자!

⇒ Goal: 토끼 세 마리 = 영어 + 글로벌 테스팅 트렌드 + 해외 테스팅 커뮤니티 네트워킹
⇒ Cost: Free

⇒ 활용법: 아래 소개되는 영문 테스팅 잡지들 중에서 맘에 들고 자기에게 맞는 것을 찾아 온라인 잡지를 무료로 구독하여 본다. 새로운 잡지가 발간되면 가입할 때 적은 이메일로 알림 메일이 오므로 편리하다. 내용이 제법 많으므로 맘에 드는 기사를 두세개 골라 프린트해서 보며 테스팅과 영어를 같이 습득한다. 
<<Testing Experience>>

  • 발간자: Díaz & Hilterscheid Unternehmensberatung GmbH, 독일
  • 웹사이트: http://www.testingexperience.com

    [출처] STEN - http://www.sten.or.kr/bbs/board.php?bo_table=free&wr_id=7465

  • 모토:” The Magazine for professional testers”
  • 간략 소개:독일에서 영어로 발간되며 계간지이다. 우리나라에 CaseMaker라는 테스팅 툴을 소개하고 STEN과도 인연이 있는 Diaz & Hilterscheid사에서 나오는 테스팅 전문잡지이다. 출간한지 2년 만에 35만 명의 온라인 구독자를 확보했고 한번 마감에 밀려드는 원고와 기사들이 200개를 넘어 추리는 일만으로도 엄청난 시간이 걸린다고 행복한 비명을 지르고 있다. 이에 탄력을 받아 2009년 말과 2010년 초에는 두 개의 테스팅 잡지를 더 만들어 현재 세개의 잡지와 테스팅 관련 행사들을 진행하고 있다.  테스팅 전반에 걸친 다양한 소재를 다룬다.
  • 연락처:Tel +49 (0)30 74 76 28-0 / Fax +49 (0)30 74 76 28-99
    원고 보낼 때 연락처: editorial@testingexperience.com

<<T.E.S.T (The European Software Tester)>>


  • 발간자: T.E.S.T Magaznie, 영국
  • 웹사이트: http://www.testmagazineonline.com/
  • 모토: “At the Heart of the Testing Industry”
  • 간략 소개: 모든 아티클을 PDF가 아닌 웹 상으로 그대로 읽고 다운 받을 수 있는 사이트이다. 카테고리 별로. 잘 정리되어 있어 관심 있는 소재를 찾아가기 좋다. 독자에게 현재 테스팅 시장의 현황을 보여주고 현대 비즈니스에서의 소프트웨어 테스팅의 중요성을 보여준다는 미션으로 발간되는 계간지이다.  소프트웨어 테시팅 시장을 결정짓고 영향주는 이슈들을 찾아 반영하는 것을 목적으로 하며 test automation; agile testing; testing methodologies; effective unit testing; testing web services and SOAs; security & code analysis; configuration management; and application profiling 등의 내용을 다루며 항시 관련 원고를 받고 있다. 한가지 흠이 있다면 다른 테스팅 잡지와 달리 온라인 버전의 잡지구독도 유료라는 점….. 물론 그만큼 컨텐츠에 진지하게 보이는 것도 사실이다. ^^
  • 가격: Print Subscription: 20파운드/ Digital Subscription: 10 파운드
  • 연락처:  t: +44 (0) 870 863 6930
    f: +44 (0) 870 085 8837
    e: info@31media.co.uk
    e: subscriptions@31media.co.uk

<<Software Test & Performance (Collaborative)>>


  • 발간자: Redwood Collaborative Media
  • 웹사이트: http://www.stpcollaborative.com/magazine
  • 모토: “Community, Resources & knowledge Sharing for Test & QA Professionals”
  • 간략 소개: 2004년부터 발간되어 한해 4~10권을 출간하여 상당량의 Archiv를 가지고 있다. 소프트웨어 및 어플리케이션 개발 매니저, 프로젝트 매니저, 팀매니저 및 테스트와 QA 매니저를 독자대상으로 전세계 50,000 이상의 소프트웨어 전문가들에게 정보 및 교육제공 및 전문가 네트워킹 기회를 제공하고 있다.
  • 최근호(2010년 1월호 Vo. 7, No. 1) 기사목록(Featured Articles)을 살펴보면 아래와 같다.

- Agile Projects: 6 Ways to Avoid the ‘Mini-Waterfall’
- STOP Defect Leaks!
- 9 Tips to Encourage Collaborative Testing
- The Politics of Testing: Making Conflict Count
- The Power of Pessimism
- Putting Intuition to the Test
- Use the Social Web to Build Your Career Brand
- Interview India’s Women Testers Gain Visibility: A Conversation With Consona’s Parimala Shankaraiah

  • 연락처: Redwood Collaborative Media & STP Collaborative
  • 주소: 105 Maxess Rd, Suite 207 Melville, NY 11747
  • Tel: +1 631-393-6051

<<Agile Record>>

  • 발간자: Díaz & Hilterscheid Unternehmensberatung GmbH
  • 웹사이트: http://www.agilerecord.com/index.html
  • 간략 소개:2009년 베를린에서 에자일 바람을 타고 처음으로 열린 “Agile Testing Days” 에서 열성적인 몇몇이 모여 주창되고 막 첫 호가 발간된 Diaz사의 두 번째 잡지이다. 에자일 커뮤니티와 연계하여 만들어지고 있으며 매해 열리게 될 Agile Testing Days 컨퍼런스와도 긴밀히 연계되어있는 그야말로 에자일의 인기를 보여주는 계간지이다.
  • 1호 내용을 간단히 들여다 보면 아래와 같다.

Be the Worst
-by Dawn Cannan (with a commentary by Lisa Crispin)
Are All Pigs Equal? - or are some more equal than others?
-by Stuard Reid
7 Steps to effcient GUI test automation using Selenium RC with Java
by Lars Trachsler and Ulrich Freyer-Hirtz
How Agile Methodologies Challenge Testing
by Rex Black
Testing in an organisation going agile
-by Eric Jimmink
Is there such a thing as an Agile tester?
-by Jeroen van Berkel
Guerrilla Scrum: How to force organizational change
-by Marc Bless
Quality - An agile point of view
-by Lior Friedman
Testability: Investment, not Overhead
-by David Evans
The Future of Testing - How Testing and Technology will Change
-by Joachim Herschmann
Agile and Performance testing? "A Contradiction of terms?"
-by Mieke Gevers
Software Testing Craft
by Markus Gärtner
Five tips for successful retrospectives
-by Tomi Juhola
Still playing planning poker? Stop gambling with your project budget.
-by Rob van Kerkwijk
Scrum and RUP - A Comparison Doesn't Go on All Fours
-by Remi-Armand Collaris and Eef Dekker

<<Better Software>>

  • 발간자: StickyMinds.com, SQE(Software Quality Engineering)의 지사
  • 웹사이트: http://www.stickyminds.com/BetterSoftware/magazine.asp
  • 모토: “The magazine for software professionals who care about quality”
  • 간략 소개: 최근호: 12호 발간(2010년 1~2월호)  6회 발간/ 1년  오래 장수해온 잡지인 만큼 탄탄하면서도 광범위한 자료를 가지고 있는 잡지이다. 소프트웨어 전문가들을 위한 툴, 오류 트레킹, 매트릭스, 매니지먼트 등 테스팅 관련 전반에 걸친 심층적 기사를 다룬다. 

<<Professional TESTER>>


  • 발간자: Test Publishing Ltd.
  • 웹사이트: http://www.professionaltester.com/
  • 모토: “Essential for Software Testers”
  • 간략 소개: 약 10여년전 출간되었다가 2003년~2005년 활발하게 활동한 후 정지되었다가 올해(2010년) 다시 재 발행되기 시작한 테스팅 전문잡지이다. 당시에는 테스팅 시장에서는 거의 선구자적이고 진지한 잡지였다고 한다. 1년에 6번 발간된다. 잡지 제목이 말해주듯이 세계 소프트웨어 테스팅 전문가들을 독자대상으로 하며 업무의 효용성과 효율성을 높여주기 위한 툴과 아이디어를 제공할 것을 목적으로 발간된다. 2005년 이전의 테스팅 관련 기사를 무료로 다운받아 읽고 테스팅이 어떤 경로로 오늘날에 이르렀는지 살펴보는 것도 상당히 흥미 있는 일 일거라 생각된다. 2010년 1호의 잡지 테마는 “Very early lifecycle testing” 이다.
  • 연락처:Editorial: editorial[at]professionaltester[dot]com
    Subscriptions: subscription[at]professionaltester[dot]com
    General inquiries: info[at]professionaltester[dot]com

<<Software Testing Club Magazine>>


  • 발간자: Software Testing Club
  • 웹사이트:http://wiki.softwaretestingclub.com/The+Software+Testing+Club+Magazine+-+No+1
  • 모토: “A Community Magazine, for testers, by testers”
  • 간략 소개: Softwaretestingclub은 이미 세계 테스팅 관련자들에게 널리 알려져 있는 테스팅 커뮤니티이다. 모든 자료나 사용료가 무료였다가 2009년에 일부 유료로 전환되었다. 이 사이트에서 창간한 잡지로 그야말로 테스팅 커뮤니티에 소속된 사람들이 궁금해할 내용으로 커뮤니티 사람들이 만드는 잡지이다. 그런 만큼 내용 또한 기사들, 만화, 게임 등의 약간은 가볍고 흥미 있는 내용으로 구성된다. 너무 진지하고 무거운 잡지들에 식상해 있다면 좋은 선택의 옵션일 듯… 커뮤니티 활동도 사이트에서 활발하게 진행되고 있으니 참여해 보면 좋을 듯 하다.
  • 연락처: Rob Lambert at rob@softwaretestingclub.com

 

출처 :http://www.sten.or.kr/bbs/board.php?bo_table=free&wr_id=7465

2010년 2월 18일 목요일

리눅스 버전확인

이를테면, redhat인지, fedora인지 모를 때 알 수 있는 명령어
#cat /etc/issue
하면 된다..
http://blog.daum.net/prattler22/6830632
http://blog.naver.com/dekarno/140051580918
http://blog.daum.net/nanhjb/3615732
< 리눅스 커널 버전 확인 >
/proc/version
/etc/redhat-release
uname -a
cat /etc/issue :: 우분투
cat /etc/issue.net
cat /etc/redhat-release :: 레드햇
cat /etc/hancom-release :: 한컴리눅스
cat /proc/version
cat /etc/rc.sysinit |grep PRODUCT
< 리눅스 시스템정보 확인 >
/proc/cpuinfo
/proc/meminfo
lspci
free
---------
< 모듈 정보 >
/lib/modules
rpm -qa | more
rpm -qa | grep 패키지명
/tmp/install.log :: 초기 설치 패키지 정보 확인 

[출처] [펌] Linux 버전 확인하기|작성자 마이콜

2010년 2월 17일 수요일

Router 와 L3 Switch의 차이

 

Router는 L3 장비죠. 라우터는 IP Layer에서 동작한다고 생각하시면 됩니다.

보통 공부를 하시다보면 L2는 Switch, L3는 Router라고 죽어라 외우고 공부했더니, 실무가더니 L3 Switch가 있어서 당황하게 됩니다. 왜 라우터를 써야할 곳에 Switch가 들어가 있어니 말이죠...^^

사실은 몇년전까지만 해도 스위치는 L2장비이고, 또 오랫동안 사용을 했습니다. 또 라우터는 L3에서 동작하는 장비였죠. 네트워크가 분리되어 있는 환경이라면 당연히 라우터를 사용하여야합니다.

간단히 정리하자면 스위치는 MAC을 보고 포워딩하지만, 라우터는 IP Layer를 보고 포워딩합니다. 당연히 라우터에는 Routing table을 보고 경로를 결정합니다. 참고로 라우터의 이런기능들은 대부분 소프트웨어적으로 구현되어 있지요. 이유는 MAC의 경우는 보통 단순하지만 IP라는 녀석은 복잡해서 하드웨어로 구현하기가 무척 까다롭습니다. 여기까진 이해되시죠.

그런데 시대가 많이 흐르다보니 하드웨어 기술이 나날이 발전하였습니다.그러다보니 하드웨어적으로 IP를 분석해서 경로를 설정하고 포워딩할 수 있는 기술로 발전하게 되었죠.

이때부터 나온 제품들이 L3 Switch입니다.  사실 스위치는 Performance측면을 많이 강조하였다고 보시면 좀더 이해될뜻.

아래표는 차이점을 정리하였습니다.

주요 특징

Classical Router

Layer 3 Switch

주요 수행 OSI Layer

Layer 3

Layer 3

Routing 수행 방법

Software
(CPU + Software)

Hardware
(ASIC chip)

지원하는 Layer 2 MAC

Ethernet, TokerRing, FDDI
ATM, WAN

FastEthernet
Gigabit Ethernet

forwarding performance

Slow
(CPU성능과 가격에 따라 다름)

Fast
(near wire speed)

Latency

약 200 ms

< 10 ms (100 Mbps)

관리 및 program 가능성

매우 높음

적음

지원 Protocol

All

IP (일부 IPX)

Routing Protocol

All

RIP1,2 OSPF (일부 DVMRP)

WAN 지원

지원함

지원하지 않음

비용

높음

낮음

참고로 최근 나온 스위치들은 대부분 Routing Protocol을 지원합니다. 일부는 WAN 인터페이스까지 제공하는 경우도 있습니다. ^^

시대가 흘려가면서 점점 라우터와 스위치의 경계가 흐려지는뜻하군요..^^

그럼. 즐거운 하루 되세요...

스티븐과 함게하는 네떡이야기 발췌-

예를 들어 A에서 보낸 팻킷이 포트 1로 들어왔다고 합시다.
그러면 L2 스위치는 포트 1에 A가 붙어있다는 정보를 얻게 됩니다.
그래서 나중에 A로 보내져야할 팻킷이 들어오게 되면 포트 1로 내보내게 됩니다.
L3의 경우는 L2와 달리 매우 넓은 범위까지 다루게 됩니다.
그래서 오가는 팻킷을 관찰해서는 충분한 정보를 얻을 수가 없습니다.
그래서 L3 스위치끼리 통신을 하면서 정보를 축적하게 됩니다.
예를 들어 포트 1에 연결되어 있는 스위치가 여기에는 팻킷이 많이 몰린다는
내용을 보낸다면, 그 내용을 받은 스위치는 팻킷을 포트 1 대신 다른 포트로
보내게 됩니다.

  L4스위치

여러대의 서버에 똑같은 컨텐츠를 탑재하는 경우는 L4에서 서버의 부하를 체크해서 가장
여유있다고 판단되는 쪽으로 보내게 됩니다.(정책이 여러개 있는데, 이방식을 가장 많이 사용합니다.)
일반 기업에서 ERP서버나 업무용서버를 운영할 때 많이 사용하는 방식입니다.
서버별로 컨텐츠가 다르다면, L4에서 정책을 세워서 해당 서비스에 대한 요청이 오면 등록된 서비스로
보내주어서 전체 부하를 분산시키는 방식을 사용합니다. 대형 포탈의 경우 이런 방식을 사용하겠죠.
그리고 대부분 DB서버는 L4를 거치지 않고 웹서버와 직접 연결시켜서 사용합니다. DB서버 분산하는게 쉽지 않기 때문에 DB를 L4에 물리는 경우는 드물죠.

세그먼트(segment)에 대해 설명드리면, 한 컴퓨터에서 발생한 신호가 수신자에 상관없이 전달되는 범위를 말합니다. 즉, 내 컴퓨터에서 자료를 보내려고 신호를 내보내면 이 신호가 일정 지역내의 모든 컴퓨터에게 전달이 되는데 그 범위를 말합니다. 그런데, 하나의 세그먼트에서는 동시에 2개의 신호가 전달될 수 없습니다. 예를 들면, 두사람이 동시에 자기 얘기만 하면 무슨소린지 모르고 충돌이 발생하듯이 하나의 세그먼트 내에서 동시에 2개 이상의 전기적인 신호가 발생하면 충돌이 발생합니다.
그럼, 여기서 한가지 생각해 보시면, 하나의 세그먼트가 컴퓨터 1000대로 구성이 되어 있다고 보면 1000대중에서 내 컴퓨터가 자료를 보내려고 하면 많은 시간을 기다려야 할 수도 있고, 충돌이 자주 발생할 수도 있습니다. 그래서~ 세그먼트를 분리시키고자 등장한 장비가 브리지(스위치는 브리지를 개량한 장비)입니다.
브리지(bridge)는 한마디로 요약하면 세그먼트를 분리시켜주는 장비입니다. 예를 들면 1000대의 컴퓨터를 100대씩 묶어서 10개의 세그먼트을 만들어 주는 장비 입니다. 이렇게 분리된 세그먼트에서 자료 교환을 중재하는 역할을 브리지가 하게 됩니다.
예를 들어 세그먼트1에 있는 컴퓨터가 세그먼트1에 있는 컴퓨터로(즉, 같은 세그먼트)데이터를 전송하면 이 신호가 다른 세그먼트에 전송이 되지 못하도록 신호를 차단하구요, 세그먼트1에서 세그먼트2로 데이터를 보내면 브리지가 이 신호를 받아서 세그먼트2로 보내줍니다. 이렇게 하면 세그먼트가 분리되어서 컴퓨터끼리 자료 교환하는데에 충돌이나 기다림(병목현상?)이 줄어들겠지요.
이제, 스위치와 라우터에 차이점을 설명 드리면.. 세그먼트를 분리시킨다는 의미에서는 같다고 보시면 됩니다. 차이점은.. 어떤걸 기준으로 분리를 시키느냐 입니다.
스위치에 여러가지 포트(하나의 포트를 하나의 세그먼트로 보셔도 될겁니다.)가 있는데, 각 포트에 어떤 컴퓨터가 연결이 되어 있는지 판단하는 것은 MAC(Media Access Control)주소 입니다. 간단히 말하면 LAN카드 번호 입니다. 이 번호는 공장에서 나올때부터 고유하게 지정된 번호로써 전세게 LAN카드가 다 다른 번호를 가지고 있습니다. 스위치는 이 번호를 가지고 스위치 장비 내부에 '표'를 하나 만들어 놓고, 포트1에는 어떤 MAC주소가 있으며, 포트2에는 어떤 MAC주소가 있는지 적어 놓습니다. 그래서, 이 표를 기준으로, 스위치로 들어오는 신호를 읽어 들여서 같은 포트의 MAC주소를 목적지로 하고 있으면 다른 포트로 데이터를 보내지 않고, 다른 포트의 MAC주소를 목적지 주소로 가지고 있으면 그곳으로 연결 시켜 줍니다.
라우터는 세그먼트를 구분하는 기준이 IP입니다. 라우터도 내부적으로 표를 만들어 놓는데 기준이 IP입니다. 따라서, 라우터로 들어오는 신호를 읽어들여서 목적지가 같은 포트(즉, 같은 세그먼트)의 IP이면 다른 포트로 신호를 보내지 않으며 다른 포트의 세그먼트의 컴퓨터가 목적지 IP이면 그 포트로 연결시켜 주는 역활을 합니다.
라우터의 역할을 보시면 알겠지만, IP를 기준으로 세그먼트를 나눕니다. 그래서, 인터넷과 독립적으로 LAN을 구축할 경우 라우터는 필요 없습니다. 하지만, 인터넷과 연결시켜서 LAN을 구축할 경우 반드시 필요한 장비가 라우터 입니다

[출처] L2,L3|작성자 새맘

1. L1 -> Flooding

2. L2 -> Swhtching

3. L3 -> Routing

4. L4 -> port number 이용 트래픽분산처리 (Load balancing)

5. L7 (cisco 6500이상 장비) -> S/W 를 장치에 올려서 Traffic filter , Security, VPN 를 할수 있다.

- 상위 계층 장비는 하위 계층 장비의 기능을 모두 가지고 있다.

- L5,L6 ? -> TCP/IP 기반이기때문에 L7이 L5~6 기능을 모두 포함하고 있다.

- TCP/IP 기반

-> L1 : Network Interface 계층

-> L2,L3 : Network (Internet) 계층

-> L4 : Transport 계층

-> L7 : Application 계층

[출처] L2,L3|작성자 새맘

한정된 IT 자원을 가지고 인터넷 트래픽을 얼마나 효율적으로 관리하는가는 IT 업계에 중요한 이슈입니다.
특히, 과거 `1ㆍ25 인터넷 대란'과 대규모 웜바이러스의 출현 이후, 네트워크 보안에 대한 관심이 늘어나면서 기존 네트워크 장비에 보안기능을 대폭 강화한 제품수요가 크게 늘어나고 있는 실정입니다.
최근 인터넷 트래픽관리 및 보안환경이 강조되고 있는 상황에서, 기존 L2/3/4 스위치에 비해 보안기능을 대폭 강화한 네트워크 장비가 L4/L7(Layer4/7) 스위치입니다.
과거에는 통상적으로 패킷의 MAC 주소나 IP 주소를 이용하여 패킷을 전달하는 역할을 수행하는 L2/L3 제품이 주류를 이뤘습니다. 그 이후 급속히 증가하고 있는 인터넷 트래픽을 효율적으로 처리하기 위하여 몇년전부터 L4 스위치가 등장해, 트래픽 부하를 분산하고 지능적인 트래픽 관리 기능을 제공하고 있습니다.
L4 스위치는 서버 및 네트워크 장비의 가용성과 확장성을 높이기 위한 수단으로 각광을 받고 있습니다. L7 스위치는 기존 L4 스위치가 제공하는 기본 기능 이외에 최근 사회적인 문제가 되고 있는 네트워크 보안문제(웜바이러스, 이메일 바이러스, DoS/DDoS 공격 등)를 어느 정도 해결해 줄 수 있는 차세대 제품입니다.
L7 스위치는 애플리케이션 스위치(Application Switch), 콘텐CM스위치(Content Switch), 다계층스위치(Multi-Layer Switch) 등 다양한 이름으로 불리는데, 이는 L7 정보가 주로 애플리케이션과 직접 연관이 있고 패킷의 내용을 분석하여 이를 바탕으로 패킷에 대한 부하분산, 리디렉션, 필터링 등을 수행하기 때문에 자연스럽게 붙여진 이름입니다.
L7 스위치는 통상적으로 L4 스위치의 연장선상에서 출발했지만 L4 스위치가 처리할 수 없는 일들을 수행합니다. L4 스위치의 경우 통상적으로 TCP/UDP 포트정보와 같은 레이어 4 정보를 이용해 패킷을 관리하는 기능을 수행하는 것을 비롯해 서버 및 네트워크 장비에 대한 부하분산 기능을 주로 제공합니다.
그러나 L4 스위치는 VoIP나 P2P와 같은 중요 애플리케이션과 같이 다양한 형태의 패킷 내용을 살펴보기 어렵고 또한 사용자의 IP가 수시로 바뀌는 경우 해당 사용자에 대한 연속적인 서비스를 제공하기 어렵다는 단점을 가지고 있습니다.
L7 스위치에서는 L4 가 갖고 있는 이러한 문제점들을 해결하기 위해 패킷의 IP/Port 정보뿐만 아니라 패킷의 URL 정보, 쿠키, 플레이로드 정보 등을 종합적으로 검사하여 사용자별로 연속적이고 차별화된 서비스를 제공해줄 수 있습니다.
L7 스위치가 기존의 L4 스위치와 가장 차별화되는 부문은 L4 스위치가 Layer4 정보(TCP/UDP port)를 바탕으로 패킷을 분류하고 원하는 서버나 장비로 전송하는 반면 L7 스위치는 패킷의 내용을 보고 이를 바탕으로 패킷을 전달한다는 것입니다. 패킷의 내용을 살펴보고 이를 바탕으로 적절한 서버를 선택할 수 있습니다.
L7 스위치 기능 중에 최근 큰 주목을 받고 있는 부문이 네트워크 보안분야입니다. L7 스위치는 기존의 L4 스위치가 갖고 있던 기능들을 모두 수용하면서 불필요한 트래픽에 대한 차단이나 네트워크에 대한 공격을 완화시켜줌으로써 서버와 네트워크의 가용성을 한층 향상시켜줍니다. 특히, L7 스위치는 웜이나, E-메일 바이러스와 같이 특정한 패턴을 갖고 있는 패킷으로서 서버나 네트워크에 불필요한 트래픽을 제어합니다.
최근에는 L7 스위치업체와 바이러스 차단업체들이 서로 제휴를 통해 새로운 바이러스 패턴이 나타날 경우 이를 빠르게 업데이트해 네트워크를 보호하고 있습니다.
또한, DoS/DDoS 와 같이 비정상적으로 트래픽이 과도하게 집중되어 서버가 정상적으로 서비스되지 못하게 만드는 부분도 해결해 줍니다.
이를 해결하기 위해서 L7 스위치에서는 트래픽의 유입수준을 일정정도로 제한하여 서버가 항상 정상적인 서비스를 할 수 있게끔 보호해 준다.
물론 L4스위치만이 L7 스위치로 발전할 수 있는 것은 아닙니다. 기존 파이어월, IPS, QoS 등 엔터프라이즈 네트워크에서 각각의 고유기능을 담당하고 있는 장비들도 패킷의 내용을 분석하는 기능을 갖고 있으며, 이를 바탕으로 여러가지 보안정책과 대역폭조절 정책을 수행해왔습니다. 따라서 이들 장비도 각각의 고유기능에 부하분산기능을 결합하고, 대용량의 트래픽을 빠르게 처리할 수 있는 스위치 구조를 도입한다면 얼마든지 L7 스위치 형태로 발전할 수 있습니다.
L7 스위치를 생산하고 있는 업체로는 시스코, 노텔, 라드웨어, 파운드리, F5 등이 있고 국내에서는 파이오링크가 L7 스위치시장에 진입해 대등하게 경쟁하고 있습니다. 한국IDC 자료에 따르면, 전 세계적으로 콘텐츠 네트워킹 시장의 46%를 L7 스위치가 점유하며 총 36억달러 이상의 매출을 보일 것으로 전망했습니다. 국내에서도 2005년도에 1000억원 규모를 훌쩍 뛰어넘는 시장으로 성장할 것으로 보고 있습니다.

[출처] L2,L3|작성자 새맘

연봉현황을 보고서

데브피아에서 온 멜을 봤다…

 

연봉이 저렇단다..

음.. 난 적정하게 받고는 있는거 같은데.. 그래도 암울하다..

 

4년제 컴공 관련 졸/병역필/자격증은 기본 보유/토익없음,스피킹 절대 안됨.

대기업,금융권 빼고 개발자의 적정연봉... 아래와 같습니다..

서울기준으로...

1년차: 2000~2200

2년차: 2200~2500

3년차: 2400~3000

4년차: 2700~3300

5년차: 2700~3500

6년차: 3300~4500

7년차: 4000~5000

8년차: 4200~5500

9년차: 4500~6500

10년차: 퇴직금도 없음. 닭집 사장.. 연봉 정해진거 없음...

2010년 2월 16일 화요일

단방향 병합 복제 구성

단방향 병합 복제 구성

게시: 2001년 8월 13일

이 팁은 SQL Server Magazine에서 제공하는 일련의 팁 중 하나입니다. 추가 팁을 보려면 SQL Server 팁과 트릭 센터를 방문하십시오.


모든 대답 보기

Q.
한 방향으로만 작동하는 SQL Server 병합 복제를 어떻게 구성할 수 있습니까?

A.

기본적으로 병합 복제에서는 데이터를 양방향으로 전달합니다. 게시자의 변경 내용은 구독자로 전송되고, 구독자의 변경 내용은 게시자로 다시 전송됩니다. 일부 경우에는 병합 복제를 사용하여 데이터를 한 방향으로만 전달되도록 허용해야 할 경우가 있습니다. SQL Server는 이를 위한 인터페이스를 제공하지 않습니다.

하지만 병합 에이전트는 단지 실행 파일(Replmerg.exe)일 뿐이라는 사실을 기억하십시오. SQL Server 에이전트에서의 병합 작업은 단순히 이 실행 파일을 호출하여 명령줄 인수를 이에 전달하기만 합니다. 이러한 선택적 명령줄 인수 중 하나는 세 가지 가능한 값을 갖는 ExchangeType입니다. 이러한 값 중 1은 밀어넣기를 지정하고, 2는 끌어오기를 지정하며, 3은 양방향을 지정합니다(기본값). 밀어넣기 구독으로 병합 복제를 설정하고 ExchangeType1로 설정하면 SQL Server가 게시자에서 구독자로 데이터를 밀어넣기만 하고 구독자에서 게시자로 데이터를 다시 보내지는 않습니다.

원본출처:http://lb1.www.ms.akadns.net/korea/sqlserver/2005/techinfo/tips/development/mergerep.mspx

[펌][MSSQL]병합 복제

구성환경
- 원본서버 : 2003 서버 엔터프라이즈, ms sql 2008
- 대상서버 : 2008 서버 스탠다드, ms sql 2008
참고 주소 : http://technet.microsoft.com/ko-kr/library/bb677158.aspx
■ 스냅숏 폴더 준비
    1.Windows 탐색기에서 SQL Server 데이터 폴더로 이동합니다. 기본 위치는 C:\Program Files\Microsoft SQL Server\MSSQL.x\MSSQL\repldata (게시자 배포설정 후 자동생성) 입니다.
    2.해당 폴더를 마우스 오른쪽 단추로 클릭한 다음 공유 및 보안을 클릭합니다.
    3.repldata 등록 정보 대화 상자의 공유 탭에서 이 폴더를 공유를 클릭합니다. 공유 이름 값이 repldata인지 확인합니다.
    4.사용 권한을 클릭합니다.
    5.추가를 클릭합니다. 선택할 개체 이름을 입력하십시오 입력란에 스냅숏 에이전트 계정(ex관리자 계정) 이름을 <Machine_Name>\<User Account>으로 입력합니다. 여기서 <Machine_Name>에는 게시자(ServerName)의 이름을 입력합니다. 이름 확인을 클릭한 다음 확인을 클릭합니다.
-복제용 계정이 따로 필요한 경우 각 게시자, 구독자 서버에서 동일한 이름과 권한으로 각각 계정생성 후 사용
       -사용자 정의 계정일 경우 게시자 생성시 해당 계정으로의 로그인 추가와 db_owner 고정 데이터베이스 역할의 멤버자격 부여 필요.

    6.확인을 클릭하여 repldata의 사용 권한 대화 상자를 닫습니다.

■ 배포 구성
    1.SQL Server Management Studio에서 게시자에 연결한 다음 해당 서버 노드를 확장합니다.
    2.복제 폴더를 마우스 오른쪽 단추로 클릭한 다음 배포 구성을 클릭합니다.
    배포 구성 마법사가 시작됩니다.  
    3.배포자 페이지에서 '<ServerName>'을(를) 자체 배포자로 사용합니다. SQL Server에서 배포 데이터베이스와 로그를 만듭니다를 선택한 후 다음을 클릭합니다.

    4.스냅숏 폴더 텍스트 상자에 기본값 로컬경로명을 삭제 후 \\<Machine_Name>\repldata를 입력한 후 다음을 클릭합니다. 여기서 <Machine_Name>에는 게시자(ServerName)의 이름을 입력합니다.

    5.마법사의 나머지 페이지에 기본값을 적용합니다.
    6.마침을 클릭하여 배포를 설정합니다.

■ 병합 복제를 사용하여 데이터 게시
    1.SQL Server Management Studio에서 게시자에 연결한 다음 해당 서버 노드를 확장합니다.
    2.복제 폴더를 확장하고 로컬 게시를 마우스 오른쪽 단추로 클릭한 다음 새 게시를 클릭합니다.
      게시 구성 마법사가 시작됩니다.
    3.게시 데이터베이스 페이지에서 게시할 DB를 선택한 후 다음을 클릭합니다.

    4.게시 유형 페이지에서 병합 게시를 선택한 후 다음을 클릭합니다.

    5.구독자 유형 페이지에서 SQL Server 2008만 선택되어 있는지 확인한 후 다음을 클릭합니다.

    6.즉시 스냅숏 만들기를 선택하고 스냅숏 에이전트 실행 시간 예약을 선택 취소한 후 다음을 클릭합니다.

    7.에이전트 보안 페이지에서 보안 설정을 클릭하고 프로세스 계정 상자에 <Machine_Name>\<User Account>을 입력한 다음 해당 계정의 암호를 입력하고 확인을 클릭합니다. 마침을 클릭합니다.

    8.마법사 완료 페이지에서 게시 이름 상자에 게시DB명 을 입력하고 마침을 클릭합니다.
    9.게시가 완료되면 닫기를 클릭합니다.
■ 병합 게시에 대한 구독 만들기
    1.SQL Server Management Studio에서 구독자에 연결하여 해당 서버 노드와 복제 폴더를 확장하고 로컬 구독 폴더를 마우스 오른쪽 단추로 클릭한 다음 새 구독을 클릭합니다.
      새 구독 마법사가 시작됩니다.
    2.게시 페이지에서 게시자 목록에 있는 SQL Server 게시자 찾기를 클릭합니다.
    3.서버에 연결 대화 상자에서 서버 이름 상자에 게시자 인스턴스의 이름을 입력하고 연결을 클릭합니다.
    4.게시DB명 을 클릭하고 다음을 클릭합니다.
    5.병합 에이전트 위치 페이지에서 각 에이전트를 해당 구독자에서 실행(끌어오기)을 클릭한 후 다음을 클릭합니다.

    6.구독자 페이지에서 구독자 서버의 인스턴스 이름을 선택하고 구독 데이터베이스의 목록에서 <새 데이터베이스>를 선택합니다.
    7.새 데이터베이스 대화 상자에서 데이터베이스 이름 상자에 구독DB명 을 입력하고 확인을 클릭한 후 다음을 클릭합니다.

    8.병합 에이전트 보안 페이지에서 줄임표(…) 단추를 클릭하여 프로세스 계정 상자에 <Machine_Name>\<User Account>를 입력하고 해당 계정의 암호를 입력한 다음 확인, 다음 및 다음을 차례로 클릭합니다.
       -구독자 생성에서의 <Machine Name>은 구독서버 게시자명 / User Account 의 경우 게시자의 계정명과 동일 해야 함.
       -복제용 계정이 따로 필요한 경우 각 게시자, 구독자 서버에서 동일한 이름과 권한으로 각각 계정생성 후 사용
       -사용자 정의 계정일 경우 게시자 서버에서 해당 계정으로의 로그인 추가와 db_owner 고정 데이터베이스 역할의 멤버자격 부여 필요.

    9.구독 초기화 페이지의 초기화 시기 목록에서 첫 번째 동기화 시를 선택하고 다음을 클릭한 후 다시 다음을 클릭합니다.

    10.마침을 다시 클릭하고 구독이 생성되면 닫기를 클릭합니다.
■ 병합 게시에 대한 구독 동기화
    1.SQL Server Management Studio에서 구독자에 연결하고 해당 서버 노드를 확장한 다음 복제 폴더를 확장합니다.
    2.로컬 구독 폴더에서 해당 데이터베이스의 구독을 마우스 오른쪽 단추로 클릭한 다음 동기화 상태 보기를 클릭합니다.

    3.시작을 클릭하여 구독을 초기화합니다.

2010년 2월 15일 월요일

[MySQL]Master/Slave Replication 구현하기

http://kldp.org/node/97646 리플리케이션의 의미

 

http://lastmind.net/blog/2008/05/mysql-replication.html 리플리케이션 정리

 

http://codememo.textcube.com/2 리플리케이션의 구성  아래내용임.

 

시스템 환경

▲구현하고자 하는 Master/Slave Replication과Replication과 시스템 환경

2. Replication 설정

Master Server (Linux)

① Replication을 위한 계정을 추가한다. 다만 4.0.2 이전 버젼의 MySQL 사용자일 경우는 REPLICATION SLAVE의 권한설정 부분이 없으므로, 대신에 FILE 권한설정 사용하여야 한다. (user id와 user password는 설정하고자 하는 것으로 하면 된다. 여기서는 둘다 repli로 설정)

mysql> GRANT REPLICATION SLAVE ON *.*
   -> TOuser id’@’%’ IDENTIFIED BYuser password’;
*4.0.2 이전 버젼은 다음과 같이 한다.
mysql> GRANT FILE ON *.* 
   -> TOuser id’@’%’ IDENTIFIED BYuser password’;

② Replication을 적용할 테이블을 생성한다.(여기서는 Test DB에 repli_test 테이블을 생성하기로 한다.)

mysql> use test;
mysql> create table repli_test (name varchar(255));

③ MySQL 서비스를 중지 시킨다.
④ /etc/my.cnf 파일을 생성하고, 아래의 내용 중 노란색으로 마킹된 내용을 추가하거나 수정한다. (my.cnf 파일은 설치시 생성되는 파일이 아니므로, 파일을 직접 작성하거나, Source를 이용해서 설치했을 경우, [mysql 설치 디렉토리]/share/mysql 디렉토리에 my-xxx.cnf 파일들이 있으므로 적당히 골라서 수정을 하여 사용한다.) server-id는 서버끼리 중복되지 않는 값을 지정하여 줄 수가 있으며, 지정범위는 1부터 2^32-1(=4294967295)까지 이다.

 

# Example MySQL config file for small systems.
#
# This is for a system with little memory (<= 64M) where MySQL is only used
# from time to time and it's important that the mysqld daemon
# doesn't use much resources.
#
# You can copy this file to
# /etc/my.cnf to set global options,
# mysql-data-dir/my.cnf to set server-specific options (in this
# installation this directory is /home/mysql/data) or
# ~/.my.cnf to set user-specific options.
#
# In this file, you can use all long options that a program supports.
# If you want to know which options a program supports, run the program
# with the "--help" option.
# The following options will be passed to all MySQL clients
[client]
#password     = your_password
port        = 3306
socket       = /tmp/mysql.sock
# Here follows entries for some specific programs
# The MySQL server
[mysqld]
port        = 3306
socket       = /tmp/mysql.sock
skip-locking
key_buffer = 16K
max_allowed_packet = 1M
table_cache = 4
sort_buffer_size = 64K
net_buffer_length = 2K
thread_stack = 64K
# Don't listen on a TCP/IP port at all. This can be a security enhancement,
# if all processes that need to connect to mysqld run on the same host.
# All interaction with mysqld must be made via Unix sockets or named pipes.
# Note that using this option without enabling named pipes on Windows
# (using the "enable-named-pipe" option) will render mysqld useless!
#
#skip-networking
server-id     = 1
# Uncomment the following if you want to log updates
log-bin
# Uncomment the following if you are NOT using BDB tables
#skip-bdb
# Uncomment the following if you are using InnoDB tables
#innodb_data_home_dir = /home/mysql/data/
#innodb_data_file_path = ibdata1:10M:autoextend
#innodb_log_group_home_dir = /home/mysql/data/
#innodb_log_arch_dir = /home/mysql/data/
# You can set .._buffer_pool_size up to 50 - 80 %
# of RAM but beware of setting memory usage too high
#innodb_buffer_pool_size = 16M
#innodb_additional_mem_pool_size = 2M
# Set .._log_file_size to 25 % of buffer pool size
#innodb_log_file_size = 5M
#innodb_log_buffer_size = 8M
#innodb_flush_log_at_trx_commit = 1
#innodb_lock_wait_timeout = 50
[mysqldump]
quick
max_allowed_packet = 16M
[mysql]
no-auto-rehash
# Remove the next comment character if you are not familiar with SQL
#safe-updates
[isamchk]
key_buffer = 8M
sort_buffer_size = 8M
[myisamchk]
key_buffer = 8M
sort_buffer_size = 8M
[mysqlhotcopy]
interactive-timeout

⑤ [mysql 설치 디렉토리]/data/test 디렉토리로 이동하여 Replication을 적용할 Table을 백업해놓는다.(백업한 Table 파일은 Slave DB Server에 복사해서 사용할 것이다. 사실 이렇게 파일 복사 말고 Table export를 하여 Slave DB에 import 시켜도 된다.)

# ls
repli_test.MYD repli_test.MYI repli_test.frm
# tar cvzf repli_test.tar.gz *

Slave Server (Windows 2000 Pro)

⑥ MySQL 서비스를 중지 시킨다.
⑦ C:\WINNT\my.ini 파일을 아래와 같이 노란색으로 마킹된 내용을 추가하거나 수정한다.

[WinMySQLAdmin]
Server=C:/mysql/bin/mysqld-nt.exe
[mysqld]
master_host=192.168.0.1
master-user=repli
master-password=repli
master-port=3306
server-id=2

⑧ Master Server에서 백업한 Replication을 적용할 Table 파일을 C:\mysql\data\test 디렉토리에 압축을 풀어놓거나 복사해 놓는다. (⑤과정참조)

Master & Slave Server

⑨ Master Server의 MySQL 서비스를 시작한 후, Slave Server의 MySQL 서비스를 시작한다.

3. Test 및 MonitoringMonitoring 하기

Test는 간단하게 Master Server에서 Data값을 Insert, Update, Delete를 해보고, 결과가 Slave Server에도 반영이 되는지 살펴보면 된다.(Master/Slave Replication 구성으로는 Slaver Server에서 Data값을 Insert, Update, Delete를 해도 Master Server에는 반영이 되지 않는다.)

*Master Server
mysql> insert into repli_test value ('test1');
Query OK, 1 row affected (0.00 sec)
*Slave Server
mysql> select * from repli_test;
+-------+
| name  |
+-------+
| test1 |
+-------+
4 rows in set (0.01 sec)

Master와 Slave Server의 상태를 확인하고 싶을 때에는 다음과 같은 명령어를 실행한다.

*Master Server
mysql> show master status \G
*************************** 1. row ***************************
       File: XXX-bin.002
    Position: 300
  Binlog_do_db:
Binlog_ignore_db:
1 row in set (0.00 sec)
*Slave Server
mysql> show slave status \G
*************************** 1. row ***************************
      Master_Host: XXX.XXX.XXX
      Master_User: repli
      Master_Port: 3306
    Connect_retry: 60
   Master_Log_File: XXX-bin.002
Read_Master_Log_Pos: 300
    Relay_Log_File: XXX-relay-bin.002
    Relay_Log_Pos: 456
Relay_Master_Log_File: XXX-bin.002
  Slave_IO_Running: Yes
  Slave_SQL_Running: Yes
   Replicate_do_db:
Replicate_ignore_db:
      Last_errno: 0
      Last_error:
     Skip_counter: 0
Exec_master_log_pos: 300
   Relay_log_space: 452
1 row in set (0.00 sec)

Slave Server에서 Replication을 중단(slave stop)하거나, 다시 시작(slave start)할 때에는 다음과 같은 명령어 실행한다.

*Slave Server
mysql> slave stop;
Query OK, 0 rows affected (20.69 sec)
mysql> slave start;
Query OK, 0 rows affected (0.00 sec)

4. Replication을 응용한 구성의 예

▲Dual-Master Replication

▲Replication RingRing

▲Relay

▲Load-Balancing Reads

5. 참고자료

http://dev.mysql.com/doc/mysql/en/Replication_HOWTO.html
http://jeremy.zawodny.com/mysql/managing-mysql-replication.html