반응형
top 이미지
date   지난 뉴스레터 보기
hot clip

LAMP 시스템 조율, Part 2: 아파치와 PHP 최적화
hot clip 이미지 LAMP(Linux, Apache, MySQL, PHP/Perl) 아키텍처를 활용하는 응용 프로그램이 끊임없이 개발되고 배포되고 있습니다. 기사 셋으로 이뤄진 이번 연재물은 응용 프로그램 성능을 향상시킬 서버 환경 설정 항목을 다룹니다. 두 번째 기사에서는 아파치와 PHP 컴포넌트를 최적화하는 방법에 초점을 맞춥니다.

로컬 컨텐츠
2008년 4월 TOP 10 기술자료가 업데이트 되었습니다.
소프트웨어 사용성 확보를 위한 몇 가지 방안 dW Column
젊음을 가치와 성장에 투자하기 dW interview
XML on HTTP, Part2: XML 문서의 대용량 처리 기법(1) Open dW
동북아시아 지역 근대화의 상징, 서구호텔 dW Column
[기획기사] 리눅스 철통 보안

SW 다운로드
IBM Lotus Quickr 8.0
Rational AppScan Standard Edition V7.7
Rational Software Analyzer Developer Edition V7.0
WebSphere Extended Deployment Compute Grid V6.1

기술자료 & 튜토리얼
지속적인 통합 안티 패턴, Part 2
프로세스 관리 기법
시맨틱 웹 사이트 계획하기
리눅스 파일 시스템 분석
CSS float 속성 이해
SOA로 변형하기 Part 3
Groovy Server Pages로 뷰 변경하기
UID와 GID 변경하기
Ajax에서 XML 처리하기, Part 1
LAMP 시스템 조율, Part 3
셀/B.E. 컨테이너 가상화, Part 2
Purify 도구와 보고 커스터마이징
오픈도큐먼트(OpenDocument) 소개튜토리얼
Lex와 Yacc을 이용하여 구문 분석기 만들기튜토리얼

공지사항
맞춤형 RSS 이벤트 : 내 블로그, dW를 품다!!
매주 업데이트되는 dW 기사를 자신의 블로그에서 볼 수 있다면 어떨까요? 그것도 보고 싶은 기사만 골라서 말이죠. 그 동안 잘 알려지지 않았지만 dW에 숨겨져 있던 이 기능을 소개합니다. 스크린캐스트를 따라 하면 누구나 구글 애드센스 달듯이 자신의 블로그에서 dW 기사를 볼 수 있습니다. 당연히 블로그 방문자들에게도 유익하겠죠.
 
Academic Initiative 배너
 
dW 커뮤니티 배너
 
기획기사 배너
 
SOA Sandbox 배너
 
dW 컬럼 배너

반응형
세계는 나의 한계이며, 나의 한계는 언어의 한계이다.”     - 비트겐슈타인

최근 그 어느 때보다도 다양한 언어에 대한 관심이 높아지고 있습니다. 자바는 JRuby, 그루비(Groovy), 스칼라(Scala) 등을 통해 언어를 넘어 플랫폼으로 발전하고 있고, 닷넷은 CLR(Common Language Runtime), DLR(Dynamic Language Runtime)을 통해 다양한 언어를 지원하고 있습니다. 또한 동적 언어와 함수형 언어에 대한 관심도 뜨겁습니다.

이번 문제는 단순합니다. 초보자 책에서도 흔히 볼 수 있는 도형 그리기 문제입니다. 하지만 익숙한 문제를 익숙하지 않은 언어, 익숙하지 않은 방법을 사용해 해결해 보면 어떨까요? 자바, C#, 루비, 파이썬, 자바스크립트, 그루비, Erlang, 스칼라, ML, 해스켈(Haskell), 리스프, Io, 펄 등 다양한 언어를 이용해 다양한 방법으로 프로그램을 작성할 수 있을 것입니다.
  • 의도적으로 디자인 패턴을 마음껏 사용해 보는 것은 어떨까요?
  • 루비 등의 오리 타입(Ducking Type)을 한번 써보세요. 타입으로서 인터페이스는 과연 어떤 의미를 지니고 있는 것일까요?
  • 함수형 언어를 이용해 작성하면 프로그램이 어떤 모습이 될까요?
  • 자바스크립트로는 어떻게 프로그램을 구조화할 수 있을까요, 클래스 상속을 사용할까요, 프로토타입 기반 상속을 사용해 볼까요?

