A.J.Kuhn, Endless supply of passion!

序.
소프트웨어의 버전관리를 위한 여러 소프트웨어가 존재하고, 이들의 기능은 충분할 정도로 강력하다. 하지만 버전관리는 어떤 버전관리 시스템을 이용하느냐(What) 보다, 어떻게 사용하는가(How)가 중요한데, 실제적으로 이에 관한 논의는 부족해 보인다.

오로지 trunk에다가 commit/update를 반복하고만 있지는 않은가? 대부분의 프로젝트들이 이런식으로 진행되는 것이 현실이다.

버전관리 방안은 프로젝트 내에서 개발자 전체가 공통으로 지켜야만 의미가 있으며, 그렇지 않을 경우 되려 프로젝트에 방해가 될 수 있다. 때문에 룰이 너무 복잡하지 않은... 모두가 따를만한 실용적인 방안을 제안하고자 한다.(Subversion 기준)

1. Glossary
* SVN : 버전관리 시스템 Subversion의 약자
* revision : Subversion의 버전번호. 하나의 commit때마다 1씩 증가됨
* trunk : 관습적으로 Subversion에서 버전의 줄기 이름이자 디렉토리 이름으로 사용됨
* branch : 버전의 가지를 의미하며, 보통 주요 릴리즈마다 생성됨 각 릴리즈에서의 버그패치는 여기서 이루어짐
* tag : 의미있는 특정revision에 부여하게 되며, 보통 특정tag의 소스는 변경하지 않는 것이 원칙
* RB : Release Branch의 약자. 배포용 branch이름의 prefix로 흔히 쓰인다.
* REL : Release의 약자, 배포용 tag이름의 prefix로 흔히 쓰인다.
* BUG : 버그수정용 branch이름의 prefix로 흔히 쓰인다.
* PRE : 버그수정이전 tag의 prefix로 흔히 쓰인다.
* POST : 버그수정이후 tag의 prefix로 흔히 쓰인다.
* TRY : 실험적인 용도의 branch의 prefix로 흔히 쓰인다.

序.
로컬에서의 테스트에서는 극히 정상적으로 quartz스케쥴러가 작동하였고, 이를 테스트서버와 실서버로 옮겼을때는 동시에 두번씩 동작하는 문제가 발생했다.
세 서버의 Tomcat/Spring/Quartz의 버전은 완전히 동일...

1. 일단 큰 차이랄 수있는 OS/JVM의 차이를 의심하였다. 구글링을 해보니 비슷한 증상(윈도우 정상작동, 리눅스 스테이징으로 옮기니 발생)인 사람들을 여럿 발견... 희망이 보이기 시작....

벗뜨.. 이런 얘기한 사람들은 다 답을 얻지 못함...

2. 다음은 Spring 혹은 Quartz의 버그를 의심.
Spring + Quartz의 조합으로 비슷한 증상을 호소한 사람들이 미쿡(= 영어였다는 얘기다;;;)에는 꽤 많았다...
이는 web.xml에서 Spring의 ContextLoader가 중복호출되어 복수의 Quartz인스탄스가 생겨 발생하는 경우였다. 웹어플리케이션 상에서 둘 이상의 Listener or Servlet을 등록때 하나의 context정보 파일을 두 번 이상 부를 수 있는 경우가 있다는 것이다.

webapp의 lifecycle과 Spring의 Bean생성 과정을 자세하게 알지 못하면 쉽게 할 수 있는 실수였다... 드디어 찾았구나~ 하고 좋아했다...
 
근데...

이 경우라면 로컬에서는 이상없는 것이 설명되지 않았다...
로컬에서 이상이 없는 이유를 찾느라 한참을 소비해야했다...

결론적으로... 내 경우의 Spring설정은 완벽했다;;;

