내 남자의 길~!

invalid-file

에서 start가 0값으로 되어있는것을 지금은 4(disable)로 바꿔 놔야 한다.

regedit 에서 SPTD 라는 문자열로 찾아서 Start 라는 값을 1에서 4로 바꾸어 줍니다. 한개가 아니고
여러항목이 있을 수 있으므로 끝까지 찾아서 고칩니다.




그러면 윈도시작할때 아래와 같이 SPTD 오류가 나지만 SOFTICE는 실행이 됩니다.



실행을 하고 나서도 breakpoint 를 걸고 나면 SOFTICE 내에서 키가 잠겨버려서 재부팅을 하는 수 밖에
없는 현상이 발생해서 또 꽤 오래 고생했는데 결국에는 다음과 같은 설정조합으로 해결을 할 수 있었습니다.

- CMOS 에서 multiple cpu support 를 off 하고 소프트아이스에서 Troubleshooting 설정에서 다음 조합을 사용




softice설치하고 화면 환경설정.
C:\WINDOWS\system32\drivers\Winice.dat 파일을 열어 INIT부분을 직접수정한다.
INIT="lines 39;set font 2;color f a 4f1f 1e;wc 20;wd 7;wr;code on;faults off;X;"

Winice.dat

그냥 이 파일을 덮어 쒸우면 된다. 물론 위에 패치된 압축파일에는 포함 되어 있다.

VMWARE에 설치하고 사용할때 softice의 화면이 뜨지 않는 경우가 있다.
아래와 같이 softice의 설정에서

test버튼을 눌렀을때도 에러메세지가 발생하면 vmware에서 로드하는 이미지 파일

인 .vmx파일을 열어 vmmouse.present = FALSE svga.maxFullscreenRefreshTick = 5
 추가해준다.

간단한 사용법이 담긴 pdf자료이다.
The big SoftICE howto  - A step by step Guide

The_big_SoftICE_howto.pdf

SoftICE Command Reference

softice_commandref.pdf

비스타에서는 softice를 사용할 수 없는 관계로 ollydbg 라는 걸 처음 사용해 보았는데...
softice에서 유용한 bpx 로 윈도 api 호출에 중단점을 설정하는 기능이 있는지는 잘모르겠습니다.
하지만 설치가 softice보다 너무 쉽고(설치하지 않고 그냥 exe 실행하기만 하면 됨).
실행하고 나서 디버그할 exe 를 선택해서 열고 화살표를 누르면 디버그 시작!
softice를 사용해봤던 사람이라면 무난히 익혀 사용할 수 있는 것 같습니다.

한 용 희 woom33@korea.com롯데정보통신 정보기술연구소에 재직 중이며, 닷넷 기반의 여러 프로젝트에 참여했다. 현재 Microsoft Visual C# MVP이며 MSDN 세미나 강사로도 활동 중이다. 처음에는 2D, 3D 게임 프로그래머로 시작하여 SQLServer 튜닝, 응용 애플리케이션 개발에 이르기까지 다양하게 경험하였으며, 주요 관심사는 DB와 애플리케이션의 연동 부분이다.

어렸을 적부터 필자는 개발하는 일 자체가 즐거웠다. 내가 어떤 것을 만들 수 있다는 것 자체가 매우 흥분되고 재미있는 일이었다. 기존의 장난감에는 창의력을 불어 넣을 수 없었다. 레고 블록과 같이 모양이 정해진 부품으로는 완전히 새로운 창작물을 만들 수 없었다. 하지만 프로그래밍은 훨씬 더 새로운 작품을 만들 수 있어서 좋았다. 필자는 그렇게 프로그래밍의 재미라는 것을 느꼈고 그 순간부터 커서 개발자가 될 것이라고 마음에 꿈을 가졌다.

프로그래밍의 재미를 알고부터는 시간이 나면 틈틈이 프로그래밍을 했다. 이러한 재미가 직업이 되면서부터 일은 필자에게 돈을 버는 수단인 동시에 재미를 느끼는 수단이 되었다. 하지만 언젠가부터 개발이라는 작업이 내가 원하는 것만 만들 수 있는 것도 아니었고, 내가 원하는 시간에 내 마음대로 혼자서 할 수 있는 것도 아닌 그런 존재가 되었다. 개발이라는 것이 결코 혼자만의 예술 작품이 아니었던 것이다.

필자는 대학 때까지 열심히 프로그래밍 기술을 익히고 기술 공부에 매진했다. 그러다가 지금의 SI 업체에 입사하게 되었는데, 그때 인사과장님이 하시던 말씀이 생각난다. “앞으로 여러분은 회사에 들어가서 열심히 업무를 배워야 합니다. 기술도 중요하지만 앞으로 하게 될 회사 업무(인사, 구매, 회계, 생산, 영업 등)를 파악하는 것이 더 중요합니다. 고객이 원하는 것을 알아야만 개발도 효과적으로 할 수 있기 때문입니다.” 그동안 기술 공부만 열심히 해왔던 필자에게는 충격적인 말이었다. 내가 지금껏 ‘헛공부’를 했단 말인가?

개발자로서 선택할 수 있는 다양한 진로가 존재한다. 대표적인 것이 바로 IT 제조업과 IT 서비스업이다. IT 제조업은 제품을 만드는 것이므로 기술 자체가 중요할지 모르겠다. 하지만 IT 서비스업은 서비스를 만드는 것이므로 그 해당 업무를 잘 아는 것이 더 중요했던 것이다.

필자는 회사에 들어가서 제일 먼저 회계 업무를 맡았다. 개발하는 것 자체에는 아무런 문제가 없었지만 현업이 요구하는 것을 개발하는 데 문제가 생겼다. 회계 업무를 모르다 보니 현업이 하는 말을 알아들을 수 없었고, 현업이 원하는 바를 이해해서 원하는 것을 정확하게 만들 수 없었다. 이때부터 회계 공부를 시작했다. 당장 회계학과 대학생들이 본다는 『회계원리』라는 책을 사서 공부를 시작했다. 하지만 처음부터 회계용어가 눈에 들어올 리가 없었다. 난생 처음 듣는 어려운 용어가 많았다. 그때마다 회계과 직원들의 도움을 받고, 스스로 다른 책도 찾아가면서 회계 공부를 했다.

처음에는 어렵기만 했던 회계 용어가 차츰 눈에 익고, 점점 업무 영역도 확대되어 갔다. 회계, 그룹웨어, 인사 등 여러 업무를 조금씩 하다가 이제는 직접 개발하기보다는 관리, 기획하는 업무의 비중이 점점 늘어가는 것을 느끼게 되었다. 바야흐로 개발자로서 선택의 갈림길이 나타난 것이다. 계속 개발자로 남느냐? 아니면 관리직으로 가느냐?

한국에서 개발자로 살아가기
개발자로 살아가다 보면 국내에서는 개발자로 살아가기가 힘들다는 소리를 여기저기서 많이 듣게 된다. 지난해 8월 자바개발자협의회(JCO)는 한국의 개발자 1,891명을 대상으로 설문 조사를 실시한 바 있다. 그 결과에 따르면 국내 소프트웨어 개발자의 72.2%는 45세까지(특히 58%는 40세까지)만 개발 업무를 계속하겠다고 응답했다. 대다수가 개발자의 수명을 40세 초반으로 바라보고 있는 셈이다. 경력 분포 면에서는 10년 이상된 개발자가 전체의 9.5% 밖에 되지 않아서 대부분이 경력이 짧은 초중급 개발자로 이뤄져 있음을 알 수 있다. 그만큼 숙련된 개발자가 부족하다는 의미이다.

개발자의 근무 실태를 보면, 응답자의 85%는 주2회 이상 야근을 하며 매일 야근하는 개발자도 28%나 되었다. 하지만 이들에게는 초과 근무 수당이 없는 경우가 대다수였다. 한 예로 노동부에서 2007년 6월부터 서울 지역 IT 업체 104곳을 점검한 결과, 93개 업체가 근로자의 수당을 미지급해서 시정 명령을 받았다고 한다.  

과거 2005년도에는 포털 서비스인 다음의 토론광장(아고라)에 ‘영재들아, 제발 IT로 오지마라’라는 글이 게재되어 한창 화제가 되기도 했다. 이 글은 한국 IT 개발 환경의 문제점을 적나라하게 표현해서 IT 종사자들 사이에서 대단한 관심을 끌었다. 이런 우울한 글을 보고 나면 정말 개발자로 남아서 살아가야 하는지 자신이 없다. 유독 한국의 개발자만 이렇게 고생하는 것은 아닐까?

임금 수준으로 본 우리 IT
이럴 때에는 선진국의 사례를 살펴보면 도움이 된다. 필자는 우리나라보다 IT 산업이 성숙한 미국의 자료를 찾아보기로 했다. PayScale이라는 연봉 정보 공개 사이트에는 각 직업의 연봉 정보가 공개되어 있다. 먼저 미국의 연봉 정보를 보자.



<화면 1>에서 뜻밖에도 고급 개발자(Sr. Software Engineer / Developer / Programmer)의 연봉이 최고 수준으로 나와 있음을 볼 수 있다. 이 사이트에는 한국의 연봉 정보도 함께 소개되어 있다. 비록 등록된 정보가 얼마 없어 절대적인 기준으로 삼기는 어렵지만 그냥 참고용으로는 볼만 하다. <화면 2>는 한국의 연봉 정보를 나타낸 그래프다.



이 자료에는 구체적인 수치가 나와 있진 않지만, 개발자의 임금 수준이 꽤 낮은 수준임을 짐작할 수 있다. 한국소프트웨어진흥원에서 한미일 3국의 소프트웨어 개발자 월평균 임금(2003년 기준)을 조사한 자료가 있는데 그 결과는 <표 1>과 같다.

<표 1>은 해당 국가의 물가를 고려하지 않고 임금을 단순 비교한 자료이므로 이것으로 절대적인 비교는 어렵지만 대략적으로 보면 미국의 임금이 한국의 3배에 이른다. 단순 절대 임금의 비교보다는 상대적 임금 수준을 비교하기 위해 임금 프리미엄이라는 지수를 사용한다. 임금 프리미엄이란 현재 임금에서 기회 임금을 뺀 것으로 그 직업의 상대적인 임금 수준을 측정할 때 유용하다. 즉, 내가 IT 직업을 가짐으로써 다른 직업을 가졌을 때보다 더 많이 받는 수준이 임금 프리미엄이다.

정보통신정책연구원에서 2003년도 발간된 자료를 보면 한국 IT 산업 근로자의 임금 프리미엄은 10%, IT 직종 종사자의 임금 프리미엄은 IT 전문직이 61%, 준 전문직이 11%, 생산직이 3%였다. 반면에 미국 IT 산업 종사자의 임금 프리미엄은 110.8%로 나와 있다. 즉, 미국에 비해서는 그만큼 한국의 IT 직종 종사자가 상대적으로 임금을 덜 받고 있음을 알 수 있다.

근로 환경은 어떤가?
ww.esj.com이라는 사이트에 가보면 미국 IT 종사자에 대한 설문조사 결과를 볼 수 있다. 가장 최근의 자료는 2007년 10월에 조사한 것으로, 이 가운데 먼저 직업 만족도를 보면 <표 2>와 같다.




미국의 IT 종사자들은 갈수록 직업 만족도가 떨어지기는 하지만 대체적으로 직업에 만족하고 있음을 알 수 있다. 그럼 이번에는 직업 안정성에 대해 알아보자. 이는 자신의 직장에서 퇴직 당하지 않고 얼마나 안정적으로 일할 수 있는지에 대한 설문조사 결과이다.

