1.
서버학 개론
2015.7
김수보 (http://subokim.wordpress.com)
kimsubo@gmail.com
앱서비스 개발사례로 본

2.
강의대상
2
아무것도 몰라요 코드는 짜봤어요 제가 핵심개발자 리딩 해봤어요. 설계할 줄 알아요.
앱 개발 서비스 사례를 중심으로…

3.
용어정리
3
Linux
Apache
Tomcat
*.jar
서버 어플리케이션
-개발자가 코딩을 해서 기능이 작동하는 실행파일
- ex. *.jar, *.js, *.py …
웹 어플리케이션 서버(WAS)
- 서버 어플리케이션이 동작할 수 있도록 해주는 실행 소프트웨어
- 웹 프로토콜로 호출이 가능하게 해준다.
- 기본적으로 깔려 있지 않고 설치를 해야 한다.
- ex. Node.js, Tomcat, Django …
웹서버
- 웹 페이지를 PC나 단말로 보내주는 기능을 하는 프로세스
- 기본적으로 깔려 있지 않고 설치를 해야 한다.
- ex. Apache, nginx
서비스
- 서버 어플리케이션들이 모여서 무형의 서비스를 제공해주는 단위
- ex. 인증 서비스, 찜하기 서비스
프로세스 vs 어플리케이션 vs 프로그램
- 프로세스 : 서버에서 메모리를 점유하고 있는 단위
- 어플리케이션 : 기능을 제공하고 있는 단위
- 프로그램 : 소프트웨어 개발자가 개발한 결과물을 통칭
- 막 혼용해서 사용됨
막 혼용되어서 사용되지만, 그래도 알아는 둡시다.

4.
서버 개발자가 부닥치게 되는 것들
4
구분 내용 실력 늘이기
어플리케이션 개발 • 기획에 맞게 기능을 개발하는 것을 말합니다. • 프로젝트를 많이 해보시고, 좋은
소스를 많이 보세요.
모델링 • 서버는 눈에 보이지 않기 때문에 모델링이 중요합
니다. 기능이 많거나 협업을 해야 한다면 필수.
• 기초가 매우 중요. 좋은 책과 강의
로 공부를 하세요. 창의력과 논리적
사고가 중요합니다.
서버 엔지니어링 • 여러 개의 프로세스나 기능이 하드웨어 상에서 잘
작동하도록 튜닝 하거나 구조를 잡는 작업을 말합
니다.
• 책도 없고 가르쳐 주는 곳도 없습
니다. 현업에서 배우는 수 밖에 없습
니다. 이론과 현장의 느낌이 많이 다
릅니다.
시스템 엔지니어링 • 서버라는 하드웨어 자체를 튜닝하는 일을 말합니
다. OS 설정을 변경하는 일이 많습니다.
네트워크 개론 • 사설 네트워크에서는 이상하게 작동하는 경우가
있습니다. 부하분산이 이상하게 작동하기도 합니다.
장비 문제는 대부분 어플리케이션 변경으로 대처합
니다.
시스템 소프트웨어 • Web Server, WAS, DB 등에 대해 충분한 지식이
있어야 합니다. 서비스 목적에 맞게 기능과 성능을
100% 활용할 수 있으면 좋습니다.
• 홈페이지, 구글링을 통해서 단편적
으로 해결할 수 있습니다.
• 벤더 교육을 별도로 받으세요.
아키텍쳐링 • 이 모든 것을 이해해서 전체적인 구조를 잡는 것
을 말합니다.
• 좋은 스승이 필요합니다. 경험이
없으면 좋은 설계를 하기 힘듭니다.
그래서 좋은 선배를 만나는 것과 다양한 환경에서 일하는 것이 중요합니다.
스타트업에 있다면 아래 것은 다 개발자 몫입니다. 다른 경우도 비슷합니다.

5.
가상의 앱을 만들어 봅시다.
5
① 제가 경험했던 것으로는 발표할 수 없어서
② 가장 유명하면서도 설명하기 쉬운 앱으로 선정
③ 설명을 위해서 핵심적인 내용만 추려서
④ 경험을 섞은 사례를 만들었습니다.
Anstagram

6.
앱 + 서비스
6
☞ 해결하고 싶었던 문제점들
- 모바일 사진은 그다지 멋있지 않다. 필터가 전문가의 사진처럼 보여줄 것이다.
- 여러 플랫폼에 공유하는 것이 힘들다. 당신은 찍어라. 우리가 공유해 주겠다.
- 사진을 업로드하기 힘들고 오래 걸린다. 우리는 빠르고 간편하게 만들고 싶다.
☞ 우리의 미션
- 내가 경험하는 멋있는 순간들을 사진을 통해 친구들과 나누고 싶다.

7.
제공하고 싶은 기능
7
Home – Timeline
- 팔로워들의 사진이 올라온다
- 좋아요와 댓글들이 요약되어
보여진다.
사용자 수 * 컨텐츠 수
Filter & Upload
- 사진을 선택해서 필터한 후
- 서버에 업로드 한다.
전송 Fail, 사진의 크기
해상도
My Info
- 내 정보와 내 소개
- 내가 찍은 사진들이 보여진다.
내 팔로워, 팔로잉 수
Popular
- 인기 사진들이 보여진다.
- 내 성향과 비슷한 사진들이 보
여진다.
인기사진 추출 정책
사용자 수 * 추천 페이지 수
Notification
- 내 팔로워의 알림을 수신한다.
- 내 사진에 일어난 일들을 수신한다.
사용자 수 * 알림 수
Photos
- 내가 찍은 사진과
- 좋아요와 댓글들이 모두 보인다.
태그, 좋아요, 댓글
알림

8.
구현해야 할 세부 기능들
8
타임라인
팔로잉
댓글
# 검색
사진 필터
해상도 조정
전송기능
타임라인
동기화
사진 보기
댓글보기
좋아요
댓글달기
타임라인
동기화
인기사진
선정처리
선호사진
선정처리
실시간 추천
사용자 검색
좋아요 알림
댓글 알림
친구활동
알림
푸쉬기능
내 정보 조회
변경
내 팔로우
정보
내 사진 조회
위치기반
조회
사용자 인증
이메일 확인
비밀번호
조회, 변경
SNS 공유
보안기능

9.
실제 서버 구조 둘러보기(2011)
9
※ 번역글 : http://bit.ly/instatechhist
※ 원 문 : http://instagram-engineering.tumblr.com/post/13649370142/what-powers-instagram-hundreds-of-instances
가입자 1,400 만명, 서버 수백 대, 개발자 3명
- 심플하게 유지한다. (=기능의 추가 및 변경, 관리가 용이한 구조로 만든다.)
- 바퀴를 재발명 하지 않는다. (=가능한 인프라를 활용한다.)
- 가능한 명확하고 증명된 방법을 이용한다. (=최신기술의 시행착오를 줄인다.)
DNS DNS
WAS WAS WAS
DB #1 DB #2 DB #3
WAS
1번유저 2번유저 3번유저
nginx 를 이용하여 Round Robin으로 호분배
 현재는 Amazon의 ELB를 사용
 DNS는 Amazon의 Router53 사용
 SSL과 ELB레벨 종료 (성능향상)
High-CPU Extra Large 25대
- 7GB Memory
- 20 Unit
- Django
Quadruple Extra Large 12대
- PostgreSQL
- Horizontal Sharding
Image
Server
Amazon S3
Cache Server Amazon CloudFront
Search PostgreSQL  Apache Solr
- Geo Search에서 Media Search로 확장
Feed Redis
Cache Memcached  Elastic Cache
Push
Open Source twisted
- Pyapns
- 200개 worker
Monitoring Munin, Pingdom, PagerDuty, Sentry
- 100대 이상의 서버관리
Scale Out
Scale Out

10.
사용자와 사용량의 증가
10
☞ 사용자의 증가(2010~2013) ☞ 사진 업로드량의 증가 (2010~2012)
☞ 서비스 회사의 투자와 기대수익의 패턴

11.
서비스 성장에 따른 기술구조 변화
11
정답은 아니지만 많은 서비스가 이러한 성장 패턴을 따라 갑니다.
단말 어플
서비스로직
인프라 임대
단말 어플
서비스로직
임대 인프라
상용 데이터
단말 어플
서비스로직
임대 인프라
상용 데이터
인프라 구축
단말 어플
서비스로직
임대 인프라
상용 데이터
인프라 서비스
인프라 구축
파일럿
서비스오픈
수익화
플랫폼화
프로젝트 팀 서비스 사용자 제휴 사업자 연계 서비스
• 아이디어를 시스템화
하는 단계
• 유즈케이스 정리
• 데이터항목 정리
• 사용자 패턴에 적합
한 기술구조로 구축
• 실전 데이터 축적
• 클라우드 인프라
• 제휴사업 기능 개발
• 수익화 로직 추가
• 제휴사업용 데이터가공
• 3rd Party 기능 개발
• 수수료 기반 유통플랫폼
개발

12.
스타트업에 필요한 기본 서버들
12
분류 서버 내용
서비스
관련
DNS 서버 도메인(예: ok.co.kr)을 구매해야 함.
보통 Whois  개인 DNS  Smart DNS
웹서버 Apache, nginx
웹 서비스, 이벤트의 랜딩페이지
아이디, 비밀번호 찾기
API 서버 Node.js, Django, Tomcat …
REST API 권장, 인프라는 J2EE 많이 사용함
DB 서버 초기 파일럿은 Document oriented database(mongodb) 권장
상용 서비스는 RDBMS (MySQL, Maria DB) 권장  이유는 구두 설명
업무관련 메일 서버 구글앱스, 네이버웍스, 다음 스마트 워크
블로그 서버 네이버 블로그, 티스토리, 워드프레스
보안 서버보안 서버 해킹에 대한 대처
서버, 네트워크 : Linux Default Firewall 사용
DB 보안 : 제한된 ip, port 보안
아무리 작게 만들어도 최소한 아래 정도의 서버를 구축하게 됩니다.
• 웹서버, API 서버, DB서버를 1대 내에 설치는 가능하지만 보통 DB서버는 따로 설치합니다.
• 초반에는 CPU, 메모리 사용률을 기준으로 서버를 나누기도 합니다.

13.
아무도 말하지 않지만 만들게 되는 기능들
13
분류 기능 설명 일반 대처방안
서비스
공통기능
로그인 기능 트위터, 페이스북, 구글, 자체 ID로그인 기능 오픈 API & 직접 구현
회원 가입 ID찾기, 비밀번호 찾기(질문,답변)
국내) 어린이, 성인, 외국인
직접 구현
단말 인증 1사람이 여러대의 단말 사용
유효한 단말인지 인증
Oauth 시스템 직접 구현
구글 앱엔진 이용
이메일 인증 이메일이 유효한지 체크하는 로직 직접 구현
푸쉬서버
(알림기능)
안드로이드, 아이폰 동시 발송 (버전별 대응)
대량 전송 가능, 안정된 성공율
오픈 API 활용 or 직접 구현
컨텐츠 관리 신고, 차단, ID정지, 스팸 필터링
컨텐츠 노출 차단 및 컨텐츠 삭제
직접 구현
SNS 공유 트위터, 페이스북 등 SNS 공유기능
인증 토큰 관리, 호출건수 관리
오픈 라이브러리 활용
서버 모듈은 직접 구현
데이터 암호화 비밀번호, 특정 정보는 암호화 암호화 모듈은 오픈 라이브러리 활용
암호화 프로세스는 직접 구현
국내 실명 인증 아이핀 인증, 휴대폰 인증 공공 API 연동
결제 모듈 카드사 연동, 현금 이체, 포인트 연계 API 연동, 법인등록(유통판매업 신고)
관리기능 서버 모니터링 서버 상태 감시 (메모리, 디스크, 프로세스 상태)
네트워크 상태 모니터링
직접 구현
- Ganglia, Munin, Zabbix
서비스 모니터링 서비스 현항에 대한 각종 통계
(요청 건수, 일일 누적 건수, 에러 건수 등)
1 Call 응답시간
Google Analytics 권장
사후 통계는 개발
실시간 통계는 오픈 라이브러리 활용

