내 남자의 길~!

앤트 파일 디버깅

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

타깃 내에 중단점 설정하기

자바 파일로 작업할 때처럼, 한 단계씩 확인을 하고 싶을 때, 작업을 호출하는 타깃에 있는 라인에 중단점을 설정할 수 있다. 라인에 중단점을 넣으려면, 간단히 왼쪽에 있는 회색 바에서 더블 클릭을 하면 된다. 녹색 공이 나타나 중단점이 정해졌음을 나타낸다(그림 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 뷰에서 이 버튼을 제공하는 이유는 퍼블릭 타깃만을 실행할 때 뷰에서 내부적인 타깃을 숨기는 것이 합리적이기 때문이다.

위로

소프트웨어 개발 프로젝트뿐만 아니라, 지금 하고 있는 일의 의미와 목적에 대해 생각해 본적이 있는가? 모든 일에는 그 목적을 위해 제때 적절한 사람이 해야 할 일이 있게 마련이다.

시점의 변화
일을 하다 보면 본래 목적과 의미를 잊어버린 채 전혀 엉뚱한 이슈에 많은 시간을 낭비하는 경우가 많다(원래 목적과는 상관없는 이슈로 몇 시간씩 회의해 본 일이 있다면 쉽게 이해할 수 있지 않을까?).

지금 무엇을 하고 있는가?
소프트웨어 프로젝트의 실패 원인 중 대부분은 ‘무엇을 왜 만들고 있는가’라는 고객의 요구사항을 제대로 파악하지 못하는 데 있다. 오픈을 얼마 남기지 않은 프로젝트 중반에 고객의 수정사항은 늘어가고, 고객들은 기능적인 면보다는 화면 디자인(색이나 폰트 사이즈 등)에 더 민감한 모습을 나타낸다. 또한 대부분의 고객은 자신이 원하는 바가 무엇인지를 제대로 알지 못하지만, 고객 자신이 좋아하고 좋아하지 않는 것에 대해서는 정확하게 알고 있다.

성공적인 프로젝트를 위해서는 가장 먼저 고객의 요구사항을 적절하게 파악하는 것이 중요하다. UML 유스 케이스 다이어그램(Use Case Diagram)이나 스토리보드 등이 매우 효율적으로 사용될 수 있으며 간단한 HTML이나 RIA(FLEX etc), 혹은 4GL(VB)로 만든 기능이 없는 스토리 위주의 샘플 애플리케이션은 고객의 요구사항을 수집하는 데 매우 좋은 도구가 될 수 있다. 복잡한 비즈니스 프로세스가 있는 업무의 경우에는 BPA 등의 도구를 사용해 워크플로우를 시각화시켜 두면 복잡한 흐름을 일목요연하게 정리할 수 있다.

이런 도구들로 수집한 요구사항에 대해 고객으로부터 확인을 받아 놓는다면(회의록에 대한 싸인이나 위의 산출물에 대한 고객 확인을 받아 놓는 것) 그 요구사항에 따라 스케줄된 일정에 새로운 변경이 이뤄졌을 경우에 합당한 개발 비용과 시간을 요구할 수 있을 것이다. 이처럼 소프트웨어 개발 프로젝트는 고객의 요구사항만 제대로 파악하고 있어도 80%는 성공한 것이다.

● TAG : 요구사항 분석, Use Case Diagram, sample software, 복잡한 비즈니스 프로세스, 워크플로우, BPA


닭 잡는데 소 잡는 칼 사용하기
모든 기술 역시 그 태생에 목적과 이유를 가지고 있다. 소프트웨어 개발에서 중요한 점 중에 하나가 현재 소프트웨어 개발 규모와 요구사항에 맞게 적절한 기술을 사용하는 것이다. 일반적으로 개발자들은 기술적인 호기심으로 인해 신기술 도입에 대한 욕심이 많다. 또한 매니저는 매니저 나름대로 신기술을 적용한 시스템이라는 ‘업적’을 원한다.

그러나 그런 기술들은 그만큼의 습득 시간과 비용을 요구한다. 예를 들어 몇 년 전 EJB 붐이 일었을 때, 많은 사이트들이 값비싼 WAS를 도입해 개발한 적이 있다. EJB는 분산 컴포넌트와 트랜잭션의 보장이 가장 큰 장점이다. 하지만 정작 이런 사이트들에서 그런 고차원적인 트랜잭션 처리가 필요한 경우는 실제 얼마나 있었을까? 그 당시 많은 사이트들이 고가의 WAS를 도입했음에도 불구하고 WAS를 단순한 JSP/Servlet 컨테이너 수준으로 밖에 사용하지 못했거나, EJB 역시 단순한 POJO식의 Business Object 이상으로 사용하지 못한 경우를 많이 봤다.

요즘처럼 JSTL, WebWork, Struts, Spring, Mapper, AOP 등과 같은 각종 오픈소스 프레임워크와 새로운 개념들이 난무하는 세상에서, 자칫하면 신기술에 대한 욕심으로 무리한 선택을 할 수도 있다. 프레임워크와 기술은 도구일 뿐이다. 아무리 좋은 도구라도 사용법을 제대로 알지 못한다면, 이런 도구들은 오히려 소프트웨어 프로젝트에 해가 될 수 있다.

그러나 한 번 더 생각해 보자. 소프트웨어 개발을 위해서는 시스템 기능과 요구사항에 적합한 적절하고 사용하기 쉬운 기술이 선택되어야 하며, 기술을 도입하는 데는 그만한 도입에 대한 비용(구입 비용뿐만 아니라 교육 및 습득에 대한 비용)이 고려되어야 한다.

● TAG : 오픈소스, 개발자와 매니저의 욕심, 도구는 도구일 뿐, 적절한 도구 사용하기

Simple is best! Easy is best!
모든 기계가 그렇듯이 복잡한 기계일수록 고장이 잘 난다. 소프트웨어도 마찬가지다. 복잡한 아키텍처일수록 문제가 생겼을 경우에 디버깅하기가 어렵고, 변경 사항이 생겼을 때 반영하기가 어렵다. 디자인 패턴으로 무장한 컨설턴트가 와서 시스템을 온통 디자인 패턴으로 도배해 놓을 수도 있다. 그렇지만 그것을 디버깅해야 하는 것은 그 컨설턴트가 아니라 개발자 여러분이다(디자인 패턴이 나쁘다는 것은 아니다. 불필요한 패턴 사용으로 시스템의 복잡도를 올리는 것에 대한 일종의 경고인 셈이다).
가능하면 시스템은 간단하게 설계하자. 고수가 설계한 시스템일수록 단순하고 고장이 적다.

좋은 기술이나 개념은 천재의 머릿속에서 나올 수 있다. 그러나 그것을 실제로 사용하는 사람은 천재가 아니라 평범한 사람들이다. 천재들의 수준에 맞춰 개발된 기술들을 과연 범인들이 쉽게 사용할 수 있을까? 인기 있게 널리 오래 사용되는 기술은 대부분 개념을 이해하기 쉽고 사용하기 쉬운 기술이다. 고수들이 만들어내는 각종 이론들로 무장한 시스템들이 아니라 오히려 이해하기 쉬운 시스템인 것이다.
 
● TAG : 간단할수록 튼튼하다. 쉬운 기술이 널리 퍼진다.

깊게 그리고 넓게
기술을 깊게 공부해야 하는 것은 당연한 이야기이지만, 지식의 깊이와 폭에 대한 균형이 필요하다. 예를 들어 소켓(Socket) 프로그래밍을 할 때, 자바의 경우 Multiplexing 성능이 떨어지기 때문에 C 언어로 MultiPlexer를 구현하고 JNI로 연결하면 훨씬 더 좋은 성능을 낼 수 있다.

화면이 많고 권한 처리가 복잡한 엔터프라이즈 솔루션의 경우에는 엔터프라이즈 포털(Enterprise Portal)과 같은 솔루션을 선택하면 시행착오를 줄이면서 양질의 소프트웨어를 만들어 낼 수 있다. SAP와 CRM 등을 통합할 때 모두가 자신이 강점을 지닌 언어로 개발할 수 있지만, 그보다 EAI 솔루션을 사용한다면 쉽고 성능 좋은 시스템 통합을 이끌어 낼 수 있다. 어느 정도 수준의 개발자라면 고객의 요구사항을 구현하는 것은 그다지 어려운 일은 아닐 것이다. 

그러나 이미 구현되어 있는 솔루션이나 오픈소스 아키텍처에 대한 지식이 있다면 처음부터 구현하는 게 아니라 그것들을 활용함으로써 주어진 시간과 비용 내에서 시행착오를 줄이고 양질의 소프트웨어를 만들어 낼 수 있다.

● TAG : 이미 있는 것들 찾아보기, 활용하기, 폭넓은 지식 가지기

마일스톤
마일스톤이란 ‘이정표’를 의미하는 것으로 프로젝트 일정 가운데 중요시점으로 생각하면 된다. 예를 들어 요구사항 분석 완료 시점, 각각 컴포넌트 완성 시점, 릴리즈 시점, 알파, 베타 테스트 시기 등이 이에 속한다.

마일스톤을 설정하는 이유는 마일스톤 전의 작업에 대한 검증을 통해 발생한 문제를 다음 단계까지 전파시키지 않기 위함이며, 요즘의 개발 방법론들이 잦은 Release와 Feed Back 등을 강조하는 것 역시 잦은 마일스톤을 설정함으로써 문제를 가능한 한 빨리 발견하고 풀어내기 위함이다(불확실성의 제거).

마일스톤이 설정된 주기는 그 각각이 전체 프로젝트에 대한 미니 프로젝트가 되며, 각 마일스톤 시 필요한 최소한의 산출물에 대한 정리와 검증(확인을 통한 문제 발견)이 뒤따라야 한다. 정확한 마일스톤을 설정한다면, 소프트웨어 개발 프로젝트에서 발생할 수 있는 위험 요소를 줄이는 데 큰 도움이 될 것이다.

나만의 도구를 갖추자
소프트웨어 개발에 있어서 IDE나 디버거(Debugger)와 같은 툴은 생산성에 지대한 영향을 준다. 개발자라면 적어도 자기가 가지고 다니는 도구 세트 하나는 있어야 하지 않을까? 여기서는 이미 많이 알려진 IDE나 디버깅(Debugging) 툴보다 소프트웨어 프로젝트에 필요한 각종 자동화 도구에 대해 간략하게 소개한다.

소스 관리
일주일 전에는 잘 돌아가던 모듈인데 일주일 동안의 작업 내용이 반영된 후에는 뭔가 문제가 생겼다. 어떻게 해야 할까? 어느 부분을 수정했는지 알 수 있다면 좀 더 빨리 문제의 원인을 밝혀낼 수 있지 않을까?

운영 중인 시스템이 새로운 코드를 반영한 후에 문제가 생겼다. 수정한 부분을 찾는 것보다 이전의 소스 코드로 원상 복귀하는 것이 운영을 정상화하는 데 더 빠르다. 그렇다면 예전에 개발한 소스는 어디에 있을까?

고객별로 릴리즈한 버전이 많은데 A 고객의 이슈를 해결한 버전은 도대체 어느 버전일까? 여러 사람이 협업 작업을 한다면 공통으로 소스 코드는 어떻게 관리해야 할 것인가? 소스를 한 곳에서 중앙 집중적으로 관리하고 협업을 가능하게 해주며 소스에 대한 변경 내역을 관리할 수 있게 해주는 것이 바로 소스 관리 시스템이다. 널리 사용되고 있는 무료 소스 관리 시스템에는 CVS와 SubVersion이 있다.

● TAG : 소스 관리, CVS, SubVersion
빌드 도구
빌드는 소프트웨어 개발에서 항상 수행해야 하는 작업이다(물론 JSP나 ASP 등의 스크립트 언어로만 개발한다면 모르겠지만). 컴파일하고 기다리고 결과가 나오면 검증하고 에러가 없으면 릴리즈(또는 배포)하고 항상 해야 하는 반복적인 작업이다.
에러가 발생하지 않는 상황이라면 특별하게 할 일도 없다. 우리가 빌드를 기다리는 것은 혹시나 있을지 모르는 에러에 대비하기 위한 것일 뿐 빌드와 배포는 커맨드들을 반복해 입력하는 단순 작업에 해당한다.

이런 단순 작업을 내가 아닌 누군가가 해준다면 그 시간에 코드를 최적화하거나 좋은 소프트웨어 구조로 리펙토링하는 등의 생산적인 작업을 할 수 있지 않을까? 그 누군가가 바로, 빌드 자동화이다. 기본적인 도구로는 make, ant, maven과 같이 커맨드들을 조합해 빌드해 주는 도구가 있고, 여기에 Daily Build (Daily Build의 중요성은 여기서 언급하지 않더라도 『조엘 온 소프트웨어』와 같은 유수의 개발 관련 서적에서 이미 충분히 언급되어 있다)나 스케줄에 따른 빌드나 Release 버전 생성을 자동으로 수행해 주는 빌드 자동화 소프트웨어가 있다. 이러한 소프트웨어들은 빌드 배포에 대한 스케줄링뿐만 아니라, 자동화된 릴리즈 버전 생성 등이 가능하고 빌드 중의 에러에 대해 담당자에게 SMS나 이메일 등으로 ALERT해 주는 기능을 가지고 있으므로, 대규모 협업 프로젝트에서 매우 유용하게 사용될 수 있다.

대표적인 공개 소프트웨어로는 Cruise Control, Ant Hill 등이 있다. Cruise Control은 Text 기반의 도구로 매우 강력한 빌드 자동화 기능을 제공하지만 Text 기반이기 때문에 다소 사용하기가 어렵다. Ant hill의 경우에는 Web UI를 제공하기 때문에 상대적으로 사용하기는 쉽지만 대신 Cruise Control과 같은 강력한 기능을 제공하기는 어렵다. 그리고 빌드 과정 중에 빌드된 컴포넌트가 제대로 작동하는지 여부를 자동으로 테스트하기 위해 JUnit과 같은 테스트 프레임워크가 있다. 빌드 자동화는 ant와 같은 빌드 도구, JUnit과 같은 테스트 도구, 그리고 Cruise Control 등과 같은 빌드 자동화 도구로 구성되고, 빌드와 릴리즈(배포)를 수행함으로써 시간 절약은 물론, 품질에 대한 향상까지 기대할 수 있다.

● TAG : ant, maven, cruise control, anthill, JUnit

테스트 도구
테스트와 QA(Quality Assurance)에 대한 중요성은 언급하지 않더라도 이미 잘 인식하고 있으리라 믿는다. 테스트의 종류에는 컴포넌트별 단위 테스트, 시나리오에 따른 기능 테스트, 적절한 용량을 커버하고 성능을 낼 수 있는지를 검증하는 부하 테스트, 그리고 장애에 대한 대처 능력을 시험하는 장애 테스트 등이 있다.
그 중에서 테스트팀이나 QA팀이 아닌 개발자들이 일반적으로 수행할 수 있는 테스트로는 컴포넌트별 단위 테스트와 부하 테스트를 꼽을 수 있다. 단위 테스트는 소프트웨어 개발 주기 중 테스트 단계에서뿐만이 아니라 개발단계 중간에서도 컴포넌트가 제작될 때마다 모듈의 기능을 검증해 버그를 예방할 수 있다.

단위 테스트는 JUnit 등의 단위 테스트를 자동화할 수 있으며, 위에서 설명한 것처럼 빌드 절차에 자동화해 포함시켜 빌드 때마다 개발한 컴포넌트 기능의 이상 여부를 검증할 수 있다. 부하 테스트는 소프트웨어의 비기능적인 요소인 성능이나 용량을 측정하는 데 사용되는데 개발자 단계의 부하 테스트를 통해 알고리즘의 최적화 여부나 과부하시에 장애(Dead Lock, Lock 대기 현상, CPU 과점유)를 검증할 수 있다.
 

● TAG : 단위 테스트, 기능 테스트, 성능 테스트, JUnit, MS Stress, JMeter, Load Runner

커뮤니케이션 도구
팀원 간의 작업 배분, 이슈에 대한 기술적인 토론, 고객의 변경된 요구사항의 반영 내용, 그리고 버그에 대한 이슈 등을 해결해 나가는 것이 개발이라고 할 수 있다. 보통 이런 이슈들은 회의나 이메일, 전화 등을 통해 이뤄지는데, 각각의 이슈에 대해 서로 이야기한 내용과 협의한 내용들에 대해 문서화해 추후에 이슈에 대해 어떻게 대처를 하고 소프트웨어 코드에 반영을 했는지를 추적해야 할 경우가 있다.

이런 이슈에 대한 추적과 커뮤니케이션을 가능하게 해주는 것이 Issue Tracking 시스템이다. 이슈를 오픈하고 관련된 사람을 추가하며 이슈에 대한 진행 상황과 중요도를 기입함으로써 현재 시스템에 대한 이슈에는 어떤 것이 있는지 알려주고, 진행되고 있는 상태를 쉽게 관리할 수 있게 해준다.

해당 이슈가 반영된 버전을 기입해 어느 버전에 문제가 있고 해결되었는지를 판단하게 함으로써 적절한 Release 버전을 판단할 수 있게 한다. 그리고 이슈가 해결되었을 때는 SubVersion과 같은 소스 관리 시스템에서 이슈를 해결한 Revision Number를 Issue Tracking 시스템에 기입해 이슈를 어떤 식으로 소스 코드에 반영했는지를 추적할 수 있게 한다. 주로 버그 관리에 많이 사용되는데, 그 외의 개발 요구사항을 반영하는 데도 응용할 수 있다. 대표적인 소프트웨어로는 BugZilla나 JIRA와 같은 소프트웨어를 들 수 있다.


● TAG : Issue Tracking System, Bugzilla, JIRA

튼튼한 소프트웨어를 만드는 관점 갖추기
마지막으로 실제 개발을 할 때 생각해야 할 것 몇 가지만을 짚고 넘어가도록 하자.

개발자는 메모리로부터 자유로울 수 없다.
자바 언어가 나오면서 개발자들은 malloc과 free(C 언어에서 메모리를 할당하는 함수)로부터 자유로워졌다. Garbage Collector라는 강력한 기능이 자동으로 메모리를 관리해 준다. 그렇다면 진정 우린 메모리에서 자유로울 수 있을까?

32비트 머신을 가정했을 때, 32비트 머신의 프로세스당 메모리 사용량은 2^32=4G이다. 여기서 유닉스의 경우는 이 가운데 2GB가 공유 메모리 영역이고 실제 자바가 사용할 수 있는 것은 2GB이다. 이 중에서 클래스(Class)나 메소드(Method)가 올라가는 Perm 영역이 대략 64~256MB이고, JVM 자체가 로딩되는 메모리 영역을 다 합하면 실제로 자바 애플리케이션의 Heap Size는 최대 1.5~1.7GB 내외이다.

그 영역 안에서도 애플리케이션이 기본적으로 꾸준히 사용되는 영역이 400~500MB라면, 일반적으로 1GB 내에서 프로그래밍을 해야 한다는 이야기다.
물론 64비트 JVM이 출시되고 GC의 성능이 좋아지면서 메모리에 대한 부담이 줄어드는 것은 사실이지만, 소프트웨어를 개발한다면 항상 메모리 사용에 대해 충분히 고려하고 시스템을 설계해야 한다.

● TAG : 메모리 신경 쓰기

성능에 대해 고민하기
성능에 대해 개발자들만큼 민감한 사람들이 또 있을까? 그렇지만 그들이 작성한 코드는 정말 최적의 성능을 낼 수 있도록 구현되어 있을까? 직접 작성한 코드를 한 두명의 유저 기반에서 테스트했을 때는 잘 돌아간다. 그렇지만 실제 환경이 여러 명의 동시 접속자를 지원하는 서비스라면? SQL 문장이나 잘못된 Synchronized 처리 등은 실제 환경이나 동시 사용자가 많지 않으면 성능에 영향을 주지 않는다.

성능에 대한 좋은 가이드와 프로그래밍 방법은 항상 고민해야 하는 문제이고, 여기에 성능에 대한 검증을 어떻게 할 것인지를 고려해 코드를 만들어야 할 것이다.
컴포넌트별로 테스트시에 Profiler나 APM-Application Performance Management Tool 등을 이용하면 도움이 되고 간단한 부하 테스트를 더한다면 성능 상에 문제가 있는 코드가 아닌지 좀 더 쉽게 검증할 수 있다. 물론 어느 정도 경험이 쌓인다면 이런 도구 없이도 코딩 시에 성능에 문제가 되는 코드의 대부분은 걸러낼 수 있을 것이다.


● TAG : 성능 고려하기, 성능 테스트, Profiler, APM
로깅 습관화
결함(Defect)이 없는 소프트웨어는 있을지 몰라도 문제(Bug)가 없는 소프트웨어는 존재하지 않는다. 그러므로 문제가 있을 때 어떻게 빨리 발견해 해결할 것인지가 중요하다. 그런 방법 중의 하나가 디버깅을 위한 로깅(LOGGING) 처리이다. 로깅은 장애나 문제가 없을 때는 그다지 소용 없는 코드이고 시간 낭비처럼 보일 수 있지만 잘 구현된 로그인(LOGGIN)은 문제 해결 시간을 줄이는 데 큰 도움을 준다. 그렇다고 로깅이 범람해서는 안 된다. 로그(LOG) 메시지도 비즈니스 로직처럼 설계가 필요하다. 적절한 로깅 설계와 반영에 대해 습관을 들이도록 하자.

● TAG : Logging, Debugging