<표 3>을 보면 대체적으로 직업 안정성이 높음을 알 수 있다. 마지막으로 주당 근무 시간에 대한 설문 조사 결과는 <표 4>와 같다.


아무래도 직원보다는 관리자가 더 업무를 오래하는 편인데, 직원들의 주당 근무 시간은 평균 43시간으로 조사됐다. 9시 출근 6시 퇴근이라 하고 점심시간 1시간을 제외하면 일일 근무시간은 8시간이다. 이는 주5일제라고 할 때 주당 40시간이 된다. 미국에서 43시간이라는 것은 결국 어느 정도 야근을 한다는 것을 의미한다.

그럼 우리나라의 경우는 어떨까? 2004년 전국IT산업노동조합연맹이 실시한 실태조사에서 소프트웨어 종사자들의 주당 평균 근로시간은 57.8시간이었다. 이는 미국과 비교해 보면 많은 차이를 나타내는 결과다. 결국 한국에서 개발자로 살아가는 것이 힘들다고 말하는 데에는 이런 이유가 있는 셈이다.

산업 분류에 따른 IT 전망
|앞서 말한 바와 같이 IT 산업은 크게 IT 제조업과 IT 서비스업으로 나눌 수 있다. 이중 우리나라는 IT 제조업의 비중이 매우 높은 편이다. <표 5>는 2005년도 IT 부문별 부가가치 및 고용 비중을 나타낸 것이다.

한편 미국의 경우는 <표 6>과 같다.

미국의 경우 IT 서비스업의 부가가치가 더 크고 인력도 더 많은 것으로 조사됐다. 하지만 우리나라의 경우에는 IT 제조업의 부가가치가 더 크고 인력도 더 많은 것으로 나타났다. 우리나라는 아직까지 IT 산업에 있어서 제조업의 비중이 더 크다는 의미다.

미국의 경우 IT 서비스업의 부가가치나 인력이 더 많은 것은 서비스 부문에서 IT를 활용한 전산화가 생산성 향상을 가져왔기 때문이다. 미국도 1995년 이전에는 제조업의 생산성이 서비스업보다 더 높았다. 하지만 IT 기술이 발전한 1995년 이후에는 IT 기술을 활용한 서비스 분야의 전산화를 통해서 생산성이 크게 향상됐다.

반면에 우리나라의 경우 2000년대 들어 IT 생산 부문은 노동생산성 향상에 크게 기여하고 있으나, IT 이용 서비스의 경우에는 오히려 기여도가 하락하고 있다.

<그림 1>을 보면 우리나라는 생산성을 높이는 데 있어 IT 이용 서비스업의 기여도가 떨어지고 그 비중 또한 작다. IT 제조업의 경우 각종 IT 제품을 통해서 생산성 향상을 가져오는데 반해, IT 서비스업의 경우는 소프트웨어를 통해 업무의 효율화를 가져와야 하는데 그 비중이 작다는 것이다.

우리 개발자의 미래
과거 미국의 경제가 일본에 추월당했다는 소리가 있었지만 미국은 IT를 통한 기술 발전에 힘입어 생산성의 향상을 가져왔고 다시금 경제에 활력을 되찾았다. IT 산업이 경제 성장의 밑거름이 된 것이다. 특히 IT 서비스업의 경우 IT 제조업보다 더 큰 부가가치와 고용 증대 효과를 가져왔다.



앞으로 우리나라도 경제가 더욱 성장하기 위해서는 미국이 그랬던 것처럼 각 산업에서의 생산성 증가가 이뤄져야 한다. 이러한 생산성 증대는 앞으로는 IT 기술을 통해 이뤄질 것이다. 특히 그동안 등한시되었던 IT 서비스를 통한 서비스업의 생산성 증가가 앞으로 중요한 이슈가 될 것이다. 이에 따라 IT 서비스업을 담당하는 소프트웨어 개발자가 앞으로는 더욱 많이 필요해지고 중요한 인력이 될 것으로 보인다.

앞서 살펴본 것처럼 우리나라에서 개발자에 대한 처우는 미국에 비해 그리 좋은 상황은 아니다. 하지만 앞으로 우리가 미국의 모델을 따라 IT 빅뱅을 통한 경제발전을 이룩한다면 소프트웨어 개발자는 그 주요한 원동력이 될 것이다. 필자는 그때쯤이면 우리나라의 개발자도 미국의 그들처럼 대우받지 않을까라는 나름대로 긍정적인 희망을 가져본다.

참고 자료
1. 자바개발자협의회 커뮤니티, http://www.jco.or.kr
2. 미국 연봉 정보 사이트, http://www.payscale.com
3. SW인력 임금수준의 국제 비교 - 한국소프트웨어진흥원(박능윤), http://www.software.or.kr
4. IT 인력의 취업률, 전공종사율, 임금수준에 대한 연구 - 정보통신정책연구원, http://www.kisdi.re.kr
5. Enterprise System, http://www.esj.com
6. 주력성장산업으로서 IT 산업에 대한 평가와 시사점 - 한국은행, http://www.bok.or.kr

1. WTP 구하기
http://www.eclipse.org/webtools/

2. WTP 선택
최신 jdk를 사용하다면 1번에 나온 download페이지를 이용하면 될것이고
만약 jdk1.4를 이용한다면 구버전이 들어있는 download를 이용하면 된다.

WTP 다운로드 페이지

톰켓서버 잡아주기

톰켓경로설정, JRE선택

Dynamic Web Project 완성

Run on Server

debug 연습

BreakPoint

디버그 모드 전환

invalid-file

invalid-file

애플(Apple)의 아이폰(iPhone) 플랫폼은 개발자들에게 흥미로운 기회를 제공하고 있다. 소형 데스크톱과 터치스크린으로 아이폰과 아이팟 터치(iPod Touch)는 짧은 기간에 100만 명이 넘는 사용자들을 가지게 되었다. 하지만 이런 고품격 디자인과 사유화된(proprietary) 플랫폼은 애플리케이션 개발자들에게 새로운 종류의 도전을 만들어 내고 있다. 애플이 소프트웨어 개발 키트(SDK)를 배포할 때까지는, 아이폰 플랫폼을 목표로 하는 개발자들은 아이폰의 룩앤필(look and feel)을 따르는 웹 애플리케이션을 만들어야만 한다.

운이 좋게도 그 일을 쉽게 할 수 있는 새로운 오픈 소스 도구들을 사용할 수 있다. Aptana의 이클립스용 아이폰 개발 플러그인은 아이폰에 특화된 프로젝트를 생성하고 회전시켜 볼 수 있는 미리 보기 화면을 제공한다. Joe Hewitt의 iUi는 CSS와 자바스크립트 프레임워크인데 아이폰 스타일의 위젯과 페이지를 가지고 있다.

본 기사에서는, Apatana와 iUi를 사용해 새로운 애플리케이션을 만들 것이다. 바로 아이폰에서 사용할 수 있는 간단한 자바독(Javadoc) 뷰어다. 먼저 아이폰에서 자바독을 브라우징할 수 있는 사용자 인터페이스(UI)를 만들겠다. 그런 다음 소스 코드에서 자바독 페이지를 만들어 내는 커스텀 doclet을 만든다. 그 뒤를 이어 아이폰을 목표로 했을 때 생기는 UI 문제를 살펴보고 이 오픈 소스 도구들을 사용해 개발과 디버깅을 간단하게 할 수 있는지, 그리고 앞으로의 아이폰 개발 방향에 대해 설명하겠다.

도구 빠르게 살펴보기

Aptana를 설치하고 iUi를 다운로드하는 것부터 시작한다.

1. 이클립스 V3.2에서 다음을 선택한다. Help > Software Updates > Find and Install.
2. Search for new features to install을 선택한다. 이 창에서는 여러분이 다운로드한 플러그인과 이클립스가 미리 정의해둔 플러그인 사이트의 목록을 보여준다.
3. New Remote Site를 클릭해 Aptana를 추가하고 URL을 다음과 같이 설정한다. http://update.aptana.com/update/3.2/.
4. 목록에서 새로 추가한 Aptana를 선택하고 Next를 클릭해 이용할 수 있는 모든 기능을 선택한다. 창을 닫고 기본 Aptana 편집기로 돌아온다.
5. 이클립스를 재시작한다.
6. Window > Open Perspective > Other를 선택하고 Aptana를 창에서 클릭한다. 툴바에 새로운 아이콘이 나타날 것이다.
7. Home 아이콘을 클릭한다. Aptana 기능에 대한 소개 페이지가 보일 것이다.
8. Apple iPhone Development에서 Download and Install을 선택한다.
9. 기능들을 설치하고, 창을 닫고 아이폰에 특화된 기능들을 Aptana에 설정한다.
10. 이클립스를 다시 시작한다.
11. 최신 버전의 iUi를 다운로드한다(참고자료 참조).

모든 준비가 끝났다면, 이클립스를 사용해 그림 1에 보이는 것처럼 iDoc이라는 새로운 아이폰 프로젝트를 생성한다.

그림 2는 간단한 아이폰 애플리케이션을 담고 있는 프로젝트를 보여준다.

HTML, CSS, 그리고 자바스크립트를 지원하는 Aptana의 기본 편집기가 제공하는 문법 하이라이팅을 확인할 수 있다.

아이폰 미리보기 모드와 애플리케이션 서버

텍스트 편집기 아래 부분에 Source, iPhone Preview, 그리고 시스템에 설치된 각종 브라우저(예를 들어 Safari Preview, Firefox Preview) 탭들을 볼 수 있다. iPhone Preview를 클릭하여 아이폰에서 보이는 샘플 애플리케이션을 보자. 폰을 돌리려면 브라우저의 바깥을 클릭하고, 네비게이션 막대를 숨기려면 폰 제목을 클릭하라. 가로로 보는 아이폰 미리보기 모드는 아래와 같다.

아이폰 미리보기 모드는 시간을 매우 많이 절약할 수 있게 하는 장치다. 새로운 디자인 아이디어를 빠르게 테스트할 수 있고 컴퓨터에서 벗어나지 않고도 점진적으로 개발할 수 있다. 애플리케이션을 실제 아이폰에서 테스트해야 할 때가 오면, Aptana에 내장된 애플리케이션 서버가 매우 유용할 것이다. 이클립스 툴바에 있는 Run 아이콘을 클릭하여 서버를 실행한다. 그림 4는 이클립스에서 동작하는 애플리케이션 서버를 보여준다.

만약 아이폰이 와이파이(WiFi) 연결을 통해 로컬 네트워크에 연결되어 있다면, 서버 창에 보이는 URL에 접속할 수 있다. E-mail this url을 클릭하여 한 단계를 생략하고 여러분 아이폰에 있는 이메일 계정으로 메시지를 보낼 수 있다. 이메일에 있는 링크를 탭(화면을 툭 치는 것)하면, 아이폰의 웹 브라우저에서 애플리케이션을 실행한다.

iUi 데모: 극장 목록 웹 애플리케이션

Aptana의 기본 애플리케이션이 아이폰에 특화된 HTML과 CSS를 포함하고 있더라도 그 기능은 매우 제한적이다. 좀 더 나은 대안책은 iUi 프레임워크다. iUi는 다양한 아이폰 인터페이스 스타일의 커스텀 위젯과 자바스크립트 효과를 가지고 있다.

