도전의 미학...

블로그 v1 운영 중지

찬욱 — Sun, 20 Feb 2011 04:13:10 +0900

열심히 사느라 블로그는 잠시 뒷전이었습니다.

제 첫 블로그를 잠정적으로 운영을 중지합니다.

돌이켜보면 블로그에 글을 쓰고, 생각을 공유하는 시간들이 저를 만들어가는 가장 큰 원동력 중 하나였습니다.

참 행복한 시간들이었네요..

블로그를 중단 한다고 해서, 관심사가 바뀌거나 게을러 졌다기 보다는

현장에서 답을 찾기 위해 치열하게 사는데 더 집중하고 싶다고 보는게 좋을 것 같습니다.

그리고 나서 잠시 여유를 찾으면 v2로 다시 이어갈 생각입니다.

제가 궁금(?)하시거나 연락을 하고 싶으신 분은 메일이나 얼마전에 시작한 페이스북으로 오세요^^.

물론, 생각보다 일찍 다시 블로그 v2를 시작할지도 모르겠습니다. (벌써부터?)

사실 블로그가 중요한게 아니고 지금 제 생각을 어떻게 정리하고, 또한 이를 어떻게 공유할 것인지의 방법적인 측면을 고민해봐야겠죠.

아무튼 그 동안 부족한 제 블로그를 구독해주시고, 많은 관심을 가져주셔서 감사드립니다.

새로운 공간을 마련하면 다시 한 번 글을 남기겠습니다.

그럼 즐거운 주말 되세요.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

폴리텍 대학 스프링 강좌 7차 강의

찬욱 — Thu, 14 Oct 2010 19:17:31 +0900

일곱 번째 강의 입니다.

이제는 폴리텍 대학 홈페이지를 통해서만 접수 받습니다.

홈페이지에 방문하셔서 서류 작성 후 팩스로 보내면 바로 접수 됩니다.

자세한 내용은 폴리텍 대학 담당자 번호인 02-6300-6300 로 연락하시면 됩니다.

[접수하러 가기]

그럼 즐거운 하루 되세요.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

마소 9월 Spring 3.0 5부 기사 내용 정정

찬욱 — Wed, 01 Sep 2010 14:29:36 +0900

이번 달 마소에는 특집 기사로 Spring 3.0에 대한 내용이 실렸습니다.

제가 그 중에 '스프링 프레임워크 3.0을 이용한 RESTful 웹서비스 구현' 글을 작성했는데 글 내용 중 오류가 있어 내용을 정정해 올맀습니다.

다음 달 호에 정정문이 실리겠지만 이번 달 마소를 읽으시고 혹시나 혼란스러워할 분이 계실 것 같아 미리 블로그에 공지합니다.

그럼 아래 내용을 참고해주세요.

마소 담당자분과 이 글을 읽고 혼란스러워 하신 독자 분들께 죄송한 말씀 올립니다 (_ _).

<정정 내용>

<리스트 5>에서 설명하는 인터페이스를 MessageConverter에서 HttpMessageConverter로 정정합니다. 그 외 관련 본문 내용의 'MessageConverter'도 'HttpMessageConverter'를 의미하므로 참고해주시기 바랍니다.

<리스트 5 정정 코드>

package org.springframework.http.converter;

public interface HttpMessageConverter<T> {

// 메시지 컨버터의 읽기 지원 여부

boolean canRead(Class<?> clazz, MediaType mediaType);

// 메시지 컨버터의 쓰기 지원 여부

boolean canWrite(Class<?> clazz, MediaType mediaType);

// 메시지 컨버터가 지원하는 미디어 타입 목록 반환

List<MediaType> getSupportedMediaTypes();

// 요청 메시지를 clazz 인자 타입의 객체로 변환

T read(Class<? extends T> clazz, HttpInputMessage inputMessage)

throws IOException, HttpMessageNotReadableException;

// t 객체를 메시지 컨버터가 지원하는 타입으로 변환 후 응답 스트림에 반영

void write(T t, MediaType contentType, HttpOutputMessage outputMessage)

throws IOException, HttpMessageNotWritableException;

}

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

폴리택 스프링 강의 6차 개설 합니다.

찬욱 — Tue, 03 Aug 2010 13:36:06 +0900

벌써 6차 교육입니다.

강의에 대한 자세한 내용은 아래 링크를 참조해주시면 감사하겠습니다.

지금 예상으로는 금번 강의를 포함해서 두 번 정도의 강의를 마지막으로 할 것 같습니다.

이번 강의는 기본적인 강의 구성은 그대로 진행하지만 강의 참가자 분들과 더 다양하게 소통할 수 있는 기회를 마련해보도록 하겠습니다.