3. 처음부터 서버 설정을 크게 의심하지 않은 것은, 테스트 서버와 실서버가 모두 잘 돌고 있었기 때문이다. 또한 설정파일 역시 모두 공유해서 사용하고 있었기 때문에 시야를 벗어나는 좋은 이유가 되었다. 처음부터 톰캣 인스탄스가 2개인것은 의심해 보았다. 2개가 떠있어서 하나는 포트를 못열고 놀고만 있는... 그러나 스케줄러는 작동되고 있는... 하지만 이것에 해당하지는 않았다.

유일하게 공유되고 있지 않은 설정파일인 톰캣의 server.xml파일을 열어봤다...

뭔가 감이 왔다;

그렇다, Host의 appBase는 여러 webapp들이 들어갈 母 디렉토리다. 즉, 이하의 디렉토리는 webapp의 자격조건을 가지고 있으면 자동으로 webapp로 구동되는 것이다.
Context는 이와는 별도로 webapp의 위치를 직접 지정가능하다.

결국 위의 설정은 두개의 'test' webapp를 구동하도록 만들었다. 스케쥴러도 두개가 뜬것이다.

Tomcat에서 동일한 Web Application Context 두 개가 뜬다한들 작동에는 별 문제가 없을 것이다. 둘의 ContextPath가 다르다면 말이다. 위의 경우 Host에서는 "test"라는 ContextPath로 webapp가 떴을 것이고, Context에서는 지정한대로 ""(=루트) ContextPath로 떴으니 아무런 문제가 없었던 건이다.

여튼 Tomcat설정시 Host의 appBase위에 Context로 설정할 app를 올리지 말아야한다. 이는 의도하지않은 작동을 야기한다. 본인은 다양한 이유로 appBase의 위치를 바꾸는 방법을 택했다.

結.
Quartz의 스케쥴러가 이중작동하는경우(굳이 이러한 경우가 아니더라도, 서버구동시 한번만 실행되도록 했는데 두번 실행되는 모든 경우).....

우선 Spring을 사용하는 경우는 Spring설정에 주의를 기울여라. Spring이 인스탄스의 라이프사이클을 제어하는 경우가 많아서, 개발자가 미처 인지하지 못하는 사이 인스탄스화가 일어날 수 있다. 구체적인 사례는 여기를 참조한다.

이게 아니라면 Container의 라이프사이클을 의심하라. 혹시 프로세스가 두개가 뜨지는 않았는지... 프로세스는 하나지만 복수의 Context를 구동하게 되지는 않았는지... 이 모든 것은 Container의 설정으로 해결해야 할 것이다. 1번의 경우(OS, JVM의심)도 결국 이러한 상황이었던 것으로 보인다.

휘발성으로 이용되는 파일들이나 로그파일등.. 파일이 생성된지 일정기간이 경과하면 파일을 삭제해야하는(하는게 좋은) 파일들이 있다. 이들을 삭제하기 위한 방법은....

* 생성된지 30일 이상 된 파일만 삭제

* 생성된지 30일 이상 된 비어있는 디렉토리만 삭제

리눅스 버전에 따라 -ctime이 먹지 않는 경우가 있다. 이때는 -mtime으로 대체(의미는 약간 다르지만)한다.

이러한 쉘을 crontab에 하루단위로 동작하도록 등록해두면 편리하겠죵?

Preface

몇 년 전, 모 솔루션 소프트웨어 개발 프로젝트의 PM일을 하고 있을 때였다. 이런저런 고생끝에 제품이 대략 완성되고, 완료보고를 하려는 즈음.... 완료보고와 함께 White Paper를 내놓으면 좀 더 완료보고의 모양새가 나지 않을까? 생각했다. 대충 다른 제품의 White Paper를 참고로 쓰면 되겠지~ 하고 샘플(경쟁제품 포함)들을 수집했는데...

이것 참;; 해외업체건 국내업체건 맘에드는 수준있는 White Paper를 내놓은 곳이 단 한 곳도 없는것이 아닌가! 이들을 참고로 작성해선 안된다는 생각이 들어 본격적으로 White Paper 작성법을 찾아보기 시작했다.