14.
여기서 짚고 넘어가는 클라우드
14
구분 BEFORE AFTER 비고
IaaS
- Infra as a Service
- 하드웨어 빌려줌
• 서버를 사서 IDC에 넣음
• ip를 받아 회사에서 접속
• 이미지 서버 개발
• IDC 이용료 (자리이용료
+NW 이용료)
• 웹으로 접속해서 신청버튼
• 그럼 ip가 나옴. 접속
• AWS S3 API를 사용함
• 이용료(무료 ~ 시분할방식)
• cafe24, AWS
• 스타트업에 유리
(초기 비용이 낮음)
• 파일럿 서비스 개발
PaaS
- Platform as a
Service
- 개발 인프라 서비스?
• push 서버를 개발해야 함
• 문자발송 서버도 개발함
• 푸쉬 라이브러리 다운받음
• 문자발송 API 호출함
• 이용료 (무료 ~ 다양)
• parse.com
• 스타트업에 유리
• 제휴전략에 유리
SaaS
- Software as a
Service
• 서버를 삼
• 회계관리 소프트웨어 설치
• 용량 부족시 증설
• 웹으로 신청함
• 로그인해서 사용함
• 이용료를 냄
• 중소기업 대상
• ERP등 필수제품
클라우드는“CPU나 디스크가 놀고 있는 PC들을 모아서 하나의 커다란 가상 컴퓨터를 만들 수 있지
않을까?” 에서 시작되었습니다. 그래도 개발자라면 아래 용어의 차이 정도는 알고 있어야겠지요?

