박종명의 아름다운 개발 since 2010.06

표준 인증체계를 정의하는 OAuth에 적용된 보안 개념들은 OAuth를 사용하지 않더라도 인터넷과 같은 열린 공간에서의 통신에서 보안을 강화하는 아키텍처로써 가치가 있다.

분산 시스템간 통신 시, 이러한 개념을 적절히 접목하면 보안성이 잘 갖춰진 시스템을 만들 수 있을 것이다.

먼저 시스템간의 통신에서 보안이란 대략 다음과 같은 요소들로 정리할 수 있겠다.

1. 기밀유지 (암호화)

보안의 가장 기본적인 요소로 데이터를 읽지 못하게 만들어야 한다.

공격자가 통신 패킷을 중간에 가로채서 보더라도 데이터를 읽을 수 없는 상태로 만들어야 하는데 이를 위해 각종 암호화 기법을 적용하게 된다.

2. 신원확인 (자격증명)

허가된 클라이언트만이 통신을 허용할 수 있도록 해야 하는데 이를 위해 클라이언트는 자신의 자격증명을 제출하도록 한다. 보통 ID/PW를 제출하기도 하고 클라이언트 인증서, 임의의 토근 등이 사용되기도 한다.

3. 변조 방지 (디지털서명)

공격자가 통신 패킷을 중간에 가로채서 변경하지 못하도록 해야 한다.

서버의 입장에서는 요청이 중간에 변조되지 않았는지를 확인 해야 하는데, 이를 위해 전송 데이터의 해시 값을 구하고 이 해시 값을 클라이언트의 비밀키로 암호화하도록 한다.

이를 디지털 서명이라고 하는데 변조 방지 뿐만 아니라 클라이언트가 자신이 보낸 것이 아니라고 하는 부인방지도 효과도 있다.

4. 재생 방지

일반적인 보안 시나리오에서 간과되기 쉬운 부분인데, 분산 환경에서의 통신에서는 특별히 주의해서 방어해야 하는 요소이다. 앞의 1,2,3 의 보안 요소들이 잘 갖춰져 있다하더라도 공격자가 중간에서 패킷을 가로채 그대로 다시 서버로 전송할 경우 이를 거부하도록 해야 한다.

OAuth 프로토콜은 이러한 보안 개념들을 적절히 잘 접목한 안전한 인증시스템이라 할 수 있다.

OAuth를 통한 인증 과정에서는 실제로 기밀유지보다는 변조방지와 재생방지에 무게 중심이 있다고 하겠다.

OAuth 인증 과정에서는 비밀번호라던가 주민번호와 같은 기밀을 유지해야 하는 민감한 데이터가 포함되지 않기 때문에 기밀유지를 위한 과도한 암호화는 불필요하다. 다만 인증된 클라이언트에 의한 유효한 요청인지가 더욱 중요하다는 것이다.

(OAuth 인증 과정 중, 사용자가 ID/PW를 입력해서 로그인 하는 과정이 있지만 이 부분은 OAuth 인증 과정이라기 보다는 사용자와 서비스 프로바이더간 보안 구간이라고 하겠다.

또한 OAuth 인증 과정을 모두 완료한 후 액세스 토큰으로 보호된 자원에 접근하는 경우에 기밀 데이터가 있을 경우 htts와 같은 별도의 암호화 장치를 둬야 한다. 이 구간 역시 OAuth 인증 과정과는 별도로 이해하기 바란다)

OAuth에서는 데이터의 변조 방지를 위해 해시 값과 디지털 서명을 사용한다.

이때 Consumer Secret 이 비밀키로 사용되며 HMAC-SHA1와 같은 해싱 알고리즘이 적용된다.

(참고로 OAuth 2.0의 경우, HTTPS를 사용하게 됨으로써 HAMC를 사용하지 않아도 된다)

그리고 재생 방지를 위해서는 Timestamp와 Nonce가 사용되는데,

Nonce는 모든 요청에 유일함이 보장되어야 하는 (클라이언트에서 생성하는) 임의의 문자열인데,

재생 공격시 이 값을 체크해서 (이미 이전 요청에 사용된 Nonce일 경우) 요청을 거부하게 된다.

그렇다면 Nonce의 유일성을 체크해야 하는 서버의 입장에서는 모든 요청의 Nonce 값을 보관하고 있어야 하는 부담이 있는데, 이는 Timestamp 체크로 부담을 제거하게 된다.