시간 별로 특정 주제에 대해 의겨을 나누는 시간이 마련할 생각입니다.

아쉽게도 5차 때는 하지 못했던 뒷풀이(?)도 반드시 할 생각입니다.

아무쪼록 금번 강의도 즐거운 6주가 됐으면 좋겠습니다.

감사합니다.

강의 개요 참조

강의 시간표 참조

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

Spring Explorer 잘 쓰기

찬욱 — Sat, 24 Jul 2010 12:10:22 +0900

Spring IDE를 설치하면 기본적으로 제공하는 뷰 중에 하나로 'Spring Explorer'가 있습니다.

하지만 일반적으로는 잘 사용하지 않습니다. 정확히 말하자면 개발 중에 그렇게 볼 필요가 없다는 겁니다.

그러나 빈 설정을 애노테이션으로 하기 시작하면서 얘기가 조금 달라졌습니다.

빈 설정을 애노테이션으로 하거나, Autowiring을 위주로 사용하보니 명시적으로 의존성을 관리할 때에 비해서 직접 테스트나 시스템을 띄우기 전까지는 의존성 관계가 정상적으로 되었는지 확인하기가 어렵다는 겁니다. 어떨때는 시스템을 띄워서 에러 메세지를 보고도 바로 파악하지 못하고 해매는 경우도 발생합니다.

방금 전 강의에서도 한 분이 패키지가 다른 위치에 있는 빈인지 모르고 특정 빈(컨트롤러)가 왜 매핑이 안되는지 한참을 찾는 경우가 발생했습니다. 의존성 주입인 경우에는 그나마 나은데 이번에는 컨트롤러다 보니 의존성 주입 실패가 아니라 웹 요청이 매핑되는 핸들러가 없다고 하니 이 부분ㅇ르 바로 캐치하지 못하신 거였죠. 더군다나 빈의 갯수가 많아지면 더 힘들겠죠.

이럴 때 Spring Explorer를 활용해 실제로 시스템이 올라갈 때 등록되는 빈들을 미리 확인할 수가 있습니다. 위의 분의 경우에도 Spring Explorer을 보고 나서 바로 빈이 올라가지 않아서 그렇다는 상황을 바로 알아낼 수가 있었습니다.

상황을 공유하려고 간략히 쓰려고 했는데 조금 길어졌군요..;

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

Shallow eTag의 정확한 의미

찬욱 — Mon, 05 Jul 2010 13:06:53 +0900

저도 처음에는 오해를 했던 것 중의 하나가 shallow eTag의 정확한 의미입니다.

Spring에서는 shallow etag 방식으로 구현한 ShallowEtagHeaderFilter 필터가 존재합니다.

최초에는 "아..여기서 갱신 여부를 비교해 변경된 내용이 없다고 하면 캐싱해둔 뷰 내용을 다시 내리니 다시 응답(resposne body)를 처리할 필요가 없겠구나"라고 생각했는 데 실제로는 그런 의미가 아니었습니다..

일단 이 필터에서는 변경 여부를 비교 하는데 여기서는 해당 요청에서 생성된 응답(response body)를 기준으로 해시 값을 구합니다. 그러므로 이미 뷰 처리가 된 것이지요.. 요청 헤더의 'If-Non-Match'의 해시 값과 이번 요청의 해시 값을 비교하게 됩니다.

비교해서 값이 같다면(즉, 변경이 없었다면) response body의 컨텐츠가 없음으로 표시하고(response.setContentLength(0)), 응답 상태를 변경 없음으로 해서(response.setStatus(HttpServletResponse.SC_NOT_MODIFIED))해서 내립니다.

결론적으로 뷰를 다시 렌더링하는 데 들어가는 비용이 아닌 클라이언트와 서버 간의 데이터 전송양(bandwidth)를 줄이는 역할을 해줍니다.

응답이 단지 변화가 없다라고 나오기 때문에 이 응답을 받아서 동작하는 방식은 역시나 클라이언트에서 결정해야 합니다.

그리고 클라이언트는 etag 헤더 값의 경우에도 클라이언트에서 비교 대상이 되는 헤더 값을 알고 있다가 서버로 요청 시에 'If-Non-Match' 헤더로 보내줘야 하는 불편함(?)이 있습니다. 이를 해결하려면 shallow eTag가 아닌 deep eTag 방식으로 서버에서 알고 있는 방법을 사용할 수도 있습니다. 아니면 Last-Modified:와 같은 헤더 값을 활용하는 방법을 제안하는 사람도 있네요.(Last Modified를 활용할 때는 구현 방식이 조금 달라질수도 있겠네요..)

