티스토리 뷰

안녕하세요. 김승진입니다.


프로젝트라는 것이 고객의 요구로 시작해서 그 요구를 달성하는데 목적이 있다고 합니다.

하지만 최근 SharePoint 기반 프로젝트를 하면서 재미난 경험을 하게됩니다.


첫번째, 고객의 요구대로 시스템을 만들었더니 괴물을 만들다.


고객은 솔루션을 생각보다 잘 이해하지 못합니다.

적지않은 비용을 들여 솔루션을 구매하는데 해당 솔루션을 이해하지 못하고 구매한다는 것이 쉽게 납득하지 못 할 수도 있습니다.

하지만 우리나라 대기업의 SW구매 절차나 의사결정 과정을 생각한다면 당연한 결과일지 모릅니다.


SharePoint를 어떤 사람은 포탈 솔루션이라고 하고 어떤 사람은 협업, 또 어떤 사람은 ECM, WCM, 아카이빙 솔루션 이라고 합니다.

표현은 다르지만 모두 맞는 이야기 입니다.


때문에 고객은 제품의 브로슈어나 영업담당자의 이야기, 때론 데모 시연 등만 보고 자기가 이해하고 싶은대로 이해해 버립니다. 그리고 일반 SI개발 프로젝트 처럼 개발 요구사항을 정의하고 시스템 구축을 진행합니다.


처음에는 문제가 없을 수도 있습니다.

그러나 시간이 지난 수록 이 프로젝트가 왜 SharePoint를 도입했는지 망각하게 되고 프로젝트는 산으로 가고 있다는 사실을 알게됩니다.


무엇이 잘 못되엇을까요?


비지니스 솔루션 기반의 프로젝트는 고객의 요구사항 만으로 요건분석단계가 끝나지 않습니다.

고객 뿐 아니라 솔루션아키텍트(SA), 어플리케이션아키텍트(AA)가 함께 개발 요구사항을 제시하고 조정하는 단계가 필요합니다. 오히려 고객은 목적과 목표에 대해서 이야기하고 상세 요구사항은 SA, AA가 제시하는 것이 맞는 방법이라고 할 수 있습니다.

이때 더욱더 다양한 시나리오와 사용자 편의성, 업무 생산성을 높이는 결과를 가져다 줍니다.


과거 경험했던 SharePoint 프로젝트를 보더라도 고객 주도로 구축되었던 시스템은 얼마가지 못해 문을 닫았던 경험이 있습니다. 반대로 프로젝트팀의 아키텍트가 중심이 되서 시스템 구조를 설계하고 개발 요구사항을 제시 할 때 만족도가 높은 시스템이 만들 수 있습니다.


두번째, 모든 기능은 다 쓰라고 만든 것이 아니다.


처음 SharePoint를 접하는 사람들에게는 마법같은 솔루션입니다.

Site Collection, Site, List, Library, Item 등 SP객체에서 부터 Search Service, Managed Metadata Service, Business Data Connectivity Service, Excel Service, Workflow, Social 등 조합한다면 못할게 없는 솔루션 처럼 보입니다.

하지만 시스템은 목적이 분명하고 단순 할 수록 잘 활용됩니다.


문서자산화 시스템을 만든다면 ECM와 관련된 기능들만 조합하여 설계를 하면 되고 홈페이지를 만든다면 WCM, 결재/승인 시스템을 만든다면 Library, InfoPath, Workflow 를 이용하여 설계하면 된다.


하지만 왠지 SharePoint 프로젝트를 하면 BI기능을 이용하여 EIS 도 구축해야 할 것 같고 Social Feed 기능을 이용하여 사내SNS도 구현해야 할 것 같은 환상을 갖게됩니다.


하지만 목적을 분명이 해야 합니다.


세번째, 기본 UI 템플릿은 필수가 아닙니다.


국내의 대부분의 프로젝트는 SharePoint 기본 템플릿에 


1. 마스터 블랜딩 작업

2. 웹파트 개발


작업으로 이루어 집니다.


그러다 보니 매번 나오는 이야기 UI/UX가 한국적이지 않다, 불편하다, 리본메뉴는 누가 쓰냐, 안쓰는 메뉴가 너무 많이 노출된다 등

매번 듣는 이야기 입니다.


하지만 이것이 SharePoint의 한계라고 정의하는 것 또한 문제가 있습니다.

SharePoint 자체를 Data Layer로 규정하고 Presentation 영역은 Silverlight 또는 JQuery 기반으로 설계 할 수 있습니다.