OAuth 인증 과정에서 포함되는 Timestamp는 요청을 생성한 시점의 타임스탬프 값으로써 1970년 1월 1일 00:00:00(GMT) 이후의 시간을 초로 환산한 숫자 값인데 이 값의 유효 범위를 지정해 기간이 경과한 요청은 거부하도록 한다.

즉 Nonce의 유일성 체크 이전에 Timestamp에 의한 유효 시간 체크를 먼저 함으로써 서버 입장에서는 유효시간 내의 Nonce값만을 관리하면 되는 것이다.

마지막으로 OAuth 인증 과정을 모두 마치면 클라이언트는 사용자의 인증을 대신하게 되는데 이때 Authorization Header라는 HTTP 헤더 값을 자격증명으로 제출하게 되는 셈이다.

이러한 OAuth 인증과정에 적용된 보안 개념들은 다른 어플리케이션을 개발할 때에도 참고하기에 충분한 가치가 있다고 하겠다.

다음 문제를 풀어 보자.

문제를 쉽게 풀었다면 패스~~

Enum을 정의할 때 FlagAttribute를 적용하면, 열거형 값들을 조합해서 사용할 수 있다.

예를 들어 File과 Database 두 값 모두 라는 의미로 다음과 같은 코드 사용이 가능하다

LogType logType = LogType.File | LogType.Database

...

bool isFile = (myType & LogType.File) == LogType.File;

FlagAttribute는 Enum을 BIT Flag 처리가 가능하도록 설정하는 것이다.

BIT Flag의 동작 방식을 이해하고 있었다면, 문제를 쉽게 풀었을 것이다.

열거자 목록에 사용된 값들의 bit가 켜고 끄는 형태 즉, On/Off 형태가 되도록 구성해야 한다.

그래야 bit의 OR / AND 연산이 제대로 동작하게 되는 것이다.

다시 말해, 각 값들의 비트 구성이 다음과 같도록 구성해야 한다.

따라서 정답은 다음과 같다.

이제 다음 코드의 의미를 다시 보면,

LogType logType = LogType.File | LogType.Database

정수 1과 2(비트 1과 10)의 비트를 (OR 연산으로) 모두 ON 상태로 만드는 것이다.

그리고 다음 연산으로 자신의 비트만 켤수 있도록 비교하게 된다.

(myType & LogType.File) == LogType.File

----------------------------------------------------------------------------------------

여기서 좀 더 세련된 코딩을 하자 치면...

이러한 비트 구성은 2의 제곱형태가 되는 걸 알 수 있다.

즉 비트가 왼쪽으로 한 칸씩 쉬프트되는 구조 이므로 다음과 같이 코딩할 수 있겠다

-------------------------------------------------------------------------------------

마지막으로 전체 선택은 비트를 모두 켠(ON) 것이고,

그 반대는 비트를 모두 끈(OFF)한 것이므로 다음과 같이 코딩하면 된다.

열거자 값이 많고 계속 늘어날 수 있는 경우 모든 비트가 켜진 정수의 최대값을 지정해되 된다.

All = Int32.MaxValue

WCF 서비스의 보안 모드를 Message 보안으로 하고 클라이언트 자격증명 타입을 UserName으로 한 후,

테스트 X.509 인증서를 생성해서 자격 증명, 암호화, 디지털 서명 등이 잘 되는지 확인을 완료했다.

그리고 알파 서버로 서비스를 셋팅하고 테스트를 해 보니 보안 예외가 계속 발생한다.

이벤트 로그를 보면 다음과 같은 로그가 남겨져 있다.

개발 PC에 서비스와 클라이언트를 모두 구동할 때는 발생하지 않던 것이, 서버를 옮긴 후 발생하는 것이다.

서버와 클라이언트 PC의 시간차에 의한 보안 예외가 발생한 것이다.

즉 메시지가 생성된 시점의 타임스탬프의 유효기간을 체크함으로써 재 전송 공격(Replay Attacks)을 방지하기 위한 보안 메커니즘에 위배된다는 것이다.

그런데 이 보안 매커니즘이 대략 난감한 상황이 될 수도 있다.

클라이언트와 서버의 시간이 어쩔 수 없이(?) 다를 수 밖에 없는 환경이거나 안정적인 타임 서버 기반으로 시간 동기화를 하지 못하는 경우에 어느 시점에 시간 차가 날지 예측할 수 없기 때문이다.