다운로드한 iUi 파일 iui-0.13.tar의 압축을 풀고, 파일을 이클립스에 있는 iDoc 프로젝트로 복사한다. 그림 5는 iUi를 가지고 있는 프로젝트를 보여준다.

iUi를 사용한 데모 웹 애플리케이션은 위에서 펼쳐진 샘플 폴더에서 찾을 수 있다. 음악 브라우저, 극장 목록 그리고 Digg와 비슷한 사이트를 포함하고 있다. Aptana의 아이폰 미리보기 모드를 사용해 이클립스에서 그것들을 확인할 수 있다. 그림 6은 극장 목록 웹 애플리케이션(samples/theaters/index.html)의 검색 페이지를 보여준다.

진짜 아이폰의 룩앤필과 얼마나 비슷한지 보기 바란다. 이렇게 미리 만들어둔 위젯은 아이폰 웹 애플리케이션을 빠르게 개발할 수 있도록 해준다.

위로

UI 디자인하기

이번 예제에서는 iDoc이라는 자바독 뷰어를 만들 것이다. 썬(Sun Microsystems)의 표준 자바독 생성기에 의해 만들어진 방대한 양의 HTML 문서들을 데스크톱에서는 잘 볼 수 있다. 하지만 아이폰에서 읽고 네비게이션하기에는 불편하다. iDoc은 아이폰에 적합한 자바독을 생성한다. — 지하철이나 짝 프로그래밍 팀에서 관찰자가 도움을 줄 수 있도록 하기에 완벽한 브라우징 애플리케이션 프로그램 인터페이스(API)를 제공할 것이다.

아이폰 휴먼 인터페이스 가이드라인

iDoc에 필요한 UI를 디자인하기 전에 아이폰 개발과 일반적인 웹 애플리케이션의 다른 점을 이해하는 것이 중요하다. 애플의 iPhone Dev Center(참고자료 참조)에서 인용한 그림 7을 보면 이를 매우 멋지게 요약했다. 손가락은 마우스가 아니다. 데스크톱에서 볼 수 있는 픽셀 선택을 없애고 그 대신 탭(툭 치는 것), 플릭(화면을 가볍고 빠르게 휙 스치는 모션) 그리고 핀치(두 손가락으로 화면을 꼬집는 듯한 모션)와 같은 풍부한 사용자 상호작용 모델을 사용했다. 게다가 아이폰은 사용자가 들고 다니면서 시급한 상황에서 자주 쓰기 때문에 애플리케이션에서 원하는 정보를 빠르고 쉽게 제공할 필요가 있다.

애플의 iPhone Human Interface Guidelines(참고자료 참조)는 아이폰 웹 컨텐츠의 세 가지 타입을 정의하고 있다.

아이폰에 있는 사파리(Safari)와 호환

비록 페이지의 일부분이 어도비 플래시(Adobe Flash)나 Java™ 애플릿처럼 지원되지 않는 플러그인에 의존하더라도 정확하게 보여줄 수 있는 모든 타입의 웹 페이지

아이폰에 있는 사파리에 최적화

아이폰에 맞게 내용의 크기를 조정했으며, 지원되지 않는 플러그인에 의존하지 않는 웹 페이지

아이폰 애플리케이션

웹 페이지가 아이폰의 룩앤필을 따르는 애플리케이션처럼 보이고, 가능하다면 전화, 이메일, 구글맵과 같은 아이폰의 서비스와 연동된다.

표준 자바독 페이지는 첫 번째 범주에 해당된다. 아이폰에 있는 사파리와 호환되는 형태다. 정확하게 보이긴 하지만 관련된 정보를 찾으려면 핀칭과 플릭을 매우 잘 해야 한다. iDoc은 완전한 아이폰 애플리케이션을 목표로 하고 있다. 비록 다른 서비스와 연동할 일은 없지만 iDoc의 인터페이스는 마치 아이폰 애플리케이션처럼 느껴질 것이다.

iDoc UI

아이폰을 목표로 할 때는 포커스를 유지하는 것이 중요하다. 애플리케이션은 특정 작업을 빠르게 수행해야 한다. 모든 가용한 기능을 포함시키려고 하면 안 된다. iDoc에서 사용자들은 클래스 이름, 메서드 이름, 메서드 시그너처 그리고 주석 등과 같은 자바 클래스에 대한 기본 정보를 찾아내야 한다. 이런 정보를 목적지인 구체적인 페이지로 안내하는 세 개로 나눈 네비게이션을 통해 제공할 것이다.

패키지 네비게이션

최상위 패키지

클래스 네비게이션

패키지 안에 있는 클래스, 인터페이스, 예외와 에러

자세한 클래스 네비게이션

클래스 안에 있는 설명, 필드, 상수, 그리고 메서드

세부 페이지

주석, 시그너처 그리고 매개변수

iDoc을 산만하지 않고 태스크에 집중된 상태로 유지하기 위해 기존의 자바독 기능을 몇 가지 제거했다. 예를 들어 패지키 설명 주석은 보여주지 않는다. 이것들은 대개 정보가 유익하지 않거나(예를 들어 acme.client에는 클라이언트 코드가 들어 있다.) 보통 존재하지 않으므로 그것들을 iDoc에서 빼고 인터페이스를 간단하게 만드는 것이 더 나은 선택이다.

세 부분으로 나눈 네비게이션을 위해 edge-to-edge 리스트를 사용한다. 이것은 전형적인 아이폰 애플리케이션에 익숙한 구조로 연락처, 이메일 그리고 음악을 브라우징할 때 사용된다. Edge-to-edge 리스트는 아이템을 44픽셀 높이의 같은 크기로 보여준다. 그리고 많은 양의 정보를 스크롤할 때 유용하다. 애플의 iPhone Human Interface Guidelines는 글꼴, 글자 크기 그리고 경계선 공간 수치를 제공한다. iUi 프레임워크는 CSS와 자바스크립트 언어로 이러한 수치에 맞게 구현해두었다. 따라서 아이폰 컴포넌트처럼 보이는 HTML 목록을 간단하게 만들 수 있다.

Listing 1은 페이지 헤더와 java.applet과 java.rmi 패키지의 첫 번째 2단계 네비게이션을 보여준다.

                
 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
      "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>iDoc</title>
<meta name="viewport" content="width=320; initial-scale=1.0;
   maximum-scale=1.0;
   user-scalable=0;"/>
<style type="text/css" media="screen">@import
   "iui/iui.css";</style>
<style type="text/css" media="screen">@import
   "iDoc.css";</style>
<script type="application/x-javascript"
   src="iui/iui.js"></script>
</head>

<body onclick="console.log('Hello', event.target);">
   <div class="toolbar">
     <h1 id="pageTitle"></h1>
     <a id="backButton" class="button"
        href="#"></a>
   </div>
  <ul id="home" title="Packages" selected="true">
      <li><a href="#java.applet">java.applet</a></li>
      <!-- more packages...-->
      <li><a href="#java.rmi">java.rmi</a></li>
  </ul>
  <ul id="java.applet" title="java.applet">
      <li class="group">Interfaces</li>
      <li><a href="java.applet.AppletContext.html">
         AppletContext</a></li>
      <li><a href="java.applet.AppletStub.html">
         AppletStub</a></li>
      <li><a href="java.applet.AudioClip.html">
         AudioClip</a></li>
      <li class="group">Classes</li>
      <li><a href="java.applet.Applet.html">Applet
         </a></li>
      <li><a href="java.applet.Applet.AccessibleApplet.html">
         AccessibleApplet</a></li>
  </ul>
  <ul id="java.rmi" title="java.rmi">
      <li class="group">Interfaces</li>
      <li><a href="java.rmi.Remote.html">
         Remote</a></li>
      <li class="group">Classes</li>
      <li><a href="java.rmi.MarshalledObject.html">
         MarshalledObject</a></li>
      <li><a href="java.rmi.Naming.html">
         Naming</a></li>
      <li><a href="java.rmi.RMISecurityManager.html">
         RMISecurityManager</a></li>
      <li class="group">Exceptions</li>
      <li><a href="java.rmi.AccessException.html">
         AccessException</a></li>
      <li><a href="java.rmi.AlreadyBoundException.html">
         AlreadyBoundException</a></li>
      <li><a href="java.rmi.ConnectException.html">
         ConnectException</a></li>
      <li><a href="java.rmi.ConnectIOException.html">
         ConnectIOException</a></li>
      <li><a href="java.rmi.MarshalException.html">
         MarshalException</a></li>
      <li><a href="java.rmi.NoSuchObjectException.html">
         NoSuchObjectException</a></li>
      <li><a href="java.rmi.NotBoundException.html">
         NotBoundException</a></li>
      <li><a href="java.rmi.RemoteException.html">
         RemoteException</a></li>
      <li><a href="java.rmi.RMISecurityException.html">
         RMISecurityException</a></li>
      <li><a href="java.rmi.ServerError.html">
         ServerError</a></li>
      <li><a href="java.rmi.ServerException.html">
         ServerException</a></li>
      <li><a href="java.rmi.ServerRuntimeException.html">
         ServerRuntimeException</a></li>
      <li><a href="java.rmi.StubNotFoundException.html">
         StubNotFoundException</a></li>
      <li><a href="java.rmi.UnexpectedException.html">
         UnexpectedException</a></li>
      <li><a href="java.rmi.UnknownHostException.html">
         UnknownHostException</a></li>
      <li><a href="java.rmi.UnmarshalException.html">
         UnmarshalException</a></li>
  </ul>
				

그림 8은 edge-to-edge 리스트를 사용하여 패키지를 선택할 수 있는 최상위 레벨 네비게이션을 보여준다.

그림 9는 아이폰 미리보기 모드로 java.rmi 패지키의 결과를 보여준다.

iDoc의 세부 페이지에서는 아이폰의 또 다른 구조를 사용한다. 바로 둥근 사각형 리스트다. 이 리스트는 정보를 그룹핑할 때 유용한데 아이폰의 설정 창에서 볼 수 있다. 둥근 사각형 리스트를 사용해 메서드 시그너처와 매개변수 목록 그리고 예외를 구분할 것이다. V0.13에서 iUi는 둥근 사각형 리스트를 오직 폼 입력 용도로만 사용하도록 지원하고 있다. 따라서 정적인 텍스트를 출력할 때 이들 엘리먼트를 그냥 사용하면 틀에 맞지 않은 블록을 만들어 낸다. 그것들의 CSS를 확장하여 (Listing 2에 보이는) iDoc.css 파일을 만들고 정적인 텍스트를 둥근 사각형 리스트로 보여줄 textRow 엘리먼트를 추가한다.

                
/* Adding a new row CSS style to iUi for displaying blocks of text */
.textRow  {
    position: relative;
    border-bottom: 1px solid #999999;
    -webkit-border-radius: 0;
    text-align: right;
}

.textRow > p {
    text-align: left;
    margin: 5px 8px 5px 10px;
    padding: 0px 0px 0px 0px;
}


fieldset > .textRow:last-child {
    border-bottom: none !important;
}
				

Listing 3은 java.math.BigDecimal의 생성자 중 하나를 보여준다.

                
<div id="java.math.BigDecimal(long,java.math.MathContext)" title="BigDecimal"
        class="panel">
    <fieldset>
        <div class="textRow"><p><b>
           public BigDecimal(long, MathContext)</b></p></div>
        <div class="textRow"><p>Translates a
           <code>long</code> into a
        <code>BigDecimal</code>,with rounding according to the contextsettings.
        The scale of the <code>BigDecimal</code>, before any rounding,is zero.
      </p></div>
    </fieldset>
    <h2>Parameters</h2>
    <fieldset>
        <div class="textRow"><p><b>long val
           </b>: <code>long</code> value to be converted
         to <code>BigDecimal</code>.</p></div>
        <div class="textRow"><p><b>MathContext mc
           </b>: the context to use.</p></div>
    </fieldset>
    <h2>Throws</h2>
    <fieldset>
        <div class="textRow"><p><b>ArithmeticException
           </b>: if the result is inexact but
    the rounding mode is <code>UNNECESSARY</code>.</p></div>
    </fieldset>
