HTTP/1.1 uses many of the constructs defined for Internet Mail (RFC 822 [9]) and the Multipurpose Internet Mail Extensions (MIME [7]) to allow entities to be transmitted in an open variety of representations and with extensible mechanisms.

http://tools.ietf.org/html/rfc2045#section-5

The purpose of the Content-Type field is to describe the data contained in the body fully enough that the receiving user agent can pick an appropriate agent or mechanism to present the data to the user, or otherwise deal with the data in an appropriate manner. The value in this field is called a media type. 

Webwork에는 재밌는 기능이 하나 있습니다. 그것은 요청 파라메터를 모델 객체로 바로 매핑 시켜주는 기능입니다. 예제 코드를 만들어 보았습니다.

public class Param extends ActionSupport {

    private final static Log log = LogFactory.getLog(Param.class);
    private Person person;
   
    public String execute() {
        log.info(person.getName());
        log.info(person.getAge());
        return SUCCESS;
    }
    public Person getPerson() {
        return person;
    }

    public void setPerson(Person person) {
        this.person = person;
    }

    private class Person {
        private String name;
        private Integer age;

        public Integer getAge() {
            return age;
        }
        public void setAge(Integer age) {
            this.age = age;
        }
        public String getName() {
            return name;
        }
        public void setName(String name) {
            this.name = name;
        }
    }
}

위와 같은 액션을 만든 후 아래와 같이 접근해보면,
http://localhost:8080/Param.action?person.name=Min&person.age=90

콘솔에 이름과, 나이가 찍히게 됩니다. GET파라메터가 객체로 바로 매핑 된 것입니다. 내부적으론 Person객체의 setter들이 호출 될 것입니다.

처음 보았을 때는 상당히 유용한 기능이라고 생각했습니다. 반복되는 코드의 작업을 줄여줄 것이라 생각했기 때문입니다. 하지만 좀 더 사용하다보니 절대 사용하지 말아야 하는 기능 중에 하나라고 생각하게 되었습니다.

이유는 "모델 객체가 요청 파라메터의 영역으로까지 영향을 미치게 되었기 때문"입니다. 즉 모델과 요청 파라메터 사이에는 강한 결합(Tight coupling)이 발생한 것입니다. 만약 위의 person.name, person.age와 같은 파라메터가 여기 저기(JSP or JS 등)에서 사용되고 있는 상황에서, 어떤 이유로 Person 객체의 name 필드가 nickname으로 수정되고 setter 또한 setNickname으로 수정되어야 한다고 가정 해봅시다. 이 때 여기 저기 노출되어 있는 파라메터명이 모두 수정(person.name->person.nickname)되어야 합니다. 아마 단순히 서블릿만을 사용해 본 신입 개발자도 의아한 표정으로 물어볼 것입니다.

"모델 클래스를 변경했을 뿐인데 왜 파라메터명들이 모두 바뀌어야하죠? 제 서블릿 코드는 자바 코드만 고치면 되는데요."

그렇습니다. 지금 상황에선 차라리 예전 서블릿에서 많이 쓰던 아래와 같은 코드가 낫습니다.

String name = request.getParameter("name");
String age = request.getParameter("age");
Person person = new Person();
person.setName(name);
person.setAge(age);

(참고. 서블릿과 구 프로그래밍 방식이 무조건 좋다는 말은 아닙니다. 요청과 모델 사이에 매핑 코드가 존재하는 구조가 좋다는 말입니다.)

위와 같은 코드는 모델이 바뀐다고 요청 파라메터까지 바뀌지 않아도 됩니다. 우리는 이것을 흔히 "느슨한 결합( Loose coupling)"이라고 얘기합니다. 사실 원래 신경쓰지 않아도 우리가 늘 해온대로만 코딩해도 느슨하게 이루어지던 부분입니다. 그런데 위의 경우에는 소위 새로운 무엇이라고 불리는 것이 오히려 기존의 장점을 없애고 해악을 끼쳤다고 볼 수 있겠습니다.

그렇기 때문에 우리는 새로운 기술을 적용할 때 좀더 신중해야합니다. 새로운 것이 항상 긍정적인 효과만을 가져다주진 않기 때문입니다. 그리고 위 서블릿의 예에서 볼 수 있듯이 오래된 방식이라고 해서 항상 퇴출해야 하는 것만은 아닙니다. 오래된 것은 오래된 것 나름대로의 숙성된 향이 있기 때문입니다. :)

예상 반론. 누군가는 변화가 발생했을 때 기존의 setter 인터페이스를 그대로 유지하면서 새로운 인터페이스로 위임하면 되지 않겠느냐고 말할 수 있겠습니다. 물론 이것은 분명히 하나의 해결책이 될 수 있습니다. 하지만 좋은 해결책은 아닙니다. setter가 많아짐으로 인해 클래스의 복잡도(setter가 많은 것도 복잡도가 높아지는 요인이라고 생각합니다)가 증가하기 때문입니다. 또한 구 setter들 위에 다른 개발자를 위해 주석을 달아놔야 할 것입니다. "기존 웹 파라메터와의 호환성을 위해 유지함"이라고 말입니다.