그런데 여기서 또 문제....

White Paper 작성법에 대한 몇몇 글들이 있긴 하였으나, 대부분 Specification이나 하드웨어 제품들을 타겟으로 하는 작성법이어서.. 당장 작성하려고 하는 Software제품에는 적용하기 힘든 부분이 많았다.

결국 Software Product에 대한 White Paper 작성법을 부족하나마 나름대로 정의해 보기로 했고, 그때 나온 결과물을 조금 손보아서 이렇게 내놓는다. 사실 7장에 나열한 참고자료들을 SW업계 환경에 맞추어 첨삭을 가하고, 약간의 의견을 더한 수준에 지나지 않는다. 여튼, 나와 같은 고민을 하는 개발자나 PM들에게 작은 도움이 되기를 바래본다.

Software의 경우는 Business Point, 혹은 Techinical Point에 중점을 두는 White Paper가 나올 수 있다. 여기서는 두 가지가 적절히 조화된 White Paper의 작성을 기준으로 기술하였다.

이 글의 초고 작업에는 지금은 N모사에 계신 김송기씨가 함께 했다.

1. What is the Software Product White Paper?

White Paper는 영국 정부의 공식 보고서 표지가 하얀색인 데서 유래한 용어로, 정부기관이 정책이나 실적을 종합 정리해 발표하는 공식 보고서의 통칭을 가리킨다. 하지만, IT 분야에서는 기술, 제품, 이슈, 표준 규격, 정책, 솔루션에 관한 개요를 브리핑하는 자료를 말한다.

그 중에서 Software Product White Paper(이하 White Paper)는 제품의 운영과 철학 또는 기술 배경을 설명하기 위해 만든 자세하지는 않지만 전문적인 자료라고 할 수 있다. 보통 소프트웨어 제품의 발표와 함께 제공된다.

1.1. 목적
White Paper는 회사의 제품을 압축적으로 간단하게 소개하는 자료로써, 다른 사람 또는 업체로 하여금 전문적인 지식 및 사업 정보를 공유하기 위한 자료이다.
White Paper는 제품 홍보 또는 기업 홍보, 세미나 자료, 회의 자료 등으로 쓰이기 때문에 새로운 분야에 대한 소개, 혁신적인 솔루션(제품)의 홍보, 특정 타겟 대상의 설명에 아주 효과적인 자료로 이용될 수 있다.
그러나 White Paper는 궁극적으로 제품 판매를 목적으로 한다.

1.2. 역할
White Paper는 White Paper를 쓰는 측과 읽는 측에 대하여 각각 다음과 같은 역할을 한다.

● Sales & Marketing 수단(작성자 측의 경우)
White Paper는 제품을 포장하는 수단이다. White Paper를 통해 제품에 흥미를 더하고 겉으로 보이는 모양 이외에 제품의 이면까지 White Paper를 통해 보여줄 수 있다. 제품을 잘 포장한 White Paper는 훌륭한 마케팅 도구로 활용될 수 있으며 보이지 않는 제품을 더욱 값진 제품으로 표현할 수 있다.

● Decision Making Point(읽는 측의 경우)
IT 산업에서 White Paper가 가지는 영향력은 가히 크다고 할 수 있다. White Paper는 구매결정자들로 하여금 제품을 구매하도록 이끄는 가장 중요한 수단이다.
제품들과 서비스를 선택할 때 구매 결정자들은 옳은 선택을 하기 위하여 엄청난 압력을 받는다. 그들이 구매를 할 수 있도록 도와줄 수 있는 가장 설득력 있는 것은 바로 왜 이 제품/서비스가 그들의 요구사항에 적합한지를 증명한 White Paper이다.

※ 리서치 자료에 의하면 구매 결정자들이 어떤 제품을 구매하려고 할 때, 가장 먼저 고려하는 것이 White Paper라고 한다.
※ 또한 구매 결정을 할 때 가장 마지막으로 고려하는 사항도 White Paper이다.
※ White Paper는 생명력이 길다. 예를 들어 잡지나 신문 같은 매체는 쉽게 버리는 반면 White Paper는 당장 필요하진 않더라도 언젠가 필요한 날을 대비하기 위해서 쉽게 버리지 않기 때문이다.

