아마도 나는 실 사용자가 있는 서비스를 개발하기 전, 즉 입사 전 개발을 공부하던 시기에는 개발에 있어서 가장 중요한 것이 퍼포먼스, 최적화, 최신 기술의 사용이라고 생각했었다. 효율적이고 성능이 잘 나오며, 어려운 비즈니스 로직을 잘 풀어내는 것이 최고라고 생각했었다. 물론 이런 부분들은 현재도 정말 중요한 부분이라고 생각한다. 최종적인 목표이며, 멋있는 개발자가 되기 위해서 필수라고 아직 생각하고있다. 개발을 조금만 하다보면 어느순간 깨달음이 와서 앞의 능력들을 보여주는 개발자가 될 것만 같았다.
1년 전의 나는?
처음에는 어려운 개발을 하는것이 잘 하는 것이라고 생각했었다. ssafy를 하던 1년 전의 나는 6개월 간 3개의 프로젝트를 하며 정말 많은 프로젝트를 했었다. 웃기게도 3개의 프로젝트동안 vue, react를 공부하여 프론트 개발에 사용했으며(사용했다고 생각했던 것 같다), 프로젝트 주제에 맞게 다양한 개발도 경험했었다.
네일 플랫폼 프로젝트를 진행할 땐, TensorFlow와 OpenCv를 활용해 카메라 상의 손톱을 인식하여 AR로 네일아트를 올려보기도 했고, 블록체인 프로젝트에서는 OpenZepplin으로 ERC-721 토큰(NFT)을 발행하고, Private IPFS를 구현하여 실제 블록체인 환경을 구현하기도 했다.
두 가지다 개발 당시에는 정말 힘들었지만 결국 모두 성공하면서 '내가 정말 개발을 잘한다'라고 착각을 했었다.
실제로 서비스했다면 10분도 안가서 온갖 버그와 장애에 시달리고, 유지보수도 되지 않는 결과물을 만들었다는 것을 지금은 깨달았다는 것이 정말 다행이라고 생각한다.
개발에 대한 생각이 바뀐 기점
1년 간 서비스를 개발하고 운영 하면서 언제나 가장 힘들 때는 장애가 발생했을 때인 것 같다. 사용자가 없는 토이프로젝트 일 경우는 장애가 발생할 경우 그저 고치면 된다. 내가 시간날 때, 고치고 다시 개발을 진행하면 되는것이다. 하지만 실 서비스의 경우 장애가 발생한 경우, 이미 연락을 받는 순간부터 문제가 된 것이다. 내가 얼마나 멋있고 아름다운 기능을 만들었는지, 얼마나 열심히 만들었는지 따위는 중요하지 않게 된다. 사용자의 입장에서는 제대로 되지 않는 서비스에 의한 스트레스만 남게 되는 것이다. 이 때부터는 장애를 고치는데 모든 집중을 쏟기 시작한다. 이미 기분이 좋지 않은 유저를 그나마 위로하는 방법으로 내가 선택한 것은 압도적인 사과와 최대한 빠른 장애 해결이다.
빠른 장애 해결은 서비스를 운영하면서 수 많은 장애를 발생시킨 내가 현재 생각하는 개발에 있어서 가장 중요한 포인트이다. 내가 만든 앱의 모든 사용자는 같은 회사, 혹은 협력사의 직원이다. 한 번의 실수에는 관대할 수 있지만 이것이 지속될 경우 내가 아니라 부서의 문제가 되어 윗 선으로 보고될 가능성이 매우 높다. 또한 장애가 반복된다면 사용자들이 좋지 않은 쪽으로 선입견을 갖게 될 것이라는 생각이 항상 나를 압박한다.
아무리 대단한 개발자라도 장애가 없는 서비스를 만들 수는 없다고 생각한다. 일반 서비스 회사에 비하면 정말 간단한 앱을 서비스하고 있지만 서버 관리(서버 IIS에 API서버를 호스팅할 뿐이다), Flutter 앱 개발, 백엔드를 모두 개발하고 있는 나는 장애를 만들어 내기에는 정말 최적의 환경이라고 생각한다. 내 성격이 꼼꼼하지 않은 탓도 있고.. 물론 애초에 장애 없는 견고한 프로그램을 만드는 것이 최선이지만, 내 실력의 부족함도 있고 앞서 말했듯이 그것이 불가능함을 알기에 나는 빠른 장애해결을 위한 방법을 고민 하는 것이 더욱 합리적이라고 생각한다.
장애를 해결하기 위한 고민
위의 고민들을 결과로 내가 시작한 것은 로깅 시스템을 만드는 것이었다. 장애 해결에서 가장 중요한 것은 원인 파악이다. 무엇 때문에 서비스의 장애가 생겼는지, 내가 어떤 부분을 수정하여 장애를 고칠지, 어떤 과정을 통해 유발되었는지 파악하는 것이 장애 해결의 프로세스라고 생각한다.
특히나 앱 사용자의 평균연령이 45세를 넘기 때문에, 문제가 생긴 유저와 대화를 통해 원인을 찾는 것이 거의 불가능했다. 때문에 모든 것은 LOG로 말한다는 신념하에, 로깅 시스템을 구축하였다. 우선 날짜별, 기능별로 로그 파일을 나누었다.
// 로그 폴더
20231118_FUNC1.log
20231118_FUNC2.log
20231118_FUNC3.log
20231119_FUNC1.log
20231119_FUNC2.log
20231119_FUNC3.log
위 형태로 파일을 만들어 장애가 발생했을 때 빠르게 그 부분을 캐치할 수 있도록 하였고, 그 안에서도 레벨별로 표기를 해 주었다. 예를 들어
// 20231118_FUNC1.log
2023-11-18 16:03:47 | Debug | {user} Login
2023-11-18 16:04:47 | Debug | {user} Do some activity
2023-11-18 16:05:47 | Warn | {user} Access Unauthorized Func
2023-11-18 16:06:47 | Debug | {user} Login
2023-11-18 16:07:47 | Error | {user} Unexpected Character 1
Debug, Warn, Error 세 가지로 레벨을 나누어 정상 동작과 유저 실수, 장애를 구별했다. 사실 대단할 것 없는, 정말 기초적인 작업으로 볼 수 있겠지만 나는 그 어떤 비즈니스 로직을 만든 것보다도 로깅 시스템을 만든것이 만족스러웠다. 이를 기반으로 빠른 장애 해결이 가능한 것은 물론, 내가 자리를 비우더라도 다른 동료가 로그만 보내주면 무엇이 문제인지 바로 파악할 수 있게 되어 빠른 문제 대처가 가능해졌다.
또한, 로깅 시스템을 만들며 로그를 찍는 코드를 넣는 동안 예외 처리에 대한 고민도 자연스레 생기게 되었다. 고민 없이 try catch를 남발하던 예전과 달리 하나의 로직을 짤 때, 유저가 사용하면서 발생하는 부분에 대해서는 if문으로 최대한 처리를 해주고, 유저 의지와 관계없이 발생한 부분만을 예외처리로 하게 되었다. 이러한 과정을통해 유저에게도 실패 상황에서 더 정확한 메시지를 전달해줄 수 있게 되었고, 나 또한 유저들에게서 장애와 실수를 구별하는 것이 더욱 쉬워져 유지보수에 할당하는 시간을 대폭 감소시킬 수 있었다.
마무리
결국 개발에서 코드를 짜는 것은 정말 일부분에 지나지 않는다는 것을 깨달았다.(정말 중요한 일부분이지만) 어떤 코드를 치는지만 고민하던 처음과는 달리 비즈니스와 도메인에 대한 이해, 타겟 유저에 대한 이해, 일정과 목표 관리 ,유지보수 등 개발은 정말 많은 요소를 고민해야 된다는 것을 배웠다.
내가 제대로된 개발자가 아닌 제조업 직장인이기 때문에 오히려 신입으로서는 할 수 없는 폭 넓은 경험을 할 수 있었다고 생각한다. 무작정 키보드에 손이 올라가던 예전과 달리 점점 더 많은 고민을 하게 되었고 성장하고 있음을 느낀다.
'생각' 카테고리의 다른 글
| 신입 개발자의 개발에 대한 생각(문제 해결, 로그) (0) | 2024.01.02 |
|---|