🌟신입 백엔드 개발자 취준을 어떻게 할 것인가?🌟

::핵심::

①이력서 & ②포트폴리오 & ③회사와의 fit

 

➜ 남들보다 뒤쳐진 것 같아 불안하다고?

신입한테 기대하는건 거대하고 방대한 지식의 양이 아님. 지식보다도, 그냥 어떤 사람인지를 보려고 함. 기본이 된 애인지를 보려고 함.

면접 볼때 얘가 회사에서 ‘블로그 글을 언제 썼나?’이런거에 중점을 두지 않음. ‘뭘 써놨는지만' 봄. 그러니까 그냥 지원하기 전까지, 계속 꾸준히 쓰면 됨.

 

➜ 어차피 들어가서 다 새로 배워야됨.

취업하면 CRUD 쓸까요? 공고 보면 20개중에 1~2개. . . 가면 CRUD 말고 보통 아예 새로운거 다 씀. 지금 우리가 하는 과정은, CRUD로 회사로 취업하려는게 아니라 이걸 얼마나 이해했고, 어떤식으로 공부를 했고, 기본을 알고 있기에 나중에 새로운걸 가르쳤을때 그걸 잘 흡수해서 자기껄로 바로바로 만들 수 있고.. 이런걸 보려는 것.

 

➜ 실전 프로젝트가 포트폴리오 메인?

맞기도 하고 아니기도 하다. 협업을 중시하는 개발자 직군 특성상, 디자이너-프론트-백까지 달라붙어서 하는 실전 프로젝트의 경험이 당연히 메릿으로 작용함. 그러나, 결국 내가 백의 모든 코드를 짜는게 아니기 때문에 외려 소스코드를(그 코드들을 쓴 목적을) 모르는데 그냥 포폴에 같다 붙여버린다? 이건 크나큰 단점으로 작용할 수 있음.

 

➜ 코드의 목적?

실전 플젝에서, 관계형 DB 특성이 더 어울릴 것 같은데 왜 noSQL 썼어요? 라는 질문 대비해놓기.

선배님 왈,,

"맨날 같은 말만 하는 것 같지만 ㅋㅋㅋ 코드의 목적을 잘 생각해 ㄹㅇ..

면접에서는 왜? 라는 질문이 많아서그래. 왜 그렇게 하셨어요? 왜 사용하셨나요? 이런거."

 

➜ 블로그/깃에 뭘 올리죠?

참고; seosu2000.tistory.com

자기가 직접 한 걸 캡쳐해서 적어보자. 남겨두자(e.g. 쿠키 발급(액세스 토큰, 리프레쉬 토큰), 본인 코드에 오픈API 사용)

 

 

** 개발자 취업 산업군 5대장(아래로 갈수록 비전공자는 진입 자체가 힘듦)

↳산업군은 신입 취업때도 중요하지만 이직때는 진짜 정말 중요하다. 

- 컨텐츠(content); 도메인-social media(카톡, 페북, 인스타 등), streaming(유튭, 넷플), portal(네이버, 다음, 줌), information(뱅샐, 강남언니), community(에타, 네이버 카페)

- 커머스(commerce); delivery(배민, 컬리, 쓱), shopping(쿠팡, 스맡스토어), p2p(당근, 중고나라), crowd funding(와디즈, 텀블벅), platform(인프런, 클래스101, 크몽, 직방)

- 핀테크(fintech); pay(카페, 토스, Payment Gateway), banking(카뱅, 시중 은행 등 - 코어 뱅킹이라고 해서 은행 관련된 도메인 지식이 중요함), stock(두나무, 증권사 어플), p2p lending(8퍼센트, 피플펀드 - 개인이 개인에게 돈 빌려주는 플랫폼), cryptocurrency(코인원, 업빗, 빗썸)

- 모빌리티(mobility); mobility(카택, 킥고잉), car sharing(타다, 쏘카, 우버), navigation(네이버/카카오 지도), self-driving(테슬라)

- 인공지능(al인공지능/ml머신러닝)

 

 

* 취업 급해도 SI 업체는 걸러야 하는 이유,,, >SI 개발 10년차인데 코드 좀 봐주세요<