2. Software Product White Paper의 내용 구성

Sortware Product의 White Paper에는 다음과 같은 내용들이 포함되어야 한다.

● 시장분석 자료
제품이 어느 분야(분류)에 해당하는지 명확한 Positioning을 하고, 해당분야의 충분한 사전 조사가 있은 후 다른 제품과의 차이점과 해결책을 제시하여, 전형적인 고객뿐만 아니라 잠재적인 고객들에게도 어필할 수 있는 객관적인 시장 분석 자료가 필요하다.

● 제품특징
제품의 특징이 무엇인지, 그 제품을 통해 무엇을 해결할 수 있는지 상세히 기술하도록 한다.

● 제품분석 자료
제품에 대한 그래프, 차트, 테이블 등의 자료를 통해, 제품의 이해도를 높이고 기술 명세를 명확히 하여 고객이 알기 쉽도록 자료를 만든다.

● USP(Unique Selling Point)
경쟁사의 제품과의 차이점을 객관적인 자료에 근거하여 설득력 있게 기술하며 이 제품만의 Unique selling point를 설명할 필요가 있다.

● 고객에게 줄 수 있는 혜택
고객의 입장에서 사업 목적과 기술적인 저해 요인을 파악하고, 이 제품을 통하여 어떤 해결책을 줄 수 있으며 고객에게 어떤 이점을 줄 수 있는지 명확히 할 필요가 있다.

3. Software Product White Paper 작성 Tips

효과적인 White Paper의 작성을 위한 다음과 같은 Tip들을 제시한다. 이러한 Tip들은 전체적인 문서의 품질을 높이는데 기여할 것이다.

● 그래프를 잘 활용하라
제품을 이해하도록 도와주는 그래프나 이미지, 테이블 등을 사용해야 한다. 그래프는 개념, 기술, 시스템 관계 등을 글로만 설명하는 것 보다 훨씬 효과적으로 White Paper의 내용을 이해시켜 준다. 특히나 기술 설명 부분은 고객들에게 지루함을 줄 수 있기 때문에 이 같은 자료가 꼭 필요하다.

● 전문용어는 피하라
어려운 용어는 사용하지 말고 명확하고 알기 쉬운 용어를 선택해야 한다. 글을 읽는 사람이 용어를 이해하지 못한다면 White Paper의 전체적인 내용에 신뢰를 잃을 수 있다. 만약, 그 용어를 꼭 사용해야 한다면 먼저 그 용어에 대한 설명부터 해주는 것이 좋다.

● 한 문단엔 하나의 주제만을 기술하라
한 문단에서는 하나의 주제를 가지고 내용을 전개해나가야 한다. 한 문단에 여러 화제가 섞여 있으면 내용의 이해도도 떨어질 뿐만 아니라 고객도 잃을 것이다.

● 사례연구를 포함하라
보통 White Paper에서는 해결방안에 있어서 이론 응용 법을 이용한다. 예를 들면 ‘제품 X는 A라는 상황에서 B를 할 것이다.’ 는 식의 내용을 쓴다. 그러나 이것은 너무 추상적이어서 고객에게 신뢰감을 줄 수 없다. 따라서 이론에 따른 실제 사례 연구가 White Paper에 포함되면 제품의 해결 방안이 고객에게 어떤 식으로 해결책을 제시해주며, 또 어떤 이점을 가져다 줄 수 있는지 증명하는데 아주 효과적이다.

● 사전 요약은 흥미로운 내용으로 작성하라
본론 시작 전에 요약 내용을 쓰기도 하는데 여기에서는 가장 흥미로운 내용을 가지고 작성하도록 해야 한다. 요약 내용이 너무 딱딱하거나 어려우면 본론을 읽기도 전에 White Paper에 대한 흥미가 떨어져 끝까지 읽지 않게 된다.