</div>
				

<fieldset> 태그에 있는 모든 것들이 textRow <div>를 사용해 둥근 사각형 안으로 들어갔다. <h2> 헤드 태그는 목록 위에서 그룹 제목을 보여준다. 그림 10은 결과 페이지를 보여준다.

3단계 네비게이션과 세부 페이지 UI를 모두 끝냈다. iDoc은 사용자들이 특정 작업에 집중할 수 있게 해준다. iUi 프레임워크의 도움과 약간의 커스텀 CSS를 사용해 마치 진짜 아이폰 애플리케이션처럼 보이게 만들었다.

iDoc 개발하기

자, UI 디자인을 만들었고 이제 HTML 파일을 생성하는 코드를 만들어야 한다. 썬의 javadoc 명령어를 끼워 넣은 간단한 Doclet를 만들어보자. 이 예제는 자바 표준 java.* 패키지를 사용하지만 iDoc은 어떤 소스 코드로부터든지 자바독을 생성할 수 있다. OpenJDK(참고자료 참조)라, 공개적으로 사용 가능하며 GPL V2 라이선스를 사용하는 소스 코드를 사용해 자바독을 만들고 배포할 수 있다.

iDoc은 간단하게 패키지와 클래스를 순회하며 위에서 만든 형식대로 정적인 HTML 페이지를 출력하기 위한 메서드를 호출한다. Listing 4는 최종 세부 페이지를 출력하기 위한 메서드다.

                
private void printDetail(PrintStream p, ProgramElementDoc doc,
    String id, String name) {
    divHeader(p, id, name, "panel");
    textHeader(p, null);
    textRow(p, getSignature(doc));
    textRow(p, getCommentText(doc.commentText()));
    textFooter(p);
    if (doc instanceof ExecutableMemberDoc) {
        printMethodDetail(p, (ExecutableMemberDoc) doc);
    }
    divFooter(p);
}

private void printMethodDetail(PrintStream p, ExecutableMemberDoc field) {
    if (field.parameters().length > 0) {
        textHeader(p, "Parameters");
        for (int i=0; i<field.paramTags().length; i++) {
            textRow(p, "<b>" + field.parameters()[i].typeName() + " "
                    + field.paramTags()[i].parameterName()
                    + "</b>: "
            + getCommentText(field.paramTags()[i].parameterComment()));
        }
        textFooter(p);
    }
    if (field.throwsTags().length > 0) {
        textHeader(p, "Throws");
        for (int i=0; i<field.throwsTags().length; i++) {
            textRow(p, "<b>" +  field.throwsTags()[i].exceptionName()
                    + "</b>: "
            + getCommentText(field.throwsTags()[i].exceptionComment()));
        }
        textFooter(p);
    }
}
				

이 코드는 일반화된 메서드인데 printDetail()는 클래스 설명, 필드, 생성자 그리고 메서드를 출력한다. 나머지 두 개의 타입은 ExecutableMemberDoc의 서브 클래스로 그것들의 매개변수와 던지는 예외에 대한 정보를 추가로 출력한다.

성능 이슈

GZIP 압축 간단하지만 효율적인 성능 팁을 소개하겠다. 바로 웹 서버에서 GZIP 압축을 가능케 하는 것이다. 현재 쓰이는 웹 서버는 대부분 이 옵션을 제공하며, 이를 사용하는 클라이언트로 보내기 전에 페이지를 압축한다. 아이폰의 사파리도 그런 클라이언트 중 하나다. GZIP 압축을 자동으로 지원한다. 간단하게 GZIP 압축을 자신의 웹 서버에서 쓸 수 있게 하면, 아이폰 사용자들은 좀더 빠른 다운로드 시간을 경험하게 될 것이다.

Aptana의 아이폰 미리보기 모드는 결과 파일에 대한 디버깅에 도움을 준다. 각 주기마다 빠른 클릭을 통해 설계했던 인터페이스와의 불일치를 찾아낼 수 있다. 하지만 미리보기 모드를 사용하는 것은 성능 문제를 일으킬지도 모른다. 대부분의 컴퓨터들은 아이폰의 620MHz ARM 프로세서보다 세 배 내지 다섯 배 정도 빠르다. 또한 사용자들은 느린 휴대폰 네트워크를 통해 페이지를 다운로드할 것이다. 따라서 자신의 애플리케이션을 실제 아이폰에서 동작시켜 보는 것이 중요하다.

아이폰에서 iDoc을 시험해본 결과 매우 덩치 큰 HTML 파일을 출력할 때 흔들리는 듯한 화면과 성능 저하를 발견했다. 이것을 수정하기 위해 패키지와 클래스 이름을 네비게이션하는 메인 파일을 하나 만들고 별도의 파일로 각각의 클래스의 주석, 메서드에 대한 자세한 정보를 보여주는 페이지들을 만들었다(Listing 5). 비록 이런 과정을 통해 여러 개의 파일을 만들어 내게 되었지만, 각각의 파일 크기가 작기 때문에 애플리케이션이 매우 부드럽게 동작하게 되었다.

                
out = new FileOutputStream(index);
p = new PrintStream(out);
printHeader(p);

PackageDoc[] packages = root.specifiedPackages();
Arrays.sort(packages);

printPackages(p, packages);

for (int i=0; i<packages.length; i++) {
    printPackageDetail(p, packages[i]);
}
for (int i=0; i<packages.length; i++) {
    ClassDoc[] classes = packages[i].allClasses();
    Arrays.sort(classes);
    for (int j=0; j<classes.length; j++) {
        // Creating a separate file for each class.
        PrintStream p2 = new PrintStream(new FileOutputStream(getFilename(classes[j])));
        printClassDetail(p2, classes[j]);
        p2.close();
    }
}
printFooter(p);
p.close();
				

iDoc 사용하기

성능 향상을 통해 iDoc은 이제 출시될 준비가 끝났다. OpenJDK에 있는 java.*와 javax.*에 있는 51개 패키지와 1304개 클래스에 대한 자바독을 만들, 모든 것을 웹 서버로 업로드한다. 16MB가 넘는 크기의 파일이지만 주요 네비게이션 페이지는 단지 112KB에 불과하며 각각의 클래스 자세히 보기 페이지는 평균적으로 13KB다. EDGE 네트워크를 사용하더라도 애플리케이션은 매우 잘 응답한다. 아이폰이 있다면 iDoc 사이트(참고자료 참조)에 접속해 보거나 iDoc을 다운로드하여 아이폰을 위한 자바독을 생성할 수 있다. 그림 11은 최종 애플리케이션을 보여준다.

iDoc의 잠재적인 확장기능으로는 자바 5 제네릭과 자바독 주석에 포함된 페이지 사이의 링크를 위한 태그를 더 잘 파악하는 것이다. iDoc의 기능 추가에 관심이 있다면 모든 소스 코드는 온라인에서 받을 수 있다(참고자료 참조).

위로

아이폰 개발의 미래

소셜 북마크 mar.gar.in Digg del.icio.us Slashdot

2007년 10월 Steve Jobs는 애플이 아이폰 SDK를 2008년 2월에 공개할 것을 발표했다. 글을 쓰고 있는 시점이 2007년 12월이기 때문에 아직 구체적인 것은 미지수이지만 SDK를 통해 사파리의 도움 없이 아이폰 바로 위에서 동작하는 애플리케이션을 작성할 수 있게 될 것이다. 아이폰 아키텍처 기반을 얻는 것은 Mac OS X과 비슷하게 개발 플랫폼이 코코아(Cocoa)와 오브젝티브-C가 된다는 것이다. 최근 소식에 의하면 애플의 한 중역은 서드파티 애플리케이션이 몇 가지 인증 절차를 거치도록 하는 것을 제안하기도 했다.

발전된 애니메이션, 그래픽 그리고 네트워크 접속을 사용하는 애플리케이션이 네이티브로 동작할 수 있는 이점을 얻을 것이다. 하지만 SDK가 배포되더라도 아이폰을 위한 웹 개발은 여전히 매력적인 위치에 있을 것이다. 웹 애플리케이션은 쉽게 만들고 간단하게 배포할 수 있다. Aptana와 iUi 같은 도구는 개발을 간편하게 해주며 웹 애플리케이션을 빨리 만들 수 있도록 해준다. iDoc을 통해 보았듯이 SDK를 기다릴 필요도 없다. 오늘 배운 도구를 사용해 아이폰 기능을 완전히 사용하며 진짜 같은 룩앤필을 가진 웹 애플리케이션을 만들 수 있다.

참고자료

• iPhone Dev Center에는 Apple Developer Center에 있는 아이폰 웹 개발과 관련된 유용한 참조 문서들이 있다.
  
  
• iPhone Human Interface Guidelines 는 UI 개발 기준과 가이드라인 모음이다.
  
  
• OpenJDK는 썬의 오픈 소스 자바 개발 키트다.
  
  
• iDoc 시연 —OpenJDK Javadoc—를 여러분의 아이폰에서 참조하라.
  
  
• "Eclipse 추천 도서 리스트 (한글)"를 확인하라.
  
  
• developerWorks의 모든 이클립스 기사를 확인하라.
  
  
• 이클립스가 처음이라면 developerWorks의 기사 "Eclipse Platform 시작하기 (한글)"를 읽고 이클립스의 탄생과 아키텍처 그리고 플러그인을 사용하여 어떻게 이클립스를 확장할 수 있는지 공부하라.
  
  
• IBM developerWorks의 Eclipse 프로젝트 리소스를 참조하고 여러분의 이클립스 기술을 확장하라.
  
  
• 소프트웨어 개발에 관한 흥미로운 인터뷰와 논의 소식을 듣기 원한다면 developerWorks 포드캐스트를 확인하라.
  
  
• developerWorks의 기술 행사와 웹 캐스트에서 최신 정보를 접하라.
  
  
• developerWorks On demand demos에서 IBM과 오픈 소스 기술 그리고 제품에 대한 정보를 무료로 보고 익힐 수 있다.
  
  
• IBM 오픈 소스 개발과 관련하여 앞으로 개최될 컨퍼런스, 트레이드 쇼, 웹 캐스트 그리고 다른 행사들을 확인하라.
  
  
• 한국 developerWorks 오픈 소스 존을 방문하여 방대한 how-to 정보, 도구, 프로젝트 업데이트를 확인하여 오픈 소스 기술을 활용한 개발에 도움을 얻고 IBM의 제품들을 활용하라.
  
  

• 최신 버전의 Aptana 이클립스 플러그인을 다운로드하라.
  
  
• 최신 버전의 iUi 프레임워크를 다운로드하라.
  
  
• 최신 버전의 iDoc 생성기 소스 코드를 다운로드하라.
  
  
• IBM alphaWorks에서 최신 이클립스 기술 다운로드를 확인하라.
  
  
• 이클립스 재단에서 이클립스 플랫폼과 기타 프로젝트를 확인하라.
  
  
• IBM 제품 평가판을 다운로드해 DB2®, Lotus®, Rational®, Tivoli®, 그리고 WebSphere® 제품군의 애플리케이션 개발 도구와 미들웨어 제품을 사용해 보라.
  
  
• 여러분의 다음 오픈 소스 개발 프로젝트를 다운로드나 DVD로 구할 수 있는 IBM 시험판 소프트웨어를 사용하여 혁신하라.

