simple note

클라우드 기반 애플리케이션 개발 국내도서>컴퓨터/인터넷 저자 : 크리스토퍼 M. 모이어(Christopher M. Moyer) / 정윤진역 출판 : 제이펍 2011.10.28 상세보기

앞부분에 작게 써있는 "개념, 패턴, 그리고 프로젝트" 를 유념해서 보면 됨.

초반의 대표 서비스별 구분은 유용하지만 이건 다른 책에도 나와 있는거라서..

패턴 부분은 다소 실망... 그리고 프로젝트도 아마존 서비스를 사용하는 파이썬 기반 개발 예제라서 그닥..

개인적으로 역자의 지나치게 자세한 설명은 흐름을 끊고 말았다. ( 용어집 내용 보다는 구글링을 권장)

하여튼, 관심사가 달라서였는지 몰라도 잘못 집은 책인듯.

/////////////////////////////////

일반적인 애플리케이션들이 필요로 하는 것은 다음과 같다.
. 컴퓨팅 파워
. 빠른 임시 저장소
. 큰 데이터를 오랜 기간 저장할 스토리지
. 작은 데이터를 오랜 기간 저장하며 쿼리가 가능한 스토리지 (DB)
. 컴포넌트나 모듈과의 통신
p49-50

큰 데이터의 대상은 멀티미디어 등 DB에 담지 않는 대용량의 데이터를 의미
RDB 서비스른 주로 MySL을 이용하고 있는 추세임. (아마존 RDB)


클라우드 프론트 서비스의 가장 큰 단점은 S3에서 발생한 업데이트가 모든 CDN 리소스에 동기화되는 데 최대 24시간이 걸릴 수도 있다는 것이다... 이렇게 민감한 형태의 자원을 다루어야 한다면, 사설 배포 옵션을 사용하고 접근을 관리할 때 미들맨 URL 인증 시스템을 제공하는 것이 더 좋은 방법이 될 수 있다. p97

... 클라우드 프론트의 새로운 기능 중 하나는 캐시로부터 기존의 파일을 강제로 삭제하고 S3의 원래의 버켓으로부터 다시 동기화하거나, S3에 파일이 남아있지 않으면 클라우드 프론트에서 모두 지워버리는 것이다. ... p98

EBS(Elastic Block Storage) EC2의 인스턴스에 연결이 가능한 가상의 디스크로 데이터의 영구적인 저장이 가능.

하지만 이 EBS볼륨은 기본적으로 네트워크를 통해 연결된 파일시스템이기 때문에 실제 물리적인 하드웨어보다는 그 속도가 매우 떨어짐에 유의하도록 한다. p111

구글이 제공하는 서비스들의 약점은 바로 이러한 형태로 서비스하는 클라우드가 구글이 유일하다는 점이다. ...
구글앱엔진을 사용한다는 것은 개발자와 서비스를 구글에 종속적으로 만들게 되며, 만약 시스템을 이전해야 하는 상황이 발생하게 되면 선택 가능한 옵션이 매우 적어지게 된다. p137

Google Storage : 아마존 S3과 유사한 스토리지 서비스. S3 사용자들의 이전을 도움. 

아마존과는 다르게 랙스페이스는 고객을 단 하나의 클라우드 서비스 공급자에 제한되도록 할 필요가 없다는 것을 깨닫고, 모든 서비스를 오픈 소스 기반으로 제공함으로써 개발자에게 기존의 하드웨어에서 동작하던 애플리케이션들을 그대로 사용할 수 있도록 지원한다 . p139

CloudFiles 서비스 : S3와 비슷한 구조와 과금 형태. 파일 저장 스토리지와 파일에 대한 권한 설정 인터페이스 제공

CloudServers : 일반적인 가상서버와 비슷한 환경을 제공 (사용후 정지시 폐기되지 않음) 

CloudSites : 랙스페이스의 PaaS 플랫폼. 구굴 앱엔진과 유사. 전통적인 웹호시팅과 유사.  

4세대인 LTE가 등장하면서 핸드폰 요금제에  더이상 데이터 무제한은 없어졌습니다.
간혹 요금제에 할당된 데이터 용량 이상으로 소비하여 요금폭탄을 하소연 하는 글이 눈에 띄기도 합니다..
해가 갈수록 보고싶은 동영상은 늘어만 가는데~ 데이터는 턱없이 부족한데~ 뭐 그렇죠...

핸드폰 요금제만 그런게 아니죠. 전기세도 마찬가지.
이제는 IT까지 클라우드란 이름으로 동참하고 있습니다.

데이터 종량제가 빛을 발하려면
내가 얼마나 쓰는지, 또 언제 요금제를 올리고 내려야 하는지
그리고 내 데이터가 새고 있는건 아닌지 잘 알고 있어야 합니다.