기본 보안 설정에서는 두 서버의 허용 시간 차가 5분이다.

서버와 클라이언트 시간을 동기화 해 주지 않는 이상 5분 이라는 최대 허용 시간을 늘릴 수 밖에 없는데...

문제는, 이 것이 간단히 속성 값 변경으로 될 수 없다는 것이다.

WCF의 커스텀 바인딩을 통해 최대 허용 시간을 변경할 수 있다고 하니, 대략 귀찮아 지게 생겼다.

http://msdn.microsoft.com/en-us/library/ms733063.aspx

http://www.danrigsby.com/blog/index.php/2008/08/26/changing-the-default-clock-skew-in-wcf/

http://msdn.microsoft.com/en-us/library/aa738468.aspx

WCF 서비스의 동시 호출, 세션, 인스턴스 수를 제한하는 serviceThrottling 항목의 기본 값에 혼동이 있다.

자료를 찾아보면, 다들 조금씩 다르게 안내한다는 혼란만 가중시키고 있다.

http://social.msdn.microsoft.com/forums/en-US/wcf/thread/110d31c2-9468-4a02-bcf6-4974f349d4e0

MSDN을 다시 확인해 본다.

이 항목의 세 가지 기본 값은 .NET Framework의 버전에 따라 기본 값의 변경이 있는 듯 하다.

.NET Framework 3.5

http://msdn.microsoft.com/ko-kr/library/vstudio/ms731379(v=vs.90).aspx

.NET Framework 4.0

http://msdn.microsoft.com/ko-kr/library/vstudio/ms731379(v=vs.100).aspx

.NET Framework 4.5

http://msdn.microsoft.com/ko-kr/library/vstudio/ms731379(v=vs.110).aspx

결국 최신 버전인 4.5을 기준으로 각각의 기본 값을 정리하면,

maxConcurrentCalls = 16 * processor count

maxConcurrentInstances = maxConcurrentCalls  + maxConcurrentSessions

maxConcurrentSessions = 100 * processor count

Entity Framework 는 다 좋은데, 저장 프로시저의 return 값을 처리할 수 없다는게 단점이다.

물론 시각에 따라서 이것이 단점이냐 하는 것은 논란(?)의 소지가 있겠지만...

실제로, Entity Framework가 SQL을 대체하는 것이 아니라 ORM 프레임워크이기 때문에 SQL의 모든 기능을 지원하지 않는 것이 단점이라고 단정할 수 없다는 예기가... 인터넷 상에 존재한다.

하지만 개인적으로 참으로 아쉬운 부분이다.

이미 만들어진 저장 프로시저 들이 return value를 많이 사용하고 있는 상황에서,

모델 계층을 Entity Framework 로 마이그레이션 하려고 하니 더욱 아쉬운 생각이 든다.

특히 MS의 또 다른 기술인 LINQ TO SQL에서는 return value를 지원하기에, Entity Framework의 버전 업에 해당 기능이 추가 되기를 기대해 보지만 아직인 듯 하다.

그렇다고 Entity Framework를 도입하려고 기존에 잘 운영되고 있는 수 많은 저장 프로시저들을 select 혹은 ouput 변수로 수정한다는 것도 현실적이지 않다.

그렇다면 return value 처리를 위해서만 별도로 LINQ TO SQL 혹은 ADO.NET을 사용할 수도 있겠지만,

MODEL 계층의 기술 기반이 복잡해지고 이중화 된다는게 맘에 들지 않는다.

그럼. 마지막으로 사용할 수 있는 카드는,

어떤 식으로든 Entity Framework 상에서 저장 프로시저의 return value를 처리하기만 하면 된다.

다시 말하지만 '어떤 식으로든...' 이다.

다음의 코드는 Entity Framework로 저장 프로시저의 return value를 반환받는 코드이다.

썩 맘에 들진 않지만, 불가피한 경우에 고민해 볼 만 하다.

WCF 서비스의 반환 값으로 사용자 정의 객체를 사용한다.

WCF 서비스와 클라이언트의 데이터 계약을 위한 DataContract Attribute 설정을 통해 시리얼라이즈 되어 통신이 가능해 진다.

그런데 이 반환 객체의 멤버 중, Collection 타입의 멤버는 내부 Item 타입만 다를 뿐이라서 상위 타입 선언을 통해 하나의 클래스만 유지하고 싶었다.

