2009/12/13

public method 변경하기

0 comment(s)

일하던 중 동료 하나가 말을 걸어 온다. 어느어느 프로젝트에서 에러가 나고 있다고. 내가 손대지도 않았는데 왜 나한테 이야기를 할까?

최근에 이런 일들이 몇 번 있었다. 그렇다고 팀원들이 정말 몰라서 그러는 것은 아니다. 오히려 그런 잘못이라면 이 프로젝트에서는 내가 처음 저질렀던 것 같다(하지만 모를 일이다).

수많은(실은 몇 안 되는) 명저들에서 본 내용 중 하나가 public method 는 함부로 고치지 말라고 했다. 혹은 신중을 기하라고 했던가. 그런 내용을 접하기 전 까지 별로 생각해 볼 수 조차 없었을 내용들인데 읽고 나서는 너무나 당연하게 생각되는 내용이라 당연히 잘 할 것이라 믿었었는데 나도 그렇고 동료들도 그렇고, 치명적인 실수를 저지르고 말았다.

동료 A 는 해당 기능을 하는 method 를 더 효율성이 높은 것으로 대체한다고 기존 것을 지웠다. 물론 본인은 충분히 확인을 한다고 하였겠지만, 문제는 그 class 가 구현된 main 프로젝트가 아니고 다른 sub 프로젝트에서 해당 method 를 참조하고 있어서 발생했다.
동료 B 는 단순히 메소드 이름을 변경하는 refactoring 을 했는데, sub project 에 그 변경이 반영되지 않았다. 상당히 신중하고 시야가 남다른 B 였기에 조금 의아했지만 결국 public 메소드에 대한 변경이 그만큼 단순한 일이 아니라는 증거일 것이다.

다들 잘못이라면 잘못을 하긴 했는데 온 세상에 널리 퍼뜨린 라이브러리도 아니고, 범위가 명확한 프로젝트 안에서 다른 참조 프로젝트에 그 변경이 반영되지 않았다는 것은 지금 쓰고 있는 eclipse 잘못인지, 너무 복잡하게 얽혀 있는 지금 프로젝트 잘못인지 모르겠다.

2009/12/04

가끔씩 보이는 '_' 는 대체 왜 쓰는 것일까?

0 comment(s)

가끔 포스터나 프레젠테이션 자료, 목차 등을 보면 '_' 를 사용한 것을 볼 수 있다. 이를테면

목적과 수단 _17
이런 식이다. 대체 왜 '_' 를 저런 곳에 사용할까? 항상 발견할 수 있지 않은 것을 보면 반드시 저렇게 사용해야 하는 것은 아닐 것이다. 게다가 어렸을 적 - 특히 컴퓨터가 지금처럼 널리 퍼지지 않았던 때 - 에는 저런 표현을 볼 수 없었던 것을 생각하면 바람직한 방향은 아닌 듯 싶다.

실제로 뭔가 만들다 만 것 처럼 보인다.

정말로 궁금하다.

2009/12/02

cURL을 사용하여 수많은 서버 상태를 확인하기

0 comment(s)

팀 내에서 일정 주기로 돌아가며 기술 관련 자유 주제를 선정하여 발표하고 있는데, 안 올 것만 같던 내 발표 순서가 돌아왔다.

새로운 주제를 찾기는 어렵고, 예전에 했던 것을 돌이켜 보니 한 3년 전에 하던 것 중 생각나는 것이 있었다. 당시 시스템 관리를 담당하고 있었는데 어느날 팀장님이 배포 이후 모든 서버를 수동으로(!) 확인하라고 한다...

그 방법은 단순무식해서, 다음과 같은 절차를 따르면 된다.

  1. /etc/hosts 를 열어 해당 도메인의 서버 ip 를 수정
  2. 브라우저 재시작
  3. 브라우저에서 http://www.target.com/path/to/test_application 접속하여 확인
  4. 1~3 반복
그 팀장님이 왜 이런 방법을 택했는지는 모르겠다. 그리고 왜 나도 이렇게 하라고 했었는지도. 그러나 서버들 각각이 제대로 작동하고 있는지 확인해야 한다는 점에는 동의한다.
한 10대만 되었어도 저 방법을 그럭저럭 감내할 수 있었겠지만, 50대가 넘는 서버를 그렇게 확인하고 싶지는 않았다...

반드시 브라우저로 확인할 필요는 없지 않을까? 뭔가 다른 방법이 있지 않을까? 없을 리가 없다. 이를 위해 쓸만한 것으로 cURL 이라는 것이 있었다. 실제로 이미 스트레스 테스트를 할 때 cURL 로 테스트 대상 서버에 부하를 주고 있었다. 그 스크립트에 사용하던 cURL 명령행은 매우 간단해서 그냥

형식이었고, 이게 제대로 작동하기 위해서 당연히 /etc/hosts/ 에는 www.target.com 에 대한 스트레스 테스트 대상 서버 ip 를 지정해 놓았었다.

그렇다면 curl http://192.168.111.111/path/to/test_application 도 작동하지 않을까?
되긴 된다. 그런데 우리의 www.target.com 은 저런 ip 기반으로 접근할 수 없었다. 그 밖에, Apache NameVirtualHost 를 사용할 경우 전혀 쓸모가 없다.

그래서 생각했던 것이, 스크립트로 /etc/hosts 안의 대상 ip 를 바꿔 가면서 curl 을 실행하는 방법이었는데... 아무래도 좋은 생각은 아니었다. 테스트 이후 /etc/hosts 를 원상복구하는 것이야 일도 아니라 쳐도, 시스템 전체에 영향을 줄 수 있는 부분을 건드리는 것은 별로 좋은 방법이 아니다. 게다가 이러한 스크립트를 실행하기 위해 root 권한을 사용해야 한다는 것도 별로 바람직한 상황은 아니다.

이런 것 말고도 다른 몇 가지 생각을 했었는데 더 바람직하지 않은 방법들이라 굳이 쓸 필요는 없겠다.

결국 cURL community 에서 힌트를 얻어 해결을 하였는데, 다음과 같이 하면 특정 도메인에 대해 어떤 ip 를 사용할 것인지 지정할 수 있다.

간단한 스크립트 등을 작성하여 대상 서버 ip 에 대해 위 명령을 순환하면 된다. 결과 html 을 적당히 처리하여 결과를 판단하면 될 것이다.
사람이 일일이 /etc/hosts 파일을 편집하고 브라우저를 재시동한 뒤 직접 주소를 입력하여 눈으로 확인하는 것은 정말 하고 싶은 일이 아니다.


P.S: 스크립트 혹은 각종 언어에서 시스템 콜을 하는 것이 그렇게 이상할 것은 없다고 생각하지만 보다 세련되게 처리하고 싶다면 libcurl 을 사용하면 된다. 이게 특별히 더 세련된 방법이라 말할 수 있을지는 모르겠다.