무관심한 사람들일수록 돈이 새어나가고 있는지 모른채 뒤늦게 뒤통수 맞았다면서 억울함을 하소연 할 뿐입니다.
(더욱 흥미로운건 대기업이든 소규모든 모두 같은 고통을 겪고 있다는 것.. )

이렇게 가려운 곳을 긁어주는 서비스.

그게 Cloudability 입니다. (블로그를 보니 RoR로 구축한듯)


무료가입해서 둘러볼수 있구요...
수많은 종류의 클라우드 서비스에 대한 정보를 제공합니다 .
대표적인것들 : 아마존웹서비스, 구글앱, rackspace, heroku, github, salesforce, phpfog, force.com

예를들어 구글앱스의 경우는 OAuth로 사용보고서, 메일주소 액세스 권한을 받아 리포팅을 해줍니다.

기본적으로 대시보드와 리포트( 계정, 기간, 서비스, 벤더 단위)를 제공하고 있고, CSV  포맷으로 내려받을수 있게 하는군요.

가입해서 서비스 등록후 본 대시보드 내용입니다. (github 정보로, $0 ... )

대충 이런 느낌입니다. 보안에 특히 신경을 쓰고있음이 곳곳에서 보이더군요..  


국내 스타트업들도 외국에 서비스를 고려한다면 Cloudability의 서비스를 활용해보는 것도 좋을것 같습니다.

참고) Cloudability의 아이디어에 대해 좀더 자세한 이야기는 다음 블로그에 있습니다.
https://www.cloudability.com/blog/why-we-built-cloudability

2012년 주목할만한 클라우드 스타트업으로 지목된 서비스 http://gigaom.com/cloud/10-cloud-startups-to-watch-in-2012/

클라우드 컴퓨팅 구현 기술 국내도서>컴퓨터/인터넷 저자 : 김형준,조준호,안성화,김병준 출판 : 에이콘출판사 2010.12.22 상세보기

클라우드 컴퓨팅에서 언급되는 각 기술들의 묶음 서비스.
그리고 Hello Cloud World 해보기
 
처음 접해보는 사람에게 이해하기 쉽게 정리해서 주지는 않지만
적어도 처음 경험해서 고생해본 앞서간 사람들이 남기는 기록이라고 한다면 의미가 있다.

개인적으로는 이름만 나돌던 각 기술들을 조금씩 정리해나가는데 도움이 된 책이다.

하둡은 이전부터 익숙하게 들어왔지만
주키퍼나 쓰리프트, 척와 등의 정체에 대해서는 잘 모르고 있었고, 왜 이것들이 나왔을까 하는
궁금증에 대해 스스로 답을 끌어낼 수 있도록 도와주었다.

많은 내용을 다루다 보니 다소 산만하고, 맛보기 수준으로 가기는 하지만
이중 마음에 드는 솔루션에 대해 깊이 파고 들어갈 수 있도록 시작하게 도와줄 수 있는 책이라고 생각된다.

적어도 구글, 아마존, 세일즈포스닷컴 광고하러 다니는 책은 아니다.

로그수집 및 저장/관리는 예전에도 있던 요구사항이다.
서버에 에이전트를 설치하여 주요 거래로그를 원격지 DB에 저장하게 하는 방식이 일반적이었다.
(주된 관심거리는 로그 위변조 이슈--WORM--나 필터링,분석, 속도에 관련된 것이었다.) 
시스템 모니터링의 경우도 어떻게, 그리고 얼마나 빨리 각 서버의 시스템정보를 획득할 것인가(주로 vmstat 등 시스템이 제공하는 기능을 이용해 정보를 수집)에 관심이 집중 되어 있었다.

그런데, 왜 클라우드 컴퓨팅 영역에서 다시 로그 얘기가 나온걸까?

IT시장에서 한동안 콘솔리데이션 경향이 있었다.
가용성 측면에서 급속도로 올라가는 요구사항은 시스템 관리자들을 야근으로 몰고 있었고,
점점 관리 리스크를 줄이고 싶어하는 필요성이 생겼다.
그것은 하드웨어 벤더와 이해가 맞아 떨어지면서 수십대의 장비를 몇대의 물리적 장비로 통합하고
그 안에서 다시 쪼개는 식의 콘솔리데이션 바람이 불게되었다.

하지만 콘솔리데이션은 고급화된 하드웨어에 의한 비용부담을 증가시켰고, 확장성에 제약을  주었다.

그다음 방법은 무엇일까에 대해 이미 글로벌 기업들은 새로운 길을 파고 있었다. 
스토리지와 데이터 관리, 애플리케이션 서버에 변화가 일었다.

무언가 새로운 것이 만들어지면 그다음은 모방이 따라온다.
하드웨어가 아닌 소프트웨어로 전환된 사고는 로그관리에도 마찬가지의 전환을 가져오게 되었다. 
클라우드 솔루션의 도입은 1~20대의 시스템이 아닌 수십대 수백대의 시스템을 예상하도록 만든다.
이는 시스템 모니터링이나 로그 관리에 있어서도 예전의 방식이 가지고 있던 문제점에 대해 또다시 아픈 기억을 떠올리게 된다. 


