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

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 가 된다.

이런 저런 관리적 업무로 많은 시간을 보내지만, 여전히 흥미로운 것과 욕심이 나는 것은 개발을 직접하는 것이다. 개발의 감각과 기본 원리,신 기술의 맥을 놓치고 싶지 않아 따로 시간을 할애해서 공부를 하고는 있지만 여건상 예전만 못하다.

설계를 하고 설계된 대로 개발을 하고 시행착오를 거치고 코드를 깊이 음미하는 시간이 제일 빨리 가는 것은 개인적으로 고무적인 일이다.

장인정신까지는 감히 엄두를 낼 수 없지만, 개발자라면 전문가로써의 사명감과 평생 공부가 당연하다고 느껴야 할 것이다.

하지만 생각해보면 컴퓨터 프로그래머라는 직업은 그 자체가 대학과 같다. 무슨 말인가 하면 컴퓨터 프로그래밍이라는 직업에 '입학'한 사람은 공부를 멈출 수 없다는 뜻이다. 프로그래머의 대학 교정은 컴퓨터 스크린 안에 활짝 펼쳐지고, 웹브라우저라는 도서관과 이클립스나 비주얼스튜디오라는 실험실에서 밤을 새운다. 끊임없이 쏟아져 나오는 패러다임과 기술은 해마다 학년이 올라가면서 새로 듣는 전공수업과 비슷하다. 철학자들의 선문답처럼 알쏭달쏭한 객체지향이라는 개념을 겨우 파악했는가 싶었는데, 함수프로그래밍이라는 (사실은 객체지향보다 더 오래된) 새로운 개념이 머리를 어지럽힌다. 자바라는 언어를 이제 좀 알겠다 싶었는데, 루비니, 파이썬이니, 스칼라니 하는 이색적인 언어가 등장해서 마음을 불안하게 만든다. 새롭게 나타나는 기술만이 아니다. 이미 알고 있다고 생각하는 데이터 구조, 알고리즘, 데이터베이스, 네트워크, 운영체제 등과 관련된 지식도 계속 가다듬고 공부하지 않으면 실력 있는 프로그래머의 위상을 유지하기 어렵다. 이미 알고 있는 지식을 유지하면서 동시에 새로운 지식을 쌓아나가야 하는 것이다. 내가 프로그래머라는 직업을 사랑하는 이유는 바로 여기에 있다. 지적인 도전, 학습에 대한 욕구, 공부하는 즐거움이 차고 넘친다. 컴퓨터 한 대만 있으면 어디에서나 스와스모어의 교정처럼 아늑한 상아탑의 분위기를 만끽할 수 있고, 흥미로운 문제를 앞에 놓고 밤을 지새울 수도 있다

 

.....

 

잠시 스스로에게 물어보기 바란다. 내가 지금 열정을 품고 '공부'하고 있는 것이 무엇인지. 적당한 대답이 떠오르지 않는 사람은 컴퓨터 스크린 속에 펼쳐지는 가상의 대학생활을 제대로 하고 있지 않은 사람이다

 

- 임백준 컬럼. '프로그래머라는 직업은 그 자체가 대학과 같다' 중

나랑 직접적인 관련은 없었지만, 6개월간 몸 담은 회사, 그리고 지인들이 처음부터 참여해서 개발한 서비스가 종료되니... 좀 그렇구먼 ..... ㅡ.ㅡ;

정상 댓글 몇 개를 삭제해 버렸어요;;; ㅡ.ㅡ

근래 이 블로그에 스팸 댓글이 지속적으로 올라와서, 매일 해당 글에 대한 IP 차단을 수동으로 일일히 하고 있었는데, 그 와중에 정상 댓글 일부도 같이 삭제되어 버렸네요..

이런...

혹여 자신의 댓글이 삭제되었다면, 오해 없으시기 바랍니다 ㅎㅎ

소프트웨어 기반 프로젝트의 성공에 매우 밀접하게 작용하는 요소가 바로... 사람이다.

인적자원관리라는 용어가 사용되는데, 인적자원의 획득과 역할과 책임, 양적/질적 관리와 교육/평가/보상 등을 관리하는데, 뭐니뭐니 해도 동기 부여를 어떻게 하느냐가 핵심이라 할 수 있다.

각 개인마다 서로 다른 내적 동기요소를 파악하여 프로젝트 혹은 회사의 궁극적 비전과 일치 시키는 것이 이상적이라 하겠다. 그러나 문제는 이게 말 처럼 그렇게 쉽지 않다는 것이다.

조직의 비전은 간혹 어떤 사람들에게는 '그들만의 비전'으로 치부되기도 한다.