https://www.popit.kr/si-%EA%B0%9C%EB%B0%9C-10%EB%85%84%EC%B0%A8%EC%9D%B8%EB%8D%B0-%EC%BD%94%EB%93%9C-%EC%A2%80-%EB%B4%90%EC%A3%BC%EC%84%B8%EC%9A%94/

 

* 원서 무작정 쓰지 말고, 아래 리스트에 있는지 먼저 확인해보는것도 좋음. 해당 회사들은 개발 문화가 좋으며, 그 말인 즉슨 앞으로 성장 가능성이 있음을 예고하는 것이기 때문.

한국에 자율 출퇴근 혹은 원격 근무가 되는 회사가 있나요?

https://github.com/milooy/remote-or-flexible-work-company-in-korea

GitHub - milooy/remote-or-flexible-work-company-in-korea: 한국에서 원격근무 혹은 자율출퇴근이 되는 회사 리

 

* 이력서

들어갈 내용: 프로젝트에 대한 간단한 설명

↳간단한 설명?

- 플젝 제목 및 개요

- 개발 기간

- 참여 인원&팀 플젝의 경우 자신의 역할-백엔드 기술 중 어떤것 담당-

- 기술 스택(주요 기술들만 나열하고 버전 반드시 명시. 버전 명시 안하면 어떤 버전인지 물어볼 수 있는데 모르면 버전도 모르고 썼냐고 공격 들어올 수 있음. 개발자는 어떤 기술을 사용할 때 왜 그걸 사용하는지 알고 쓰는 사람들. 버전(자바 몇버전)과, 버전의 특징(깃도 기술.. 버전관리를 깃으로 하니까. 깃헙 아니고 깃!!!), 그 버전과 다른 버전들의 차이점 정도는 간략하게라도 파악 필요. 면접에서 이런 버전 관련된 질문이 들어온다면, 진짜 어떤걸 썼는지가 궁금해서가 아니라!!! 개발자로서 기본 자세가 됐는지 궁금한 것!!!!!

- 주요 개발 내용(웹소켓을 이용한 채팅 기능 구현 등)

- 트러블슈팅 경험(댓글 기능 구현중 생겼던 순환참조 문제를 NTT 설계 변경으로 해결 등)

- 성과(트래픽 등); 이건 인상적인 수준 아니라면 굳이 안써도 됨

- 퐅폴 링크+데모 링크/깃헙 링크+데모 링크

➜ 이런걸 적는건 이력서에 나 이런거 했어요~하고 설명하려고? 노놉!!!!

그게 아니라 면접에서 이런거 질문하라고, 질문 유도하려고 적는것!!!(‘뭔 기술’을 썼느냐가 아니라 ‘그 기술을 왜썼냐’가 포인트임)

이력서는 면접까지 가기 위한 수단, 밑거름이잖니. 이력서는 면접 꼭 염두에 두고 적는것!!!! 그러니 뭔가를 적을때는 꼭 면접 가서 제대로 답변할 수 있도록 적자.

프로젝트 경험 부분은 면접에서 가장 많은 질문을 받는 부분. 그러니까 면접에서 받을 수 없는 질문은 배제하기(문제 해결 경험 없으면 굳이 적지 마라..)

 

+ 신입 개발자 이력서? 당연하겠지만 보통 다 거기서 거기^ ^! (서류 전형 통과 이력서 기준)

이력서에 작성된 정보들은 거의 비슷비슷해서 면접에 불러낼 지원자 추리기 힘듦.

이때, 퐅폴은 지원자마다 편차가 꽤 커서 이력서가 비슷하다면 퐅폴로 우열을 가릴 수 있슴(이력서 = 정량 평가, 퐅폴 = 정성 평가)

➜ 신입 개발자는 여타 스펙보다 개발 실력과 잠재력이 더 중요… 개발자를 조선시대에 비유하면 학자나 선비가 아니라 도공~! 무슨 학당을 다녔고 뭔 책을 공부했고 이게 아니라 작은 간장종지라도 만들어봤는지. 어떻게 만들었는지. 왜 그 방법을 사용해서 만들었는지가 중요하다…!!! 그런걸 어필할 수 있는 포트폴리오를 제출하자~! 

 

 

* 포트폴리오

: 플젝에 대한 자세한 설명

+ 백엔드 포폴? '코드의 동작' 중심.

⇒ 도메인 설계 어떻게?

⇒ 주요 로직 작성 어떻게?

⇒ 예외처리 어떻게?

⇒ db 뭐 썼고 데이터 쿼리는 뭐?

⇒ 보안 이슈는 없나?

등 웹페이지 퐅폴(For Frontend developer)에서는 확인하기 어렵고 코드를 봐야 확인할 수 있는 것들을 평가함.

백엔드는.. 깃헙 저장소에 플젝 설명 + 코드에 주석 달아서 이해 쉽도록 돕는것이 훨씬 중요.

 

+ 신입 개발자들이 만든 플젝의 동작 화면은 다 비슷해서 감흥도 없음. 근데 코드에 예외처리 제대로 해둔걸 보면 ‘오’스럽다. 주니어 백엔드 개발자에게 제일 중요한건 결국 ‘코드’!! 프로젝트 소개 글과, 코드를 잘 보여주는 것이 더 중요함. 또한 '얼마나 챌린징한 기술을 많이 써봤는가?'가 아님. 그런 기술들을 정말 '제대로'알고 구현했으면 당연히 너무 좋지. 근데 그게 아니고 그냥 복붙하면서 갖다 쓴 정도면? 그저 이것 저것 해봤다 뿐... 디메릿 디메릿 디메릿.

 

+ 프로젝트는, 여러개 한다고 더 좋거나 한게 아님니다~! 평가자에 다라 다르지만(겁나 겁나 겁나 바쁜 평가자라면 휘리릭 보느라 갯수 많은걸 좋아할지도 모르겠으나) 일반적으로 양보다 질이 중요. 클론코딩 따라한 수준의 플젝만 놓여있다면 좋은 평가 받기 어려움. 오히려 보여주기식으로, 부풀리기 식으로 만들었구나 하면서 낮은 점수 맞을 경우 다분. 실력 부족한 죄보다 실력 부족한걸 과장하거나 부풀리다 들통나는 괘씸죄가 더 크리티컬^ ^ 비전공자 뽑는 분들은 우리가 얼마나 개판인지 알고있음ㅋㅋㅋㅋㅋㅋㅋㅋ 잠재력 보고 뽑는것. 그니까 부족한 실력 과대포장하면 매의 눈에 다 걸리고 외려 신뢰도만 겁나 하락해서 안좋은 평가 받기 십상. 그니까 하나를 만들어도 제대로!! 신경써서!!! 만드는게 택할 수 있는 우월전략임.

 

* Git 포트폴리오(하나라도 빠지면 안됨니다)

1. 깃헙에 /portfolio 저장소 생성 + MEADME.md 파일 추가

2. 간단한 본인/이력 소개

3. 프로젝트 소개 나열

4. 각 프로젝트 저장소의 README.md 파일에 프로젝트 상세 설명 작성

 1) 플젝 제목/주제

 2) demo 링크

 3) 제작 기간 & 참여 인원

 4) 사용한 기술(기술 스택)

 5) ERD

 6) 핵심 기능(코드로 보여주거나 코드 링크)(게시판 만들었을시 그냥 게시판 플젝 x. 댓글? 대댓글? 대대댓글? 되나? 이런식으로 게시판이라고 하더라도 사용한 기능은 다양할 수 있으니까 잘 소개하기)

 7) 트러블슈팅 경험(문제를 어떻게 해결했는가?) / 자랑하고픈 코드(이 코드는 정말 효율적으로 자료구조 잘 썼다! 할 때 구로나.. 보통 시니어들 눈에는 엉망 진창일 경우가 많아서.. 굳이....ㅎㅎ)

 8) 회고 / 느낀점(프로젝트 개발 후.. 플젝은 기술/코드로만 설명되니까 딱딱할 수 있는데 속이야기를 여기서 적을 수 있음)