● 도입부분에 결론을 써라
글의 도입부분은 White Paper의 내용으로부터 만들어낸 결론 및 주제를 드러내기에 가장 좋은 부분이다. 마치 신문 기사에서 헤드라인을 화려하게 장식하는 것과 같다. 물론 마지막에 결론을 쓰긴 하지만 미리 독자에게 결론을 알려주고 그 결론에 따라 전체적인 내용을 파악할 수 있도록 만든다.

● 투자자의 입장에서 생각하라
먼저 고객들을 이해하려고 노력해야 한다. 고객들이 관심을 가지고 있는 것을 정확히 판단하여 그들이 요구하는 것들을 충족시켜줘야 한다. 특히 고객들은 그들의 요구를 충족시키기 위한 신뢰할 수 있는 증거들을 찾을 것이다. 이 증거를 제공하는 것으로, 그들에게 시간을 덜어줄 뿐만 아니라 신용도를 증가시킬 수 있다.

● 차별성을 강조하라
타 제품과의 차별성을 객관적인 사실에 근거하여 기술해야 한다. 제품의 해결방안이 경쟁 제품보다 좋다는 것을 증명하고 어떤 이유로 더 좋은지를 설명해야 White Paper가 더 설득력을 가질 수 있다.

● Feature와 Benefit의 차이점을 이해하라
종종 특징과 이점을 정확히 구별하지 못하고 글을 쓰게 되는 경우가 있다. 간단히 이 차이점을 설명하면 특징은 제품을 판매하는 쪽과 관계가 있고 이점은 제품을 구매하는 쪽과 관련이 있다고 할 수 있다. 따라서 이점을 쓸 때는 이 제품을 통해 구매자가 어떤 이익을 얻을 수 있는지를 써야 한다. 예를 들면 이 제품을 구입함으로써 구매자의 매상은 얼마나 올라가는지, 시간은 얼마나 줄일 수 있는지, 사업을 얼마나 향상 시킬 수 있는지를 작성해야 하는 것이다. 

특징과 이점의 차이를 다음 문장을 통해 구별할 수 있다.

[특징]
* 우리의 신제품은 100회의 반복을 줄일 수 있습니다.
* A 제품은 사용하기 쉽습니다.
* 우리의 웹사이트는 전송 받는 시간이 아주 빠릅니다.

[이점]
* 구매자는 한 달에 100만원의 이익을 가져가실 수 있습니다.
* 사용자는 5분만에 A 제품의 사용법을 알 수 있습니다.
* 고객님은 우리 사이트를 방문하는 것만으로도 시간을 절약할 수 있습니다.

● 조화를 이뤄라
White Paper는 기술 문서도 아니고 마케팅 문서도 아니다. 지나치게 기술 위주의 문서가 된다면 내용이 딱딱해져 글을 읽는 사람에게 흥미를 떨어뜨릴 것이고, 또 너무 마케팅 위주의 문서가 된다면 제품이 과장되어 보여 신뢰성을 떨어뜨릴 것이다. 따라서 기술과 마케팅 문서의 적정한 선을 지키며 조화를 이룰 수 있도록 한다.

● 부정적인 내용을 언급하지 마라
제품의 부정적인 내용은 언급하지 말고 경쟁 제품의 약점을 언급한다. 단, 경쟁사의 이름을 직접적으로 표기하진 않는다.

● 적절한 분량으로 작성하라
White Paper의 길이는 보통 2-3 페이지에서 약 50 페이지 정도로 작성하며, 12-18페이지 정도가 가장 적당하다.

● 적절한 포맷으로 배포하라
포맷은 HTML이 가장 좋고, 다운로드 하기 쉽도록 PDF로 하는 것도 좋다.

4. Software Product White Paper 작성절차

보통 White Paper의 작성절차는 다음과 같은 절차를 따른다.