예를 들어서 이런 식이다.

위의 코드를 보면, ResultCollection 프로퍼티의 아이템 타입만 다를 뿐 나머지는 모두 동일하다.

따라서 최상위 타입인 System.Object로 아래와 같이 처리하려 했다

이렇게 하면 하나의 클래스를 유지하면서 다형적으로 처리할 수 있게 된다.

그런데 문제는 WCF 환경에서 이 객체를 원격 통신용 객체로 이용할 때 발생한다. System.Object 타입을 시리얼라이즈 할 수 없다는 것이다.

그래서 아래와 같이 지네릭을 이용하기로 한다.

지네릭을 이용하면, 객체 생성 시점에 타입이 결정되기 때문에 원격 통신에도 문제없이 잘 동작한다.

추가로, 이렇게  서비스 단에서 지네릭 기반으로 생성된 객체를 원격으로 전달받는 클라이언트에서는 지네릭 버전이 아니라 이미 결정된 객체 이름으로 전달받게 된다.

즉 서비스 참조로 생성된 프록시 객체를 보면 지네릭 버전의 객체 이름에 임의의 문자열이 추가된 것을 확인할 수 있다. 실제 서비스 환경에서는 이러한 상황이 달갑지 않다.

따라서 아래와 같이 이름을 지정하면 좋을 것이다.

이렇게 하면 클라이언트에서 반환 받는 객체 이름은 타입이 결정된 이름이 붙여 진다.

예를 들어 Product 타입으로 객체를 생성했다면, ReturnCollectionObjProduct 가 된다.

기존 프로젝트에 데이터 제공을 목적으로 하는 중계 서비스가 존재하고 있다

수 년전에 개발된 거라,

개발 모델이 과거에 머물러 있고 이기종간 다중값의 데이터 교환을 위해 2차원 배열에 의존하고 있는 구조이다.

이 서비스를 좀 더 진보된 형태로 개선하기 위한 프로젝트를 착수하게 되었다

큰 틀에서의 개선 목적은 다음과 같다

- 더 효율적인 상호 운영성

- 보다 진보된 개발 모델 차용

그리고 좀 더 세부적인 것까지 본다면 아래 요건도 고려되어야 한다

- 제공되는 데이터의 가공 용이성 

- 기존 서비스의 마이그레이션 용이성

- 더 좋은 생산성과 유지보수성

- 비즈니스 기능 외 인증,보안 필터와 같은 추가 로직의 삽입 용이성

닷넷 개발환경의 관점에서 대략 아래와 같은 개발 모델로 압축 시킬 수 있다

1) WCF 웹 프로그래밍 모델

2) WCF Data Service

3) ASP.NET Web API

이 세가지 중, oData 질의를 지원하는 것은 2),3)번이다.

또한 WCF Web API는 ASP.NET Web API로 대체되었다는 MS의 취지와 보다, 진보된 개발 모델 차용이라는 목적에 충실할 경우에도 2),3)번으로 압축할 수 있다

그렇다면 과정 WCF Data Service로 할 건인가? ASP.NET Web API로 할 것인가에 귀착된다.

두 개발 모델의 차이점과 선택 기준을 살펴 보기 위해 관련 자료를 검색해 봤다

먼저 oData 개념의 근원지이자 닷넷 환경의 개발사인 MS의 기술 자료부터 살펴 보고,

http://msdn.microsoft.com/en-us/data/odata

이 사이트의 포럼에 검색을 수행해 본다.

http://social.msdn.microsoft.com/Search/en-US/data?query=web%20api&rq=meta:Search.MSForums.GroupID(787c8d54-d241-48d2-8522-bcc5d7e41315)+site:microsoft.com&rn=All+Data+Platform+Development+Forums

http://www.codeproject.com/Articles/341414/WCF-or-ASP-NET-Web-APIs-My-two-cents-on-the-subjec

그리고 WCF 자체와 비교한 아래 글도 참고할 만 하다

http://mattmilner.com/Milner/Blog/post/2012/02/28/WebAPI-or-WCF.aspx

ASP.NET Web API에 대한 스콧 형님의 간단한 단상도 볼 만 하다

http://weblogs.asp.net/scottgu/archive/2012/02/23/asp-net-web-api-part-1.aspx

구글의 아래 키워드로 검색하면 적당한 참고 자료를 찾을 수 있다

검색 키워드: wcf data service vs web api