Eclipse 디버거와 Debug 뷰

Eclipse SDK -- 특히, Java™ Development Tools (JDT) 프로젝트-는 단계별 실행을 수행하는 기능, 중단점과 값을 설정하는 기능, 변수와 값을 검사하는 기능, 쓰레드를 중지하고 재시작 하는 기능을 포함하여 표준의 모든 디버깅 기능들을 제공하는 빌트인 자바 디버거들로 구성되어 있다. 게다가, 원격 머신에서 실행되는 애플리케이션들을 디버깅 할 수도 있다. Eclipse 플랫폼은 다른 프로그래밍 언어들도 각각의 언어 런타임에 이 디버그 장치들을 사용할 수 있다는 강점을 갖고 있다. 앞으로 알게 되겠지만, 같은 Eclipse Debug 뷰 역시 C/C++ 프로그래밍 언어에도 적용될 수 있다.

Eclipse Platform Workbench와 툴은 JDT 컴포넌트에 구현되어 다음과 같은 기능들을 Eclipse에 제공한다.

• 프로젝트 관리 툴
• 퍼스펙티브와 뷰
• 빌더, 에디터, 검색, 빌드 함수
• 디버거

Eclipse 디버거는 그 자체로 표준 플러그인 세트이다. Eclipse에는 또한 특별한 Debug 뷰가 있어서, 이 뷰를 통해서 Workbench에서 프로그램의 디버깅 및 실행을 관리할 수 있다. 디버깅 하고 있는 각 대상에 대해 중지된 쓰레드에 대한 스택 프레임을 디스플레이 한다. 프로그램의 각 쓰레드는 트리에 있는 노드로서 나타나고, Debug 뷰는 여러분이 실행하고 있는 각 대상의 프로세스를 디스플레이 한다. 쓰레드가 중지되면, 스택 프레임은 자식 엘리먼트로서 보여진다.

Eclipse 디버거를 사용하기 전에 Java SDK/JRE (Java VM V1.4를 권장한다.) 와 Eclipse Platform SDK V3.3이 설치되고, 이것들이 아무런 문제 없이 실행되고 있는 것으로 간주하겠다. 일반적으로, Eclipse 샘플을 사용하여 디버깅 옵션을 테스트 하는 것도 좋은 생각이다. C/C++ 프로젝트를 개발 및 디버그 한다면, C/C++ Development Tools (CDT)를 설치해야 한다. Java SDK/JRE, Eclipse 플랫폼과 샘플, CDT에 대한 링크는 참고자료 섹션을 참조하라. 그림 1은 Debug 퍼스펙티브의 모습이다.

자바 프로그램 디버깅

프로젝트를 디버깅 하기 전에, 코드가 깨끗하게 컴파일 및 실행되어야 한다. 애플리케이션에 맞게 실행 설정을 해야 하고 이것이 올바르게 시작되는지를 확인해야 한다. Run > Debug 메뉴를 사용하여 디버그 설정을 한다. 디버거에 의해서 메인 자바 클래스로서 사용될 클래스를 선택해야 한다. (그림 2) 단일 프로젝트에 원하는 만큼의 디버그 설정을 가질 수 있다. (Run > Debug에서) 디버거가 시작될 때, 새로운 창에서 열리며 이제 디버깅을 시작할 준비가 된 것이다.

이제는 Eclipse에서의 일반적인 디버깅 방법들을 설명하도록 하겠다.

중단점 설정하기

디버깅을 위해 애플리케이션을 시작할 때, Eclipse는 자동으로 Debug 퍼스펙티브로 전환한다. 가장 일반적인 디버깅 절차는 조건 문 또는 루프 내에 변수와 값을 검사할 수 있는 중단점을 설정하는 것이다. Java 퍼스펙티브의 Package Explorer 뷰에서 중단점을 설정하려면, 선택된 소스 코드를 더블 클릭하여 에디터에서 연다. 코드를 검사하고 마커 바(에디터 영역의 왼쪽 가장자리)에 있는 커서를 중지된 코드가 있는 라인에 둔다. 더블 클릭하여 중단점을 설정한다.

이제 Run > Debug 메뉴에서 디버깅 세션을 시작한다. 한 라인에 여러 문을 놓지 않는 것이 중요하다. 같은 라인에 있는 한 개 이상의 문에 라인 중단점을 뛰어넘거나 설정할 수 없기 때문이다.

모든 중단점들을 관리하는 편리한 Breakpoints 뷰도 있다.

조건적 중단점

에러가 어디에서 발생했는지 알았다면 프로그램이 충돌하기 전에 올바르게 수행되었는지를 확인해야 한다. 한 가지 방법은 문제 지점에 다다를 때까지 한번에 하나씩 프로그램의 모든 문을 검사하는 것이다. 가끔은 코드의 한 섹션을 실행하고 그 지점에서 실행을 멈춰서 그 위치에 있는 데이터를 검사하는 것이 더 나을 때가 있다. 식의 값이 변할 때마다 실행되는 조건적 중단점을 선언할 수도 있다. (그림 6) 게다가, 조건 식을 타이핑할 때 Code Assist를 사용할 수 있다.

식 계산하기

Debug 퍼스펙티브에 있는 에디터에서 식을 계산하려면, 중단점이 설정된 전체 라인을 선택하고 콘텍스트 메뉴에서 Ctrl+Shift+I 또는 관심 있는 변수를 오른쪽 클릭하여 Inspect 옵션을 선택한다. 식은 현재 스택 프레임 컨텍스트에서 계산되고 결과는 Display 윈도우의 Expressions 뷰에 디스플레이 된다.

활성 코드 스크랩북킹(Scrapbooking)

Display 뷰에서는 스크랩북 형태로 활성 코드를 조작할 수 있다. (그림 8) 변수를 처리하려면 Display 뷰에 변수 이름을 타이핑 하면 익숙한 Content Assist가 나타난다.

디버거가 중단점에서 멈추면 Debug 뷰 툴바에서 Step Over 옵션을 선택하여 디버거 세션을 계속 진행할 수 있다. (그림 9) 이것은 하이라이트 된 코드 라인을 건너뛰고 같은 메소드의 다음 라인에서 실행을 계속한다.(또는 현재 메소드가 호출되었던 메소드에서 실행을 계속한다.) 마지막 단계의 결과로 변경된 변수들은 색깔로 하이라이트 된다. (기본 색은 노란색이다.) 색상은 디버그 프레퍼런스 페이지에서 변경할 수 있다.

Debug 뷰에서 쓰레드의 실행을 중지하기 위해, 실행 쓰레드를 선택하고 Debug 뷰 툴바에서 Suspend를 클릭한다. 이 쓰레드에 대한 현재 호출 스택이 디스플레이 되고 현재 실행 라인이 Debug 퍼스펙티브의 에디터에서 하이라이트 된다. 쓰레드가 중지되면 커서는 Java 에디터의 변수 위에 놓이고 그 변수의 작은 창으로 디스플레이 된다. 또한, 이 쓰레드의 상단 스택 프레임이 자동으로 선택되고 스택 프레임에 있는 변수들이 Variables 뷰에 디스플레이 된다. 이름을 클릭하여 Variables 뷰에 있는 해당 변수들을 검사할 수 있다.

Hotswap Bug Fixing: 코드 픽스

Java Virtual Machine (JVM) V1.4 또는 이후 버전을 실행한다면, Eclipse는 Hotswap Bug Fixing (JVM V1.3 이하 버전에서는 실행되지 않음)이라고 하는 기능을 지원한다. 디버거 세션 중에 소스 코드를 변경할 수 있는데 이는 애플리케이션을 종료해서 코드를 수정하고 재컴파일 한 다음 또 다른 디버깅 세션을 시작하는 것 보다 낫다. 이 기능을 사용하려면 에디터에서 코드를 수정하고 디버깅을 재시작 한다. 이 기능은 JVM V1.4가 Java Platform Debugger Architecture (JPDA)와 호환되면서 사용할 수 있게 되었다. JPDA는 실행 애플리케이션에서 수정된 코드를 대체하는 기능을 구현한다. 물론 이것은 애플리케이션을 시작하거나 오류가 난 지점으로 가는데 오랜 시간이 걸릴 경우에 특히 유용하다.

디버깅을 끝냈음에도 프로그램이 완전하게 실행되지 않는다면 Debug 뷰의 콘텍스트 메뉴에서 Terminate 옵션을 선택한다. 디버거 세션에 있는 동안 Resume 대신 Debug 또는 Run을 사용하는 실수를 흔히 저지른다. 이것은 현재 세션을 지속하는 것이 아닌 또 다른 디버거 세션을 시작한다.

위로

원격 디버깅

Eclipse 디버거는 원격 애플리케이션을 디버깅 하는데도 재미있는 옵션을 제공한다. 자바 애플리케이션을 실행하는 원격 VM으로 연결하여 애플리케이션에 부착할 수 있다. 원격 디버깅 세션에서 실행하는 것은 로컬 디버깅과 비슷하다. 하지만, 원격 디버깅 설정에는 Run > Debug 윈도우에서 다른 설정을 해야 한다. 왼쪽 뷰에서 Remote Java Application 항목을 선택한 다음 New를 클릭한다. 새로운 원격 시작 설정이 이루어지면 세 개의 탭(Connect, Source, Common)이 보인다.

Connect 탭의 Project 필드에서 (소스 코드 검색용) 시작 참조용으로 사용할 프로젝트를 선택한다. Connect 탭의 Host 필드에서, 자바 프로그램이 실행되는 원격 호스트의 IP 주소나 도메인 이름을 입력한다. Connect 탭의 Port 필드에서, 원격 VM이 연결을 수락하는 포트를 입력한다. 일반적으로, 이 포트는 원격 VM이 시작될 때 지정된다. Terminate 명령어를 원격 세션에서 사용할 수 있는지 여부를 디버거가 결정하도록 하려면 Allow termination of remote VM 옵션을 선택한다. 연결된 VM을 종료하고 싶다면 이 옵션을 선택한다. 이제 여러분이 Debug 옵션을 선택하면, 디버거는 지정된 주소와 포트에 있는 원격 VM으로 연결하고 결과가 Debug 뷰에 디스플레이 된다.

런처(launcher)가 지정된 주소에 있는 VM에 연결되지 않으면 에러 메시지가 나타난다. 일반적으로, 원격 디버깅 기능의 가용성은 원격 호스트에서 실행되는 Java VM에 달려있다.

위로

다른 언어 디버깅 하기

자바가 Eclipse에서 가장 일반적으로 사용되지만, Eclipse는 다른 많은 언어들도 지원할 수 있는 확장성 있는 플랫폼이다. Eclipse는 C/C++ Development Tools (CDT) 프로젝트를 통해 C/C++을 지원한다. CDT는 C/C++ 코드를 디버깅하는 기능으로 표준 Eclipse Debug 뷰를 확장하고, CDT Debug 뷰에서는 워크벤치의 C/C++ 프로젝트의 디버깅을 관리할 수 있다. CDT에는 내부 디버거가 없지만 GNU GDB 디버거에 대한 프론트엔드를 제공한다. 이것은 로컬에서만 사용된다. PHP Development Tools (PDT) 같은 프로젝트도 고유의 디버거를 제공한다. (그림 11)