5. 가독성 향상 작업(md파일에서 문단 사이에 여백 좀 준다거나,, 이모지 쓴다거나! 이모지는 포인트만 줄것. 예쁘게 하는게 목적이 아님니다~!)

 

 

---

https://d2.naver.com/news/3435170

개발툴

Jenkins, AWS 등 Backend에 도움이 되는 도구를 배웠지만
도구를 배운다는 게 과연 실력을 키우는 것인지는 의문입니다.

 개발도구를 잘 활용하는 능력은 생산성과 직결되기에 중요합니다. 그런데 개발도구를 '배워야'하는 개발자보다는 스스로 익힐 수 있고, 적절한 도구를 선택할 수 있는 개발자가 현장에서는 필요합니다. 특정 개발도구를 익혔다는 사실은 단기적으로는 실력이라고 할 수 있습니다. 새로운 도구가 나왔을 때도 적응할 수 있는 학습력/적응력/판단력이 본질이고 이것이 누적되어 실력이 됩니다.

개인적으로는 아래와 같이 개발자의 수준을 분류하고 싶습니다.

• 레벨0: 이미 쓰고 있는 개발도구의 사용법을 알려주거나 가이드 문서를 줘도 잘 못 씀
• 레벨1: 알려주거나 같은 팀에서 만든 가이드 문서에 있는 만큼만 쓸 수 있음
• 레벨2
  • 개발도구의 공식 레퍼런스를 보고 사용법을 스스로 익힐 수 있음
  • 자신이 경험한 사용법을 문서화해서 팀 내에 전파할 수 있음
