두리미 Just Do IT

JTBC 종편 개발

기간 : 11.09 ~ 11.12
담당파트 : 뉴스 DB SP,인프라,CMS,서비스페이지,VOD, jquery 공통 ui script 작업
개발툴 : Visual Studio 2010
환경 : .Net Framework 4.0 + IIS 7.5 + MS-SQL 2008

이래저래 말많던(?) JTBC 종편 프로젝트

동시에 네군데의 회사에서 각자 서로의 종편사이트가 12월을 목표로 개발되었을거다.
대충하면 왠지 비교당할수도 있겠다는 생각 + 이젠 방송사 사이트도 만들어보는구나 라는
설레임

컨텐트 수급이 가장 큰 이슈였다.
개국일은 잡혔지만, 시간이 가도 채널 번호도 결정되지 않았고 프로그램도 확실히 정해진게 없었다.

담당했던 부분은 뉴스파트, 나중에 추가로 다른 파트에서 쓸 플레이어 부분 작업을 했다.

- 플레이어

방송사이트에서 동영상 플레이어가 차지하는 비중이 크다.
애초에 자체개발을 했어야 했지만, 개발에 주어진 프로젝트 기간 두달반내에 모든 인프라를 구성할 수는 없었다.  결국 유명한 jwplayer + plugin 를 구매해 도입하기로 했다.

스킨의 자유도도 있고, 쓸만한 광고 플러그인이 있어 나쁘지 않은 선택이었다.
덕분에 올초에 개발되었던 Display Ad 솔루션을 약간 수정해 동영상 광고도 커버할 수 있게 하고 두개를 연결시켜 동영상 광고 수익을 발생시킬 수 있는 환경을 큰 비용없이 구축할 수 있게 됐다.

이번 jtbc 프로젝트의 특징 중 하나는 패드의 접근성을 충분히 고려했다는거다.
(모바일용은 따로 만들었지만 아이패드나 갤럭시탭에서 보기엔 너무 광활하다)
플래시 대신 메뉴나 쇼케이스의 effect를 javascript로 구현했다. 다행히 복잡한 효과가 아니라 가능했다. iPad로 사이트에 들어왔을때 플래시 기반의 jwplayer 대신 html5의 video 태그를 활용해 거의 동일한 사용자 환경을 제공한다. 물론 갤럭시탭도 마찬가지...

- One-Time URL

CDN에서 영상소스를 url로 받아올 때 one-time url 솔루션을 거쳐 인증키를 파라미터로 같이 받아온다.
이렇게 해놓으면 해당 주소로는 호출이 설정에 따라 다르겠지만 1~3회 정도로 제한하거나 유효시간을 걸 수 있어 영상 url의 노출되어도 직접 재생을 막을 수 있다.

인증키를 받아 오는 방법은 소켓통신.
CDN에서 dll 하나와 샘플소스를 보내줬지만, 동작은 잘 됐지만 SVN에 커밋하려고 보니 연결된 모든 개발자가 해당 dll를 자기 pc의 레지스트리에 따로 등록해야 빌드가 깨지지 않았다. 이룬..
결국 유지보수 이슈를 고려해 비슷한 역할을 하는 모듈을 새로 만들기로 했다.
System.Net.Sockets를 참조해 별도의 dll import  없이 구현했다.
이래야 나중에 편하다.

 

- 뉴스

뉴스쪽 개발인원은 3+3.
따로 6층 회의실을 하나 전세(?)내서 모였다.
솔직히 처음에 걱정이 됐었다. 3+3이라고 쓴 이유는 3명이 아직 졸업을 앞둔 대학생 신입들이었기 때문.
"기존인력 셋, 신입사원 셋" 라고 해서 기존 3명을 프로젝트 초반에 바짝 긴장하게 만들었다.
결론부터 얘기하자면 3명의 신입들은 예상보다 잘해줬다.

