네이버는 비즈니스 플랫폼(CPC, CPS)에서 대부분의 수익을 얻음(47%)
Line 및 기타 플랫폼이 38% 정도의 수익을 얻음
코드 한줄은 어떻게 빛을 보는가
정민우/PaaS
- Backend, 9년차, 자바, 플랫폼&프레임워크 개발, 현재는 핀포인트(APM툴), 어플리케이션 성능을 모니터링하고 찾아보는 것(제니퍼와 비슷함), 신입사원 경력직 교육을 주로 해오셨음
- 현업의 개발은 어떻게 하는가?
1 개발 시 고려사항
1 사용자
사용자들이 각각 다양한 형태로 접속함, 거의 모든 운영체제, 거의 모든 브라우저에서 전부 접속하기 때문에 이를 효율적으로 해결해야한다.
2 데이터의 양
데이터의 양이 현업에 갈수록, 데이터의 양이 기하급수적으로 늘어남. 동일한 기능을 하더라고 규모가 큰 사황을 고려해서 개발해야한다
3 24/7
24시간 사용자들이 언제든 급격한 트래픽을 일으킬 것이라는 고려를 해야함
4 서비스의 규모
서버의 양이 어느정도 수준이냐고 할 때, 하나의 서비스가 4000대의 서버를 사용한다면, 그 서버를 어떻게 효율적으로 설계할지가 문제됨
2 개발환경
1 OS를 고려하지 않음
2 프로그래밍 언어 - 자바가 대부분, 스파크, Go를 사용하기도 함
3 IDE - 웹개발은 이클립스, 인텔리제이, 애플은 Xcode, 안드로이드는 studio 사용
4 레파지토리 - git을 사용(네이버는 github의 상용라이센스를 사용), svn은 예전에 사용
5 CI(Continuous Integration) - 코드가 정상적으로 동작하는지 계속해서 확인하는 과정(젠킨스를 주로 쓰고, 허드슨도 사용) - 10만줄, 20만줄의 코드를 확인하기가 힘듬
6 배포 서버 - 배포할 수 있는 시스템이 있음. dev, stage, real이 있는데, 여러가지 테스트 단계를 거쳐서 배포하는 과정을 거침
7 빌드 배포는 한번에 됨
3 웹 서비스 구조
http -> 요청 -> Web Server -> WAS(Web Application Server) -> Database
Multi-Server
http -> 요청 -> Web Server -> WAS여러대 -> 분산화된 DB
Add Switch
http -> 요청 -> Web Server 여러대 -> WAS여러대
Add Cache
http -> 요청 -> 웹서버 여러대 -> WAS 여러대는(cache와 연결됨)
Add Batch
http -> 요청 -> 웹서버 여러대 -> WAS 여러대는(cache와 연결됨) -> 분산화된 DB -> 뱃치 서버에서 주기별로 DB에 입력해줌
여러 서비스를 연동해야할 때,
여러 서비스에서 갔다와야 하는데, 요청의 결과가 2개만 실패했다면 그것의 결과를 어떻게 나타날지가 문제됨
이런 것들을 파악해내는 것은 굉장히 힘든 일임. 하나의 문제를 찾기 위해서 몇달이 걸리고 해결을 못하는 경우도 생긴다.
Protocol
각각의 서비스에 서로 다른 프로토콜을 사용함. 각각 서비스마다 프로토콜이 다르면 그것을 연결할 객체를 매번 만들어야함
etc
모니터링, 게이트웨이(API 호출 시), 서버 파일 정보 수집, 한 사람이 모든걸 담당하기가 힘들고, 쪼개진 것 마다 담당자가 필요함
4 개발자는 어떤일을 하지?
1 개발자?
-
기획자
-
관리자
-
디자이너
-
QA : 테스팅
-
개발자 : 기능 제작
2 어떤걸 사용하는가?
-
플랫폼 - 개발하기 위한 환경
-
프레임워크 - 개발하는 툴
-
라이브러리 - 필요할 때 마다 불러쓰는 도구’
용어를 익히고 도메인에 관련된 단어, 정의를 습득하는게 어려움
각각을 비교하고 선택해서 결정(기능, 안정성, 성능)
내부적으로 그 기능이 어떻게 동작할 수 밖에 없느냐를 알고, 내부적인 원리를 아는게 가장 중요함
3 오픈소스
네이버는 오픈소스를 정말 많이씀. 오픈소스를 이용해서 만들 수 있는 것은 웬만하면 다 씀
오픈소스에 대한 검증작업은 굉장히 중요함, 많이 알고 있고, 잘 사용하는게 중요하다.
4 좋은 코드
-
남이 보기 좋은 코드
-
나중에 내가 봐도 이해 가능한 코드
-
일관성 - 코딩 컨벤션을 어떻게 짜는지가 중요하다.
-
에러 처리 - 노하우, 항상 처리해주는게 좋음, 뻗지 않게끔하는게 제일 중요함
-
주석 안씀 - 거의 주석을 안씀, 기능이 바뀔때마다 주석이 바뀌지 않아서 문제임
-
작명 - 용어들을 잘 정리해놓는게 중요함
-
Commit message - 어떤 기능이 어디에 commit 되어있는지를 파악해야함
-
글 잘 쓰는 사람은 생각보다 코딩도 잘함
-
오픈소스 코드를 많이 보는게 좋음
-
고민을 많이 하면 코드가 달라지게 됨
5 코딩 시 고려할 점
-
예외 처리가 가장 중요함
-
앱은 버그 픽스가 힘듬
-
앱은 구버전이 항상 존재함 - 처음 만들때 심각한 고려가 필요, API같은 이름도 바꾸기는 거의 불가능함
-
WIFI, LTE에 따라 달라짐
-
성능, 안정성
-
테스트 코드는 곧 품질
6 코드 리뷰
-
온라인 리뷰
-
오프라인 리뷰 - 큰 기능은 회의실 잡고 다같이 보게 됨, 팀의 분위기에 따라 굉장히 달라짐
-
페어 프로그래밍
-
리뷰는 모든 버그를 막지 못한다 - 리뷰를 아무리 많이해도 테스트는 반드시 필요함
7 테스트
-
단위테스트(junit), 기능테스트(핀리스), 부하테스트 - 굉장히 독하게 하는 편, 주니어 개발자일수록 테스트를 하도록 권장함
-
dev, alpha, real - dev 환경마다 테스트가 들어감
-
테스트 도구
-
QA 담당자 - 테스트 자동화가 가장 큰 화두임
8 운영
-
서스테이닝 - 서비스가 더 커지지 않고 유지보수정도의 업무
-
간단한 버그 픽스
-
개발 가이드 문서
-
모니터링을 하는 것들
-
플랫폼 설치, 버전 업그레이드
-
사용자의 단순 문의에 대응
-
신규 보다는 개선에 가까운 일들을 주로 함
-
하기 싫어하는 사람이 많다, 반복, 스트레스, 난이도 하, 단순한 적은 양의 코딩, 낮은 만족도, 낮은 성과(운영하기 위해서는 그 서비스를 정확하게 알게 됨, 반복되는 것들을 자동화 할 수 있음, 불필요한 일들을 제거할 수 있음, 느린 것들을 빠르게 함, 개선 -> 운영에서 이런 것들을 배울 수 있음)
5 트러블 슈팅
트러블 슈팅을 해결해주는 자동화 툴은 없음
트러블 슈팅에 대한 노하우를 쌓는게 굉장히 중요함
접속자 수가 1분에 1명, 초당 1명은 문제가 없음. 하나의 서버에 천명, 2천명이 접속하는 경우에 문제가 많이 생기고
그런 상황에서 노하우를 쌓고 해결해나가는게 중요함
2 갑자기 문제 발생
-
동시 요청량 증가
-
점점 쌓이는 데이터
-
커진 로그 파일
-
장비 문제
-
간헐적 동시성 문제
-
네크워크 오류
-
기타
3 종류
동시성, 디비, 데드락, 타임아웃, 트랜젝션의 문제일 경우가 가장 큰 문제임
스프링에 문제가 생기면 스프링을 다 까서 볼 정도로 문제를 찾아나가야함
4 해결
삽질을 엄청하다보면 해결할 수는 있음
-
재현 -> 원인 -> 해결
-
재현만 되는 70% 해결됐다고 보면 되는데, 재현하기도 매우 힘듬
5 예방
-
예외처리
-
모니터링
-
로깅 - 로깅해놓는 것이 가장 중요함
6 커뮤니케이션
상사가 커뮤니케이션을 못하는 경우가 굉장히 힘듬.
상하 관계에 대한 장벽을 최대한 없애는 게 중요함
-
혼자만 개발 안함
-
질문만 잘하면 평균 이상(어떤걸 질문하고 싶은지만 잘 이야기 하면 됨, 3년 정도는 질문해도 괜찮음)
-
잘하기도 어렵고 배우기도 어렵다
-
다른 직무 담당자와 대화 - 디자이너와 기획자의 시각에 맞게 용어를 잘 사용해주는 게 중요하다
-
대화 내용을 잘 정의하는 게 중요
-
어떤 게 중요한가?
-
어떤 고민이 필요한가?
-
어떤걸 힘들어 하는가?