주된 관심을 받고 있는 클라우드 계의 로그관리 솔루션으로 두가지가 있다. 
Chukwa, Scribe
 
- Chukwa : hadoop의 서브 프로젝트
Hadoop FS 에 로그를 저장하고 Map-Reduce로 로그를 분석.
장점 : 타겟 서버의 수정이 필요없음, 하둡FS를 이용해 로그 저장의 안정성 제공, 준/실시간 분석 기능 제공
단점 : 하둡FS만 지원, 바이너리 포맷인 하둡 SequenceFile로 저장됨
cf) HICC 하둡 상태정보를 제공하는 웹인터페이스 (MySQL 사용)
cf) 직접 명령실행용 어댑터(ExecAdaptor)나 로테이트 되는 로그파일 처리용 어댑터도 제공(filetailer.FileTailingAdaptor)

- Scribe : facebook의 로그관리 솔루션 . APL
장점  : 다양한 개발언어 지원(thrift interface)
단점 : 기존 로그파일을 스크라이브 api로 변환해야함, 로그저장 스토리지 및 시스템 구성은 사용자가 직접 구성해야함
cf) log4j 용 scribe appender 제공

그런데 로그 자체를 일반 파일이 아닌 NOSQL로 저장하는 접근은 없나? (방금 찾아보니 log4mongo 라는게 걸린다.  http://log4mongo.org/ )

최근 조류의 특이점은 1. 오픈소스, 2. 특정 개발언어 종속성 최소화, 3. 대용량 분산환경
이것은 MS나 ORACLE이 추구하는 방향과는 사뭇 다르다.
(오라클이 NOSQL 솔루션을 제공하지만 그 줄기에는 ORACLE DB나 하드웨어와 같은 벤더 친화적인 개념으로 유도하기 위한 미끼의 느낌이다. 그것이 Enterprise 솔루션이란다. )


참조 : 클라우드 컴퓨팅 구현 기술 / 김형준 외 / 에이콘

용도 : ibatis sql coverage 측정
라이센스 : 미정
제작사 : NHN
관련자료 : http://helloworld.naver.com/helloworld/1255
문서로는  The Platform 2011 PDF 안에서도 확인이 가능합니다. http://helloworld.naver.com/helloworld/2675

특징 : 테스트 실행후 ibatis xml 파일의 sql에 대한 라인 커버리지 제공

작년동안 SQL Code Inspection을 고민해서 부족하게나마 구현하여 몇번 프로젝트에 적용해보았습니다.
물론 상용 검사도구에서도 충분히 기능을 제공할 수 있는 수준의 것들이라 더이상 진행은 되지 않았지만, SQL에 대해 고민하고 어떤 코드가 좋은 코드일까 고민하도록 해주는 좋은 기회였습니다. (groovy 언어를 즐기는 기회가 되기도 했습니다. )

그런데 비슷한 시기에 SQL에 대한 또다른 유용한 접근이 있었음을 이제야 알게 되었네요.

테스트에서 측정은 중요한 고려사항입니다.
테스트를 했는지 안했는지 알아야 결과를 해석도 할 수 있을테고, 의미가 있는지 없는지도 판단할 수 있을테니까요.

DBMS의 테스트 커버리지 대상을 두 가지 영역으로 나누어 보면 다음과 같습니다.

- TABLE 영역 : TABLE에 대한 C/R/U/D 유무 여부 
목적 : 미사용 TABLE 또는 CRUD Matrix 매핑이 안된 경우, 테스트 수행 여부를 확인
방법 : SQL 로그를 통한 분석 또는 DBMS가 제공하는 View를 이용하여 확인가능
비고 : 영향도 분석과 같은 정적분석 방법으로도 사전에 파악이 가능

- SQL 영역 : 프로그램에서 작성된 SQL 실행 여부
목적 : 작성된 SQL의 사용여부 및 테스트 여부를 확인
방법 : 
1) 소스 코드내에 SQL이 있는 경우
각 소스 언어별로 제공하는 coverage 툴을 통해서 수행여부를 확인할 수 있습니다.
단 소스와 SQL이 섞여있는 형태이므로 둘을 나누어 식별하기에는 어려움이 있습니다.
2) ibatis와 같이 개발언어와 독립적인 외부 파일로 추출된 형태의 경우
SQL 주석에 식별자를 제공하고 log 또는 DBMS가 제공하는 기능을 이용하여 확인하는 방식을 선택할 수 있습니다. ( Coverage4iBatis의 경우에는 SQL 주석안에 CoverageID 를 부여하고 로그에서 실행 여부를 확인하고 있습니다. )  cf) ibatis가 제공하는 id를 사용하지 않고 별도의 id를 부여한 것은 나름의 이유가 있었겠죠?
비고 : 고유 ID 내에서도 동적으로 나누어지는 경우를 어떻게 처리했을까 하는 부분은 흥미롭습니다.
Coverage4iBatis 블로그 글에서 예로 보여준 동적 SQL의 iterate 문장의 실행 여부를 어떻게 접근했을까요?