15.
Level 0. 파일럿 단계
15
서버 기능을 만들기 위한 상세한 기능명세가 확정되지 않은 상태입니다.
그래서 기능명세를 확정하는데 초점을 둡니다.
앱을 만들면서 세부 기획 사항들이 결정되는 단계입니다.
서버가 많아야 1~2대 입니다.
구분 설명
기획 • 기획 의도, 철학, 비전, 미션 등이 정의되어 있음
• 개발자가 이해하고 있어야 기술 구조, 기능 구현의 우선순위를 결정할 수
있음
기능명세 • 더 좋은 UI/UX 를 위해 화면이 변할 수 있음
• 더 좋은 선택을 위해 비즈니스 기능이 변할 수 있음
• 실제 사용자들이 어떻게 반응할 수 알 수 없음
핵심
고려사항
• Try & Error를 많이 하기 위해 투자비용(개발시간 외)을 최소화할 수 있는
기술 선택
• 빨리 서비스 기능을 시험해 볼 수 있도록 개발이 간편한 기술
- 기획의도를 제대로 구현할 수 있어야 함.
- 완성도 보다는 기획 의도의 올바른 구현에 집중
• 사용자들의 반응을 추적할 수 있도록 기술적 장치 필요

16.
Level 0. 파일럿을 위한 기술 구조
16
단말 로직
단말 화면
Node.js
mongodb
1. 가능하면 PaaS를 활용하세요.
- 서버를 맨 땅에서부터 구축하지 않아도 됩니다. 그리고 여러 가지 프레임워크
와 인프라를 제공하기 때문에 핵심 로직에 집중할 수 있습니다. 주요 사이트로
는 구글 앱엔진, Parse.com 이 있습니다.
2. 사용자 피드백 수집은 Google Analytics를 활용하세요
- 추적하고 싶은 내용을 설계하고, 서비스 코드에 삽입해야 합니다.
- 사용자들이 기획의도대로 쓰고 있는지 확인할 방법을 미리 결정해야 합니다.
※ 자료 : 오늘 밤부터 쓰는 GA
http://www.slideshare.net/yongho/ga-47277482
3. DB로는 mongodb를 추천해요.
- mongodb는 데이터모델링을 미리 하지 않아도 좋습니다.
- 처음에는 화면과 DB를 1:1 매핑해서 쓰세요.
4. 독립서버를 구축해야 한다면 mean.io를 써보세요.
- mongodb + express.js + angular.js + node.js
- JavaScript Full Stack 입니다.
5. 이 기간동안 정리해야 할 것
- 서버 개발은 눈에 보이지 않기 때문에 모델링이 중요합니다. 모델링이 필요없
을 정도로 간단한 경우가 아니라면 어플리케이션 모델링을 해두세요.
어플리케이션을 만들 때 변경이 용이한 스크립트 기반 언어 사용을 추천합니다.
이 기간 동안에는 어플리케이션 모델링을 튼튼하게 하세요.

