런칭 이후의 일들

요 몇년간 큰 조직과 작은 조직에서 번갈아 가면서 서비스를 런칭을 해보면서 드는 생각이 있다. 런칭 이전에는 설계와 코드에 많은 공을 들이지만, 이후에는 그것 보다는 좀 더 프로세스 및 자동화에 신경을 많이 쓰게 되는 것 같다.(설계와 코드는 항상 중요하다.) 오픈하고 땡이라는 개념은 개발-운영이 분리된 조직에서나 가능한 것 같고. 개발하면서 운영도 해야하는 작은 조직에서 가장 중요한 것은 개발생산성과 품질을 운영을 하면서 유지 하는 일이다.

당연히 운영이 더 중요한데 당장 발생하는 운영상의 이슈들을 처리해야하고 운영하면서 필연적으로 발생하는 작업들, 정산, 통계, 데이터 확인 등의 부차적인 작업들도 해야한다.(정산팀, 데이터분석팀이 있으면 상관 없다.) 이런 일들이 신규 개발보다 중요한 이유는 경영이나 마케팅, 비지니스 적으로 중간 중간에 방향을 결정하는 중요한 지표들이 되기 때문이다. 예를 들어, 어떤 매장이 좀더 매출이 잘 나오는지, 전체적으로 시간별, 메뉴별 어떤 상품이 잘 팔리는지 등의 지표는 전체 팀이 다음 스텝을 어디에 가져갈 것인지, 어디에 좀더 집중할 것인지를 결정 할수 있게 된다. 중간관리자 혹은 Intermediate 이상의 개발자는 운영이 신규개발을 잠식하지 않도록 해야한다. 운영상의 이슈들을 프로세스화 하고 기술적인 운영이슈는 자동화를 하는 등의 최소한의 인력과 비용으로 운영부담을 최소화 시키고, 개발/테스트에 개발팀이 집중하도록 노력해야한다.

개발쪽도 런칭 이후에는 운영을 위해서 테스트에 더 신경을 쓰고 배포시의 이슈에 대해서 점검해야하고, 효율적으로 배포할 수 있는 방법에 대해서 고민해야한다. 또한 이 과정에서 개발팀의 생산성을 최소한으로 떨어트리는 방법을 찾아야 한다. 예를 들어, 테스트를 하고 배포를 했는데도 장애가 나서, 테스트케이스를 작성하게 하고 일일이 수동으로 테스트 하게하는 등의 장애이후 후조치도 중요하지만, 그런 조치로 인해서 하나의 개발건(issue ticket) 조치 이전과 이후에 들어가는 비용(cost) 에 대해서 생각해봐야 한다. 테스트를 자동화 하거나 하는 등의 노력이 필요하다.

요즘들어 느끼는 것들은 본의 아니게 나이가 들어가면서 예전과 다르게 코드코드코드 하기 보다는 이런 서비스의 생명주기 안에서 개발팀을 어떻게 운영하고, 개발 프로세스를 어떻게 가져가고 그 안에서 어떤 툴을 쓰고, 이런것들을 같이 일하는 개발자들에게 어떻게 설득 시키는지가 더 중요하다는 생각이 든다.

일을 잘하면서 회사를 그만둔 주변의 동료 개발자들을 보면 결국 반복되는 프로세스 안에서의 작업때문에 스스로나 조직, 회사가 발전 가능성이 없다고 판단해서 그만두는 경우가 많은것 같다. 그만큼 프로세스를 잡고 개발팀을 운영해 나가는건 정말 중요한 일이라는 생각이 든다.