1. 자료수집
전체적인 내용을 파악하고, 표/그림등을 활용하기 위하여, 제품을 개발하기 위해 작성되었던 기능명세서, 모듈설계서, 디자인설계서등을 수집한다. 또한 타 제품과의 비교를 위하여 시장조사 자료도 준비한다.

2. 주제의 선정
당연히도 제품의 설명과 우수성의 설파가 주제가 되겠으나, White Paper의 내제적 용도는 업체/시장/제품 사정상 다소 상이할 수 있다. 이에 알맞은 적절한 주제를 선정한다.

3. Target의 선정
글을 읽을 대상이 누구인지 정하고, 대상에 맞는 수준의 내용을 작성하도록 하여 이해도를 높이도록 한다.

4. 목차 선정
목적과 대상에 따라 White Paper의 목차를 잡고 개요를 잡도록 한다. 목차에 따라 글의 흐름이 달라질 수 있기 때문에 충분히 검토하도록 한다.

5. 용어의 통일
공통으로 쓰이는 용어나 통일성을 가져야 할 용어는 미리 정하여 작성 담당자들이 모두 같은 용어를 쓸 수 있도록 한다. 각 부분의 작성 담당자가 다르기 때문에 미리 규칙을 정해놓지 않으면 글의 통일성이 떨어지기 때문이다.

6. 양식 및 폰트 결정
문서의 형식(단계별 번호나 형태 등)부터 폰트까지 글을 쓰기 전에 미리 정하도록 한다.

7. 작성 담당자 선정
목차에 따라 각 부분의 작성 담당자를 정한다.

8. 작성
앞서 정해진 규칙에 따라 담당자 별로 작성한다.

9. 취합 및 퇴고
마지막으로 작정자 중 대표자가, 나누어 쓰여진 각 부분을 모두 취합하여 목적에 맞게 잘 쓰여졌는지 검토를 하고 마지막 수정을 하도록 한다.

10. Release
문서를 배포한다.

5. Software Product White Paper 목차 예제

목차의 선정은 가장 고민스럽고 가장 신중해야 하는 작성 단계이다. 일반적인 목차예제를 다음과 같이 제시한다. 그러나 이는 제품의 특성에 따라 상이해야 할 필요성도 있으므로 참고 자료로만 활용하라.

1. Introduction
제품에 대한 소개 글로써 제품을 만들게 된 명확한 목적과 배경을 기술하되, 제품에 대한 시장 현황과 흐름, 타 제품과의 차이점 등을 기술하도록 한다.
* Needs
시장에서의 제품의 필요성을 기술한다. 어떤 회사 또는 어떤 부분(시장)에서 이 제품을 필요로 하는지 대체 상품으로는 무엇이 있는지 기술한다.

2. Overview
제품의 전반적인 컨셉을 기술한다. 제품의 이름 설명(의미), 기본 개념, 정의, 제품 구성, 사용 환경, 전체적인 사용법 등을 설명한다. (소개 자료와 비슷한 맥락 일 수 있으며 보통은 소개 글과 합쳐서 하나로 쓰이는 경우가 많으나 나누어 쓰기도 한다.)

3. Feature
제품의 주요 특징을 기술한다. 타 제품과 비교하여 장점을 상세히 설명하고 왜 이 제품을 사용해야 하는지 설득력 있게 설명한다. 

4. Functions
제품의 주요 기능을 기술한다. 우선 주요 기능을 구분하고 각각의 기능에 따른 정의를 명확하게 설명한 후 프로세스와 기능리스트를 상세하게 작성한다.

5. System Architecture
제품의 시스템 구성을 기술한다. 시스템 구성에 대한 소개와 각각의 기능을 설명하고 이미지를 첨부하여 이해가 쉽도록 한다. 우수하고 검증된 System Architecture는 고객에게 제품의 신뢰감을 높이는데 일조한다.
* Standard Support
국제 표준을 따르고 있는지 기술한다. 어떤 국제 표준을 따르고 있으며, 표준화로 인한 이점이 무엇인지 설명한다.