조직의 비전, 개인의 가치.. 이 둘의 함수관계에 따른 공헌도 조사가 흥미롭다.

아래 글에 따르면, 이 두 가지 가치의 조화가 가장 이상적이지만, 차선책은 개인의 가치 확립에 무게 중심을 둬야 한다는 시사점을 제공한다.

결국 조직의 비전을 확고히 하고 이를 공유,공감시키는 활동과 더불어 이와는 별개로 개인의 가치 확립에도 노력과 비용을 들이는 것이 궁극적인 프로젝트 성공에 열쇠가 될 수 있다는 점이다.

개인적 가치의 확립은 헌신과 솔선수범에 이르는 길이 된다.

한 조사기관에서 사람들에게 이런 가치 확립과 특별한 성과를 얻기 위한 노력 간의 함수관계에 대해 질문했더니, 집단이나 조직의 가치가 불분명하고 개인의 가치도 확립되지 않았을 경우에 평균 공헌도는 7점 만점에 4.9점이 나왔다. 또 집단의 가치가 명확하고 개인의 가치가 불분명할 경우에도 역시 평균 공헌도는 낮았다. 그에 반해 집단의 가치가 명확하지 않지만 개인의 가치가 확립되어 있을 때는 7점 만점에 6.12점이 나왔고, 개인의 가치와 집단의 가치가 모두 확실하고 이 두 가지가 조화를 이룰 때는 평균 공헌도가 7점 만점에 6.26점으로 가장 높았다. 이런 수치로 미우러 볼 때, 자신의 개인적 가치를 알고 있다는 것은 집단의 가치를 공유하는 것보다 더 중요하다는 사실을 알 수 있다.

- +9(플러스 나인), 로버트 K. 쿠퍼 저

지금으로부터 100여 년 전, 나폴레온 힐이라는 사람이 강철왕 카네기로부터 다음과 같은 제안을 받았습니다.

힐 씨, 내가 보기에 이 세상에는 두 부류의 사람들이 존재하는 것 같습니다.

한 부류는 삶에 두려움을 가진 사람들입니다. 그들은 평생 패배자적 사고방식으로 살아갑니다. 그들은 늘 시간에 쫓기고 돈에 지배 당합니다. 그들의 가슴 속은 울화로 가득 차 있고 생활은 정돈되어 있지 않습니다.

 

반면 또 한 부류는 삶에 자신감을 가진 사람들입니다.

그들은 나날이 성장하는 삶을 살아갑니다. 그들은 감사로 하루를 시작하고 기쁨에 찬 하루를 보냅니다. 다른 누구와 마찬가지로 그들 역시 삶의 고달픔과 대인관계의 어려움을 매일 겪습니다. 하지만 그들은 거기에 매몰되지 않고 도리어 그것들을 딛고 더 넓은 세계로 나아갑니다.

 

그런데 특이한 것은 이 두 부류의 사람들이 한때는 같은 처지에 있었떤 사람들이라는 것입니다. 힐 씨, 나는 후자의 성공비결을 밝히고 싶습니다. 그들의 공통점을 찾아내서 세상에 널리 알리고 싶습니다. 만일 당신이 이 일을 맡아 주신다면 모든 경비는 제가 내겠습니다. 비용이 얼마가 들든, 몇 년 혹은 몇십 년이 걸리든 상관하지 않겠습니다. 어떻습니까? 저의 제안을 받아 주시겠습니까?

카네기의 제안을 받아들인 힐은 그 날부터 사회 각 분야의 성공자들을 만나 그들의 성공비결을 연구하게 됩니다. 그가 조사한 사람들은 단순한 출세자들이 아니었습니다. 삶의 정도를 추구해서 꿈을 이룬 진정한 의미의 성공자들이었습니다. 돈도, 집안배경도, 학벌도 보잘것없는 그야말로 밑바닥에서 시작해서 정상의 자리에 오른 사람 20,000명을 대상으로 한 그의 연구는 무려 25년에 걸쳐 이루어졌습니다.

힐의 연구에 따르면, 나날이 성장하는 삶을 사는 사람들의 가장 큰 공통점은 실패를 받아들이는 마음 자세에 있었다고 합니다. 하나의 일이 실패할 때, 그것을 인생의 실패로 확대하지 않고, 오히려 성공의 전조로 받아들이면서 꿈을 향해 더욱 힘차게 나아간 하루하루의 생활 태도에 있었다고 합니다.

- 18시간 몰입의 법칙 (이지성 저) -

컴퓨터 폴더 정리 중, 발견한 텍스트 문서에 있는 아래와 같은 기호키 팁!