Coverage4iBatis는 두번째 영역인 SQL에 대해 테스트가 되었는지를 확인하는 방법을 제공하고자 했습니다. 물론 특정 프레임워크(ibatis)에 한정적인 접근이기는 하지만 숨겨져있던 DBMS 영역에 대해 또다른 테스트의 메스를 들어올린 점은 반가운 일입니다.


주제넘지만 한가지더 NHN의 생산성 혁신랩에 권고드리는 것은 (SQL의 코딩 컨벤션 가이드가 언급되는걸 보면 아마도 이미 제공하고 있을지도 모르겠네요..) SQL 상의 나쁜 냄새에 대한 패턴을 확장하고, 이를 알려주는 도구도 같이 활용하시라는 겁니다. (java의 PMD와 같은 역할을 생각하시면 될거 같네요.)

Coverage4iBatis 블로그 글 말미에 언급하듯이 테스트하기 쉽고, 단순한 SQL을 작성하기 위해 개발자의 노력이 필요합니다.
코드의 복잡도가 "당신의 코드가 정말 그렇게 복잡해도 되냐"고 다시 생각하도록 유도하듯이,
SQL의  나쁜 냄새에 대해서도 "당신은 그 냄새를 맡고있어도 괜찮냐" 고 물어보도록 하는 것이 좋을듯합니다.

피하지 못한다면 즐겨야겠죠.

RoR, Django, grails의 장점을 계승한 java web framework
License : Apache 2 licence
site : http://www.playframework.org/

특징
- 소스 수정시 자동 리로딩
- Restful,  무상태 유지 모델 ( share nothing architecture)
- 그루비 기반 템플릿
- 순수 자바

======================

생각해본 장점들

1. 최근 웹 프레임웍의 동향을 잘 반영했다. (스캐폴딩, JPA, 템플릿엔진)
그레일즈를 많이 참조한듯 싶군요..

2. 순수자바로 개발이 가능하다는점
그루비나 스칼라, 루비 기반 웹 프레임워크 들이 지적받는 점중 가장 큰것은 언어적 기반입니다.
지금도 배울게 많은데, 새로운 스크립트를 또 배워야 하나.. 하지만 이건 그냥 자바 코딩이라는 유혹..

3. share nothing 구조가 장점이 될 수 있겠다. (단 공유가 필요할 경우 주의해야 합니다.)

======================
생각해본 문제점

1. 웹프레임웍 비호환성
legacy(java)를 이용한다는 건 legacy의 재사용성을 장점으로 수용하려는 것인데, (grails는 spring위에 올라타는 선택을 했다.) play는 stateless를 내세우면서 웹 영역을 특정 환경으로 고정시키는 선택을 했습니다.
따져보면 일반적인 라이브러리의 재사용은 타 스크립트 언어도 가능합니다. 그거 없으면 다들 곤란하니까요..
웹 프레임웍들에서 만들어낸 유용한 기능들(필터 등)을 play에서 적용이 불가능하다는 말은 안하겠지만 쉽지 않을듯 하네요.
또한가지.. stateless 방식을 주장하는 것은 이해할만하나, spring과 같이 선택적으로 운용할 수 있는 여지를 주는 것이 더 바람직하지 않을까 싶습니다. (자바세계가 MS와 다른 특징중 하나는 열린 표준과 확장성이 아닐까요.. )
물론 신생 프레임워크에서 선택과 집중을 한 결과라고 생각하긴 합니다..

2. 레퍼런스 & 벤더
우선 절대적으로 레퍼런스가 작고.. (이건 grails도 마찬가지 )
TypeSafe에 붙은 것도 그닥.. ( grails는 그나마 springsource에 붙어있으니 적당한 후원자라도 얻었죠. )

3. View layer의 익숙하지 않은 template syntax
그루비어들에게는 친근하겠지만, 일반 JSP나 X-Intenet에 익숙한 사람들에게는 또다른 재앙이 될 수 있겠습니다.

4. 핵심모듈은 scala
playframework의 소스를 추적하다보면 play.api* 들은 모두 scala .
아직 성숙도에 대해 검증이 필요한 프레임워크를 사용하다보면 필연적으로
내부구조를 파악해야 하는데, 다소 걸림돌이 될 것으로 보입니다.
ex) play.db.DB.getConnection(xx,xx) => play.api.db.DB.scala ...

아무튼... 흥미로운 프레임워크임에는 틀림없습니다.