17.
Level 0. 중요한 모델링
17
화면개발은 로직이 화면의 움직임에서 시작되는 경
우가 많습니다. 그래서, 굳이 UML을 쓰지 않고도 쉽
게 어플리케이션의 구조를 파악할 수 있습니다.
그러나 서버는 눈에 보이지 않습니다. 그래서 UML
모델링이 필수적입니다. UML은 복잡한 서버개발을
위한 설계도입니다.
그러나, 기능 중심인 게이트웨이 서버는 UML을 만
들지 않습니다. 비즈니스가 없기 때문입니다. 이런
중계 서버는 Call Flow가 더 중요합니다. 하지만,
SNS서비스라면 아마 초반에 중계 서버를 만들 일이
없을 겁니다.

18.
Level 0. 채팅을 만들어야 해요.
18 연산처리
Parser
연산처리
Parser
DB
화면
Text(JSON, XML)
http
http
socket
socket
get, post, put, delete
connect, transfer
disconnect
Disconnected
Oriented
Transaction
Connected
Oriented
Transaction
자료를 요청할 때마다 연결을 맺음
다수의 사용자가 자원을 공유해서 써야 할 때
속도를 희생
불특정 다수의 요청을 처리하는 서비스에 적합
이미 연결된 채널에 데이터 요청을 함
응답이 빠름. 그러나 서버쪽 자원소모가 큼
인프라 내부 구성에 적합
채팅은 서버 쪽이 얼마나 자원을 소모하는지 측정해 두어야 함.
채팅방이 많을수록 메모리 사용량이 늘기도 함
잘 짜면 사용자가 많을 때만 메모리 사용량이 늘어남
일반적인 웹 서비스 개발의 경우 REST API가 바이블입니다. (CRDU)
채팅과 같은 경우는 Socket 통신. 웹이라면 node.js + socket.io 를 써보세요.