이런저런 이유때문에 처음 목표는 일정도 일정이니 기존 중앙일보 신문사의 테이블 구조를 그대로 어떻게 잘 한번 묻어가서 UI쪽만이라도 어떻게 잘 마무리 해보자였으나....
기존 구조가 몇년동안 조금씩 조금씩 개선되어가는 과정에서 분석하고 변경하는데 시간이 너무 걸릴 것 같았다.  결국 기획서를 기준으로 모든 뉴스 테이블을 다시 설계했다. 
(내가 아니라 훌륭한 DBA느님께서)

물론 테이블 명세서와 기획서를 참고해 필요한 프로시저는 직접 만들었다.

기사면 html에 플레이어 호출 스크립트를 넣는 것은 jQuery 의 extends 를 활용해 기존의 컨텐트 소스를 건드리지 않으면서 옵션을을 추가할 수 있는 식으로 구현해봤다.

프로젝트 초반에 약간 부지런을 떨어 뉴스쪽 탭네비를 간단하게 구현할 수 있는 jQuery 기반의 공통 플러그인을 개발해놨다. 덕분에 프론트 ui쪽 스크립트 작업 시간을 많이 단축시켰다.

뉴스의 건당로그는 파일기반으로 구현했다.
처음엔 그냥 건당 insert 라는 만용을 부려볼까 했지만,
그러다 네이버 홈에 기사가 노출되었을때 DB가 죽으면 바로 대형사고다.
이런 백엔드 작업까지 모두 처음부터 할려니 힘들었지만 할 수 없다.

파일 로그를 쌓고 분석서버에서 처리후 주기적으로 로그DB에 업데이트한다.
이걸로 많이본기사, 많이본VOD 등의 데이터를 통계낼 수 있다.

이번에 특히 신경쓴 건 운영툴 쪽이었다. 기존 기획서보다 더 편한 방법이 생각나면
운영자들에게 이런건 어떠냐고 물어보고, 꼼수를 부려댔다.
(고백하자면 코딩도 그게 더 간편했다)
 
아무튼 정해진 기간내에 큰 문제없이 오픈한 프로젝트.

기간 : 1M (2011.07)
참여 : 개발(1인), 디자인(1인), 마크업(1인) 

용도 : 고객사 관리, 계약서 파일 관리, 영업히스토리 관리


솔루션 개발팀으로 온 후 첫 1인 프로젝트.
.NET 4.0 + MSSQL로 구현되었다.


업무프로세스 분석 외 기능상 특이점은 없음, 대부분의 CRUD 외
간단한 파일업로드 및 관리기능, 엑셀 출력기능 밖에... 
그래도 보편적인 영업 관리를 위한 기본적인 컨셉과 .NET 프로젝트 기본 구성의 형태로 볼 때
소스를 보관하고 있으면 여기저기 써먹을만 할 것 같다.
대부분의 관리툴의 범주가 여기서 벗어나지는 않을테니...

흔한 업로드 컴포넌트도 안쓰고 막코딩으로 모두 구현.

내부툴이라 URL이나 문제가 될만한 부분은 자체 검열;

개발인원 3명


http://da.opap.co.kr/    

개발기간 2011.2월 중순 ~2011.5월31일
테스트기간 2011년 6월1~30일
오픈시기 2011년 7월 1일

기반 : .NET Framework 4.0 
Window 2008 IIS 7.5 + MSSQL 2008

포털 런칭 후 주 수익모델인 광고관련 시스템을 정비할 필요가 있었다.
솔루션 개발팀이 신설되고, 그쪽으로 배정되어 광고솔루션 개발에 들어갔다.

몇가지 난관이 있었다.

1. 인터넷 광고 업무흐름에 대한 이해.
소재, 슬롯, 인벤토리, 켐페인... 등 인터넷 광고쪽에 관련있으신 분들이라면 쉽게 알만한 말들을
올해 처음 들어 봤다는 것. 솔루션을 만들기전에 업무파악을 하는게 우선이었다.