• 레벨3
  • 여러 개발도구를 비교 분석해서 상황에 적합한 도구를 선택할 수 있음
  • 공식 레퍼런스 문서에서 부족한 부분을 수정해서 기여할 수 있음
• 레벨4
  • 개발도구의 문제를 소스 코드를 수정해서 Fork/패치해서 사용할 수 있음

신입사원이라도 레벨2 정도는 함께 일할 개발자에게 기대를 하게 됩니다.

 

 

테스트

테스트가 얼마나 중요하다고 생각하는지 궁금합니다. 
실제 서비스에서는 테스트 코드를 어떻게, 어느 정도로 짜는가요?

많은 사람이 협업해서 개발하고 지속적으로 개선해나갈 소프트웨어라면 테스트 코드를 작성하는 일은 더욱 중요합니다. 테스트 코드를 작성하는 능력도 백엔드 개발자의 핵심역량 중 하나이기도 합니다. FE개발이 분업화되고 서비스간의 API 호출이 많아지면서 최근 백엔드 개발자의 업무는 API 서버 개발에 더 집중되고 있습니다. 따라서 최종적으로 UI와 통합하기 전에 개발한 API를 스스로 테스트해야 할 필요성이 더 커졌습니다. 오류를 있다는 제보를 다른 개발자로부터 받아서 수정 후 재배포하고 다시 알리는 비용은 스스로 오류를 발견했을 때보다 굉장히 크기 때문입니다. HTTP API에 대한 테스트는 작성하기도 쉽고 작성했을 때의 이득도 큽니다. 최근 진행 중인 프로젝트에서는 Rest-assured 와 Spring MVC Test Integration 을 이용해서 HTTP API를 통합 테스트 하고 있습니다. 라이브러리나 개발플랫폼을 개발하는 경우에도 테스트 코드는 중요합니다. 수천 대의 서버에 배포되는 라이브러리에서 사소한 수정을 해서 배포한 적이 있었는데, 최대한 모든 경로를 상상해서 테스트 코드를 작성할 수 밖에 없었습니다. 라이브러리 배포 후 이를 적용한 서비스에서 오류가 발생했을 경우 재배포하는 과정이 비용도 크고 신뢰를 잃게하는 요인이 되기 때문입니다.