19.
Level 1. 서비스 오픈 단계
19
서버 기능을 만들어도 좋을 만큼 상세한 기능명세가 확정된 상태입니다.
서비스 오픈을 한 후에도 기능의 추가와 삭제가 적지 않게 일어납니다.
사용자가 에러 때문에 이탈하지 않게 완성도를 높여야 하는 단계입니다.
서버가 10여 대 이하입니다.
구분 설명
기능명세 • 대부분의 화면이 확정되어 있지만 사소한 변경들은 발생
• 중요한 기능들은 정해졌지만 로직 변경과 기능 추가는 계속 생김.
• 서비스의 지표(사용량, 사용패턴)를 알 수 있어야 함.
핵심
고려사항
• 기능의 추가, 현재 모듈의 변경 비용이 기하급수적으로 늘어나지 않게
- 느슨한 모델링
- 기능 재활용이 가능한 구조
• 충분한 어플리케이션 완성도
- 최소한 사용자 이탈의 원인이 되지 않아야 함
- 오류 빈도가 높은 것보다 기능이 없는게 낫다.
• 서비스 안정성이 중요
- 사용량 증가로 인한 서버 장애는 즐거운 일
- 반면 작은 증가에도 서버 어플리케이션이 죽는다면 안될 일
- 관리하기 편리한 기술 구조
• 서비스의 지속적인 모니터링이 중요
- 사용자 반응은 Google Analytics로 추적이 가능
- 전체 사용량과 이용통계는 별도로 구축해야 함