6. Benefit
제품을 사용하는 회사 또는 사용자에게 주어지는 혜택을 기술한다. 제품을 사용함으로써 회사 또는 사용자에게 어떤 이점을 주며 그것으로 인한 회사의 발전 방향이 무엇인지 상세히 설명한다. 가능하면 수익 구조에 관한 내용도 첨가할 수 있도록 한다.

7. Conclusion or Epilogue
White Paper의 결론을 맺는 내용으로 제품의 간략한 소개와 비전을 기술하도록 한다.

6. White Paper Example

http://www.hannonhill.com/downloads/pdf/Hannon_Hill_Content_Management_WhitePaper.pdf
http://www.sitecore.net/Benefits/Product%20overview/Evaluation%20tools/Choosing%20CMS.aspx
http://software.emc.com/collateral/content_management/documentu\m_family/wp_tech_cis.pdf
http://www.eclipse.org/whitepapers/eclipse-overview.pdf
http://www.utopianet.org/news/file-11.pdf#search='white%20paper'
http://www.sun.com/products/soa/composite_app_tco.pdf
http://www.wapforum.org/what/WAP_white_pages.pdf
http://java.sun.com/developer/technicalArticles/WebServices/JWS_2/JWS_White_Paper.pdf
http://www.uddi.org/pubs/Iru_UDDI_Technical_White_Paper.pdf

7. 참고자료

http://ww.casestudieswriter.com/how2wp.html
http://ww.perrymarshall.com/whitepapers/
http://www.stelzner.com/copy-HowTo-whitepapers.php
http://www.writing-world.com/tech/tech4.shtml
http://www.studygs.net/wrtstr11.htm
http://www.darrenbarefoot.com/writingsamples/TenTips.pdf
http://aplawrence.com/Misc/ctaylorwhitepaper.html
http://owl.english.purdue.edu/owl/resource/546/01/
http://www.mwknowles.com/free_articles/white_paper/white_paper.html
http://pegasus.cc.ucf.edu/~gurney/WhPaperRev4LAH.doc
http://www.pegr.com/whitepapers.html
http://www.itbusinessedge.com/research/?ggkey=white+paper
http://www.bpm-advisor.com/whitepaper2.php
http://www.klariti.com/white-papers/index.shtml
http://www.sage.org/whitepapers/guidelines.mm
http://www.clarityconsulting.com/what_makes_a_good_white_paper.htm

무료 텔넷/SSH 클라이언트인 Putty는 많은 사람들이 사용하는 유명한 프로그램이지만, 한글 입력문제가 있어왔다. 때문에 KLDP에서 한글화 작업프로젝트가 있어왔고, 그 결과물로 한글PuTTY가 돌아다니고 있다.

하지만 오리지널 PuTTY가 버전업을 계속하고 있는 반면, 한글 PuTTY는 그 후 버전업이 없는 상태라 계속해서 이전버전을 쓸 수 밖에 없다(요거 상당히 찝찝하다...). 또한, 한글 PuTTY에서는 Serial통신 기능이 빠졌다고 한다.

이미 깔려있던 영문 PuTTY로 한글을 쓸 순 없을까 고민해서 검색해 봤더니 인터넷에서 좋은 방법이 이미 나와 있었다. 방법대로 해보니 이상없이 한글입력이 되었다!!

참고로 나의 PuTTY는 0.60버전이다.


원문 : http://cafe.daum.net/KingOfLinux/2LGH/34?docid=bCrN|2LGH|34|20070320164333&q=%C7%D1%B1%DB%20putty&srchid=CCBbCrN|2LGH|34|20070320164333