'시간이 없어서 테스트를 못 만들었다’는 말은 '나는 테스트 코드를 만드는데 시간이 많이 걸린다’는 말과 동일합니다. 해당 언어에 대한 숙련도가 떨어지는 사람일수록 테스트 코드를 작성하는데 부담을 크게 느끼는 경우도 많이 봤습니다. 능숙해질수록 테스트 작성 시간은 줄어들어 테스트에 투자한 대비 이득이 커집니다. 가끔 테스트를 작성할 때 이 테스트 덕분에 어느 시점에 실제적인 이득이 있을지 나누어 생각할 때가 있습니다. 예를 들면 아래와 같습니다.

• 유지보수 기간의 생산성을 높여주고 새로 프로젝트에 투입될 사람에게도 이득을 주는 테스트
• 프로젝트 오픈 일정 직전까지의 코드 변경과 버그 발견에 도움을 주는 테스트
• 오늘 당장 프로그램을 목표한 곳까지 작성하는 일을 더 빨리 마치게 해주는 테스트

테스트 코드를 작성하다 보면 실제로 당장 할 일을 더 마치게 빠르게 해주는 테스트도 만나게 됩니다. 복잡하게 얽힌 프로그램을 개발할 때는 최종적인 UI를 통해서 수동으로 테스트하기 전에 부분적으로 잘라서 테스트하는 것이 버그를 쉽게, 빨리 잡는데 도움이 됩니다. 예를 들어 일주일 걸려서 만든 프로그램을 마지막 날에 한번에 테스트한다면 디버깅에 훨씬 시간이 많이 걸릴 것입니다. 몇 달 간 진행하는 프로젝트에서 단 한 줄의 테스트 코드도 안 짜는 분이 있다면 당신의 지금 능력으로도 그 방식이 오늘 일을 가장 빨리 마치는 방법이 아닐 것 같다고 말씀드리고 싶습니다. 그리고 테스트를 적극적으로 짜다보면 오늘 하루를 넘어서서 더 큰 이득을 주는 테스트를 만들어서 다른 사람의 생산성에도 긍정적인 영향을 미칠 수 있을 것입니다.

실제로 테스트로 인한 긍정적인 경험을 쌓아가다 보면 더 넓은 범위와 다양한 기법으로 테스트 코드를 작성하는데 동기유발이 됩니다. 제 개인적인 경험을 돌아보면, 점진적으로 테스트 코드를 작성하는 범위를 늘려가는 방식이 도움이 되었습니다. 처음에는 테스트가 쉬운 Utilty 클래스에 대한 테스트부터 작성했습니다. 전에도 간단한 유틸리티에 대한 테스트는 main메서드 안에서 하기도 했는데, 그런 코드를 JUnit 안으로 옮기니 반복해서 실행하고 결과를 확인하기에 훨씬 편해졌습니다. 그 이후에는 Spring framework의 통합테스트 기능을 이용한 테스트를 작성하기 시작했습니다. 특히 테스트 코드에서 DB에 입력한 데이터를 자동으로 롤백시키는 기능이 DB와 연동된 테스트를 할 때 유용했었습니다. 이후에 더 정교한 테스트를 하려다 보니 테스트용 객체를 만드는 프레임워크인 Mockito를 사용하게 되었습니다. 테스트 코드를 먼저 작성하는 기법도 사용할 수 있게 되었습니다. 저는 실무에서 테스트코드를 작성하기 시작한 후부터 6개월정도가 지나서야 Mockito와 같은 라이브러리의 필요성을 느끼게 되었었습니다. 처음으로 시도한 프레임워크는 EasyMock이었는데, 그 당시에는 프레임워크 제목처럼 전혀 Easy하게 느껴지지 않았습니다. 근래에는 프레임워크의 발달로 이전보다는 테스트 코드를 작성하기도 쉬운 구조로 모듈을 구성하기도 쉽고 테스트 코드 작성 자체도 훨씬 편해졌습니다. 따라서 이제는 대부분 제가 겪었던 단계적인 과정을 훨씬 더 빠르게 경험하실 수 있으실 것이라 예상합니다.

 

 

네이버의 백엔드 개발

개발,배포 방식

실무에서 어떻게 협업을 하고 개발, 배포를 하나요? 

개발팀이나 프로젝트의 성격에 따라서 일하는 방식은 다양합니다. 제가 참여하는 프로젝트 중 하나의 예를 들면 아래와 같습니다.