2. 광고솔루션 로직에 대한 구성
단순히 광고를 등록하면 나오는게 다가 아니라 일정기간동안 목표 노출량을 나눠놓으면 최대한 균등하게.. 그러면서 목표치에 근접하게 노출시키는 로직을 구현하는게 관건이었다. 당연히 이런 정보는 구글링으로 찾아볼 수 없다. 설상가상으로 광고개발 솔루션 경험자도 없었다. 맨바닥에 헤딩하는 기분으로 3명이서 회의를 해나가며 로직을 잡아나갔다. 진행하기로 한 컨셉은 일주일동안 발생하는 Joinsmsn 사이트의 트래픽 비율을 계산해놓고 그 정보를 기준으로 10분당 노출할 비율을 결정해 유료광고를 내보내고, 유료광고가 소진시 하우스 광고를 내보내는 방식이었다.

3. 대용량 트래픽 로그 처리
JoinsMSN은 당연히 네이버 다음에 비할 수는 없겠지만 트래픽이 좀 나오는 편에 속한다.
내가 작업할때는 국내기준 사이트 트래픽 순위 5위~7위를 왔다갔다 했다.
옥션이나 G마켓과 비슷하거나 약간 많은 수준
목표는 하루 2억 PV 이상을 견딜 수 있는 것으로 잡았는데 단순히 노출만 시키는 것이라면 그리 어려운 작업은 아니다. 하지만 건당 log를 모두 저장하고 분석하는 작업이 file io를 많이 발생시켰다.
처음에는 appendLine() 방식으로 트래픽이 발생할때마다 파일에 한줄 더 하는 식으로 구현했었다.
초당 200회 이상의 호출이 누적되자 문제가 생겼다. 큐가 밀리면서 cpu와 메모리 사용량이 급증했다.
최근에 구매했던 [웹개발자를 위한 대용량 서비스를 지탱하는 기술] 에 나와있던 컨셉이 도움이 됐다.
너무나 당연한 방법이지만 메모리에 누적시키다 한꺼번에 파일에 append 시키면서 file access 횟수를 줄였다. 5000라인 정도 쌓으면 한번 쓰는 식으로... 이건 web.config 파일에서 변경할 수 있게 해놨다.
그러다보니 Web Application이 비정상적으로 종료되는 경우 그동안 메모리에 쌓은 로그를 날릴 염려가 있어 그부분을 처리하는 것도 구현했다.
하나의 String Builder에 쌓으니 초당 500 호출이 넘어가면서 단순한 기능인데도 중복요청으로 오류가 생겼다. 파일을 쌓고 지우기 전에 결국 저장소를 분리하는 기법으로 해결했다.

결과적으론 최종테스트 땐 10분에 580만 처리까지 가능했다. cpu는 60% 수준. 더 할수도 있었겠지만 이미 기사에 광고100개가 붙어있다고 가정한 상태의 부하테스트였기 때문에 더이상의 테스트는 무의미했다. 

이번 작업을 하면서 가장 큰 소득이 대용량 파일로그 생성과 처리 부분이었던 것 같다.

추가

학부시절 Java 이후론 한동안 주로 VBScript 방식의 asp 만 해오다가 간만에 다시 c#으로 했다.
아무튼 .NET으로 개발하면서 처음에는 속도가 나질 않았다.  기간이 넉넉하진 않았기 때문에
마음은 시작부터 조급했는데 단위페이지를 처음 개발할때 시간이 많이 걸렸다.
하나의 페이지 템플릿이 나오니 물론 그 다음부터는 수월해졌다.

차트는 늘 하던대로 플래시 기반의 fusion chart 를 쓸려고 했다가...
아이폰에서도 모바일로 볼 수도 있겠다 싶어 javascript 기반 차트로 변경했다.
highchart. 찾아본 javascript 기반 차트 중 UI가 가장 깔끔하게 나오는 차트였다.
물론 라이센스를 구매했다.

웹사이트 신규개발이나 리뉴얼은 많이 했지만 솔루션이라고 부를만한 것은
이번에 개발한 광고솔루션이 처음이라 기념할만 하다.

처음 예상보다 야근도 별로 안하고, 계획했던 일정대로 무난하게 흘러갔던 프로젝트.
협업의 중요성을 다시금 알게된 시간이었다.

그나저나 이걸로 돈 많이 벌었으면 좋겠다.