일본에서 나름(?) 대기업에 신졸채용으로 입사하게 된 나,,,
성실성과 정확성을 너무 많이 어필한 나머지, 본방(production환경,한국에서도 본방이라고 말하나요..?)권한과 운영작업을 초고속으로 담당하게 되고... 어쩌다보니 "이 부분은 김상과 상의해봐"하는 목소리가 점점 많아지고,, 결국엔 운영팀의 리더까지 맡게 됐다.
팀원들과의 사이도 좋고 배울만한 멘토도 있었지만, 일단 개발자로써의 커리어 패스를 봤을때 난 개발, 코딩실력이 터무니없이 부족하다고 생각했고, 이동을 결심했다. 충분한 인수인계 과정을 거친 후, 부서이동을 신청, 몇 번의 면접후 완전 개발위주로 하는 직무로 이동할 수 있었다!
지금은 이동했긴 하지만? 운영팀의 리더를 하면서 배운건 꽤나 있다. 이 경험,관점을 갖고있는 개발자와 아닌 개발자의 개발 시 커버리지 범위는 차이가 있다고 생각하므로 미래에 까먹어버리진 않을까 아주 조금 기록해두려고 한다.
🔰물론 이 방법들이 정답인건 아니고, 또 한국기업의 문화와는 다를수도 있다!!
규모가 꽤 있는 그룹이었지만 그 그룹에서 하고있는 수많은 사업중 하나의 부서에 들어간 나는, 아니.. 대기업 시스템이 이렇게 기능이 없다고(물론 인프라, 보안면에서는 지원이 빵빵했지만,, 내가 속했던 사업자체가 하락세였던 느낌ㄷㄷ)? 생각할정도로 운영면에서 자동화가 안 된 서비스를 담당하게 되었다.(아마 IT강대국인 한국에서는 이거 이거 바로바로 릴리즈해냈을거같은데 일본 회사는 그에 비해 좀 많이 기다려준다고 해야하나,,,, 이건 우리 고객들이 법인들이어서 그 쪽도 쉬는 날엔 쉬니까 그런걸수도 있다..) 우리 팀에서 주로 나왔던 키워드는 DevOps 그리고 SRE였다.
개발 + 운영, 그러니까 운영팀과 개발팀이 따로 업무를 담당하는것이아니라 엔지니어가 개발, 테스트, 배포 그리고 그 후의 운영까지 모두 진행하는 방식이다. 개발과 운영의 이해관계의 격차를 줄이기 위한 하나의 "문화"이다.
내가 속해있었던 팀의 경우 팀의 70%가 파트너 스태프(파견계약!or위탁업무)들이셨다.
그분들에게 바로 prod작업을 맡기기엔 책임을 물 곳이 애매해질 수도 있다고 판단했기 때문에 개발팀, 운영팀이 나뉘어져(내가 이동할 쯔음이 돼서는 데브옵스 형태로 점차 바뀌어갔다.)있었으나, 역시 개발팀은 운영에 대한 관점을 놓치기 쉽고, 운영팀은 이미 개발이 완료된 브랜치를 다시 고치라고도 할 수도 없었으니 이해관계가 조금 다를 수밖에 없었다.
✅우리가 진행한것
- 개발팀과 운영팀의 운영에 대한 시각 일치화 시키기 : 설계, 코드리뷰시 확인해야할 최소한의 체크시트를 규칙으로 정의, 체크시트 안에 운영시의 관점포함 시키기(개발팀에게 강제성이 들어가고 수고가 늘어나지만,,각 개발자들의 운영에대한 지식은 각기 달랐기때문에 선택한 최선의 방법이었다..)
- 요건정의 : 프로듀서와의 충분한 소통, 실제 운영시 일어날 상황을 사업, 개발부에서 가능한대로 전부 리스트업한 후, 커버할 대상이 개발쪽인지, 사업부인지 확실시하기
사이트 신뢰성 엔지니어링(SRE)은 IT운영에 대한 엔지니어링 방법론이다. SRE팀은 서비스를 "툴"로 활용화여 시스템을 관리하고, 운영 태스크를 자동화 한다.
내가 속했던 이전 팀은 SRE을 지향하지만 그런 전문적인 팀이 되기전 단계였던것같다. 모니터링도 제대로 되지않은 단계였기때문에 폭풍 릴리즈 후 나타나는 운영적인 결함 때문에 추후에는 자동화하는데에만 꽤나 많은 코스트를 들였다.
하지만 처음 요건정의때부터 이런 모니터링 자동화라는 요건이 들어가 있었다면 후에 들어온 개발자들이 조사하고, 상담하고, 견적내는 수고로움을 덜 수 있었지 않았을까? 그에반해 새로운 부서에 들어와서는 그 부분(jaeger 등 모니터링 시스템에 대한 설계)이 굉장히 잘 되어있어서 정말 개발자는 "개발"에만 집중 할 수 있다.
운영에 대한 관점이 있는 개발자는 결국, 개발에만 집중할 수 있는 환경을 만들 수 있다.
테스트 주도 개발, 반복테스트를 이용한 소프트웨어 '방법론'이다. 일반 개발 방식의 경우 결과가 초기 설계와 달라질 가능성이 높고 개발자는 이를 수정하는 과정에서 결국 재설계가 불가피하다. TDD는 테스트 코드를 작성하여 도중 발생하는 예외 사항(버그, 수정사항)들을 테스트 케이스가 추가하고 설계를 개선, 그 후 테스트가 통과된 프로세스만을 실제 코드로 작성한다.
이전 부서에서는 정석 개발 방식이 기본 개발플로우였는데, 요건정의-조사-설계(리뷰)-개발-코딩리뷰-테스트케이스설계(리뷰)-테스트실시-결과리뷰의 순으로 시간이 꽤나 걸리는데에 반해, 실제 코딩,테스트시 생각한 결과와 달라 재설계, 요건의 수정이 들어가곤 했다. 코스트적으로 적지 않은 손해였다.
✅우리가 진행한것
- TDD개발방식을 도입, 정석개발방식보다 실제 테스트를 진행해가며 '있을 법한' 요건대로 코딩을 하기를 권장했다.-> 개발 코스트는 줄이고 릴리즈 시간단위가 줄어들어 결국 운영의 자동화에 투입할 인력을 확보
정말 기능만 ! 개발하고 뒷일(운영 측면)은 생각하지 않았던 담당자들과 대화를 나눈 결과, 그들은 그저 요건대로 만들었을뿐이라는 대답을 하곤 했다. 아, 요건부터가 운영을 생각하지 않고 코스트를 냈는데 시간내에 마치려면 정말 기능만! 만들뿐이겠구나, 생각했다.
✅우리가 진행한것
요건에서부터 운영에 대한 지시사항을 명확히하도록 개발,운영,프로듀서(그리고 사업부)가 충분한 대화를 가지는 장을 만들었다. 처음부터 요건에 운영에 대한 관점이 들어가고 개발에 착수하여 쓸모없는 운영코스트가 만들어지지 않도록!
추가로 비기능요건이란, 배치의 성능, 안정성 종료 시간 등 특정한 기능에대한 요구사항은 아니지만 시스템의 속성과 제약사항들을 정의하는 요구사항이다.
예전팀은 규모가 꽤 있었기 때문에 충분한 커뮤니케이션이 무엇보다도 중요했다.
우리팀은 로그가 정말 중구난방이었기때문에 조사시에 꽤나 골머리를 앓았다. 예상외 상황이 발생하면? -> 에러로그를 남기도록 하자.가 일반 사고의 흐름인데, 그 에러로그는 누가 보고 누가 대응하는데?까지 케어한다면 베스트다.
물론? 난 지금 운영을 맡고있지않고, 개발중점 직무를 하면서 어리버리 개발자로,, 조금은 말하는 감자처럼 지내고 있지만, 데브옵스 개발자를 육성해본 경험..!이 있긴있다. 데브옵스 개발자가 되기 위해선,, 음 좀 거시적인 이해도가 있어야 본인에게도 편한것같다. 그리고 운영의 관점을 아는 개발자는 릴리즈 후 뒷탈도 없는 편인것같기도 하고...?(극히 주관적 의견) 음 어느쪽이든 충분한 커뮤니케이션이 되도록, 하지만 본인이 아니라고 생각하는 부분은 충분히 전달하고 조정이 가능한 상태가 딱 현재 2년차 개발자에게 바라는 바인것같긴하다. 후후 올해도 화이팅!!
가만히 둬도 알아서 모니터링하고, 트러블을 케어하는, 릴리즈만 해도 수익을 내는 시스템을 만들자.
이건 우리 매니저의 한마디 !
끝
☝ 자전거와 dslr만 가지고 집 주변 탐방에 맛들려있는 요즘 ㅎ