기술적인 정보와 참고 자료로 선정하는데 적잖은 혼란을 느끼던 중,

간과해서는 안될 매우 중요한 팩터인 '실제 구축하는 시스템의 성격'이라는 축을 고민하기에 이르렀다

실제 구축하는 시스템의 성격은 대략 아래와 같다

1) 조회 90%, 입력/수정: 10%

전체 서비스에서 대략 10%를 제외하면 모두 데이터 제공 즉 조회 기능이다.

2) 한정된 데이터 제공

선택의 기준에서 아주 중요한 부분이란 생각이 들었다.

현재 개선을 하고자 하는 시스템의 경우 보안 목적으로 중계 서비스 역할을 하고 있다

즉 데이터 제공이 목적이긴 하지만 본질은 클라이언트가 직접 데이터 저장소에 액세스 할 수 없다는 목적을 달성하기 위해 만들어진 중계 서비스인 것이다. 그러기에 데이터를 광범위하게 제공하기 보다는 한정된 데이터를 특정 로직에 의해 가공해서 제공하는 성격이 짙다는 것이다.

WCF Data Service의 경우 oData 질의를 필수로 동반하기에, 데이터 제공의 한정을 위해서는 데이터 모델 차원에서 규칙을 부여할 수 밖에 없다. 반면 Web API의 경우 oData 질의는 선택사항일 수 있고 상호 협의된 형태의 데이터 반환만 가능하도록 비즈니스 처리가 가능하다.

WCF Data Serivce가 Web API에 비해 보다 더 깊은 oData를 지원한다고는 하지만, 실제 시스템의 활용도 측면에서는 어쩌면 불필요한 요소일지도 모른다.

WCF Data Service를 놓지기 싫었던 이유 중 하나는,

클라이언트가 닷넷 기반일 경우 데이터 질의를 LINQ 쿼리로 직접 할 수 있다는 부가적인 장점이었는데 이 부분은 포기해도 무방한 사소한 장점일 수 있다.

그리고 개발 생산성 측면에서도 WCF Data Service가 더 적은 코드를 요구하지만 데이터 원본 자체의 넓고 다양한 제공일 경우가 아니고서는(데이터 원본 대비 한정되고 가공된 데이터 제공) 그 가치가 크지 않겠다는 판단이다.

MS가 두 가지 유사한 개발 모델을 제공해서 약간의 혼동이 있으나, 결국 중요한 것은 두 개발 모델의 설계 사상과 특징에 기반한 현재 시스템 성격을 투영해 선택하는 것이 최선이 아닐까 한다.

현재 카테고리에 맞지 않는 영역이지만....

관리도 안될게 뻔한 카테고리를 새로 만들고 싶지 않아 ASP.NET MVC 카테고리에 꺼적인다

ASP.NET MVC로 DB 관련 개발할 때,

EntityFramework 나 LING to SQL을 사용하곤 한다

근데 이 두 넘은 다 좋은데, 저장 프로시저의 다중 결과 셋을 지원하지 않는다.

음.. 지원하지 않는다기 보다는 자동으로 생성되는 designer.cs에만 의존하면 그렇다고 해야 정확한 표현인 듯 싶다.

예를 들어,

게시판 글 보기 페이지일 경우, 글 내용과 해당 글에 대한 댓글 정보를 하나의 프로시저에서 두 개의 결과 셋으로 반환하도록 할 경우 처음으로 반환된 결과 셋이 자동으로 바인딩 되는 것이다

물론 이런 상황이라면 글 내용은 OUTPUT 변수로 받고 댓글 리스트는 결과셋으로 받아서 해결 가능하다. 실제로 이렇게 사용한 적이 꽤 많다.

그러나 문제는 정말로 리스트형태의 결과 셋이 여러 개일 경우이다. 이젠 더 이상 OUTPUT 반환 값에 의존할 수 없게 되었다.

저장프로시저의 시나리오는 대략 이렇다.

1. OUTPUT 변수로 몇 가지 값을 반환한다

2. 3개의 결과 셋(레코드 셋이라는 표현을 좋아하는 사람이 있다)도 같이 반환한다

그러니깐, 의미적으로 총 3가지 형태의 결과값을 받고 싶은 게다

(OUTPUT 반환 값 + 결과셋1 + 결과셋2 + 결과셋3)

물론 결과셋의 개수는 중요치 않다. 두 개 이상의 결과셋을 반환한다는 게 중요하다