20.
Level 1. 서비스 오픈을 위한 기술 구조
20
단말 로직
단말 화면
Node.js / Django
MySQL
1. 여전히 PaaS를 활용하세요.
- 핵심 서비스 로직에 집중하기 위해서 PaaS는 여전히 편리합니다.
- 사용량 증가에 따른 대처방안도 고민해야 합니다.
※ 참고 : 왜 레진코믹스는 구글앱엔진을 선택했나?
http://www.slideshare.net/curioe_/lezhincomics-google-appengine-30453946
2. 서비스 지표를 정하세요.
- Google Analytics는 이미 기본입니다. 사용자들의 변화를 눈치챌 수 있는 지표
여야 합니다. 시스템의 사용량도 알 수 있어야 합니다.
3. RDBMS를 추천해요.
- 사전에 데이터 모델링을 해야 하는 불편함이 있습니다. 분석시스템을 따로 만
들지 않으려면 RDBMS가 편리합니다.
4. 독립서버를 구축한다면 구글앱엔진을 써보세요.
- AWS와 구글앱엔진은 장단점이 다릅니다. 비용, 서비스 성격, 개발인력 등의 변
수에 따라 선택이 달라집니다.
5. 이 기간 동안 정리해야 할 것
- 복잡해지는 모델링의 현행화
- 사용량 증가에 대응하기 위한 기술 구조 (자동 배포, 모니터링, 병목구간)
- 복잡성에 대비한 어플리케이션 구조(모듈 분리, 기능 공통화 등)
- 지속적인 리팩토링과 리엔지니어링 필요 (필요수준에서)
Batch Server
어플리케이션을 다시 개발하세요. 파일럿 경험을 바탕으로 기술 구조도 다시 잡고요.
나도 모르게 Batch Server란 걸 만들게 되는 단계입니다.

21.
Level 1. 단말팀과 계속 싸우게 되요
21
작업을 어떻게 나눌 것인가로 자꾸 싸우게 되나요? 우선 어플리케이션 모델에 합의를
하세요. 일반적으로는 Thin Client를 선호합니다.
※ 출처 : http://www.leaseweblabs.com/2013/10/api-first-architecture-fat-vs-thin-server-debate/

22.
Level 1. 데이터베이스를 선택해 봅시다.
22
데이터베이스 SW는 그 특징과 사용방법이 달라서 미리 공부해야 합니다. 구현해야 할 서비스로직과
어플리케이션의 성격에 따라서 선택이 많이 달라집니다. 포털 쪽은 mongodb, MySQL을 많이 쓰고
일반 기업들은 Oracle을 많이 쓰고 있습니다. 물론 둘 다 섞어 씁니다.
구분 종류 설명
NoSQL mongodb 페이지 단위의 데이터 조작이 많을 때
대량 데이터에 유리
HBase SQL을 지원. Hadoop 위에 설치
RDBMS MySQL 소호규모에 유리 But 글로벌 서비스에도 많이 씀
Maria DB MySQL을 오라클이 인수하자 개발자가 새로 만든 DB
PostgreSQL Spatial 검색기능이 장착된 DB
Oracle 백업과 복구기능이 매우 강화된 DB
SUN 인수 직후 구글과 특허분쟁을 함으로써 악의 축으로 등극
Memory DB Redis Key-Value 타입의 메모리 데이터 조작
Memcached 캐시 서버. DB가 추가로 있어야 함
Altibase 상용 DB 서버. SQL 지원. 다양하고 복잡한 기술 지원

23.
Level 1. 웹 개발도 해야 되요
23
※ 출처 : http://www.optisolbusiness.com/insight/how-to-integrate-angularjs-with-rails
웹 브라우저 상에서 안드로이드 앱처럼 동작하게 만들기도 합니다. 그러다보니 웹 화면도 MVC 패
턴으로 설계를 해야 합니다. 엄밀히 말하면 프론트 엔드 개발자의 영역이지만, 서버개발자로 일이
넘어오는 경우도 있습니다. 가능하면 프론트 엔드 개발자를 찾아 보세요.