관련사이트
프리스비 http://www.frisbeekorea.com/ 오자키 행사중 (필름, 펜) 회원가입시 3000원 쿠폰 제공
에이샵 http://www.theashop.co.kr/ 코엑스에 두군데 매장이 있음
디멕샵 http://www.dmacshop.co.kr/ 무난한 곳인듯..
컬트몰 http://www.cultmall.com 맥컬리 행사 이미 종료됨
바투카 http://vatuka.co.kr 가끔 세일이벤트 하는듯. 기다릴수 있다면 좋았겠지만 ...

선택기준.
1. 저렴 : 뽀대는 뒷전...
2. 이용방식에 최적 : 사용 장소를 고려해보면 주로 집, 지하철, 가끔의 외출 (들고다니면서 본다기 보다는 어디 고정자리에서 보는 위주. ) + 주로 보는것 (TV, 영화, 인터넷컨텐츠, Kids)
3. 추가 요구사항 : - 안전 : 구름이가 있는 관계로 부서지지 않게.. 그리고 먼지 덜쌓이게..., 무게 : 가능한 가볍게..

둘러보다 결국은 바투카로 결정했다.
다른 파우치들은 고정기능이 없어서 단지 이동할때 보관 역할만 하는데, 바투카는 커버 역할도 하고, 무게도 비교적 가벼운듯해서... 쓰다가 바로 어디 들고 나가기에도 편할듯 싶었다.

색 선정기준은 당연히 구름!!!


////// 사용후기 (제품 받은 다음날.. )
1. 처음 생각보다 얇고 가벼움
2. 색이 뻘겋다 보니 사무실에 떡하니 내려놓기가 뭐했음 (외부에서는 좀 튈수 있겠지만..)
3. 딱 맞게 고정되는건 좋은데, 전원 버튼이나 볼륨, 무음 누르는게 아주 힘듬.... ( 밴드가 덮어써서 .. )
4. 그나마 다행인건 커넥터 연결하는건 불편하지 않았음.
5. 세울수 있어서 그나마 다행. 나름 실용적.

곧 논문을 준비하시는 분의 부탁도 있어서 짧은 기간동안 경험한 논문 작업에 대해 기록을 남겨둡니다.

1. 주제 선정

미리 주제를 두개정도 생각하고 시작했는데 교수님이 별다른 이견없이 인정해주셨습니다. 무난해서 그랬는지...
주제 선정은 남들이 얘기하고 있는 주제를 다루는 것이 좋고 (관심을 끌수 있으니까요),
이왕이면 참신한 것이 좋겠네요. (다른 사람들도 잘 모르니 공격당할 부분이 적으니까요... )

어떤 주제가 좋은지 찾는 데에는 아래 RISS를 찾아보는 것도 좋습니다.
최근 관련 대학원이나 전공에서 나온 논문들의 목록을 보면서 어떤 주제를 다루고 있는지 찬찬히 제목만 훑어봐도 뭐가 유행이다 싶은 감이 옵니다.
제 경우에는 정보시스템 감리였는데, 사업 특성별(게임, 보안, DB등) 로 감리점검 포인트를 찾는 것들이 많았고, 방법론 쪽에서는 애자일, 스크럼이 계속 언급되고 있었습니다. 

 
2. 참고자료 ( 이게 젤 도움이 될듯합니다. )

http://www.riss.kr 
KERIS에서 운영하고 있는 학술정보서비스로 학교소속으로 가입하시면
다수의 관련 논문들을 무료로 조회 및 다운로드 받을 수 있습니다.
(원 저작자의 라이센스 정책에 따라 무료제공 또는 일정기간, 또는 원문제공 불가인 경우가 있음)
=> 원문제공 불가인 경우 유료로 신청이 가능한데, 제가 속한 대학에서는 "외부문헌서비스 비용지원"을 학교 도서관에서 지원해주고 있었습니다. 학교에서 어떤 도움을 주는지 미리 확인해보세요. (게을러서 활용을 못했네요... )

여기서 관련 주제로 어떤 논문들이 있었는지 찾아볼 수 있었고, 관련 논문들을 몽땅 PDF로 모아두고 필요한 시기에 적절하게 참고 할 수 있었습니다. 출력물보다는 전자문서가 편합니다. 쓸데없이 분량이 많아서 출력한 문서의 활용도는 그닥...  => 가장 유용했던 레퍼런스.. (기타 논문 각 영역에 필요한 정보들도 비교해볼 수 있었음)
** 참고 하나더. 교수님이 추천해주신 모범 논문의 경우 인쇄본을 빌려서 계속 가지고 다니면서 참조했습니다. 초반에 방향잡기가 막막할때나 관련 항목에 대해 어떻게 했는지 보고, 생각이 잘 안풀릴때 보면 도움이 되더군요.