어디서 발췌 한 건지 몰겠으나, 유용할 듯 하여 블로그로 급 옮김.

이거 최초 정리하신 분 고생 좀 하신듯 한데, 무단 사용.. 맘에 안 드시면 연락 주세용~

▒▒▒ ㄴ을 누르고 한자키를 눌렀을때 : 곽괄호 ▒▒▒
＂（ ）［ ］｛ ｝‘ ’ “ ” 〔 〕〈 〉《 》 「 」『 』【 】

▒▒▒ ㅁ을 누르고 한자키를 눌렀을때 : 특수문자-1 ▒▒▒
＃ ＆ ＊ ＠ § ※ ☆ ★ ○ ● ◎ ◇ ◆ □ ■ △ ▲ ▽ ▼ → ← ↑ ↓ ↔ 〓 ◁ ◀ ▷ ▶ ♤ ♠ ♡ ♥
♧ ♣ ⊙ ◈ ▣ ◐ ◑ ▒ ▤ ▥ ▨ ▧ ▦ ▩ ♨ ☏ ☎ ☜ ☞ ¶ † ‡ ↕ ↗ ↙ ↖ ↘ ♭ ♩♪ ♬ ㉿
㈜ № ㏇ ™ ㏂ ㏘ ℡

▒▒▒ ㄹ을 누르고 한자키를 눌렀을때 : 각종 단위 ▒▒▒
＄ ％ ￦ Ｆ ′ ″ ℃ Å ￠ ￡ ￥ ¤ ℉ ‰ ㎕ ㎖ ㎗ ℓ ㎘ ㏄ ㎣ ㎤ ㎥ ㎥ ㎦ ㎙ ㎚ ㎛ ㎜ ㎝ ㎞ ㎟
㎠ ㎡ ㎢ ㏊ ㎍ ㎎ ㎏ ㏏ ㎈ ㎉ ㏈ ㎧ ㎨ ㎰ ㎱ ㎲ ㎳ ㎴ ㎵ ㎶ ㎷ ㎸ ㎹ ㎀ ㎁ ㎂ ㎃ ㎄ ㎺ ㎻ ㎼
㎽ ㎾ ㎿ ㎐ ㎑ ㎒ ㎓ ㎔ Ω ㏀ ㏁ ㎊ ㎋ ㎌ ㏖ ㏅ ㎭ ㎮ ㎯ ㏛ ㎩ ㎪ ㎫ ㎬ ㏝ ㏐ ㏓ ㏃ ㏉ ㏜ ㏆

▒▒▒ ㅁ을 누르고 한자키를 눌렀을때 : 특수문자-2 ▒▒▒
＃ ＆ ＊ ＠ § ※ ☆ ★ ○ ● ◎ ◇ ◆ □ ■ △ ▲ ▽ ▼ → ← ↑ ↓ ↔ 〓 ◁ ◀ ▷ ▶ ♤ ♠ ♡ ♥
♧ ♣ ⊙ ◈ ▣ ◐ ◑ ▒ ▤ ▥ ▨ ▧ ▦ ▩ ♨ ☏ ☎ ☜ ☞ ¶ † ‡ ↕ ↗ ↙ ↖ ↘ ♭ ♩♪ ♬ ㉿
㈜ № ㏇ ™ ㏂ ㏘ ℡

▒▒▒ ㅅ을 누르고 한자키를 눌렀을때 : 한글 원문자, 괄호문자 ▒▒▒
㉠ ㉡ ㉢ ㉣ ㉤ ㉥ ㉦ ㉧ ㉨ ㉩ ㉪ ㉫ ㉬ ㉭ ㉮ ㉯ ㉰ ㉱ ㉲ ㉳ ㉴ ㉵ ㉶ ㉷ ㉸ ㉹ ㉺ ㉻
㈀ ㈁ ㈂ ㈃ ㈄ ㈅ ㈆ ㈇ ㈈ ㈉ ㈊ ㈋ ㈌ ㈍ ㈎ ㈏ ㈐ ㈑ ㈒ ㈓ ㈔ ㈕ ㈖ ㈗ ㈘ ㈙ ㈚ ㈛

