솔직히 고백하겠습니다. 스타트업에서 소위 '야생마'처럼 구르던 시절, 제 머릿속 세상은 완벽한 이진법이었습니다. 코드는 성공(True) 아니면 실패(False)였고, 서버는 살아있거나 죽어있는 상태뿐이었습니다. "되는 거야, 안 되는 거야?"라는 대표님의 다그침에 저는 항상 명쾌한 답을 내놓으려 애썼죠. 그게 실력이라고 믿었으니까요.
하지만 최근 체계가 잡힌 대기업으로 이직해 대규모 트래픽과 씨름하면서, 그 믿음이 얼마나 위험하고 오만한 것이었는지 뼈저리게 깨달았습니다. 우리가 다루는 시스템, 특히 거대한 분산 환경(Distributed System)은 0과 1로만 설명할 수 없는 '회색지대'로 가득 차 있었기 때문입니다. 오늘은 제가 뒤늦게 깨우친, 그리고 20세기 초 한 폴란드 논리학자가 이미 꿰뚫어 보았던 '제3의 값'에 대해 이야기해 보려 합니다.
제가 겪은 결정적인 실패는 결제 모듈을 리팩토링하던 중에 일어났습니다. 외부 PG(Payment Gateway) 사와 통신하는 로직이었는데, 저는 단순하게 생각했습니다. 결제 성공이면 주문을 완료하고, 결제 실패면 에러 메시지를 띄운다. 너무나 당연한 if-else 논리였죠.
그런데 배포 후 첫 블랙 프라이데이, 끔찍한 사태가 벌어졌습니다. 트래픽이 폭주하자 PG 사의 응답이 지연되면서 타임아웃(Timeout)이 발생하기 시작한 겁니다. 제 코드는 타임아웃을 명확한 '실패'로 간주하고 주문을 취소해 버렸습니다. 하지만 실제로는 PG 사 내부에서 승인이 떨어진 건들이 있었죠. 결과적으로 고객 돈은 빠져나갔는데 주문은 취소되는, 이커머스에서 가장 피해야 할 데이터 정합성 불일치(Inconsistency)가 수천 건 발생했습니다. 운영팀 전화기에 불이 나고, 저는 식은땀을 흘리며 로그를 뒤져야 했습니다.
그때 깨달았습니다. 네트워크 너머의 세상에는 성공과 실패 외에 '알 수 없음(Unknown)'이라는 상태가 존재한다는 것을요.
이 뼈아픈 경험을 하고 난 뒤, 우연히 얀 루카시에비치(Jan Łukasiewicz)라는 인물에 대해 읽게 되었습니다. 그는 아리스토텔레스가 정립한 이치 논리(True/False)의 세계를 깨고, 현대 컴퓨터 과학과 데이터베이스의 근간이 되는 '다치 논리(Many-Valued Logic)'를 창시한 폴란드의 논리학자입니다.
루카시에비치의 삶은 그 자체가 '불확실성'과의 싸움이었습니다. 그는 1, 2차 세계대전을 모두 겪었습니다. 나치의 폭격으로 평생 모은 장서와 원고가 잿더미가 되었고, 바르샤바 봉기 직전에는 목숨을 걸고 독일을 탈출해야 했습니다. 전쟁통에 내일 살지 죽을지 모르는 극한의 상황에서, 그는 세상이 단순히 '참'과 '거짓'으로만 나뉠 수 없다는 것을 직감적으로 알았을지도 모릅니다.
그는 기존의 0(거짓)과 1(참) 사이에 1/2(가능성, 미정)이라는 제3의 값을 도입했습니다. 이것이 오늘날 우리가 DB에서 마주하는 NULL 값의 철학적 기원이자, 비동기 프로그래밍에서 마주하는 Pending 상태, 그리고 제가 그토록 간과했던 네트워크의 Timeout 상태와 맞닿아 있습니다.
그는 1920년대에 이미 "미래에 대한 진술은 지금 참도 거짓도 아니다"라고 말했습니다. 이는 현대 MSA(Microservices Architecture) 환경에서 "다른 서비스의 응답은 오기 전까지 확정되지 않는다"는 '결과적 일관성(Eventual Consistency)'의 개념과 소름 돋게 닮아 있습니다.
이 개념을 받아들인 후, 저의 개발 방식은 완전히 바뀌었습니다.
첫째, '모호함'을 명시적으로 코딩합니다.
이제 저는 API를 설계할 때 성공/실패 외에 Pending이나 Unknown 상태를 반드시 정의합니다. 서킷 브레이커(Circuit Breaker)를 도입해 외부 시스템이 '가능성'의 영역(지연, 불안정)에 있을 때 무작정 실패 처리하기보다, 재시도(Retry) 큐에 넣거나 사용자에게 "확인 중"이라는 정확한 상태를 안내합니다. 루카시에비치가 제안한 '제3의 값'을 시스템 아키텍처에 녹여낸 셈입니다.
둘째, AI 도구를 활용해 '엣지 케이스'를 집요하게 묻습니다.
최근에는 Claude나 Cursor 같은 AI 도구를 활용할 때도 프롬프트를 다르게 짭니다. "이 코드 짜줘"가 아니라, "이 로직에서 네트워크가 3초간 끊기면 데이터는 어떤 상태가 돼? 루카시에비치의 3치 논리 관점에서 '알 수 없는' 상태가 발생할 구멍을 찾아줘"라고 요청합니다. AI는 확률론적 모델(Probabilistic Model)을 기반으로 하기에, 이런 '가능성'의 영역을 탐지하는 데 탁월한 능력을 발휘합니다.
셋째, 비즈니스 커뮤니케이션에서 '확신'을 줄입니다.
예전에는 기획자에게 "무조건 됩니다"라고 말했다면, 지금은 "이 부분은 외부 의존성이 있어 지연될 가능성이(1/2) 존재합니다. 그럴 경우 정책은 어떻게 할까요?"라고 묻습니다. 이것은 자신감이 없는 게 아니라, 시스템의 불확실성을 있는 그대로 인정하고 대비하는 프로의 태도입니다.
주니어 개발자 여러분, 그리고 저처럼 성장통을 겪고 계신 동료 여러분.
Boolean은 달콤합니다. 세상을 깔끔하게 둘로 나눠주니까요. 하지만 우리가 만드는 소프트웨어가 운영될 현실 세계는 전쟁과 피난을 겪었던 루카시에비치의 삶처럼, 예측 불가능하고 혼란스럽습니다.
단순히 기능이 동작하는 것에 만족하지 마십시오. 코드를 짤 때 항상 질문을 던지세요. "이 변수가 True도 False도 아닐 때, 내 서버는 어떻게 행동하는가?" 그 질문에 대한 답을 준비하는 것이야말로, 단순 코더(Coder)에서 시스템을 설계하는 엔지니어(Engineer)로 도약하는 첫걸음입니다. 루카시에비치가 잿더미 속에서도 논리를 놓지 않았듯, 우리도 불확실한 시스템 속에서 견고한 로직을 쌓아 올려야 합니다.
오늘 여러분의 코드는 '제3의 값'을 품을 준비가 되어 있나요?