• 주 1회 배포
  • 월요일 쯤에 회의로 이번 주 배포 범위를 확정. 목/금요일에 주로 배포
  • 치명적인 버그에 대한 Hot fix는 주1회 주기에 상관없이 배포
  • 최대한 무정지 배포
• 버전 관리/ 코드 리뷰
  • master에서 추가할 기능별로 feature branch(topic branch)를 따고 주로 master를 목표로 PR(pull request) 요청
  • Github의 마일스톤으로 버전을 입력하고 PR마다 매핑
  • 한번에 반영하기 힘든 기능이나 큰 단계의 버전업은 별도의 feature branch로 merge하기도 함
  • 리뷰를 충분히 받았는지는 PR을 올린 사람이 판단하여 merge
  • 배포일이 다가오는데 기능 오류가 없는 것으로 검증된 branch는 일단 merge후 사후 리뷰를 하기도 함
• DB 스키마 관리
  • 개발환경에서는 Liquibase 로 관리
  • 운영환경에는 Liquibase에서 생성된 SQL을 사내 스키마 관리 시스템을 통해서 요청
• 테스트
  • PR를 올리면 CI서버에서 빌드 실행. API 서버의 테스트 코드와 FE코드에 검사도구인 Eslint의 검증을 통과해야 merge 가능
  • 현재는 서버 모듈만 테스트 코드 작성
    • 통합 테스트: JUnit + Rest assured + (Spring MVC Test framework 또는 Embeded Tomat 활용) 이용
    • 단위 테스트: JUnit + Mockito 활용
    • 특별히 의식하지는 않았는데 Line coverage 는 74% 정도
  • Docker를 이용한 테스트 환경 활용
    • 마크업 등 UI변경을 확인해야 하는 경우는 PR에 'Docker build'라는 라벨을 붙임
    • 그러면 docker 이미지가 만들어져서 사내 docker 이미지 배포용 cluster에 해당 branch를 확인할 수 있도록 배포가 됨
    • docker로 배포된 서버에서 어느 정도 테스트 후 merge
  • 주1회 배포전 QA시간을 따로 잡고 개발팀 전체가 함께 테스트. (전담 QA가 없는 프로젝트인 경우)
  • 테스트 시나리오는 그 주 변경된 기능과 영향받는 기능 위주로 작성
  • 큰 기능 추가, 전체적인 코드 변경 시점에는
    • 스테이징 서버에서 1~2주 정도 개발팀이 미리 운영 데이터로 시스템을 써보기도 함
      • 전체 기능에 대한 테스트 시나리오를 다 수행해보기도 함

 

인프라 기술 활용

네이버에서 클라우드 컴퓨팅 기술(IaaS, PaaS, SaaS)을 어떻게 활용하고 있는지 알고 싶습니다. 

네이버 서버 개발팀과 IT Operations팀 간의 소통 방식과 코드 배포 방법, 또 모니터링 툴들에 대해서 알고 싶습니다.

네이버 내부에서 가상 서버(VM)를 관리하는 방식은 IaaS에 가깝습니다. 개발망에서는 특별한 결재없이 개발자 누구나 직접 가상서버(VM)를 생성할 수 있습니다. 운영망에서는 예산 승인 절차 등을 거쳐서 SE에게 요청해서 VM 서버를 생성합니다. 물리서버도 필요하다면 사용 신청을 할 수 있는데, 가상서버에 비해서는 신청 절차에 시간이 더 걸립니다. 최근에는 Docker container를 이용해 더 운영효율성을 높이려는 시도도 진행되고 있습니다. 이에 대해서는 아래 자료들을 참조하실 수 있습니다.

• Docker + Kubernetes를 이용한 빌드 서버 가상화 사례
• DEVIEW 2015의 Docker Orchestration 발표를 참고하실 수 있습니다.