▒▒▒ ㅇ을 누르고 한자키를 눌렀을때 : 영문/숫자 원문자, 괄호문자 ▒▒▒
ⓐ ⓑ ⓒ ⓓ ⓔ ⓕ ⓖ ⓗ ⓘ ⓙ ⓚ ⓛ ⓜ ⓝ ⓞ ⓞ ⓟ ⓠ ⓡ ⓢ ⓣ ⓤ ⓥ ⓦ ⓧ ⓨ ⓩ
① ② ③ ④ ⑤ ⑥ ⑦ ⑧ ⑨ ⑩ ⑪ ⑫ ⑬ ⑭ ⑮
⒜ ⒝ ⒞ ⒟ ⒠ ⒡ ⒢ ⒣ ⒤ ⒥ ⒦ ⒧ ⒨ ⒩ ⒪ ⒫ ⒬ ⒭ ⒮ ⒯ ⒰ ⒱ ⒲ ⒳ ⒴ ⒵
⑴ ⑵ ⑶ ⑷ ⑸ ⑹ ⑺ ⑻ ⑼ ⑽ ⑾ ⑿ ⒀ ⒁ ⒂

▒▒▒ ㅈ을 누르고 한자키를 눌렀을때 : 아라비안 숫자 ▒▒▒
０１２３４５６７８９ⅰⅱⅲⅳⅴⅵⅶ ⅷ ⅸ ⅹ Ⅰ Ⅱ Ⅲ Ⅳ Ⅴ Ⅵ Ⅶ Ⅷ Ⅸ Ⅹ

▒▒▒ ㅊ을 누르고 한자키를 눌렀을때 : 분수, 첨자 ▒▒▒
½ ⅓ ⅔ ¼ ¾ ⅛ ⅜ ⅝ ⅞ ¹ ² ³ ⁴ ⁿ ₁ ₂ ₃ ₄

현재 팀에서 사용하고 있는 소스 형상관리 툴은 TFS와 SVN 이다.

DB 스크립트나 일반 문서만을 다루는 사람들을 위한 소스 관리 환경이 필요했다.

즉 Visual Studio를 사용하지 않는 사람들만을 위한 환경이 필요한 것인데...

언뜻, SVN이 적합하다는 생각이 들었다.

다만 윈도우 탐색기로 소스 관리하는 것과 더불어,

이들이 주로 사용하는 툴인 SSMS(SQL Server Management Studio)와 연결해서 좀 더 편한 관리를 할 수 있는 방법이 없나 하면서 TFS 관련된 플러그인 들을 찾아 봤다.

먼저. 아래 플러그인을 설치 하면 SSMS에서 TFS로 연결할 수 있게 된다.

http://www.techtree.co.uk/sql-server/management-studio-ssms/use-team-foundation-server-tfs-as-your-source-control-in-ssms/

툴을 설치하고 SSMS의 옵션에 아래 그림과 같이 소스 제어 플러그인을 설정할 수 있다.

그리고 이후 프로젝트 생성하고 TFS서버에 연결해서 관리하면 된다.

그리고 TFS도 (SVN 클라이언트 처럼)윈도우 탐색기를 통해서 소스 관리가 가능하다는 아래 글을 보고 설치 해 봤다.

http://support.microsoft.com/kb/2699161/ko

http://visualstudiogallery.msdn.microsoft.com/c255a1e4-04ba-4f68-8f4e-cd473d6b971f

음.. 그런데 기대 했던 것 보다 불편하다.

2번째 툴을 설치하고 탐색기를 보니, 일단 글과 다르게 아이콘 모양이 표시되지 않는다.

그러나 TFS와 연결된 폴더의 컨텍스트 메뉴를 보면 아래 그림과 같이 TFS 로 관리할 수 있다.

단 아쉬운 것은 TFS와 미리 연결되어 있는 폴더라야만 해당 메뉴가 나타난다.

SVN과는 달리 일반 폴더에 TFS 연결 부터 하고 싶을 경우는 지원하지 않나 보다.

Visual Studio를 같이 사용하지 않는 이상, 이런 방식의 TFS 사용은 별로다.

이것저것 대략 살펴보다, 빠른 결론 내린다.

SSMS의 SVN 클라이언트 플러그인을 설치하기로 한다.. ㅎㅎㅎ

http://www.zeusedit.com/agent/ssms/ms_ssms.html

참 좋은 곳. 도서관!!!

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

수 년전에 개발된 거라,

개발 모델이 과거에 머물러 있고 이기종간 다중값의 데이터 교환을 위해 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가 두 가지 유사한 개발 모델을 제공해서 약간의 혼동이 있으나, 결국 중요한 것은 두 개발 모델의 설계 사상과 특징에 기반한 현재 시스템 성격을 투영해 선택하는 것이 최선이 아닐까 한다.

경험은 돈으로도 살 수 없는 매우 소중한 재산입니다

공부를 많이 한 사람보다 경험을 많이 한 사람에게 실제적 지식을 얻을 수 있습니다.

프로젝트를 진행하고 시스템을 운영하다 보면, 참으로 다양한 경험을 합니다.