제가 자바로 작성해 본 간단한 예제가 있습니다. 어떤 언어, 어떤 방법도 좋습니다. 다양한 언어의 상상력에 여러분의 상상력을 더해 주세요.

마지막으로 여러분이 작성한 코드를 공유해 주세요. 블로그에 작성한 코드를 정리한 후, http://innolab.tistory.com/1173513751에 댓글이나 트랙백을 남겨주시거나 이메일(dwkorea@kr.ibm.com)로 보내주시면 됩니다. 창의적인 코드를 보내주신 분에게는 일정 기간에 한 번씩 선물도 드릴 예정입니다.



 
 



   
   
     
   
Listing 1. Shape.java
package codekata;

public interface Shape {
	public void draw();
	public void moveTo(int x, int y);
	public void moveBy(int dx, int dy);
}
 

Listing 2. AbstractShape.java
package codekata;

public abstract class AbstractShape implements Shape{
	protected int x;
	protected int y;
	
	public void moveTo(int x, int y){
		this.x = x;
		this.y = y;
	}
	
	public void moveBy(int dx, int dy){
		this.x += dx;
		this.y += dy;
	}
	
	public String toString(){
		return "[X : " + x + " Y : " + y + "]";
	}
}
 

Listing 3. Rectangle.java
Package codekata;

public class Rectangle extends AbstractShape{
	private int width;
	private int height;

	public Rectangle(int x, int y, int width, int height){
		this.x = x;
		this.y = y;
		this.width = width;
		this.height = height;
	}
	
	@Override
	public void draw() {
		System.out.println("Drawing Rectangle - " + this.toString());
	}
	
	public String toString(){
		return super.toString() + " [Width : " + this.width + ", Height : " + this.height + "]";
	}

	public int getWidth() {
		return width;
	}

	public void setWidth(int width) {
		this.width = width;
	}

	public int getHeight() {
		return height;
	}

	public void setHeight(int height) {
		this.height = height;
	}
}
 

Listing 4. Circle.java
Package codekata;

public class Circle extends AbstractShape{
	private int radius;
	
	public Circle(int x, int y, int radius){
		this.x = x;
		this.y = y;
		this.radius = radius;
	}

	@Override
	public void draw() {
		System.out.println("Drawing Circle - " + this.toString());
	}
	
	public String toString(){
		return super.toString() + " [Radius - " + this.radius + "]";
	}

	public int getRadius() {
		return radius;
	}

	public void setRadius(int radius) {
		this.radius = radius;
	}
}
 

Listing 5. Test.java
Package codekata;

public class Test {
	private static void doPolymorphicOp(Shape shape){
		shape.draw();
		shape.moveBy(10, 20);
		shape.draw();
		shape.moveTo(100, 130);
		shape.draw();
	}
	
	public static void main(String[] args) {
		Shape[] shapes = new Shape[]{new Rectangle(0, 0, 10, 15), new Circle(10, 10, 5)};
		
		for (Shape shape : shapes) {
			doPolymorphicOp(shape);
		}
	}
}
 
반응형

알고리즘은 아랍의 수학자 알콰리즈미 ( al-Khw ā rizm ī ) 의 이름에서 유래한 것으로 유한한 단계를 통해 문제를 해결하기 위한 절차나 방법을 말합니다. 쉽게 말해 어떤 문제를 해결하기 위해 사용 가능한 방법이란 뜻이죠. 여러분이 어떤 문제를 프로그래밍 언어를 통해 해결해 냈다면, 그 문제를 해결할 수 있는 한 가지 알고리즘 ( 문제 해결을 위한 절차 ) 을 찾아냈다고 보셔도 됩니다.

퀴즈 1. 프로시저 Both 를 완성해 봅시다.

우선 한 가지 문제를 해결해 볼까요? Listing 1 은 두 ArrayList 데이터 내에서 공통 원소만을 뽑아 모으는 프로시저, either 를 자바 언어를 이용해 만든 것입니다. 만일 두 ArrayList 내의 모든 원소를 합쳐 모으는 프로시저, both 가 필요하다면 어떻게 하면 좋을까요?