이제 이 프로시저를 LINK to SQL로 연동해서 결과를 처리하고 싶다

먼저 desiner.cs 가 자동 생성한 아래의 코드를 보자

매우 복잡한(?) 코드에 의미 두지 말자. designer.cs 가 자동 생성해 준 코드를 그대로 옮긴 것이니..

그리고 저장프로시저의 원형에 의미도 두지 말자. 그냥 대충 다중 셋을 반환하는 저장프로시저라고 생각하면 된다. 중요한 것은 ISingleResult를 반환한다는 점이다. 그래서 다중 결과 셋의 첫 번째 결과만 바인딩 되는 것이다.

그렇다면 해결책은 ISingleResult가 아닌 다중 셋을 반환할 수 있도록 IMultipleResults을 반환하면 된다.

이를 위한 새로운 메서드를 정의해야 하는 데, designer.cs가 자동 생성한 클래스를 사용할 생각은 말아야 한다. DB 연동이 추가/제거/변경 될 경우 이 클래스는 다시 생성되기 때문에 자신의 코드가 모두 사라질 수 있기 때문이다.

그렇기 때문에 파티셜 클래스 기법을 이용하면 된다.

designer.cs가 생성한 클래스와 동일한 이름으로 파티셜 클래스를 선언하고 다중 셋을 반환할 수 있도록 다음과 같이 작성할 수 있다

자동생성된 이전의 코드와 거의 유사한 것을 알 수 있다

다른 점이라면 IMultipleResults 타입을 반환한다는 점과, 다중 셋의 결과를 자동으로 바인딩 하기 위한 클래스 선언이 있다는 점이다.

LINQ to SQL을 사용하면서 다중 결과 셋에 대한 목마름이 있었던 사람은 위의 코드만으로도 그 즉시 적용가능하리라 본다.

MVC 기반의 사용자 화면에서는 다중 입력 폼(form)을 허용한다.

사실 허용한다기 보다는 일반적인 HTML 페이지의 동작을 그대로 수용한 것이다

이전 개발 환경인 ASP.NET WebForm에서는 서버 측 폼을 기반으로 작업을 많이 했으며 한 페이지에 오직 하나의 서버 폼이 존재할 수 있었다

MVC환경에서는 서버 측 폼이라는 개념을 사용하지 않기에 (일반적인 HTML 규칙과 같이) 다중 폼의 사용이 가능한 것이다.

그리고 MVC에서는 폼 입력에 대한 유효성 체크와 유효성 메시지 노출을 자동화 시켜 주는 편리한 기능도 있다

그런데 이 둘(다중 폼 & 유효성 체크)을 조합해서 사용하다 보면, 의도치 않는 결과를 만나곤 한다

예를들어, 다중 폼 환경에서 특정 하나의 폼의 유효성 체크가 다른 폼의 유효성 체크와 통합되어 표시되는 현상 같은 것이다.

두 개의 폼의 입력 필드 이름을 다르게 해서 각각의 입력 컨트롤의 유효성 실패 표시는 쉽게 구분할 수 있으나

@Html.ValidationSummary와 같은 유효성 메시지를 각 폼에 독립적으로 사용하고자 할 때는 기대처럼 동작하지 않는다. (파샬뷰로 분리된 다중 폼이라고 해도 결국 하나로 합쳐지기 때문에 현상은 동일하다)

이에 대한 솔루션을 제공하는 아티클이 있다

ASP.Net MVC: Validation a on page with multiple forms

간단하게 설명하자면,

필드 이름을 폼 마다 (접두어를 두어) 구분하고, 사용자 정의 HtmlHelper를 만들어서 자신의 이름과 일치하는 폼에 대해서만 유효성 체크 Summary(ValidationSummary)를 반환하도록 한 것이다. 그리고 뷰에서는 이 사용자 정의 HtmlHelper를 통해 유효성 메시지를 표시하도록 한다.

이러한 접근 방식이 마음에 들지 않는다면, 다음과 같이 설계 할 수 있겠다

1) 다중 폼을 사용하지 않기

2) 다중 폼을 사용하되, MVC 유효성 체크에 의존하지 않기

3) 위 아티클의 방식을 나름 응용해서 사용하기

(입력 폼에 자동 모델 바인딩을 사용할 경우, 입력 필드 이름에 의존적이기 때문에 필드 이름을 변경하는 게 불편할 수도 있다)