위로

결론

Eclipse 플랫폼은 단계 실행을 수행하는 기능, 중단점과 값을 설정하는 기능, 변수와 값을 검사하는 기능, 쓰레드를 중지 및 시작하는 기능을 포함한, 표준 디버깅 기능들을 갖춘 자바 디버거를 제공한다. 원격 머신에서 실행되는 애플리케이션을 디버깅 하는 데에도 사용될 수 있다. Eclipse 플랫폼은 주로 자바 개발 환경이지만, 같은 Eclipse Debug 뷰가 C/C++, PHP, 기타 프로그래밍 언어에서도 사용될 수 있다.

위로

감사의 말

그림 11"을 만들어 준 Tyler Anderson에게 감사의 말을 전한다.

참고자료

• Eclipse.org: 프로그램 정보와 사용 방법
  
  
• PlanetEclipse.org: Eclipse 커뮤니티 소식
  
  
• Eclipse.org의 CDT project: C/C++ 개발 툴 관련
  
  
• Ajax Tools Framework (ATF) flash page와 project page: JavaScript 디버깅
  
  
• EclipseCon tutorial: Eclipse의 Debug Framework
  
  
• "Eclipse 추천 도서 리스트 (한글)."
  
  
• Eclipse 기술자료: developerWorks.
  
  
• Eclipse 기술자료: 한국 developerWorks.
  
  
• Eclipse 시작하기 (한글): Eclipse 입문자용
  
  
• IBM developerWorks Eclipse project resources.
  
  
• developerWorks podcasts: 소프트웨어 개발자들의 인터뷰와 토론
  
  
• "Eclipse Platform 시작하기 (한글)": Eclipse 플랫폼 소개
  
  
• developerWorks Technical events and webcasts.
  
  
• IBM 오픈 소스 개발자 관련 컨퍼런스, 트레이드 쇼, 웹 캐스트, 기타 이벤트
  
  
• 한국 developerWorks 오픈 소스 존: 오픈 소스 기술과 IBM 제품 사용에 대한 how-to 정보, 툴, 프로젝트 업데이트
  
  

• 최신 Eclipse technology downloads: IBM alphaWorks.
  
  
• IBM product evaluation versions 다운로드: DB2®, Lotus®, Rational®, Tivoli®, WebSphere®의 개발 툴과 미들웨어 제품들
  
  
• IBM 시험판 SW 다운로드 또는 DVD 구매.

• Eclipse CDT newsgroups: C/C++ 디버깅 (기본 Usenet 뉴스 리더기 애플리케이션이 시작되면 eclipse.platform이 열린다.)
  
  
• Eclipse ATF newsgroups: JavaScript 디버깅 (기본 Usenet 뉴스 리더기 애플리케이션이 시작되면 eclipse.platform이 열린다.)
  
  
• Eclipse platform newsgroups: 디버깅 및 기타 Eclipse 플랫폼 관련 질문들 (기본 Usenet 뉴스 리더기 애플리케이션이 시작되면 eclipse.platform이 열린다.)
  
  
• Eclipse Platform newsgroups: Eclipse 관련 기본 질문들 (기본 Usenet 뉴스 리더기 애플리케이션이 시작되면 eclipse.platform이 열린다.)
  
  
• Eclipse newsgroups: Eclipse 사용과 확장과 관련한 자료들
  
  
• Participate in developerWorks blogs and get involved in the developerWorks community.
  

앤트 파일 디버깅

자바 파일을 디버깅하는 것처럼, 이클립스에서 앤트 파일을 디버깅할 수 있으며, 모든 표준 디버깅 기능을 사용할 수 있다. 이것이 이클립스 앤트 통합에서 가장 유용한 기능이다.

타깃 내에 중단점 설정하기

자바 파일로 작업할 때처럼, 한 단계씩 확인을 하고 싶을 때, 작업을 호출하는 타깃에 있는 라인에 중단점을 설정할 수 있다. 라인에 중단점을 넣으려면, 간단히 왼쪽에 있는 회색 바에서 더블 클릭을 하면 된다. 녹색 공이 나타나 중단점이 정해졌음을 나타낸다(그림 15). 클릭함으로써 일시적으로 중단점을 활성화하거나 비활성화할 수 있고, Breakpoints 뷰에서도 중단점을 비활성화로 변경할 수 있다. 비활성화된 중단점은 하얀색 공 모양으로 표시된다. 자바의 중단점과 달리 카운트를 세거나 중단점에 상태를 줄 수 없다는 점-앤트 파일을 디버깅할 때는 결국 필요 없다-을 주의하자.

위로

빌드 파일 디버깅

이제 디버깅을 시작해 보자. Ant 뷰나 Outline 뷰에서 타깃에 마우스 오른쪽 버튼을 클릭한 다음, Debug As > Ant Build를 클릭하자. 자바 파일을 디버깅할 때처럼, 빌드 파일은 우리가 설정해두었던 중단점이 있는 라인에 도달하게 되면 멈춘다.

여기부터가 중요하다. Debug 뷰에서 Step Over 버튼을 클릭하면 자바 구문이 실행되는 것처럼, 빌드 파일이 한 줄씩 진행된다(그림 16). 각 작업을 순차적으로 진행함으로써, 작업이 실행되고 결과가 나온다. 이를 통해 빌드 프로세스에서 무엇이 잘못 됐는지를 확인할 수 있다. 오른쪽 버튼을 클릭하고, Run to Line을 클릭함으로써 해당 줄에서 마우스 특정 줄에 도달할 때까지 계속 빌드 파일을 실행한다. 이 과정은 선택된 줄에 도착하자마자 중단점을 삭제하는, 줄에 일시적으로 설정하는 중단점과 비슷하다.

Debug 뷰는 현재 실행되는 작업의 호출 스택을 보여준다. 작업에서 또 다른 타깃을 호출하면(antcall이라고 한다), 호출 스택의 현재 작업 위에 해당 타깃이 나타난다.

Variable 뷰 또한 이용할 수 있다(그림 17) 이 뷰를 열면 앤트에서 변수와 동일한 역할을 하는 모든 앤트 속성을 보여준다. 속성들은 다음 세 부분으로 분류된다.

• 시스템 속성(System properties): 빌드를 하기 위해 시스템에서 설정하는 속성
• 사용자 속성(user properties): -D 옵션을 사용해 지정한 것과 같은 속성User properties:
• 실시간 속성(Runtime properties): 실행되는 동안에 빌드 파일에 정의된 속성

자바 디버거와는 달리, 앤트 디버거는 Variables 뷰에 있는 속성들의 값을 바꿀 수 없다.

프로젝트 구축을 위해 앤트 빌드파일 사용하기

이클립스 자바 IDE를 사용할 때, 무의식적으로 자바 빌더(Java Builder)를 사용한다. 자바 빌더는 파일을 저장하자마자 즉시 컴파일 작업을 내부적으로 수행하는 조용하고 날쌘 녀석이다.

비록 이 기능이 크게 다룰 문제가 아닌 것처럼 보일지라도, 사실 이클립스의 가장 놀라운 기능 중 하나다. 모든 코드가 에러 상태일지라도, 항상 컴파일되기 때문에, 자바 빌더는 모든 컴파일 과정을 유지해준다. 그러므로 길고, 성가신 컴파일 단계를 먼저 수행하지도 않고, 소스 작성 후 바로 자바 프로그램을 즉각 실행할 수 있다. 이 유용한 기능 덕분에 이클립스 사용자들은 불필요한 노력과 많은 시간을 절약할 수 있었고 프로그래머들 사이에서의 이클립스가 엄청난 인기를 끌 수 있었다.

그러나 우리가 단지 파일을 컴파일하는 것보다 더 많은 일을 하고 싶다면? 전체 프로젝트를 묶는 jar 파일을 만들길 원하고, 프로젝트가 변경될 때마다 특정 디렉토리에 이 jar를 복사하고 싶다면 어떻게 해야 할까? 그리고 매번 이클립스에 지시하지 않고, 내부적으로 이 모든 작업이 수행되길 원한다면? 차분히 앉아, 마음을 가라 앉히고, 코드 몇 줄을 작성한 다음에, 커피 맛을 음미하는 동안 이클립스에서 실제로 무슨 일이 벌어나는지 알 필요도 없이 내부적으로 복잡한 빌드 프로세스를 관리해 준다면 어떨까.

꿈처럼 들리는가? 꿈이 아니다. 우리는 실제로 이 일을 할 수 있다. 우리는 내부적으로 복잡한 모든 빌드 프로세스를 포함하면서 프로젝트의 “builder” 역할을 하는 앤트 빌드 파일을 추가만 하면 된다. 이 일을 하면 마법이 시작될 것이다.

왜 프로젝트 빌더로 앤트를 사용하는가

프로젝트에 있는 클래스 파일을 jar 파일로 만들고, 프로젝트의 최상위 경로에 위치시켜 주는 앤트 빌드 파일이 있다고 가정해 보자(빌드 파일의 정확한 내용은 지금 나오는 내용과 관련이 없다). 우리는 자바 파일이 수정될 때마다 실행되는 빌드 파일을 원하며, jar 파일은 항상 최신 상태를 유지한다. 이 작업은 다음 단계를 거쳐 완성된다.

1. Package Explorer 뷰에서 해당 프로젝트를 마우스 오른쪽 버튼으로 클릭하고, 다음으로 Properties를 클릭한다.
2. Builder를 선택하고, 프로젝트에 새로운 빌더를 추가하기 위해New를 클릭하자.
3. 결과 화면에서 Ant Build를 선택하고, OK를 누르자.
4. 빌더의 속성 창jd 다음과 같이 나타난다(그림 18). 여기서 빌더를 구성하자.
   
   
   그림 18. 빌더 설정 창
   
   
   
5. Name 박스에 MyBuilder를 입력하자.
6. 프로젝트에 있는 빌드 파일을 선택한 다음, Buildfile 바로 아래 Browse Workspace를 클릭하자.
7. Base Directory 밑에 있는 Browse Workspace를 클릭하고, 빌드 파일이 포함하는 프로젝트를 선택한다. 빌드 파일에 인자를 제공할 수 있지만, 우리는 지금 이 예제에서는 제공할 필요가 없으니, 공백으로 남겨두자.
8. Refresh 탭을 클릭하자(그림 19).
   프로젝트를 다시 로드하면 앤트와 같은 외부 도구에 의해 로컬 파일 시스템에 생성된 프로젝트가 변경된 부분이 있는지를 찾도록 Eclipse Workbench에 지시하게 된다. 그리고 이제 빌드 스크립트가 끝난 후에 Refresh를 수행해야 할지 말지, 만약 수행한다면 workspace에서 어느 부분을 Refresh를 해야 하는지를 이클립스에 정해줘야 한다.
   
   
   그림 19. Refresh 탭
   
   
   