Listing1. FirstQuizSet
import java.util.*;
  public class FirstQuizSet {
    public static ArrayList both(ArrayList xs, ArrayList ys) {
      // TODO: 이 곳을 채우는 문제입니다.
    }

  public static ArrayList either(ArrayList xs, ArrayList ys) {
    ArrayList eitherList = new ArrayList();
    Object y = null; Iterator elems = ys.iterator();
    while (elems.hasNext()) {
      y = elems.next();
      if (xs.contains(y)) eitherList.add(y);
    }
    return eitherList;
  }

  public static ArrayList toArrayList(int[] xs) {
    ArrayList ys = new ArrayList();
    for (int i = 0; i < xs.length; i++) ys.add(new Integer(xs[i]));
    return ys;
  }

  public static void main(String[] args) {
    int[] xVec = { 1, 3, 4, 5, 6, 9, 7 };
    int[] yVec = { 4, 5, 8, 9, 10, 15, -1 };
    ArrayList xs = toArrayList(xVec); ArrayList ys = toArrayList(yVec);
    System.out.println( both(xs, ys) ); System.out.println( either(xs, ys) );
  }
}


Listing 1 의 실행 결과 예시
[1, 3, 4, 5, 6, 9, 7, 8, 10, 15, -1] ß both 의 실행 결과
[4, 5, 9] ß either 의 실행 결과

첫 번째 퀴즈인 both 를 해결하셨나요? 실행 결과는 제대로 나오구요? 축하드립니다.


 
 


퀴즈 2. 수행 속도를 높인 fastEither 를 만들어봅시다.

저는 부산 토박이라 서울에서 차를 몰고 어디로 이동해야 하는 상황이라면 항상 네비게이션의 힘을 빌립니다. 그런데 제가 사용하는 네비게이션은 항상 큰길 중심으로 길을 찾아줘서, 지름길을 알고 나면 그 동안 다녔던 길이 비효율적이였던 적이 많더군요. 20 분이면 도착할 거리를 50 분이나 걸려서 다녔던 적도 있습니다.

이처럼 목적지를 향해 가는 길은 하나만 있는 것이 아닙니다. 여러 가지 대안이 존재하기 마련이고, 각 대안마다 나름대로 장점과 단점이 있습니다. 그러므로 단지 그 문제를 해결했다고 해서 만족하는 것은 올바른 프로그래머의 자세가 아니라고 생각합니다. 좀 더 고급 개발자로 올라서려면 원하는 품질을 확보했느냐를 따져보는 습관이 중요합니다.

이번 문제에서 요구되는 품질이 성능이라고 가정해 봅시다. 성능을 중요하게 여기는 문제라면, 위에서 샘플 코드로 소개한 either 프로그램은 만족스럽지 않은 답입니다. 샘플 코드에서 xs 와 ys 가 이미 오름차순으로 정렬되어 있다고 가정하면 훨씬 빠른 프로시저를 만들 수 있기 때문입니다.

아래는 이 아이디어에 바탕을 두고 both 를 개선한 fastBoth 입니다. 같은 방식으로 fastEither 도 한번 만들어보세요. 물론 더 빨리 실행될 수 있도록 하는 아이디어가 생각났다면, 그 방식으로 구현해도 좋습니다.

Listing 2. FastEitherQuiz
public class FastEitherQuiz {
  public static ArrayList fastEither(ArrayList xList, ArrayList yList) {
    // TODO: 이곳을 채우는 문제입니다.
  }

  public static ArrayList fastBoth(ArrayList xList, ArrayList yList) {
    ArrayList bothList = new ArrayList();
    final int xSize = xList.size(); final int ySize = yList.size();
    Comparable x, y;
    int order; int xpos, ypos;
    xpos = ypos = 0;
    while ( xpos < xSize && ypos < ySize ) {
      x = (Comparable)xList.get(xpos); y = (Comparable)yList.get(ypos);
      order = x.compareTo(y);
      if (order == 0) {
        bothList.add(x); // or y
        ++xpos; ++ypos;
      } else if (order < 0) {
        bothList.add(x); ++xpos;
      } else {
        bothList.add(y); ++ypos;
      }
  }
  if (ypos == ySize) bothList.addAll( xList.subList(xpos, xSize) );
  else bothList.addAll( yList.subList(ypos, ySize) );
  return bothList;
  }