eTag에 대해 정리하면서도 역시나 기존의 웹 시스템의 구현이나 구성 방식의 경험을 기준으로 생각하면 안 된다는 것을 다시 한 번 느꼈습니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

전자정부 FW 실행환경 기능 분석 리스트

찬욱 — Fri, 02 Jul 2010 10:10:00 +0900

일전에 전자정부 FW 실행환경 소스를 쭈욱 살펴보다가 개인적으로 정리했던 자료 입니다.

강의때도 그렇고 근래 들어 전자정부 FW에 대해 질문 주시는 분들이 가끔 계시는데 혹시나 살펴보시는 데 도움이 되실까 해서 올립니다.

제가 살펴보면서 참고할 목적으로 정리되어 있기 때문에 내용 자체보다는 전체적인 구성이나 기본적으로 제공하는 기능 정도를 살펴보는 정도로 참고하시면 됩니다.

레퍼런스나 참고 문서들이 있으나 대부분 스프링이나 관련 오픈소스를 기반으로 설명을 하고 있기 때문에 실제로 전자정부 FW에서만 제공하는 기능을 보기에는 혼란(?)스러운 면이 있습니다. 그래서 순수하게 전자정부 FW 고유의 기능만 클래스 수준으로 정리해봤습니다. (물론 표준을 제시하고 가이드 하는 것 자체도 의미가 있습니다).

전자정부 FW 자체에 대한 가치를 논하기는 사실 어렵지만, 전자정부 FW가 있음으로 프로젝트에서 올바른 기술 구조를 선택하고 적용할 최소한의 기회의 기반이 된다는 측면에서는 확실히 가치가 있다고 생각합니다. 물론 다른 여러 분야(자체적인 기능, 기술 지원 등)는 차차 좋아지겠죠^^

사실 전자 정부 FW는 (아직까지는) 실행 환경을 통한 다양한 기능 지원보다는 환경적인 측면이나 공통 기능 지원에서 더 큰 장점을 가지고 있다고 볼 수 있습니다. 사실 아직까지는 실행 환경 자체를 활용해서 얻는 메리트는 그렇게 크지는 않다고 생각합니다.(앞으로 개선되겠지만요..) 연계 통합 레이어에 메타 수준의 관리 기능부터 많은 클래스들이 개발되어 있지만, 실제로 활용되는 건지는 모르겠습니다..(역시 사이트 별로 다르겠지만 실제로 경험해신 분들에게 확인해봐야겠지요..)

이번에 정리한 건 기능 분석의 관점이었고, 실제 적용의 관점에서는 다시 한 번 정리해봐야겠습니다.

틀린 내용이 있다면 피드백 주세요.

전자정부FW_실행환경기능분석.xlsx

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

REST 표준 수립 시 고민해야 할 문제들

찬욱 — Fri, 02 Jul 2010 08:00:00 +0900

오랜만에 자리에 앉아 차분히 블로깅을 하네요^^;

조만간 REST 표준 수립에 관련된 일을 하게되어 잠시 REST에 대해서 서베이를 좀 해봤습니다..

사실 'RESTful'이라는 용어에 대해 이해하기가 쉽지가 않습니다.

글세요.. 역시나 보는 사람에 따라 다양한 방식으로 정의할 수 있겠지만 제가 생각하기에 핵심은

"기존의 '요청(Request) 중심'의 사고 방식에서 '자원(Resource) 중심'의 사고 방식으로 변환"

이라고 생각합니다.

여기에 더해서 이러한 사고 방식의 변화에 따라 엔드 포인트와 뒷 단의 서비스를 구현 하는 방식도 중요하겠지요.

실제 표준 수립 시에는 이러한 '자원 중심'의 관점에 입각하여 REST의 주요 세 가지 구성 요소인 "Resource, Action, Message"의 표준을 수립하는 게 중요할 것으로 생각합니다.

Resource의 경우 자원에 유일성(Identity)을 부여해야 하는 데 이게 말처럼 쉽지가 않습니다.

기존에는 다양한 파라미터와 조건에 따라 컴포넌트가 다양한 형태의 결과를 조합해서 서비스를 제공하면 됐는데, REST의 경우 이렇게 구성하면 자원을 기준으로 유일성을 부여하기가 어렵게 됩니다. REST가 아키텍처 스타일이기 때문에 REST 구성시 단순히 엔드포인트(컨트롤러) 수준에서의 표준이 아닌 뒷단의 서비스 컴포넌트(서비스나 DAO 등) 수준에서의 설계와 구현 입장에서도 REST에 적합한 구현 스타일을 가져가야 합니다.