9. 체크 박스에서 Refresh resources upon completion을 선택하자. 탭 아래에 있는 옵션을 선택할 수 있게 되었다. 얼마나 많은 workspace가 Refresh될 것인지 이클립스에 정해주자. Workbench를 계속 빠르게 실행할 수 있도록 가능한 가장 범위가 좁은 옵션을 선택하자. 이 예제의 경우 단지 현재 프로젝트의 Refresh만 필요하기 때문에, The project containing the selected resource 옵션을 선택하자.
10. Targets 탭을 클릭하자.
    
    
    그림 20. Targets 탭
    
    
    
    이제 실제 실행될 빌드 파일을 선택할 수 있고, 좀 더 상세하게 실행될 타깃까지 선택할 수 있다. 네 가지 옵션을 사용할 수 있다.
    
    • - After a "Clean" – 프로젝트에 clean 작업을 수행할 때마다 타깃을 실행함.
    • - Manual Build – 이 옵션은 자동 빌드 기능이 꺼져 있는 경우에 사용된다. 사용자가 수동으로 빌드를 수행할 때마다, 정해진 타깃이 실행된다.
    • - Auto-Build - 자동 빌드가 수행될 때마다 타깃이 실행된다. 일반적으로 이 옵션은 자바 파일을 저장할 때마다 수행된다.
    • - During a "Clean" – 이 옵션은 After a “Clean” 옵션과는 다르게 타깃이 clean 오퍼레이션을 수행하는 동안에 호출된다. 이 옵션은 clean 오퍼레이션을 수행하는 동안에 파일의 맞춤 삭제 작업을 수행하기 위해 사용된다.
11. 타깃이 실행되도록 설정하자. 각각의 타깃 옵션에는 매번 오퍼레이션이 수행되는 동안 실행되는 타깃을 설정하는 Set Targets 버튼이 있다. 일반적으로 여기서는 기본 타깃을 설정하지만, 실행되는 순서를 정해줌으로써 어떤 타깃-심지어 다수의 타깃의 동시 설정도 가능-이든지 설정할 수 있다.
12. 실행하는 빌드 파일을 원하는 오퍼레이션이 무엇이든 이에 상응해 실행되는 타깃을 정의하자.
    이 경우에 우리는 항상 최신 jar 파일을 원하기 때문에 After a “Clean”과 Auto Build 오퍼레이션으로 타깃을 설정하자. 이렇게 설정하기 위해, Set Targets를 클릭하고, 그 다음 실행되는 타깃을 선택하자. Manual Build처럼 어떤 다른 오퍼레이션을 위해 정의되어 있는 타깃이 있다면, Set Targets을 클릭하고 그 오퍼레이션이 수행되는 동안에 실행되는 빌드 파일이 이용될 수 없도록 해당 타깃의 체크 박스에서 선택을 해제하자.
    
    또한 예를 들어, 매번 Auto Build 오퍼레이션이 수행된 후에 실행되는 타깃까지도 선택할 수 있다는 것을 알아두자. 하지만 일반적으로 빌드 프로세스가 길게 진행된다면 Workbench 속도가 반으로 저하되기 때문에, 이 옵션은 주의 깊게 사용해야 한다. 보통 Manual Build와 After a “Clean”만을 옵션으로 설정한다.
13. OK를 클릭하자.

이제 새로 추가된 빌더를 테스트할 시간이다. 프로젝트에서 자바 파일을 열고, 몇 가지를 수정하고(예를 들어, 빈 공간을 넣는다든지), 저장을 하자. Auto Build가 수행되고, 콘솔에서 빌드 파일이 선택해놨던 타깃을 수행하는 것을 확인할 수 있다. jar 파일은 빌드되고, Navigator와 Package Explore 뷰에 보인다. 이 모든 작업은 자동으로 매번 발생한다.

결론

이클립스가 제공하는 소스 작성하기, 디버깅, 앤트 빌드 스크립트 내 이동을 위한 막강한 기능들을 살펴 봤다. 심지어 앤트 파일을 백그라운드에서 자동으로 실행함으로써 프로젝트 빌더로 앤트를 사용할 수 있었다. 이제 이클립스에서 매우 친숙하게 빌드 스크립트를 작성할 준비가 되었다.

앞서 설명한 기능을 더 공부해 스스로 앤트 빌드 스크립트를 작성하고 앤트를 프로젝터 빌더로 사용해 보기를 추천한다. 또한 빌드 스크립트를 작성하면서 사용할 수 있는 모든 작업들의 설명을 찾아 볼 수 있는 앤트 공식 레퍼런스 문서를 확인하는 것을 잊지 말자.

참고자료

교육

• 아파치 앤트 1.7.0 메뉴얼
  
  
• Anthony Young-Gamer가 쓴 develperWorks 기사 “Extending Ant to support interactive builds”를 보면 런타임에 상호 작용 가능한 빌드를 생산해 내기 위해 앤트를 확장하는 법을 보여준다.
  
  
• 앤트를 잘 소개하고 있는 Michael Cymerman의 “Automate your build process using Java and Ant”
  
  
• Malcolm Davis의 앤트를 잘 소개하고 있는 또 다른 글 "Incremental development with Ant and JUnit"
  
  
• 앤트 온라인 문서에 있는 “Writing Your Own Task”에서는 앤트를 사용한 커스텀 태스크 개발의 기초를 설명한다.
  
  
• 이클립스 내에서 앤트와 관련된 기능들은 이클립스 문서 중 Ant support 부분을 읽는다.
  
  
• “Eclipse 추천 도서 리스트 (한글)”를 읽어보라.
  
  
• 한국 develperWorks에 실린 모든 이클립스 기사를 검색해 보라.
  
  
• 이클립스를 초보 사용자는 Eclipse 시작하기 (한글)를 보라.
  
  
• IBM develperWorks의 Eclipse 프로젝트 리소스 (한글)를 확인함으로써 이클립스 기술을 확장하자.
  
  
• 소프트웨어 개발자들의 흥미로운 인터뷰나 토론을 듣고 싶다면 developerWorks 포드캐스트를 구독하라.
  
  
• 이클립스 플랫폼을 소개하고 있는 “Eclipse Platform 시작하기 (한글)”을 보라.
  
  
• developerWorks의 기술행사와 웹 캐스트.
  
  
• IBM 오픈 소스 개발자들의 흥미를 끄는 세계 곳곳에서 열리는 컨퍼런스, 웹 캐스트, 전시회 등의 행사.
  
  
• 오픈소스 기술을 사용한 개발과 IBM 제품을 사용할 때 도움을 얻으려면 정보, 도구 활용, 프로젝트 업데이트 등의 방대한 내용이 있는 한국 developerWorks 오픈 소스 존을 방문하자.
  
  

제품 및 기술 얻기

• 아파치 앤트에서 최신 앤트 개발 뉴스를 보라.
  
  
• IBM alphaWorks에서 최신 이클립스 기술 다운로드를 확인하라.
  
  
• 다운로드나 DVD를 통해 구할 수 있는 IBM 시험판 소프트웨어로 여러분의 차기 오픈 소스 개발 프로젝트를 개선해 보라.

토론

• 앤트 메일링 리스트에서 앤트에 대해 토론해 보자.
  
  
• 이클립스 플랫폼 뉴스그룹은 이클립스에 관련된 질문에 토론할 수 있는 첫 번째 장소다(이 링크를 선택하면 여러분의 기본 유즈넷 뉴스 리더 애플리케이션이 실행되고, eclipse.platform이 열린다).
  
  
• 이클립스 뉴스그룹에는 이클립스를 확장하고, 사용하는 데 관심있는 사람들을 위한 많은 자료가 있다.
  
  
• developerWorks 블로그와 커뮤니티에 참여하자.
  

앤트로 작업하기

새로운 앤트 빌드파일 만들기

프로젝트에 새 앤트 파일을 추가하자. 이 파일은 튜토리얼의 나머지 부분에서도 사용할 것이다.

1. Package Explorer를 연다.
2. Java Project에서 오른쪽 버튼을 클릭하고 New > File을 클릭한다.
3. New File 윈도우에서 파일 이름을 build.xml로 입력한다.

파일이 생성되고, 앤트 편집기가 열린다. 이제 이 파일에 몇 가지 내용을 추가하자. 편집기의 아무 곳이나 클릭한 다음 Ctrl+Space를 누른다. 그러면 ‘Buildfile template -- simple buildfile with two targets’라는 자동 완성이 나타난다(그림 1). 이것을 클릭해 타깃 두 개가 들어있는 예제 프로젝트를 파일에 추가한다.

준비가 되었으니, 이제 앤트 편집기에 대해 좀 더 자세히 살펴보자.

앤트 편집기

앤트 편집기의 가장 좋은 기능에는 코드 하이라이트(highlighting), 코드 완성(code completion), 접기(folding), 이름 변경(renaming), 발생한 문제 해결(making occurrences and problems) 같은 것들이 있다.

코드 하이라이트

좀더 쉽게 사용할 수 있도록 편집기에서 빌드 파일의 각 요소들을 다른 색으로 보여준다. 예를 들면 주석은 속성이나 다른 요소들과는 다른 색으로 표시된다. 각각의 요소 유형에 대한 색은 사용자가 원하는 대로 변경할 수 있다.

코드 하이라이트 색을 바꾸려면 다음 세 단계를 거치면 된다.

1. Window > Preferences > Ant > Editor 클릭.
2. Syntax 탭 클릭.
3. 결과 페이지에서 각 요소 유형의 색 선택

코드 완성

앤트 편집기에서는 앤트 빌드 파일을 빠르게 작성할 수 있게 포괄적인 코드 완성 기능을 제공한다. 타깃 정의 안을 클릭하고, Ctrl+Space를 누르면 사용할 수 있는 작업의 모든 목록을 볼 수 있다. 한 작업을 선택하면, 편집기는 시작 태그와 종료 태그를 포함해 자동으로 삽입한다(그림 2).

그림 2. 작업 목록

그러나 이것이 다가 아니다. 앤트 편집기의 코드 완성 기능은 자동 태그 삽입 이상의 기능을 제공한다. 편집기는 빌드 파일에 정의된 타깃들을 알고 있다. 자, 예를 들어 타깃의 이름을 삽입하고 싶을 때, 즉 프로젝트의 default 속성이나 타깃의 depends 속성을 입력하면서 Ctrl+Space를 누르면 우리가 채울 수 있는 이용 가능한 모든 타깃 목록을 보여준다(그림 3).

그림 3. 이용 가능한 타깃들

편집기는 심지어 빌드 파일에 정의되어 있는 속성들까지도 알고 있다. 그래서 속성의 값을 입력해야 할 경우에 먼저 앞에 $(달러 기호)를 입력한 후에 Ctrl+Space를 누르면 빌드 파일에서 정의된 이용 가능한 모든 속성과 모든 시스템 속성 목록을 볼 수 있다(그림 4).

그림 4. 이용 가능한 속성 목록

앤트 편집기에서 제공하는 또 다른 코드 완성 기능은 코드 템플릿이다(그림 5). 빌드 파일에 예제 내용을 추가하기 위해 빌드 파일 템플릿을 사용했을 때 이 기능을 사용한 것이다. 몇몇 템플릿은 앤트 편집기에서 이용할 수 있고, 이를 사용해 쉽고 빠르게 타깃 정의와 속성 정의 등 그 밖에도 많은 내용을 입력할 수 있다. 템플릿을 적용한 다음에 텍스트가 들어가는 위치에 나타난 박스는 자동으로 채워지게 된다(그림 6). 이 박스들은 빈칸을 채우는 일을 좀 더 쉽게 수행하기 위해 중요한 역할을 한다. 이 박스에는 타깃의 이름이나 의존성과 같은 텍스트를 입력할 수 있다. 우리는 Tab 키를 사용해 템플릿에 있는 빈칸(blank) 사이를 이동할 수 있다.

그림 5. 작동중인 코드 템플릿



그림 6. 템플릿 적용하기

접기