  public static void main(String[] args) {
    int[] xVec = { 1, 3, 4, 5, 6, 9, 7 };
    int[] yVec = { 4, 5, 8, 9, 10, 15, -1 };
    Collections.sort( xs ); Collections.sort( ys );  // 먼저 정렬을 한 다음,
    System.out.println( xs ); System.out.println( ys );
    System.out.println(fastBoth(xs,ys)); System.out.println(fastEither(xs,ys));
  }
}


Listing 2 의 실행 결과 예시
[1, 3, 4, 5, 6, 7, 9] ß xs 의 내용 
[-1, 4, 5, 8, 9, 10, 15] ß ys 의 내용 
[-1, 1, 3, 4, 5, 6, 7, 8, 9, 10, 15] ß fastBoth 의 결과 
[4, 5, 9] ß fastEither 의 결과 


다 완성했다면 얼마나 빨라졌는지 반드시 확인해야 합니다. 작성한 코드의 수행 속도를 계산할 수 있는 코드는 다음과 같습니다 ( 즐겨 사용하는 프로파일러가 있다면 해당 프로파일러를 사용해도 좋습니다 ). 과연 여러분이 기대한 만큼 성능이 향상됐나요? 그렇다면 이전 코드에 비해 몇 % 의 성능 향상을 얻으셨나요?


Listing 3. 작성한 코드의 수행속도 계산
long start = System.currentTimeMillis(); 
// 시간을 잴 코드
long end = System.currentTimeMills();long time = end-start;


이러한 성능 최적화를 수행할 때 주의해야 할 점이 몇 가지 있습니다.

1. 최적화가 필요하다고 확인되지 않았다면 코드를 최적화하지 않는 것이 좋습니다. 최적화에 투입하는 개발자의 노력 역시 중요한 자원이기 때문입니다. 그리고 무작정 “ 이 부분이 느린 것 같으니까, 이렇게 고치면 빨라질 거야 ” 라는 막연한 생각으로 덤벼 들면 안 됩니다. 직접 수행 시간을 확인하거나, 프로파일러를 통해 성능 개선이 필요한 부분을 점검하고, 성능 개선 목표를 정하고, 적용한 기법이 기대한 효과를 얻어 내는지 확인해야 합니다.

2. 최적화를 매우 신중하게 끝맺지 못했다면 버그가 있을 수 있습니다. 그러므로 수정한 코드가 정상적으로 동작함을 반드시 테스트해야 합니다. 늦더라도 정확하게 동작하는 코드가, 빠르면서 버그 있는 코드보다 나은 법입니다.

3. 무작정 빠른 코드를 만들기 위해 전체적인 설계를 깨트리는 일이 있어선 안 됩니다. 사소한 성능 이득을 취하기 위해, 설계 과정에서 고치거나 다루기 쉬운 구조로 잡아놓은 프로그램의 틀을 스스로 깨버려야 한다면, 잃는 것과 얻는 것을 면밀히 검토해야만 할 것입니다. 이런 불행을 피하기 위해서는 설계를 튼튼히 하는 수 밖에 없습니다. 개발 초기에 프로그램 설계나 자료구조, 알고리즘 선택에 집중하게 되면, 정작 코드를 더 빠르게 돌아가도록 고쳐쓸 때, 훨씬 더 쉽게 적은 비용으로 코드 수정이 가능하게 됩니다.

4. 유행하는 기법이나 잘 알려진 속설에 의존하기보다, 스스로 주어진 환경에서 검증된 결과를 믿어야 합니다. 비어있는 메서드나 죽은 코드 없애기, 압축 연산자 사용하기, 반복문에서 불변 코드 빼내기, 반복문 펼치기, String 대신 StringBuffer 사용하기, 어떤 수준의 컴파일 최적화 옵션 사용하기 등 잘 알려진 최적화 기법들이 과연 내가 사용하는 환경에서도 적용될까요? 어떤 기법들은 컴파일러가 알아서 해주는 것을 불필요하게 작업한 것도 있을 것이고, JVM 기술이 발전하면서 오히려 역효과가 나는 것도 있으며, 언어의 버전이 올라가면서 더 나은 최적화 기법이 고안된 경우도 있을 겁니다. 결국 제대로 된 최적화 작업을 수행하기 위해서는, 유연하고, 확장성이 쉬운 구조로 프로그램의 틀을 만드는 큰 관점의 시각과 런타임 최적화 원리나 VM 의 클래스 로딩 절차, 각종 최적화 기법과 그 적용 범위 등을 깊이 있게 이해하는 작고 깊이있는 관점의 시각이 균형감있게 제공되어야 할 것 같습니다.