http://www.cseric.or.kr/ 컴퓨터 연구정보 센터
이거 활용했어야 하는데 못한곳입니다. ㅠ.ㅠ  국내 논문, 학회, 학술지 정보가 다 나오는데(RISS에서는 유료 또는 비공개였던 자료들)... 뒤늦게 발견한데다 보안모듈이 충돌해서 결국은 못썼습니다..
cseric는 컴퓨터 전문분야고 타 분야는 다른 이름으로 비슷하게 있습니다.

그리고 주제를 정한 상태라면 관련 논문들을 몽땅 뽑는 과정에서 논문 제일 뒤에 나오는 참고문헌 목록을 다시 본인의 주제와 관련한 것들만 뽑아내는 작업을 하면 (책, 논문, 사이트, 법령, 학술지, 신문기사 ... ) 이게 바로 논문 준비할때 찾아봐야 할 목록이 됩니다. 어차피 연구하게 되면 다 돌고도는 책들이지만 끊임없이 참고문헌들은 더 늘어나고 있으니까요....  (기존 문헌보다 더 새로운 문헌이 나오면 그걸 인용하는게 더 효과적일거란 생각은 듭니다. )

논문 작성중에도 다른 사람들의 논문을 가끔씩 읽어보면서 여러가지 도움을 받았습니다.
(좋은 논문에서는 본받을 점을, 부족한 논문에서는 '이렇게 써도 통과하는구나'??? 하는 자신감을 ㅎㅎ - 아마 제것도 후자에 속하게 될듯... )

3. 논문 작성과정

길고 고통스러운 과정입니다.

전체적으로 말씀드리자면, 중간중간 교수님과 주위 경험자들의 검토를 받으시는게 좋구요.
중요한건 피드백인거 같습니다....
이미 논문의 과정을 경험한 분들이 지적하는 것은 다 이유가 있구요, 나중에 심사때 또다시 지적받을 수 있는 내용들이니 지적받은 내용들을 잘 체크해두시면 좋습니다. (지도교수님의 의견을 최대한 존중해둬야 나중에 공격받을때도 조금 방어가 될겁니다. )

목차를 먼저 잡는게 맞겠죠.. 이미 주제를 잡았다면 비슷한 주제를 가진 논문들의 목차를 훑어보시고 비슷하게 구성하시면 되고,
스타일마다 다르겠지만 제 경우는 각각의 목차마다 뼈대를 만들고 거기에 계속 살을 붙여나가는 방식으로 진행했습니다. (물론 특정 부분은 벼랑끝에 몰린 폭풍집필??? 도 있었지만요)

관련연구

논문의 주제와 관련하여 남들이 어떤 내용을 다루고 있었는지와 기존 연구가 가지는 한계(결국은 그게 바로 쓰려고 하는 논문의 강점이자 차별점이 되겠죠)를 다루게 됩니다. 왜 이 논문을 쓰는지에 대한 이유를 다른 사람들의 논문을 근거로 하게 되는 것이기도 합니다. (연구의 특성에 따라 방향은 달라질수 있겠습니다. )

증명

어떤 방식으로 증명을 할 것인가도 중요하고 심사때 많이 지적받게 되는 부분인것 같습니다. (저도 여기가 가장 취약한 부분이었습니다.)
제가 참조한 통계학 책은 이영훈교수의 연구조사방법론/청람 (회사 정보자료실에 있었음)
그리고 관련 사이트
http://www.spss.co.kr/ 통계프로그램인 IBM SPSS 를 다운받기 위한 곳 (15일 짜리라서 불편했네요.. )
어떤 검정방식을 택할지는 연구모형이 대부분 결정해줍니다.
통계 자체는 논문 과정 한참 뒤에 해도 되지만 방법론에 대한 이해는 주제에 따라
실사례, 설문 등 다양한데 저는 주제 성격상 설문을 선택했습니다.
만약 설문을 주제로 한다면, 설문 문항 구성이 아주 중요합니다. (제가 크게 실수한 부분이기도 합니다.)
그냥 어설프게 남들 설문지를 대충 비슷하게 따라하는 것이 아니라 (물론 구성이 끝나면 따라가게 되지만요)
 어떤 결론을 얻기 위해 설문의 요소를 구성할지 잘 선정하는 과정을 교수님이든 조교든 도움을 받아서 진행하시는게 좋습니다. (이 설문이 어떻게 증명에 활용될지를 고민하고 검정방법과 연계되도록 미리 시뮬레이션 해보세요. 그냥 막연한 설문은 증명할때 고생하게 합니다. )

설문받기
이것 역시 신경을 쓰셔야 할 부분.
뭐든 투자하는 만큼 나오는게 확실한거 같습니다. 온라인 설문 효과는 상당히 낮았습니다. (경품이라도 걸걸 그랬습니다..  ) 오프라인/대면 방식이나 권위(??)에 의한 설문이 그나마 결과가 나옵니다.

6. 기타 절차 