경우에 따라 C/S프로그램만 이용하도록도 할 수 있겠죠.

(활용 사례 - 전자FAX수신 시스템, 스캔관리시스템, 전표관리시스템 등)


다만 이경우 UI를 기획/설계/개발 비용이 더 들어갑니다.

하지만 원하는 UI/UX를 구현할 수있습니다.


무조건 SharePoint 기본 UI템플릿은 필수라고 생각할 필요는 없습니다.


네번째, 다시 강조해도 부족한 설계의 중요성!!


업무의 목적, 사용자의 수, 자료의 규모, 권한 체계 등에 따라 설계는 무척 다양해 질 수 있습니다.

POC가 아닌 이상 전체 프로젝트 비용 중 설계의 비용을 아끼지 마십시오. 

제 개인적으론 개발비율보다 높게 산정하라고 조언하고 싶습니다.


SharePoint 잘 못된 설계는 DB처럼 튜닝처럼 손쉽게(?) 이뤄지지 않습니다.

경우에 따라 사용자의 업무 패턴이 바뀌어야 하는 상황이 발생할 수도 있습니다.


작은 규모에서는 크게 고려되지 않을 수 있지만 사용자 수가 3~400명 이상만 되어도 설계는 무척 중요합니다.


다섯번째, ShaerPoint는 느리다???


정확히 이야기 하면 SharePoint이기 때문에 느린 것이 아니라 뭔가 잘 못 쓰고 있기 때문에 느린 것입니다.

다음 몇가지만 지킨다면 아주 빠른 SharePoint를 만날 수 있습니다.


1. 시스템의 시작페이지는 사이트페이지가 아닌 어플리케이션페이지를 이용합니다.

이유는 어플리케이션페이지에서 ASP.NET 캐시, 객체 캐시 등을 더 적극적으로 이용할 수 있습니다.

대부분 시작페이지를 사이트페이지에 목록 웹파트를 여러게 나열하여 배치합니다. 좋은 선택은 아닙니다.

2. Database의 Data/Log File에 대한 Auto-Growth 셋팅을 고정 값이 아닌 비율로 가져가길 권장합니다.

자료가 기본 250M까지 등록할 수 있는 2013버전의 경우 Growth 값이 1M, 10M라면 File증가에 속도가 지연될 수 밖에 없습니다. 따라서 Auto-Growth 값은 비율로 가져가길 권장합니다.(다만 디스크의 여유율은 25%이상 되도록 관리 되어야 합니다.)

참고 : http://technet.microsoft.com/ko-kr/library/hh292622.aspx

3. 항목에 대한 권한 예외 처리를 줄여야 합니다.

이부분은 비지니스 시나리오와 관련한 부분이라 어려운 부분입니다만

SharePoint 속도를 가장 많이 느리게 하는 것은 권한 예외 처리입니다.

(목록 내에서 특정 항목에 대해 권한 상속 중지를 선언하는 경우)

반드시 권한예외 처리를 해야하는 상황이 아니라면 '목록 뷰'를 이용한 필터를 적극적으로 이용해야 합니다. 

4. 개발 코드1 - SPList Items의 반복적인 호출 제거 해야 합니다.

목록의 항목을 호출 할 때 반복적으로 항목의 속성에 접근하게됩니다.

이 경우 객체 캐시를 이용하지 못하게 됩니다.

5. 개발 코드2 - 잘못된 쿼리 호출 제거(SELECT TOP 2147483648) 해야 합니다.

개발자들이 SPQuery를 작성 할 때 제한항목 갯수와 컬럼 수를 지정하지 않는 경우가 많습니다.

이런 경우 내부적으로 SELECT TOP 2147483648 같은 어머어마한 쿼리가 호출됩니다.

5.1 SPQuery에 RowLimit만 추가하여도 속도가 많이 개선됩니다.

5.2 SharePoint내부 API에서도 이러한 코드가 호출되는 것을 보게 됩니다.

목록의 총 갯수를 호출할 때는

SPContext.Current.List.Items.Count 보다 SPContext.Current.List.ItemCount를 이용해야만 합니다.

(2013에서는 확인하지 못했지만 MS내부적으로도 튜닝이 필요해 보입니다.)

http://apmblog.compuware.com/2010/03/18/how-to-avoid-the-top-5-sharepoint-performance-mistakes/


해당 문서는 지속적으로 업데이트 예정입니다.(2013.09.12)

저작자 표시 비영리 변경 금지
신고
댓글
댓글쓰기 폼