이처럼 프로시저나 함수 수준에서 해결해야 할 문제라고 하더라도, 성능이라는 한 가지 주제가 더해지면 많은 생각을 하게 되는 문제로 바뀝니다. 데이터나 객체 수준으로 추상화 수준이 올라가고, 고려해야 할 품질 속성이 더 많아지면 그 복잡성이란 이루 말할 수 없겠죠? 그래서 프로그래머란 직업이 평생 학습과 훈련을 반복해야 하는 고된 전문직이라 말할 수 있는 게 아닐까요?

비슷한 유형의 퀴즈 두 개를 더 풀어보는 것으로 이번 연재를 마무리하겠습니다.



 
 


퀴즈 3. isSubstring 을 작성해 봅시다.

세 번째 퀴즈는 두 개의 배열을 받아 왼쪽 배열에 들어있는 문자열이 오른쪽 배열에 포함되어 있는지 검사하는 프로그램, isSubstring 을 작성하는 것입니다.

Listing 4. PatternTest
public class PatternTest {
  public static boolean isSubstring(char[] left, char[] right) { ... }
  public static void main(String[] args) {
    char[] first = { ’a’, ’b’, ’c’ };
    char[] second = { ’a’, ’c’, ’b’, ’c’};
    char[] third = { ’a’, ’a’, ’b’, ’c’};
    isSubstring( first, second ); // false
    isSubstring( first, third ); // true
  }
}



   


퀴즈 4. 프로시저 match 를 작성해 봅시다.

네 번째 퀴즈는 문자열이 들어있는 배열을 받아 열고 닫는 괄호 문자가 짝이 맞는지 검사하는 프로시저 match 를 작성하는 것입니다. 괄호 이외의 문자는 무시하도록 합니다.

Listing 5. MatchTest
public class MatchTest {
  public static boolean match(char[] cs) { ... }
  public static void main(String[] args) {
    char[] first = { ’(’, ’[’, ’<’, ’{’, ’}’, ’>’, ’]’, ’)’ };
    char[] second = { ’(’, ’[’, ’<’, ’{’, ’>’, ’}’, ’]’, ’)’ };
    char[] third = { ’(’, ’a’, ’c’, ’)’, ’[’, ’{’, ’}’, ’]’ };
    match(first); // yes
    match(second); // no
    match(third); // yes
  }
}

자신이 알고 있는 언어의 특성을 마음껏 발휘해 다양한 해답을 만들어 보는 것도 흥미로울 것 같습니다. C 나 리스프 (LISP), 파이썬, 자바스크립트, Haskell, 펄 (Perl), C#, 자바 등이 그 대안이 될 수 있겠죠? 두 가지 이상의 언어를 알고 있다면 두 개의 문제를 각각 다른 언어로 해결하고, 그 언어가 가지는 표현력과 특징이 문제를 해결하는 데 어떤 영향을 나에게 끼치고 있는지를 실험해 보기 바랍니다. 다양한 언어를 다룸으로써 그 언어가 제공하는 패러다임을 경험한 만큼 내 사고가 유연해진 것을 느낄 수 있을 겁니다.