Action의 경우에는 역시나 다양한 HTTP Method의 정확한 의미를 규명하는게 우선시 됩니다. 다양한 자료에서 HTTP Method에 따라 의미를 정의하고 활용하는 방식을 설명하고 있는 데, 정리해보니 조금씩 다르기도 하고 보는 관점에 따라 해석이 다르기도 합니다. 물론 일반적으로 이해되는 방식을 준수하면서 시스템을 구현하는 요건에 맞게 재정의할 필요는 있어 보입니다. 더군다나 기본적으로 사용할 수 있는 HTTP Method로는 자연스럽게 의미가 일치하지 않는 요건을 구현할 때가 더 문제입니다. 메서드들에 대한 의미를 일반화하거나 별도의 메서드를 수립하는 등의 방법을 좀 생각해봐야 겠습니다.

Message의 경우에는 스키마 구성을 잘 고민해야 할 것 같은데, 이 문제는 대상 조직이나 시스템의 표준을 기준으로 할 수도 있으니 구현은 복잡하겠지만 고민거리는 상대적으로 적은 부분입니다. 그래도 hypermedia와 같은 REST의 속성을 적용하는 부분은 고민해야 되니 역시나 쉽지는 않네요.. 그리고 역시나 대규모 시스템에 적용할 때의 비기능 요건도 고려해야 하니 오히려 기존의 가지고 있는 구조와 REST 표준 간의 연계성이나 대체 방식을 고민하는 게 문제일 것 같습니다.

사실 하다보니 이 세가지 기준 외에도 고려하고, 생각해봐야 할 내용이 더 많습니다.

저도 처음에 프로토타이핑하면서 삽집을 많이 했는데 데이터와 페이지 네비게이션 등의 처리와 같은 요청에 대한 응답을 위주로 구현하는 컨트롤러 방식에서 해당 자원에 대한 다양한 서비스를 노출해야 하는 방식으로 구현하려니 먼가 어색하고, 기존 개발 방식으로는 처리하지 못하는(하면 안 되는) 부분이 발생하기 시작했습니다.

일례로 컨트롤러 메서드의 인자와 반환 타입이 웹 파라미터나 HTTP Request의 속성이 아니라 모두 Request/Response의 Body로 처리해야 합니다. 그래서 스프링의 경우 별도의 애노테이션(@RequestBody, @ResponseBody)을 이용해 이를 표시(markup) 해주도록 하고 있습니다. 더군다나 페이지 네비게이션에 대한 내용은 이제 컨트롤러에는 전혀 등장하면 안 되는 친구가 되버렸습니다.

REST의 단점 중 하나로는 주고 받는 데이터 형식 등에 대한 표준 기술과 같은 기준이 없기 때문에 자체적으로 표준 수립 시 클라이언트 단의 공통 기능, 또는 매핑 원칙을 제공해야 합니다. XML이나 JSON 같은 데이터 형식에 대한 가이드가 필요합니다.

또 가장 고민되는 부분 중의 하나는 상태(state)에 관련된 내용인데, REST의 경우 자원에 대한 요청 간에 의존성이 없어야 하기 때문에 서버에서의 상태 유지를 하면 안 됩니다. 그러나 기존의 시스템 구현 시 서버의 상태를 가지고 제공하는 다양한 서비스나 기능들이 있는데 이를 어떻게 구현하고, 적용해야 하는지가 가장 고민입니다.

Spring @MVC와 JAX-RS도 비교해 봤는데 이 부분은 사실 그렇게 크게 문제가 되지 않을 것 같습니다. 기능 목록 상에서는 거의 동일하기 때문에 선택의 문제가 됩니다. 다만 기존 시스템의 기반 기술이나 프로그래밍 모델을 고려하면 될 것 같습니다. REST와 비REST(일반 웹)의 구현이 상호 보완적으로 구성할 수 있는 경우에는 확실히 스프링 쪽이 유리하겠죠.

티스토리가 확실히 표 기능이 약해 비교 표를 올리기 조금 어려운데 둘 간의 매핑 정보만 간단히 정리해보면 다음과 같습니다.

Spring @MVC : JAX-RS

@RequestMapping : @Path

@PathVariable : @PathParam

@RequestMapping(method=RequestMethod.*) : @GET, @POST, @PUT, @DELETE, @HEAD

@RequestParam : @QueryParam

@CookieParam : @CooikeValue

@RequestHeader : @HeaderParam

HttpMessageConveter(또는 Conversion, Formatter) : MessageBodyReader

HttpMessageConverter(또는 View) : MessageBodyWriter

@ResponseStatus : Response.*()

물론 REST 관점에서 시스템의 전체적인 아키텍처 스타일에 대한 고민도 해봐야 하는데 이런 고민은 조금 더 넓은 시야를 가지고 생각해봐야 하기 때문에 차후에 한 번 해보도록 하겠습니다..