그 중에서 어떤 문제를 해결한 경험의 가치는 이루 말할 수 없이 값진 거란 생각이 듭니다.

특히 개발자들은 늘 버그를 수정하고 삽니다.

배운대로 개발을 하더라도, 잘 개발된 시스템일지라도.. 다양한 이유로 버그는 발생할 수 밖에 없지요.

이럴때면 개발자들은 문제점의 원인을 분석하고 여러 기법을 동원해 문제를 해결해 나갑니다.

이러한 고도의 지적 활동 경험은 매우 가치있는 지식입니다.

안타까운것은 이 중요한 지식이 담당 개발자의 머리속에만 저장되어 있다는 겁니다.

더 슬픈건, 담당 개발자의 머리속에서도 언젠가는 지워질게게 분명하다는 점입니다.

그래서 경험 지식을 관리하고 싶어 졌습니다.

6하원칙이면 좋겠네요

- 언제

- 어디서

- 무엇이

- 왜

- 어떻게

- 누가

언제 어떤 문제가 어디서 발생했으며 왜 그러한 문제가 나타났는지, 그래서 누가, 어떻게 해결했는지입니다.

개발자의 경험 지식을 DB화하여 체계적으로 관리하면 좋은 점이 많습니다.

- 그 자체가 새로운 지식입니다.

- 인수인계를 받거나 신규 직원이 들어왔을 때 해당 시스템을 보다 빨리 습득할 수 있습니다.

- 유사한 형태의 개발을 진행할 때, 버그를 수정할 때  참고하면 버그 발생률을 현저히 저하시킬 수 있습니다.

- 잊어버렸던 과거 지식을 필요할 때 언제든 다시 불러올 수 있습니다.

KMS라는 거창한 솔루션이 필요한게 아닙니다. 그냥 카테고리화 할 수 있고 검색할수 있고 약간의 템플릿을 구성할 수 있는 게시판이면 족합니다.

외부 시스템을 인수 받아서 운영을 해야 할 경우, 전달 받아야 할 산출물을 생각해 봤다.

유스케이스 명세서, 기능 차트, 제품 백로그와 같은 실제 구체적 산출물은 개발 방법론 혹은 프로세스에 따라 달라지기 때문에 필요한 항목과 설명을 우선하고 예시로 산출물을 제시한다.

또한 자체 개발일 경우 개발 과정에서 산출되어지는 산출물은 배제되었다.

산출물 예시는 아래와 같다. 좀 과한 느낌? 필수와 옵션으로 나누면 될터이다.

마지막으로.. 이런 건 정답 없다!

그 자리를 대신 할 사람은 많지만, 그 사람을 대신 할 사람은 없다

프로젝트를 관리하다 보면, 제일 어렵고도 중요한 것이 사람이라는 생각이 듭니다.

유용한 많은 기법과 방법론들, 자동화된 각종 도구들이 많은 업무를 깔끔하게 처리해 주지만

'결국 일은 사람이 하는 거다' 라는 말 처럼 사람이 근간이지요.

모든 프로젝트 팀이 혹은 모든 팀의 구성원이 높은 열정을 지속하기 힘든 게 현실입니다.

업무의 비전, 당면한 처우, 상대적 박탈감과 같은 다양한 사건들이 항상 우리의 열정을 끌어 내리려 합니다.

문득 책일 읽다가 좋은 표현을 봤습니다.

'그 자리를 대신 할 사람은 많지만, 그 사람을 대신 할 사람은 없다'

말 장난 같은 이 말을 가만히 들여다 보면, 참 감동되는 말입니다.

'자네 아니라도 그 일 할 사람 많어!!!' 라는 일침을 가하기 전에 생각해 보아야 할 문제입니다.

실제로 그 일 할 사람은 많을지 모릅니다. 그게 현실이다 보니 직업 불안정성은 언제, 어디나 있죠.

(죄송합니다. 저도 가끔 이와 유사한 말을 내뱉은 적이 있습니다)

그런데 좀 더 본연으로 들어가 보고 싶습니다.

업무가 아닌 사람을 먼저 보고 싶습니다(음.. 대선 후보 같은 말이네요...)

그 사람 만이 가진 능력, 개성은 아무도 대체할 수 없습니다.

박애주의냐구요?... 아닙니다.

저는.. 성과지향, 경쟁을 통한 쟁취, 현실적.. 이런 단어들과 친숙한 사람입니다.

다만,

사람에 대한 이해와 공감을 선행하고 그 사람만의 개성과 능력을 발휘할 수 있도록 도움을 주는 것이 관리자가 갖추어야 할 덕목이라는 말을 하고 싶은 겁니다.

노력 해야죠.