마지막으로 여러분이 작성한 코드를 공유해 주세요. 블로그에 작성한 코드를 정리한 후, 제 블로그에 댓글이나 트랙백 (http://seal.tistory.com/trackback/150) 을 남겨주시거나 이메일 (dwkorea@kr.ibm.com) 로 보내주시면 됩니다. 창의적인 코드를 보내주신 분에게는 일정 기간에 한 번씩 선물도 드릴 예정입니다. 적극적인 참여로 한걸음씩 같이 발전해봅시다

반응형
top 이미지
date   지난 뉴스레터 보기
hot clip

객체 지향론자를 위한 함수 프로그래밍
hot clip 이미지 이 번에 시작하는 연재에서는 함수와 객체 지향 기법을 혼합한 JVM을 위한 프로그래밍 언어인 스칼라를 소개합니다. 언어 소개와 함께 동시성(concurrency) 등 굳이 스칼라를 배워야 하는 이유를 설명하고, 스칼라를 얼마나 빨리 써먹을 수 있는지를 살펴봅니다.

로컬 컨텐츠
테러리스트에서 버그까지 dW Column
루비 메타프로그래밍 part 2 : eval 메서드 Open dW
코드 트레이닝 part 2 - 알고리즘과 성능Special Issue
오픈 소스로 재미 이상의 가치를 전달하기 dW interview
[기획기사] 동적인 언어를 동적으로 호출하기

SW 다운로드
Rational Developer for System z 시험판
Lotus Forms V3.0.1 업데이트
WebSphere Business Modeler Advanced V6.1.1 업데이트
Lotus Domino 8 시험판
DB2 Express-C 9.5 무료 제품

기술자료 & 튜토리얼
리눅스 네트워킹 스택 분석
E4X와 Prototype으로 구현하는 Ajax 스무고개 게임, Part 2
클래스 동작
LAMP 시스템 조율, Part 1
메모리 디버깅 기법
IBM Lotus Expeditor에서 안전한 웹 서비스 개발하기
Ajax와 딜리셔스(del.icio.us)로 자신만의 정보 공간을 만들자튜토리얼
셀/B.E. 컨테이너 가상화, Part 1
LAMP 시스템 조율, Part 2
javax.tools를 이용한 동적 애플리케이션 생성
메모리 프로그래밍을 개선하자
이클립스 플러그인이 OSGi에서 어떻게 동작하는지 이해하기
IBM Information Server를 사용한 SAP NetWeaver Business Intelligence와 데이터 통합
이클립스로 비즈니스 프로세스 실행하기튜토리얼

공지사항
초보 개발자 코드 트레이닝
dW 스페셜 이슈에서는 독자들이 정답이라는 압박에서 벗어나 창의력 있게 문제를 풀 수 있는 기회를 제공합니다. 프로그래밍 기술을 향상시킬 수 있는 문제 풀이에 적극 참여해보세요.
 
Academic Initiative 배너
 
dW 커뮤니티 배너
 
기획기사 배너
 
SOA Sandbox 배너
 
dW 컬럼 배너

뉴스레터 추천하기
하단 배너
반응형
반응형
top 이미지
date  
hot clip

PHP로 사용자 정의 가능한 RSS 피드 수집기 구현하기
hot clip 이미지 이 기사에서는 사용자 정의 가능한 RSS 피드 수집기를 구현해 봅니다. 완전히 돌아가는 PHP 코드를 제공하고, RSS 피드 수집기 수정을 위한 서버측 PHP 함수 사용법도 소개합니다.

로컬 컨텐츠
혼성 기술들 속에서 방향과 질서 부여하기 - 이해일 dW Interview
고전 탐험 2탄: 유닉스 프로그래밍 서적 - 박재호 dW Column
개발자 코드 트레이닝, Part 1 Special Issue
루비 메타프로그래밍, Part 1 dW CoD
[기획기사] End-to-end Ajax 애플리케이션 개발

SW 다운로드
Rational Developer for System z 시험판
Lotus Forms V3.0.1 업데이트
WebSphere Business Modeler Advanced V6.1.1 업데이트
Lotus Domino 8 시험판
DB2 Express-C 9.5 무료 제품

기술자료 & 튜토리얼
리눅스 커널 해부
HTML 5에 추가된 새로운 요소
Thinking XML: 파이어폭스 2.0과 XML
AIX 6.1 최적화와 성능 튜닝
Grails 마스터하기: GORM: 재미있는 이름, 진지한 기술
애셋 기반 개발을 SOA에 있는 서비스에 적용하기, Part 2
리눅스 팁: cron과 at를 사용한 작업 일정 관리
JSF, CSS, 자바스크립트를 사용하는 정교한 Ajax 애플리케이션 Part 1
코드 품질 향상을 위해 : 행위 주도 개발의 모험
시스템 관리자 툴킷 : 전자편지를 위한 스팸과 바이러스 필터링
IBM Lotus Sametime과 IBM Lotus Connections REST 서비스 통합하기
DB2 Change Management Expert, Part 2
다중 유닉스 플랫폼을 위한 소프트웨어 작성튜토리얼
OLPC 랩톱 애플리케이션 개발튜토리얼

 
 
 
 
 
 

반응형

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 퍼스펙티브의 모습이다.


그림 1. Eclipse Debug 퍼스펙티브의 뷰
Eclipse Debug 퍼스펙티브의 뷰

자바 프로그램 디버깅

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


그림 2. 디버거 설정 시 프로젝트의 메인 자바 클래스 설정하기
디버거 설정 시 프로젝트의 메인 자바 클래스 설정하기

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

중단점 설정하기

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


그림 3. 에디터의 왼쪽 부분에 있는 두 개의 중단점 마커
에디터의 왼쪽 부분에 있는 두 개의 중단점 마커

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


그림 4. 왼쪽 여백에 화살표로 현재 실행되고 있는 것을 보여주고 있다.
왼쪽 여백에 화살표로 현재 실행되고 있는 것을 보여주고 있다.

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


그림 5. Breakpoints 뷰
Breakpoints 뷰

조건적 중단점

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


그림 6. 조건적 중단점 트리거 설정하기
조건적 중단점 트리거 설정하기

식 계산하기

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


그림 7. Inspect 옵션을 이용하여 식 계산하기
Inspect 옵션을 이용하여 식 계산하기

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

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


그림 8. Display 뷰
Display 뷰

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


그림 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에 달려있다.


그림 10. 원격 디버깅 세션을 위한 연결 프로퍼티 설정하기
원격 디버깅 세션을 위한 연결 프로퍼티 설정하기




위로


다른 언어 디버깅 하기

자바가 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)


