13. 나는 무엇을 믿고 만드는가

문제 제기: 코드는 믿음의 흔적이다

새벽 두 시, 장애 알림이 울린다. 모니터에는 빨간 그래프가 솟아 있고, 팀 채널에는 “일단 이전 버전으로 되돌리자”는 메시지가 올라온다. 누군가는 배포 버튼을 누르고, 누군가는 로그를 찾고, 누군가는 고객 문의를 복사해 붙인다. 이때 우리는 대개 기술적인 질문을 한다. 어느 서비스가 죽었는가. 어떤 커밋이 원인인가. 롤백하면 복구되는가. 그러나 그보다 먼저 물어야 할 질문이 있다. 우리는 시스템이 어떤 방식으로 작동해야 한다고 믿었는가.

모든 소프트웨어에는 명시되지 않은 믿음이 들어 있다. 사용자는 약관을 읽을 것이라는 믿음, 데이터는 정확할 것이라는 믿음, 네트워크는 잠시 끊겨도 다시 연결될 것이라는 믿음, 관리자는 권한을 남용하지 않을 것이라는 믿음, 미래의 개발자는 오늘의 코드를 이해할 것이라는 믿음. 설계 문서에는 보통 기능과 인터페이스가 적히지만, 시스템의 성격을 결정하는 것은 그 아래 깔린 전제들이다. 공학자는 무언가를 만드는 동시에 “이 세계는 이러하다”라는 문장을 실행 가능한 형태로 고정한다.

철학적 논점: 믿음은 취향이 아니라 책임이다

철학은 당연한 전제를 잠시 멈춰 세운다. 효율이 좋다는 말에서 효율의 기준은 누구의 것인지 묻고, 자동화가 편리하다는 말에서 편리함의 대가는 누가 치르는지 묻는다. 공학은 그 질문을 다시 코드와 구조로 번역한다. 따라서 “무엇을 믿는가”는 개인적인 신념 고백이 아니다. 의사결정의 기준이며, 실패했을 때 책임을 추적할 수 있게 하는 설계 원칙이다.

예를 들어 추천 시스템을 만든다고 하자. 팀은 체류 시간을 늘리는 것을 성공 지표로 정한다. 처음에는 자연스러운 선택처럼 보인다. 사용자가 오래 머물면 콘텐츠가 더 매력적이라는 가정이다. 하지만 그 지표가 반복될수록 시스템은 사용자의 만족보다 자극의 강도를 최적화하기 시작할 수 있다. 분노를 부르는 게시물, 불안을 자극하는 제목, 이미 믿는 이야기를 강화하는 정보가 화면을 점령한다. 여기서 알고리즘은 중립적인 계산기가 아니다. “오래 보는 것이 좋은 경험이다”라는 믿음을 매 순간 재생산하는 기관에 가깝다.

반대로 우리는 사용자가 자신의 피드를 이해하고 조정할 권리가 있다고 믿을 수도 있다. 그렇다면 설계는 달라진다. 추천 이유를 표시하고, 특정 신호의 가중치를 낮추거나 끌 수 있게 하고, 시간순 보기나 탐색 기록 삭제 같은 선택지를 제공한다. 자율성은 도움말 페이지의 문구가 아니라 API, 데이터 모델, 설정 화면, 감사 로그에 들어가야 한다. 믿음이 구조가 되지 않으면, 그것은 슬로건에 머문다.

공학 사례: 유지보수 가능한 시스템은 미래를 믿는 방식이다

유지보수 역시 믿음의 문제다. 빠르게 출시하는 조직은 종종 “나중에 정리하자”고 말한다. 그러나 그 말은 단순히 기술 부채를 미루는 약속이 아니다. 아직 오지 않은 개발자의 시간을 현재의 속도를 위해 사용하겠다는 결정이다. 이름 없는 플래그, 서로 얽힌 전역 상태, 왜 존재하는지 설명되지 않은 예외 처리는 미래의 누군가에게 해석 비용으로 청구된다.

반대로 읽을 수 있는 코드, 명시적인 경계, 실패를 숨기지 않는 관측성은 미래의 동료를 신뢰하는 설계다. 그들이 모든 맥락을 기억하지 않아도 시스템을 고칠 수 있으리라는 믿음이다. 테스트는 단지 버그를 막는 장치가 아니다. “이 동작은 우연이 아니라 우리가 보존하기로 한 약속이다”라고 선언하는 기록이다. 데이터베이스의 마이그레이션 절차와 되돌리기 계획도 마찬가지다. 시스템이 언제나 정상일 것이라고 믿는 대신, 망가져도 복구할 수 있어야 한다고 믿는 것이다.

조직의 결정에서도 같은 질문이 반복된다. 보안 검토를 배포 직전의 승인 절차로 둘 것인가, 초기 설계의 입력으로 둘 것인가. 장애를 낸 사람을 찾을 것인가, 그런 실수가 증폭되지 않도록 권한과 자동화의 경계를 바꿀 것인가. 전자는 개인의 주의를 믿고, 후자는 구조의 힘을 믿는다. 둘 사이의 선택은 회의록에만 남지 않는다. 온콜의 피로, 고객의 신뢰, 다음 장애의 규모로 나타난다.

반론 또는 긴장: 믿음 없이 만들 수 있는가

물론 모든 전제를 의심하다 보면 아무것도 만들 수 없다는 반론이 있다. 출시에는 마감이 있고, 예산은 한정되어 있으며, 어떤 가정은 임시로 받아들여야 한다. 실제 제품은 완전한 확실성 위에서 만들어지지 않는다. 문제는 믿음을 갖는 것 자체가 아니라, 믿음을 사실처럼 숨기는 데 있다.

가정은 가정으로 표시되어야 한다. 어떤 사용자가 핵심인지, 어떤 오류율을 감당할 수 있는지, 어떤 데이터를 보관해야 하는지, 누가 시스템을 중단할 권한을 가져야 하는지 문서와 지표에 드러나야 한다. 그리고 그 믿음이 틀렸을 때 바꿀 수 있어야 한다. 되돌릴 수 있는 배포, 점진적 출시, 실험의 중단 조건, 독립적인 감사 경로는 철학적 겸손을 공학적 장치로 바꾼다.

마무리 질문

내가 오늘 작성한 함수와 승인한 로드맵은 어떤 인간상을 전제하는가. 사용자를 통제해야 하는 대상으로 보는가, 설명하고 선택할 수 있는 협력자로 보는가. 동료가 미래에도 이 코드를 고칠 수 있다고 믿는가. 그리고 그 믿음이 틀렸을 때, 시스템은 누군가의 선의에 기대지 않고 스스로 경고하고 멈출 수 있는가. 우리가 만드는 것은 기능만이 아니다. 우리가 믿는 세계의 작은 모형이다.