논문발표
논문을 요약한 간단한 PPT를 준비합니다. 별도 양식을 요구하지는 않았고, 함축적인게 좋습니다. 길어지니까 지루해하시더라구요. 핵심만 잘 짚어주면 될듯. 어차피 설명은 논문에 있는 내용으로 하면 되니까요..
아, 참고로.. 논문발표때 심사해주시는 교수님들이 모두 오시니까 선물 준비. (저도 미처 몰랐는데, 동료가 센스있게 준비해두었더라구요. 와인이 무난한거 같습니다. )
식사도 한다는데, 제 경우는 skip했습니다. 발표 끝나고 지도교수님이 술도 사주시더라구요...

인준서
가능하다면 논문 최종발표때 통과하면서 바로 그자리에서 인준서 서명도 받는게 좋음. 연말이라 교수님들 학교에 올 일도 없고 일일이 찾아뵙는 것도 시간 맞추기 어려워서 제출일정 맞추는게 쉽지않았습니다. (여기만 그런지는 모르겠습니다... ) 참고로 온라인으로 인쇄맡길때는 인준서 원본도 미리 준비해야합니다. 

초록영역 및 인쇄
http://www.booktory.com  
초록 영역 및 논문인쇄에 활용 ( 가격 비교 같은건 못했고.. 그나마 연말에 전화로 이것저것 물어보는데 친절한 편이었습니다.  ) 학교가 그나마 10% 할인 대상이었네요.. 원우회나 학생회쪽에 유용한 정보가 있지 않을까 싶습니다.
학교 주변 인쇄소가 나을지도 모르겠지만 저는 좀 거리가 멀어서 온라인이 더 맘편했습니다.  

감사의글
논문심사 항목은 아니지만 역시 지도교수님외 도움을 주신 모든 분들에게 감사의 표시를 하는 것은 의미가 있겠습니다. 그리고 아직까지 자신의 이름으로 내어본 책이 없다면 정말 고마웠던 가족들에게도 인쇄물로 감사한 마음을 전달할 기회더군요.


마치며.

이게 끝은 아닙니다.
교수님이 슬쩍 박사쪽을 권유하실지도 모릅니다.
젊고 도전할 수 있다면 바로 시작할지 고민해야할 시기이고, 그렇지 않다면 1년정도의 휴식기간을 두고 고민하라고 합니다.

막판으로 갈수록 논문을 포기하고 일반수료를 할까하는 충동이 많았습니다.
생각만큼 글은 안써지고, 지적받은 문제를 어떻게 풀어나갈지 하루종일 멍하니 답답한 마음만 가득했던 때도 기억납니다.
이건 일종의 자격 시험과 같습니다. 주변의 도움을 많이 받으시고, 또 마음을 단단히 부여잡고 시간을 즐기세요.

윈도우 NT의 쉘 명령으로 날짜를 제공하는 명령어는 date 입니다.

>date /t
>2011-12-29

아쉽게도 국가코드에 따라 출력되는 포맷이 달라집니다.

이걸 해결하는 방법중 하나가

>command.com /c date
>Current date is Thu 2011-12-29

인데... 이건 또 2003 서버 이상의 OS에는 command.com 을 지원하지 않기 때문에 제약이 있네요.

다른 방법은 각 요일마다 각각 고유한 이름의 배치파일을 실행하도록 at 에 등록하면 어쨌든 해결 될텐데 그닥 깔끔해보이지는 않네요....

http://www.methodsandtools.com 에서 메일링으로 보내는 뉴스레터입니다.

여기에 항상 재미난 자료가 많이 나와서 관심있게 지켜보고 있는 편입니다.


어떤 주제가 나왔는지 목차 먼저

* How to Make Your Culture Work with Agile, Kanban & Software Craftsmanship  1)


슈나이더의 문화 모델에 따라 각각을 협력(Collaboration)과 성장(Cultivation), 통제(Control), 경쟁(COMPETENCE) 으로 나누어 


설명해주고 있습니다. 

* How Software Architecture Learns 2)

Russel Brand의 "How Buildings Learn"의 독후감이랄까.. 건축과 소프트웨어를 비교하여 서로의 배울점을 비교해서 설명하고 있습니다. 

* Understanding of Burndown Chart 3)
애자일의 가장 기본적인 매트릭인 번다운 차트에 대한 설명

* The Psychology of UX - Part 2
-> 이건 part 1을 읽어야 해서 생략.

* Tools: Cucumber, Sureassert, ChiliProject, Scrum-it 4)
저는 이 툴쪽도 늘 관심있게 보는 편입니다.
Cucumber는 예전부터 알려져있던 툴이고..
Sureassert는 어노테이션 기반 단위테스트 툴인데... 어노테이션 써보려는 아이디어는 저도 제작년에 잠깐 고민했었던 기억이 납니다.
ChilliProject는 redmine의 fork라고 하고..
Scrum-it 은 예전에도 본거 같긴 한데 홈페이지 동영상에서 보여주는
그런 커다란 멀티터치 스크린을 사려면... 배보다 배꼽이 커지지 않을까 싶은 생각이 들더군요..