24.
Level 2. 수익화 단계
24
사업 담당자가 제휴사업계획를 가지고 옵니다.
서비스와 별 관련이 없는 듯한 새로운 숙제를 받은 듯한 느낌이 듭니다.
개발량도 만만치 않고 애자일을 포기하고 싶은 유혹도 생깁니다.
이 때는 별도의 개발팀이 필요한 단계입니다.
그간 관리했던 상세한 모델링 데이터가 가장 필요해지는 시기입니다.
서버가 30~40대 정도로 불어납니다.
구분 설명
기능명세 • 제휴 조건에 따라 구현해야 할 기능의 내용이 바뀜.
• 일반적으로 API 연동을 많이 사용함 (기능 공유, 데이터 전달)
• 광고는 서비스 화면에 표현되는 경우도 있음
핵심
고려사항
• 서비스 로직의 청결 유지
- 제휴 기능의 변화, 중지, 추가에도 서비스 흐름이 안정적일 것
- 제휴가 늘어나도 서비스가 불편하지 않을 것
• 제휴 인프라는 별도로 구축해야 함
- 수익성 트래픽을 서비스와 분리
- 정확한 계량과 정산 처리가 필요함

25.
Level 2. 수익화를 위한 기술 구조
25
단말 로직
단말 화면
Node.js / Django
MySQL
1. 제휴 인프라는 별도 구축하세요.
- 서비스 간섭 현상을 방지하기 위해 서버를 따로 구축하세요.
- 정산, 결제, 인증 등은 공통 인프라로 별도 구축하세요.
2. API로 트랜잭션 분리
- 서비스와 제휴는 개발과 운영 방법이 상이합니다. 그리고 어플리케이션이 서로
다른 라이프사이클을 가지고 있습니다. API로 연동하시고 에러처리를 잘 해서
장애파급이 나지 않게 잘 분리하세요.
3. 어플리케이션 구조의 단순화
- 제휴가 복잡해질수록 서비스가 복잡해지게 됩니다. 관리하고 대응하기 쉽게
어플리케이션을 자주 리팩토링하세요. 그리고 필요하면 서버 리엔지니어링도 하
세요.
- 중요한 건 개발자가 변경 관리하기 쉽게 유지하는 것입니다.
5. 이 기간동안 정리해야 할 것
- 팀간 협업문제가 발생하므로 업그레이드 계획이나 사전 테스트가 중요해집니
다. 그리고 배포 후 확인 절차도 중요해집니다. 따라서 제휴 인프라와 서비스 간
에 연계된 서버 및 어플리케이션 호출 구조 등이 눈에 보이는 문서로 관리되어
야 합니다.
Batch Server
제휴 인프라
풀이법이 다양하지만 하나인 듯 하나가 아니게 구축해야 하는 숙제입니다.
API 기술을 잘 활용하세요.
모든게 까다로워지고, 유지보수 노력이 갑자기 두 배 이상 증가되는 시기입니다.

26.
Level 3. 플랫폼화 단계
26
여기까지 왔다면 이미 몇 차례의 투자를 받았을 것이고,
회사가 충분히 돈을 벌고 있을 겁니다.
좋은 CTO를 모시고 좋은 전략을 가지고 문제를 풀어가시기 바랍니다.

