문제보다, 문제에 다가가는 길이 거칠었다

두 번의 상용 에러, 그런데 수습조차 빠르지 않았다

이번 주 진행했던 작업에서 크게 두 번 이상의 상용 에러가 발생했다.

에러를 냈던 사실보다 더 마음에 걸린 것은 수습이 생각만큼 빠르게 이루어지지 않았다는 것이다. 롤백을 하고 로컬에서 이슈를 재현하는 과정에서 원인을 찾는 데만 몇 시간이 걸렸다.

잘못 구성된 리드미와 정상 동작하지 않는 명령어 때문에 문제 이외의 상황에 적지 않은 시간이 소요되었다. 상용 이슈는 가뜩이나 상황이 급박하게 진행되는데 환경이 받쳐주지 않으니 문제를 들여다보기도 전에 소중한 시간만 흘려보내게 된 것이다.

프로그래밍을 잘한다는 건 이런 수많은 걱정거리를 한 번에 처리하는 능력이 아니라, 코드에서 여러 걱정거리를 분리해 낼 수 있는 능력

인간의 인지는 한 번에 다룰 수 있는 정보가 그리 많지 않다. 그래서 소프트웨어 엔지니어링은 결국 이 인지 한계를 체계적으로 극복하기 위한 방법론에 가깝다.

문제는 장애의 폭풍 속에 있을 때는 이 ‘분리’가 정상적으로 작동하지 않는다는 것이다.

환경과 씨름하며 인지 부하가 한계에 닿으면 걱정거리를 차분히 나눠서 다룰 여유가 사라진다. 그 순간엔 눈앞의 이슈만 황급히 쳐내게 된다. 그래서 근본 원인을 들여다볼 의지와 행동력이 생기기 어렵다.

장애 자체는 결국 해결할 수 있었다. 당시 상황을 다시 되돌아 봤을 때 정작 시간을 잡아먹은 것은 그 앞에 놓인 마찰들이었다.

각각은 사소해 보인다. 하지만 촉박한 상용 이슈 상황에서 이 사소함은 인지 부하가 되어 큰 부채로 되돌아온다.

“지금 이게 맞나?”를 반복하는 사이 정작 써야 할 집중력은 문제 해결이 아니라 묵인해온 환경과 씨름하는 데 소모된다.

로컬에서는 빌드 환경도 쉽게 접근할 수 없었다.

npm run dev로는 멀쩡한데 빌드 환경에서는 다르게 동작했다.

실제 버그는 배포와 동일한 빌드본을 로컬에서 똑같이 돌릴 수 있어야 비로소 재현된다. 재현 환경이 없으면 “무엇이 잘못됐는가”를 따지기 전에 “어떻게 다시 일으켜 볼 것인가”부터 막혀버린다.

그런데 막상 그 재현 환경을 만들려니 명령어부터 발목을 잡힌 상황이었다.

재현하는 길에서부터 문서와 어긋나 있었다. 결국 문서 어디에도 없는 우회 명령을 직접 조합해야 했다.

디버깅을 시작하기도 전에 시간이 새어나갔다.

이런 마찰의 비용은 좀처럼 집계되지 않는다.

리드미가 한 줄 틀려서, 명령어가 예상과 달라서, 설정이 파일마다 어긋나서 새어나가는 시간은 사소해서 측정하기도 모호하다. 어디에도 기록되지 않은 채 가랑비에 옷 젖듯 조용히 빠져나간다.

친절한 세팅, 정확한 문서, 재현 가능한 빌드는 사고가 한 번 나야 비로소 만들어지는 경향이 있다. 누군가 다치고 나서야 난간이 세워진다.

슬프지만 장애는 환경을 개선할 가장 비싸지만, 가장 확실한 명분이다.

현실적인 질문이 남는다. 전담 프론트엔드 플랫폼이 없는 지금 누가 나서서 해야 할까?

전담 조직이 없다는 건 이 문제에 책임 주체가 없다는 뜻이기도 하다. 서비스에 직접 영향을 주지 않으니 성취감도 적고 우선순위에서도 쉽게 밀린다. 그래서 “급한 거 끝나고”가 영원히 오지 않는 영역이다.

이러한 상황을 묵인하고 싶지 않다.

거친 세팅을, 문서와 어긋난 명령어를, 위치마다 다르게 도는 설정을 “원래 그런 것”이라고 뭉개서 넘기고 싶지 않다. 불편을 민감하게 감지하고 틈이 날 때마다 그 시간을 흘려보내지 않고 개선으로 나아가는 행동력이 필요하다.

전담이 없으면 결국 불편을 먼저 느끼고 민감하게 반응하는 사람이 그 역할을 대신하게 된다.

티가 나지 않는 부분이지만 이런 노력이 결국 문제에 다가가는 길을 매끄럽게 만들어줄 것이다.