네이버 개발자들 어떻게 일하나?

발췌 : https://realzero0.github.io/study/2017/07/21/Boost_Camp-_%EB%84%A4%EC%9D%B4%EB%B2%84_%EA%B0%9C%EB%B0%9C%EC%9E%90%EB%8A%94_%EC%96%B4%EB%96%BB%EA%B2%8C_%EC%9D%BC%ED%95%A0%EA%B9%8C(%EC%84%B8%EB%AF%B8%EB%82%98).html

1 국내 웹환경에서의 Naver 플랫폼 개발 시 고려하고 있는 부분들

1) 사용자

사용자들이 각각 다양한 형태로 접속함, 거의 모든 운영체제, 거의 모든 브라우저에서 전부 접속하기 때문에 이를 효율적으로 해결해야한다.

2) 데이터의 양

데이터의 양이 현업에 갈수록, 데이터의 양이 기하급수적으로 늘어남. 동일한 기능을 하더라고 규모가 큰 사황을 고려해서 개발해야한다

3) 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 웹 서비스 구조

생략 ...

---

4 Naver 개발자의 구체적인 일들

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 갑자기 문제 발생 case

• 동시 요청량 증가

• 점점 쌓이는 데이터

• 커진 로그 파일

• 장비 문제

• 간헐적 동시성 문제

• 네크워크 오류

• 기타

3 종류

동시성, 디비, 데드락, 타임아웃, 트랜젝션의 문제일 경우가 가장 큰 문제임

스프링에 문제가 생기면 스프링을 다 까서 볼 정도로 문제를 찾아나가야함

4 해결

삽질을 엄청하다보면 해결할 수는 있음

• 재현 -> 원인 -> 해결

• 재현만 되는 70% 해결됐다고 보면 되는데, 재현하기도 매우 힘듬

5 예방

• 예외처리

• 모니터링

• 로깅 - 로깅해놓는 것이 가장 중요함

6 커뮤니케이션

상사가 커뮤니케이션을 못하는 경우가 굉장히 힘듬.

상하 관계에 대한 장벽을 최대한 없애는 게 중요함

• 혼자만 개발 안함

• 질문만 잘하면 평균 이상(어떤걸 질문하고 싶은지만 잘 이야기 하면 됨, 3년 정도는 질문해도 괜찮음)

• 잘하기도 어렵고 배우기도 어렵다

• 다른 직무 담당자와 대화 - 디자이너와 기획자의 시각에 맞게 용어를 잘 사용해주는 게 중요하다