디버깅 탐색 수색 가이드
에러 메시지는 성장퀘스트이고 실패는 그저 성장여정의 한 챕터일 뿐
코드를 작성하다 보면 필연적으로 버그를 만나게 된다. 화면이 하얗게 변하거나 아예 컴파일 로딩이 어디서 꼬였는지 모르겠지만 멀쩡히 로컬에선 잘만 돌아가던게 디플로이만 되면 다 깨지는 경우도 허다하다. 버튼이 눌려지지 않는 경우도 흔하고 기대했던 결과와 전혀 다른 모습이 나타날 때 당황스럽고 좌절스럽기도 하다.
하지만 디버깅은 실패의 증거가 아니라 모든 개발자가 매일 같이 거치는 자연스러운 문제 해결 과정이다. 마치 사건 현장에서 단서를 찾아 범인을 추리하듯, 개발자는 에러 메시지라는 단서를 통해 문제의 원인을 찾아 해결한다. 결국 기술적 문제 해결에 대한 막연한 두려움을 없애고 오류를 성장의 기회로 만드는 마음가짐이 중요하다. 소스 컨텍스트의 한 구절처럼, 디버깅은 우리를 더 나은 개발자로 성장해주는 과정이다. 명확한 진단과 체계적 접근만이 이 혼돈속에서 질서를 찾아낼 수 있다.
성공적인 디버깅은 복잡한 기술이 아닌 체계적인 사고방식에서 시작된다. 수사에 필요한 도구를 다루듯, 문제 해결을 위해 4가지 기본 도구를 익혀야한다.
1. 단서읽기. 에러메시지는 시스템이 보내는 단서 메시지이다.
2. 가설세우기. 읽은 단서를 바탕으로 혹시 이게 문제 아닐까 하고 가능한 원인을 추측한다.
3. 용의선상 좁히기. 세운 가설들을 검증하며 가능성이 없는 원인들을 제거해나간다. 수사망 좁히기.
4. 원인 확정 및 해결. 의심의 여지가 없는 원인을 찾아내고 이제 그에 맞는 해결책을 적용한다.
이 4단계는 모든 디버깅의 기본 골격이 된다. 자 그럼 이제 실제 벌어진 일에 대해 이것들을 어떻게 사용하는지 직접 확인한다.
흔한 버그 파헤치기. 디버깅은 단순히 지식을 쌓는 것이 아니라 자전거를 배우듯 연습을 통해 향상되는 기술이다. 오늘 당신이 마주한 장애는 내일의 당신을 더 단단하게 만들어 줄 훈련과정이다. 소스 컨텍스트의 개발자는 이런 지리멸렬한 과정을 매번 마주하는 것이 그들의 직업이다.
사실 이러한 관점의 숙지는 비록 개발자에게만 필요한 것은 아니라고 생각한다.
입력된 인풋을 하나의 핵심 아이디어를 담은 여러 개의 아토믹 아이디어로 분해하고 이를 기반으로 스토리 보드를 짜보는 것이 중요하지 않을까. AI의 붐이 일어나며 이러한 과정에서의 오류, 그리고 그것을 극복하는 반복에서 성장하는 과정의 가치를 점점 경시하게 되서 나는 좀 유감이다.
AI의 효용성에 대해서 나는 완전 부정하는 타입이 아니다. 실제로 자료조사나 브레인스토밍 단계에선 일반인들보다 더 활성화되어 쓸 때도 많다. 허나 생성형 LLM AI 에이전트 서비스의 기반인 머신러닝을 대학원에서 공부하는 입장이기에 좀 더 분명하게 득과 실이 보일 뿐이다.
이런 의미에서 이런 서비스를 제대로 된 컴플라이언스를 반영도 하지 않고 마음껏 정보보안 침해를 유도하고 있는 기업 CEO들이 노동시장에 대해 fear mongering을 유포하며 인력들을 감축하고 있는 거라던가, 소위 전문가나 이런 기술을 보유하고 있는 경영자들이 이런 사태를 '예견'이라도 한 듯 말하고 자꾸 바이럴을 돌리는 게 영 탐탁치 않다. 애초에 니들이 그렇게 만들었잖아요.만들어놓고 왜 입을 털어, 만들 때 잘 하던가.
중간 허리급 이상의 실무자들은 말한다. 내 직장을 잃는게 아니라 같은 노동비를 받고 처리해야할 일이 늘어났다고. 변호사, 의사 커뮤들도 말한다. 어차피 본인들은 라이센스를 걸고 검수를 해서 컨설팅을 해야하는 직업이라 본인들이 모든 걸 다 최종 검수하고 일을 마쳐야하는 건 똑같은데 LLM AI가 만들어댄 생성 churn들을 검수하는 작업이 배로 늘어 작업 시간이 더 늘었다고. 이런 말은 경력직 개발자들 사이에서도 마찬가지다. 분명 코드 자체를 작성하는 시간은 줄었을지 몰라도 그걸 검토하고 리팩토링하는 시간은 그만큼 배로 늘었기 때문에 어느 분야에서 leverage는 될지언정 디버깅과 리팩토링 시간을 합산하면 생산력은 제로섬에 가깝다고.
무엇보다 AI 상품군들 패키지들의 실제 비용이 이제 점점 증가되어 가고 있다. 무료로 배포하던 서비스들은 티어를 높이고 리밋을 둬서 강제로 울트라 프로플랜을 가입할 수 밖에 없게 해놓고 막상 배포버젼보다 조금 나을 뿐 그 가격에 비해서 가성비를 못 맞추는 형국으로 점점 가고 있따. 토큰 초과 사용료, 팀 플랜 강제 업그레이드, API 사용료를 고려하고 이렇게 생성해서 만든 코드들을 다시 사람이 수동으로 리팩토링하고 재검토할 리소스를 생각하면 개발자 1인당 소요하는 리소스 소모 비용은 이전보다 더 높아질 수 있다.
서비스 장애 발생 시 업무 마비는 말할 것도 없다. AI에 리소스를 집중하느라 기존 서비스 품질 maintenance는 뒷전이라 플랫폼 서비스 장애 발생 비율도 이전에 비해 높아진 체감이 분명 있다. 2024년에 오픈AI와 클로드 API에 연동해서 서비스를 구동시작하던 여러 스타트업 상품군들이 이 API 커넥션 이슈로 잠깐이지만 글로벌 스케일로 셧다운 했던 사건을 사람들은 참 빨리도 망각한다. Null 체크, 타임존, 접근성 고려가 부족하여 이렇게 급속도로 만들어진 프로덕트들은 많은 부분에서 접근성/보안성/안정성 규제에 통과가 힘든 퀄리티로 나온다.
ai 성능이 얼마나 좋은지의 문제를 거론하는 것은 의미가 없다. 애초에 문제의 본질은 과정과 시스템, 그리고 프로토콜 개선에 더 이상 산업인력들이 가다듬을 노력을 안 하고 커뮤니케이션을 소홀이 하는 '일의 프레임워크/조직 문화'에서 오기 때문이다. 애초에 개발자들은 느린 코드작성으로 일이 힘들었던적이 없다. 방향을 마구 틀어버리는 윗선의 결정과 협업에서의 의견 조율의 마찰에서 매번 일이 틀어져 쓰던 코드를 뒤엎고 맞지 않는 마감과 프로젝트 운영에 갈려나가는 일이 더 큰 이유이기 때문이다. 이런 상황에서 암만 보조 도구 툴의 성능이 좋아져봤자 무슨 소용인가 말이다. 그리고 이런 고민은 조직, 그리고 각 조직마다 연결된 부서, 기업, 회사, 더 나아가 인더스트리에서의 인식 문제에서 시작해야한다.
어쩌면 단순하고 우직하고 기본적인 한 가지에 충실하게 몰입하는 것이, 가장 정답일지도 모른다.
그런 생각이 든다.