=============================================================

1) 요약


애자일을 방법론류가 아닌 문화로 바라보도록 하는 시각..
문화는 슈나이더의 문화 모델에 따라 네가지로 분류되는데, 협력(Collaboration)과 성장(Cultivation), 통제(Control), 능력(COMPETENCE) 입니다.




 


애자일 문화는 협력(Collaboration)과 성장(Cultivation)이라고 합니다. 


칸반(Kanban)의 문화는 통제(Control)에 가까움  (애자일은 사람을 우선으로 하고, 칸반은 시스템 우선적이라고 분류합니다.)


물론 통제를 필요로하는 조직, 회사의 입장에서는 스크럼보다는 더 좋은 툴로 활용될수 있다고 하는군요.
소프트웨어 장인정신(Software Craftsmanship)은 능력(COMPETENCE)의 문화라고 봅니다. 


XP의 주요 프랙티스인 refactoring, tdd, atdd, 지속적통합(continuous integration), 지속적배포(continuous deployment), 코드 소유권 공유(shared code ownership), 깔끔한코드(Clean code) 등으로 대표된다.


기존에 통제 문화인 곳에서는 협력이나 경쟁 쪽으로 조심스럽게 나아가도록 권유하고 있다. 


ref) 그림 http://agilitrix.com/2011/04/software-craftsmanship-promotes-competence-culture/
스크린 캐스트 http://agilitrix.com/2011/05/screencast-how-to-make-your-culture-work-with-agile/

 
2)
Russel Brand의 "How Buildings Learn"
- 건물 설계자로부터 배울수 있다. -> 유지보수와 확장성
- 건물 설계자들과 같은 실수를 할 수 있다. 
- 반대로 건물 설계자들은 소프트웨어 설계자로부터도 배울 수 있다. -> 애자일 테크닉
 
 
3) 
스타트업 입장에서 애자일은 product에 집중하도록 해주기때문에 좋은 방법이다. 
 
remaining effort for a given period of time (sprint or release)
X : working day
Y : remaining effort (회사마다 다르게 적용)
 
cf) 
X = Story수 -> 각 스토리는 노력의 규모가 다르므로 실제 진행상태 설명에 적절하지 않다.
X = 시간 => 지나치게 세분화된 관리가 된다.
X = 남은 크기 (remaining size) story point => 계단현상이 나타난다 ( 데일리 미팅을 통해 해소할수 있다.)
 
부가작업이 추가된 경우 발생하는 진척 차이를 설명하기 위해 스프린트 백로그 총계를 표현하는 추가적인 지표가 필요할수도 있다.
 
주의할것은 velocity는 팀의 지표나 KPI가 아니다. 수행가능성을 계획하는데 쓰는 도구(capacity planning tool)일 뿐이다.
 
4) 
- Cucumber 
BDD 툴  http://cukes.info/  v1.1.2 
지원언어 : java ruby .Net
License : MIT License
Given When Then 방식으로 진행
 
장점 : 사례와 자동화의 분리 (코드와의 분리를 뜻하는듯), 지나치지 않는 구조화(심플?)
단점 : 여분의 오버헤드 (개발자만 쓸거라면 rspec이 더 낫다), 정규표현식의 복잡함
 
- Sureassert
어노테이션 기반의 unit testing 도구, 커버리지 제공
www.sureassert.com
대상언어 : java
requirement : Eclipse 3.4 + distro 
License : open source & free 
 
흐름 : declaritive testing -> test execution -> coverage reporting -> 다시..
ex)
@Exemplars(set={
 @Exemplar(instance="'hamburger'", args={"4","8"}, expect="'urge'"),
 @Exemplar(instance="'smiles'", args={"1","5"}, expect="'mile'"),
 @Exemplar(instance="'negtest'", args={"-1","5"},
      expectexception="StringIndexOutOfBoundsException") })
public String substring(int beginIndex, int endIndex);
 
- ChiliProject
웹기반 프로젝트 관리도구
이슈추적, 프로젝트 계획(애자일,스크럼 지원), 시간추적,위키,VCS통합...
http://www.chiliproject.org
requirement : ruby(1.8.7 over), db(mysql,,,)
ROR로 만들어짐.
License : GNU GPL v2
 
redmine에서 fork된 프로젝트임 (redmine이 너무 폐쇄적이라고 판단해서..)
 
 
- Scrum-it
가상 스크럼보드 
http://www.scrum-it.ch 
License : CC By 3.0 
스위스 쮜리히의 BSgroup Technology Innovation AG에서 개발.
기술기반 : java j2ee,  mysql and tomcat , html5, css3, jQuery mobile 
흥미로운건 아이패드에서 보여지는것과 멀티터치 지원..