앤트 편집기에는 빌드 파일에서 모든 XML 요소들을 접을 수 있다. 간단히 +나 - 버튼을 클릭하면 다양한 요소를 펼치거나 접을 수 있다. 이 기능을 이용하면 빌드 파일을 빠르게 훑어 볼 수 있기 때문에 매우 유용하다. +아이콘에 마우스를 올려 놓으면 해당 요소의 내용을 담은 창을 띄워준다.

위로

이름 변경

실제로 앤트 편집기에서 가장 유용한 기능 중 하나는 파일의 이름 변경 기능이다. 이 기능을 사용하면 파일 전체를 통틀어 타깃과 속성의 이름을 변경할 수 있다(그림 7). 예를 들어 타깃의 이름을 변경하고 싶다고 하자. 이름에서 마우스 오른쪽을 클릭한 다음에 Rename in file을 클릭하자. 정사각형 박스가 파일 전체에 걸쳐 해당 타깃 이름을 참조하는 요소에 표시가 된다. 이제 타깃 이름을 수정할 수 있고, 파일 전체에 이 변화가 반영될 것이다. 이 특징은 심지어 속성 이름에도 적용된다.

그림 7. 타깃 이름 변경

위로

동일성 표시

상단에 있는 Toggle mark occurrences 버튼을 클릭하면 동일성 표시 기능을 활성화/비활성화할 수 있다. 이 기능을 활성화하면, 타깃이나 속성의 이름을 클릭했을 때 파일 전체에 타깃이나 속성의 모든 동일성을 확인, 강조해 준다.

그림 8. 동일한 타깃 표시

위로

선택된 요소만 보여주기

Show selected elements only 버튼(그림 9)을 클릭하면 클릭된 요소만 볼 수 있다. 이 기능은 다른 흩어져 있는 것들에 방해를 받지 않으면서, 큰 타깃의 정의를 작성하고 싶을 때 특히 유용하다. 파일 요소의 다른 부분을 클릭해 사리지게 만들 수 있어, 오로지 타깃에만 집중할 수 있다.

그림 9. 현재 타깃만 보기

위로

문제 체크하기

앤트 편집기는 우리가 타이핑하는 동안에 해당 빌드 파일에 에러와 경고를 보여줄 수 있다. 이 기능을 이용하면 빌드하는 동안 알 수 없는 에러를 만나는 게 아니라 쉽게 에러를 정의하고, 빌드 파일을 작성하면서 할 수 있는 잠재적인 실수를 조기에 찾을 수 있다.

이 기능이 제대로 동작하는지 보기 위해 build.xml에 project 태그로 시험해보자. default 타깃 값에 빌드 파일에 존재하지 않는 타깃 이름을 입력한다. project 태그에 빨간색의 물결 모양의 표시가 밑줄로 표시된다. 마우스를 이 표시 위에 두면, 창이 뜨고, 기본 타깃이 해당 프로젝트에 존재하지 않는다고 조언해준다. 빨간X 아이콘은 표시의 좌측에 나타난다.

그림 10. 에러를 보여주는 앤트 편집기

또한 편집기 창의 오른쪽에 나타나는 막대도 알아두자. 이 막대는 파일의 모든 에러와 경고를 보여준다. 파일에 에러나 경고가 나타나자마자, 빨간색과 노란색에 대응되는 막대가 적절한 위치에 위치하게 된다. 나타난 표시를 클릭하면 에러가 발생한 위치로 이동할 수 있다. 이 기능은 현재 파일에 발생한 수많은 에러와 경고 사이를 쉽게 이동할 수 있게 해주므로 효과적인 검토를 가능하게 해준다. 그리고 파일에 에러가 발생하면 나타나는 오른쪽 막대의 상단에 있는 사각형이 빨간색으로 변경된다. 그러므로 단순히 사각형만 봐도 파일이 정확하게 작성되었는지를 즉시 판단할 수 있다.

다음 과정을 거쳐 앤트 편집기가 문제를 다루는 방법을 변경할 수 있다.

1. Window > Preferences 클릭.
2. Ant를 클릭 선택하고, 다음으로 Editor를 선택
3. Preferences 창에서 Problems 탭을 클릭(그림 11).
   
   
   그림 11. 앤트에서 문제를 나타내는 방법 설정하기
   
   
   
4. 옵션을 선택한다. Ignore all buildfile problems 체크박스를 선택해 모든 에러 체크 기능을 사용하지 않을 수 있다. 기본적으로 이클립스는 모든 앤트 빌드 파일을 XML 파일로 간주하며, 그 중에서 에러를 찾으려고 시도한다. 그렇지만 몇몇 XML 파일에서 에러 체크를 원하지 않는다면, Names 박스에 그 파일의 이름을 넣어주면 된다.
   
   Names 박스 밑에는 앤트 편집기가 찾을 수 있는 에러의 종류를 볼 수 있고, 각각에 대해 간단한 몇 가지 수준-Ignore, Warning, Error-을 설정할 수 있다. 이 목록에서 Warning을 선택하면 잠재적인 문제를 만들 수 있는 중요한 코드의 에러 유형을 숨길 수 있다. Error를 선택하면 코드의 명확하게 정의되어 있는 몇몇 문제에 맞추어 문제 유형을 지시할 수 있다. 코드를 작성하는 동안에 많은 문제들이 반환되는 문제가 발생하면, 일단 Ignore로 변경해 작업할 수 있지만 추천하지는 않는다.

주의: 막대 또한 동일성 표시하기 기능과 함께 작동될 수도 있다. 동일성 표시하기 기능을 활성화하고, 타깃 이름을 클릭해 보자. 막대는 이를 참조하는 각각의 참조 값의 위치에 대응돼 노란색으로 표시된다. 참조하는 곳으로 이동하려면 표시를 클릭하자.

빌드 파일 이동하기

이클립스에서는 방대한 양의 빌드 파일 내에서 쉽게 이동할 수 있게 도와주는 몇 가지 방법을 제공한다. 하이퍼링크를 포함하는 예제나 기능키 네비게이션뿐만 아니라 Outline과 Ant 두 가지 뷰를 제공한다.

하이퍼링크와 기능 키 이동

Ctrl 키를 누르고 타깃이나 속성 이름 위에 마우스를 올려보자. 그러면 이 이름이 하이퍼링크로 변한다(그림 12). 이 하이퍼링크를 클릭하면 해당 타깃이나 속성의 선언부로 이동한다.

그림 12. 타깃의 참조가 하이퍼링크로 변함

또한 F3 키를 눌러도 타깃이나 속성의 선언부로 이동할 수 있다. General 탭을 열고, Keys를 연 다음 key preference 페이지에 접근해 단축키를 변경할 수 있다.

Outline 뷰

이름에서 추측할 수 있는 것처럼, Outline 뷰는 빌드 파일 전체의 개요를 보여준다(그림 13). Outline 뷰를 이용해 파일에 정의되어 있는 모든 타깃과 속성을 쉽게 볼 수 있다. Internal target과 Public target은 아이콘이 달라 둘의 차이를 쉽게 구별할 수 있다. 기본 타깃도 선택할 수 있다. 특정 타깃을 보기 위해 확장하면, 그 안에 있는 모든 작업들을 볼 수 있다. Outline 뷰에 있는 어느 요소든 클릭해 직접 이동할 수 있다. 이 뷰는 뷰 상단에 몇 개의 버튼을 갖고 있다. 항목을 정렬하거나 Internal target, 속성들, 임포트한 요소들(imported elements)와 최상위 수준의 요소(top-level element)들을 숨기는 필터 기능을 사용할 수 있다.

그림 13. Outline 뷰

Outline 뷰에서 타깃을 실행하고 디버그할 수도 있다. 그렇게 하려면 Outline 뷰에서 타깃을 오른쪽 클릭을 하고 Run As (or Debug As) > ANT Build를 클릭한다.

Ant 뷰

많은 경우에 한 사람이 다수의 프로젝트에서 다수의 스크립트로 작업을 하게 된다. 그래서 Navigator나 Package Explorer 뷰로 빌드 파일을 추적하거나 외부 툴의 툴바 리스트를 통해 힘들게 작업하기보다는, 보기 어렵게 흩어져 있는 내용을 보기 쉽게 유지하기 위해 이클립스 Ant 뷰를 사용하자(그림 14).

그림 14. Ant 뷰

우선 Window > Show View > Other > Ant > Ant 순으로 클릭해 들어가서 Ant 뷰를 열자. Ant 뷰는 처음 열 때는 공백으로 되어 있기 때문에, 반드시 빌드 파일을 추가해야 한다. + 버튼을 클릭해 창을 열면, 해당 워크스페이스의 프로젝트에 있는 빌드 파일을 선택할 수 있다. 빌드 파일을 선택하고, Run을 클릭하거나 타깃에서 마우스 오른쪽을 클릭하고 Run as > Ant Build를 선택함으로써 타깃을 실행할 수 있다.

앤트의 검색 기능을 사용해 빌드 파일을 추가할 수도 있다. 툴바에서 Flashlight 아이콘을 클릭하면, 창이 뜨고, 검색을 위한 파일 이름을 정의할 수 있다. 특정 문자열이나 문자를 위한 공통의 파일 이름에는 *(별표)나 ?(물음표) 같은 특수 문자를 사용하자. 예를 들어, build로 시작하는 모든 XML 파일 이름과 일치하는 것을 찾으려면 build*.xml을 입력하면 된다. Include buildfile containing errors 체크 박스를 선택하지 않았다면, 에러를 포함하고 있는 파일은 검색되지 않는다. 마지막으로 전체 워크스페이스에서 검색했든지, 작업 단위(working set)에서 검색했든지 간에 관계 없이 빌드 파일을 선택할 수 있다.

Ant 뷰에서 파일을 제거하려면, 빌드 파일을 선택하고 Remove를 클릭하면 된다. Remove All을 클릭하면 모든 뷰가 제거된다.

위로

Ant 뷰와 Outline 뷰의 차이점

Ant 뷰를 처음 보는 많은 사람들은, 이 뷰가 다수의 파일 관리를 위한 Outline 뷰라고 잘못 생각한다. 그러나 이 두 개의 뷰 사이에는 약간의 미묘한 차이점이 존재한다. Outline 뷰가 현재 파일에서 이동을 돕기 위해 고안된 것에 반해, Ant 뷰는 워크스페이스 전체에 흩어져 있는 다수의 빌드 스크립트에서 다수의 타깃을 실행하고 디버깅하는 것을 관리하기 위해 고안되었다.

이 기본적인 차이점은 두 개의 뷰에서 제공되는 특징(기능)을 자세히 들여다 보면 좀 더 명확해진다.

• Ant 뷰에는 다수의 파일을 추가할 수 있지만, Outline 뷰는 단지 현재 파일의 요약 정보만 보여준다.
• Outline 뷰에서 타깃을 더블 클릭하면 편집기에서 해당 타깃의 선언부로 이동하지만, Ant 뷰는 실제 타깃을 실행한다.
• Ant 뷰는 속성을 “실행”할 수 없기 때문에 속성이나 최상위 수준의 요소를 보여주지 않는다.
• Outline 뷰와 Ant 뷰 둘 다 공개하지 않은 모든 타깃을 숨길 수 있는 Hide internal targets 버튼을 포함하고 있지만, 두 개의 뷰는 서로 다른 목적으로 이 버튼을 사용한다. Outline 뷰에서는 이 버튼을 뷰를 분류해 보기 위한 또 다른 방법으로만 제공하지만, Ant 뷰에서 이 버튼을 제공하는 이유는 퍼블릭 타깃만을 실행할 때 뷰에서 내부적인 타깃을 숨기는 것이 합리적이기 때문이다.

위로