영문 오리지널 putty 한글 사용하기
SE 일을 하다 보니, 이것 저것 잡다한 일을 많이 하게 됩니다. ^^;
Unix/Linux 시스템(OS + Application)을 만지면 telnet 이나 ssh 를 많이 사용합니다.
그러다 보니, 한글 환경은 당연히 되야 작업이 편하지요.
하지만, KLDP에 있는 한글putty와 같은 한글 작업이 완료 된 것들은
Serial 통신 부분이 없습니다. 아마도 한글화 작업 과정에서 정상적으로 안되어 뺀것으로 알고 있습니다.
Putty 오리지널 설치 패키지 파일을 설치하고, 다음과 같은 작업을 하면, 터미널 접속시 한글 작업 및 콘솔(Serial 통신) 접속시 정상적으로 작업이 가능합니다.
네트워크(L4/L3/L2) 및 서버 장비에 Console 접속시 아무런 이상없이 접근이 가능했습니다.
SecureCRT와 같은 상용프로그램을 자주 사용하시는 분이라면 가볍고, GNU GPL 라이센스 정책을 따르는 오픈소스를 사용해 보시 것도 좋은 생각이라 사료됩니다. ^^

1. putty 0.59 (최신버전) 다운(http://www.chiark.greenend.org.uk/~sgtatham/putty/)
2. putty session을 하나(Default Settings) 만들어서 save 한다.
3. 윈도우 regedit를 실행한다.
4. HKEY_CURRENT_USER - Software - SimonTatham - PuTTY - Sessions - Default%20Settings 항목을 선택한다.
5. 오른쪽 창에 FontCharSet이 0으로 되어 있는데, 그걸 16진수 81(10진수 129)로 바꾼다.
6. Putty로 Serial(콘솔) 및 Telnet, SSH 접속해 보세요. 잘 될 겁니다.

Sessions 밑에는 기존에 만들었던 모든 세션들이 있다. 이들의 FontCharSet값을 변경해주면 기존 세션에도 모두 적용된다.

p.s. 원문이라고 표현한 다음까페의 글이 실제 작성자의 오리지날 원문같지는 않다. 왜냐하면 해당글이 [펌]게시판에 있고, 첫줄처럼 제목이 내용속에 함께 들어있었기 때문이다.

ASF의 DBCP를 사용하나, 커넥션이 자주 사용되지 않는 Java Application의 경우에 Database에 의해서 커넥션이 단절되는 현상이 나타날 수 있다.
MySQL의 경우에는 8시간동안 사용되지 않은 커넥션(DBCP가 물고있던..)은 MySQL이 강제로 끊어버리게 되는데, 이렇게 되면 Java Application이 기대대로 동작하지않게 된다. 보통은 아래와 같은 메시지가 나타나게 된다.

'com.mysql.jdbc.CommunicationsException: Communications link failure
Last packet sent to the server was 18 ms ago.'

이러한 경우 MySQL의 JDBC설정 시

url="jdbc:mysql://127.0.0.1:3306/test?autoReconnect=true"

와 같이 'autoReconnect'옵션을 주게 되면, 커넥션에 문제가 있을 경우 다시 접속하게 된다.
그러나, 이 경우에도 끊어진 후 처음 한번의 시도는 실패가 나게 된다(이때 문제가 있다는것을 알게 되는 것이므로..).
 
이때는 추가적인 DBCP옵션인 'validationQuery'값의 설정으로 해결 가능하다.

validationQuery="select 1" => MySQL의 경우
validationQuery="select 1 from dual" => Oracle의 경우

validationQuery는 가장 간단한 결과값을 갖는 쿼리를 넣어야 한다. 왜냐하면 모든 사용자쿼리의 실행전에 이 쿼리가 실행되어 validation을 체크하기 때문이다.
valicationQuery가 추가적인 부하이기 때문에 실제로 커넥션 사용이 거의 없는 Application에서만 사용할 것을 권장한다.

validationQuery에 대한 추가적인 설정은 여기를 참조한다.

crontab -e로 편집모드로 진입. 편집이 완료되면 :wq 로 종료
별도의 재기동절차는 필요없다.

Quick Reference는 아래를 참조
http://www.adminschoice.com/docs/crontab.htm

원문 : http://hbesthee.tistory.com/276