그림 11. PHP 디버거
PHP 디버거




위로


결론

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




위로


감사의 말

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



참고자료

교육

제품 및 기술 얻기

토론
  • 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 뷰에서도 중단점을 비활성화로 변경할 수 있다. 비활성화된 중단점은 하얀색 공 모양으로 표시된다. 자바의 중단점과 달리 카운트를 세거나 중단점에 상태를 줄 수 없다는 점-앤트 파일을 디버깅할 때는 결국 필요 없다-을 주의하자.


그림 15. 빌드파일 라인에 중단점 설정
빌드파일 라인에 중단점 설정



위로


빌드 파일 디버깅

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

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


그림 16. 빌드 파일에서 줄별로 한 단계씩 진행하기
빌드 파일에서 줄별로 한 단계씩 진행하기

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

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

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

그림 17. 모든 속성을 보여주는 Variable 뷰
모든 속성을 보여주는 Variable 뷰

자바 디버거와는 달리, 앤트 디버거는 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 탭
    Refresh 탭

  9. 체크 박스에서 Refresh resources upon completion을 선택하자. 탭 아래에 있는 옵션을 선택할 수 있게 되었다. 얼마나 많은 workspace가 Refresh될 것인지 이클립스에 정해주자. Workbench를 계속 빠르게 실행할 수 있도록 가능한 가장 범위가 좁은 옵션을 선택하자. 이 예제의 경우 단지 현재 프로젝트의 Refresh만 필요하기 때문에, The project containing the selected resource 옵션을 선택하자.
  10. Targets 탭을 클릭하자.


    그림 20. Targets 탭
    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. Package Explorer를 연다.
  2. Java Project에서 오른쪽 버튼을 클릭하고 New > File을 클릭한다.
  3. New File 윈도우에서 파일 이름을 build.xml로 입력한다.

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


그림 1. Buildfile 템플릿 사용하기
Buildfile 템플릿 사용하기

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

앤트 편집기

앤트 편집기의 가장 좋은 기능에는 코드 하이라이트(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 뷰에서 타깃을 실행하고 디버그할 수도 있다. 그렇게 하려면 Outline 뷰에서 타깃을 오른쪽 클릭을 하고 Run As (or Debug As) > ANT Build를 클릭한다.

Ant 뷰

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


그림 14. Ant 뷰
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 뷰에서 이 버튼을 제공하는 이유는 퍼블릭 타깃만을 실행할 때 뷰에서 내부적인 타깃을 숨기는 것이 합리적이기 때문이다.




위로

반응형

+ Recent posts