27.
산업별로 서버의 기술 구조가 다릅니다.
27
구분 포털 금융권 이동통신사
비즈니스 환
경
• 많은 사용자가 많이 조회
• 단순 조회성 트래픽 중심
• 응답시간이 느리면 사용자 이탈
• 화면 구성이 빠르게 변화됨
• 신규 기능의 추가 빈도가 높음
• 서비스 간의 의존도가 적음
• 일정한 사용자 일정한 사용 패턴
• 응답시간이 느려도 대기
• 신규 기능이 규제에 따라 생성됨
• 업무가 먼저, 기능은 나중
• 일정한 패턴으로 서비스 연계
• 회선을 다양한 상품으로 패키징
• 통신 인프라 판매 서비스
• 제휴 서비스 선호,유무선 통합 상품
• 회선과 과금 대행 인프라가 핵심
• 무선포털사업은 사라짐
• 최근 전략 변화가 심함
주요 기술
구조
• 대량 단순 조회 트래픽  간단한
기술구조 선호
• 비용절감 이슈로 오픈소스 선호
• 스택 중심의 기술구조
• 느슨한 업무 모델링
• 스크립트 기반의 언어 선호
• 복잡한 아키텍쳐 + 단순한 기능개
발
• 안정성을 위한 상용소프트웨어 선
호
• 통제된 운영 환경과 최적화된 기술
구조
• 컴파일 기반의 언어 선호
• 미들웨어 중심의 트랜잭션 처리
• 업무 변화가 심해 기능 중심의 구조
• 오래전부터 인프라와 플랫폼 공통
• 다양한 장비로 인한 GW 가 많음
• 운영계는 오픈소스, 과금계는 상용
소프트웨어 선호
특징 • 운영 데이터가 사용자 분석을 위한
중요자료로 활용됨
• 운영 개발 (DevOps) 스트레스가 매
우 높음
• 운영업무와 구축업무가 확연히 분
리되며 운영이 보수적임
• 상품이나 서비스의 변화가 심해 업
무 자동화 및 구조화가 매우 어려움
어떤 비즈니스인가에 따라 기술구조가 달라집니다. 따라서 적성에 맞는 직장을 찾는
것도 매우 중요합니다. 산업 영역을 갈아탈 때 많은 경험과 기존 지식들이 인정받지 못
하게 됩니다.

28.
보너스. IDC가 어떻게 생겼지?
28
Internet Data Center
- 일정한 온도와 습도
- 안정된 전력과 정전 백업 장치
- 내진 설계, No 먼지
Server Rack
- 여러 대의 Server, Disk
- 관리하기 편리하게 모아서 배치
HP ProLiant DL360 G3
- Rack 설치용 Blade 타입 케이스
- 강력한 냉각팬
Main Board
- Multi CPU, Multi Memory Slot
- 여러 개의 HDD Bay
- HDD 핫스왑 기능

29.
보너스. 서버가 어떻게 생겼지?
29
Scale Out
- 서버 대수를 늘려서 전체 트래픽 처리량을 늘림
- 서버가 나누어서 일처리 할 수 있도록 하드웨어를
잘 구성해야 함
- 서버가 나누어서 일처리 할 수 있도록 소프트웨어
배치 및 기능 구성을 잘 해야 함
- 블로그 서비스와 같은 경우에 적합
(많은 사용자, 단순한 기능, 빠른 응답)
- 웹서버로 많이 사용됨
Scale Up
- CPU와 메모리를 추가해서 처리성능을 높임
- 메인보드가 허용하는 한계까지만 추가가 가능
- OS (Unix, Windows 등)가 CPU를 인식해야 함
- 1개의 프로세스가 모든 CPU를 사용하지는 못함
- 2개의 프로세스가 2개의 CPU를 사용하도록 구성
해야 함
- 데이터 분석 서비스에 적합
(소수 분석가, 복잡한 연산처리, 많은 데이터 로딩,
후처리가 전처리에 의존적)
- DB서버로 많이 사용됨

30.
보너스. 네트워크가 어떻게 생겼지?
30
Cisco Router
- 데이터 패킷을 전송해준다.
- 인터넷의 실체(?)
L4 Switch
- 특정 ip에만 데이터 전송
Eathernet Hub
- 연결된 곳에 모두 데이터 전송
Redis Server #1 Redis Server #2 Redis Server #3
Router
Router
Router
Router
Internet
- Router와 회선을 타고 형성된 가상의 네트워크

31.
31
Q&A
kimsubo@gmail.com