사내에 많이 쓰이는 플랫폼은 조직마다 직접 설치하고 운영할 필요가 없도록 PaaS 형태로 제공되고 있습니다. 로그수집시스템 Nelo, 어플리케이션 성능 측정 도구인 Pinpoint, 성능테스트 도구인 nGrinder, 분산메모리 저장소인 NbaseARC이 그 대표적인 예입니다. 많이 쓰이는 오픈소스 솔루션도 PaaS화하여 운영하는 사례가 늘어가고 있습니다.

최종 사용자가 바로 서비스를 사용하는, 네이버 메일, 캘린더, 클라우드(NDrive) 등이 SaaS의 예라고 생각합니다. 네이버 내부의 IaaS/PaaS/SaaS 기술들은 Naver Cloud Platform ( https://www.ncloud.com/ )을 통해서 외부에도 제공되고 있습니다.

코드 배포는 내부적으로 만든 배포 솔루션을 사용하고 있고, 개발자 누구나 서버에 몇번의 클릭으로 서버에 배포할 수 있습니다. 개발 환경에서는 코드 Push나 Pull request가 올라오는 이벤트 등과 연결시켜서 자동으로 배포하기도 합니다. 운영환경에 배포하는 작업은 개발팀의 내/외부와 긴밀한 협의를 거쳐서 시점이 정해집니다. 배포 일정에 맞춰서 코드 리뷰, 소스 합치기, 테스트, 의존하는 다른 서비스에 공지하는 작업 등이 사전에 이뤄져야하기 때문입니다.

모니터링 도구는 여러가지를 복합적으로 사용하고 있습니다. 장비별 주요 자원 사용량, 네트워크, 어플리케이션 성능, 로그 수집 분석 등 모니터링 툴마다 특화된 영역이 다르기 때문입니다. 장애에 대한 모니터링을 하는 시스템은 빌드배포 시스템, 각종 모니터링 시스템과도 연동되어 있습니다.

네이버 내부에 정확히 'IT operation팀'이라는 용어는 쓰이고 있지는 않습니다. Nginx, Tomcat, JVM과 같은 솔루션의 설치와 설정 변경은 개발팀에서 직접하고 있습니다. 운영서버 VM의 생성, OS패치 등의 작업, 인프라 구성 등에 대한 컨설팅을 서비스마다 지정된 SE분들이 해주십니다. 개발DB의 설치와 스키마 변경은 개발팀에서 자율적으로 하고, 운영 DB에 대한 중요한 작업은 전담 DBA에게 요청합니다. 오랫동안 서비스를 개발,운영하면서 실용적인 프로세스가 정착되었다고 느껴집니다.

 

 

마치며

 개발과 요리가 비슷한 면이 있다는 생각이 들 때가 있습니다. 몇 명이 먹을 요리를 정해진 레시피를 보고 혼자 만드는 일은 어렵지 않습니다. 그런데 많은 사람을 위한 음식을 여러 사람이 함께 준비하는 일은 차원이 다른 일입니다. 예전에 친척 분의 집에 방문했다가 샌드위치 500인분을 만드는 과정에 한두시간정도 참여한 적이 있습니다. 재료가 얼마나 필요할지 예측해서 구하고, 일하는 방식과 담당자를 정하고, 작업 시간을 계획하는 것 등 하나하나가 수월해 보이지 않았고, 그 중 하나만 어긋나도 샌드위치는 예상대로 만들어지지 않을 것 같았습니다. 그 일을 겪은 이후로 저는 큰 식당이나 결혼식 피로연에 갈 때마다 그 음식들을 준비하신 분들이 정말 대단하다고 느낍니다.

 일단 실행은 되는 백엔드 프로그램을 만드는 일은 쉽습니다. 요즘은 특히 인터넷에 많은 재료와 레시피가 있기에 더욱 그러합니다. 그러나 협업하기에 좋은 방식으로, 성능과 안정성까지 고려한 백엔드 프로그램을 만드는 개발은 쉽지 않습니다. 그리고 모니터링과 데이터 수집,분석 등 사용자의 눈에 보이지 않는 영역들도 실무에서는 많은 비중을 차지합니다. 데이터나 사용자가 적었을 때에는 효율적이었던 구현 방식이 시스템이 성장하면서 문제의 근원지가 되기도 합니다.