누구나 동료들에게 유능하다는 인정을 받고 싶어 한다. 필자도 “저 사람은 자기 일을 잘 아는구나”라는 평가를 듣고 싶다. 그리고 대부분 경우, 우리는 꽤 잘 해내고 있다. 그렇지 않은가?

하지만 솔직히 말해 몇 가지 주제는 여전히 우리를 혼란스럽게 만든다. 머릿속에서는 뒤죽박죽인데, 마치 잘 아는 것처럼 고개를 끄덕이며 넘어가는 주제들 말이다. 이해하려고 책을 사고, 공부하고, 반복해서 읽어보지만 결국엔 ‘그럴듯하게 아는 척’하는 데 그친다.

물론 당신은 이런 것들을 완벽히 이해할 것이다. 하지만 주변 사람은 어떨까? 솔직히 대부분은 ‘아는 척’이다.

괜찮다. 부끄러워할 일은 아니다. 우리 모두 같은 처지다. 어쩌면 당신은 이 복잡한 프로그래밍 영역 중 한두 가지는 정말로 잘 이해하고 있을지도 모른다. 하지만 “이 모든 걸 다 안다”라고 말한다면? 글쎄, 그건 조금 의심스럽다.

아무튼, 여기서는 필자가 생각하기에 대부분 개발자가 완전히 이해하지 못하는 프로그래밍 주제를 정리했다.

복잡한 부울 표현식

필자가 자주 언급하는 주제다. 아래처럼 생긴 코드를 볼 때마다 머리가 지끈거리고 혼란에 빠진다.

function shouldApplyFreeShipping(order: Order): boolean {    return    ((order.total >= 100 && order.itemCount > 0)           && (order.isVIP ||               (!order.isVIP && order.paymentMethod === "credit"))           && !(order.hasBackorder && order.shipping === "express"));    }   

이런 코드를 보면 도대체 왜 이렇게 복잡해야 하나 싶다. 물론 제대로 작동한다. 규칙도 정확히 들어 있다. 하지만 이런 코드를 한 번에 읽고 모든 조건을 머릿속에 정리한 뒤 “무슨 일이 일어나고 있는지” 완전히 이해한다고? 글쎄, 그 말을 곧이곧대로 믿긴 어렵다. 이런 코드야말로 필자가 항상 “설명 변수를 두려워하지 말라”라고 말하는 이유다.

참고로, 위 코드를 챗GPT에 “한 문장으로 설명해달라”라고 요청했더니 다음과 같이 답했다.

총액이 100달러 이상이고 상품이 하나 이상이며, 고객이 VIP이거나 VIP가 아니더라도 신용카드로 결제하고, 백오더 상품이 포함된 익스프레스 배송이 아닐 경우에만 true를 반환한다.

듣고 보니 더 복잡해 보인다.

멀티스레딩과 동시성 문제

요즘 CPU는 마치 끝없는 코어를 품은 듯 보인다. 그래서 멀티스레딩은 이제 프로그래밍에서 피할 수 없는 일상이 됐다. 하지만 스레드는 동시에 거대한 문제를 만들어낸다. 아마 개발자라면 누구나 한 번쯤은 ‘스레드 버그’의 악몽을 경험했을 것이다. 간헐적으로 재현되고, 호출 스택(Call Stack)은 마치 세로 단서가 전부 빠진 십자말풀이 퍼즐처럼 아무 쓸모도 없는 경우 말이다. 이런 문제는 피할 수 없는 운명에 가깝다.

물론 대부분 개발자는 스레드 코드를 작성할 수 있고, 스레드가 어떻게 동작하는지도 기본적으로 알고 있다. 하지만 결국, 서로 다른 4개의 스레드가 동일한 자원을 놓고 경쟁할 때 정확히 어떤 일이 벌어질지 완전히 예측할 수 있는 사람은 없다. 솔직히 말해, 아무도 모른다.

부동소수점 연산

신입 개발자라면 누구나 한 번쯤 겪는 충격이 있다. 바로 0.7이나 1/3 같은 숫자가 컴퓨터의 부동소수점(floating point)으로는 정확하게 표현되지 않는다는 사실이다. 처음엔 이상하고 낯설게 느껴지지만, 결국엔 “아, 그런 거구나” 하며 받아들이게 된다. 하지만 그 이유까지 제대로 이해하고 있을까? 어쩌면 그렇다고 할 수도 있다. 그 원리를 아무리 잘 이해하더라도, 실제 계산 결과가 매번 정확히 떨어지진 않는다. 현실적으로는 불가능하다.

쿠버네티스에 관한 모든 것

물론 세상 어딘가에는 쿠버네티스가 어떻게 작동하는지 완벽히 이해하는 사람이 있을 것이다. 실제로 존재하는 기술이니 누군가는 알아야 한다. 하지만 솔직히 말하자면, 그건 소수의 헌신적인 ‘쿠버네티스 사제단’ 같은 사람들뿐이다. 클러스터 토폴로지(Cluster Topology)부터 네트워킹, 역할 기반 접근 제어(RBAC), 커스텀 리소스 정의(CRD), 인그레스 컨트롤러, 스토리지 클래스, 파드 중단 예산(Pod Disruption Budget), 어피니티 규칙(Affinity Rules), 그리고 그 외의 47단계짜리 난해한 설정까지, 이 모든 걸 완벽히 이해하고 다루는 개발자는 극히 드물다.

대부분 개발자는 YAML의 기초 문법 정도만 알고, 남이 만든 설정 파일을 조금씩 수정해 ‘그럭저럭 돌아가는’ 구성을 만든 뒤, 그게 망가지지 않기를 간절히 바란다. 솔직히 인정하자. 당신의 쿠버네티스 설정 중 90%는 다른 누군가의 작동하는 설정을 복사해 붙여 넣은 것이고, 그중 절반은 무슨 의미인지 정확히 모른 채 쓴 것이다.

유니코드와 문자 인코딩

많은 개발자가 한때는 익숙한 ASCII나 ANSI 문자 집합으로 코딩을 배웠다. 하지만 이후 유니코드(Unicode)가 등장하면서 세상은 완전히 달라졌다. 이모지, 온갖 윙딩체(Wingdings), 비로마 문자 등 디지털 세계의 모든 문자가 열려버린 것이다. 유니코드는 분명 훌륭한 발명이다. 다만 이를 모두 이해하는 것은 불가능에 가깝다. 예를 들어, 유니코드 문자는 2바이트 크기‘일 것 같다’는 느낌이 들지만 실제로는 그렇지 않다. 그렇다고 4바이트로 고정된 것도 아니다. 하지만 뭐, 아마 당신이라면 UTF-8, ISO-8859-1, Windows-1252의 차이를 완벽히 설명할 수 있을 것이다. 그럴 거라고 믿는다.

시간대와 서머타임

지구상 모든 시간대 규칙을 완벽히 이해하는 사람은 아마 4명 정도일 것이다. 그리고 솔직히 말해, 당신은 그중 한 명이 아닐 가능성이 높다. 예를 들어, 네팔이 전 세계에서 단 세 곳뿐인 45분 오프셋(time offset) 국가 중 하나라는 사실을 알고 있었는가? 서머타임(DST) 규칙을 모두 반영해 타임스탬프를 정확히 정렬할 수 있다고 자신할 수 있는가? 그렇다면 지금 인디애나주 녹스군의 정확한 시각이 몇 시인지 맞혀보라. 확신이 있는가? 솔직히 말해, 아닐 것이다.

이렇게 말해보자. 스택오버플로우에서 전설적인 명성을 자랑하는 개발자 존 스키트는 .NET용 날짜·시간 라이브러리까지 만든 인물이다. 그런데도 그조차 시간대 규칙을 완벽하게 따라잡기란 여전히 어렵다고 말한다. 그렇다면 나머지 우리야 오죽하겠는가.

정규식

복잡한 부울식도 머리를 아프게 하지만, 그나마 글로 풀어 쓸 수는 있다. 그러나 정규식만큼 쓰기도 어렵고 읽기도 어려운 건 없다. 규칙은 난해하고 복잡하며, 각 기호는 상황에 따라 의미가 달라진다. 솔직히 말해서, 정규식은 외계인이 농담 삼아 인간에게 전송한 코드가 아닐까 싶을 정도다.

물론 간단한 매칭 정도는 누구나 작성할 수 있다. 하지만 그 이상의 복잡한 패턴을 다룰 때는? 대부분은 필자처럼 스택오버플로우에 누군가 올려둔 예시를 복사해 붙여 넣었을 것이다.

예를 들어 다음을 보자.

/^(?:+?d{1,3}[-.s]?)?(?:(?d{1,4})?[-.s]?)?(?:d[-.s]?){6,14}d$/

이 정규식이 ‘국제 전화번호’를 검증하는 패턴이라는 걸 단번에 알아봤다면 정말 대단하다. (적어도 누군가 블로그에서 복사해 붙인 댓글에는 그렇게 써 있었다.)

이쯤 되니 진짜 머리가 지끈거린다. 사실 이런 주제는 더 많다. 빌드 스크립트를 완벽히 이해한다고 자신 있게 말할 수 있는가? 캐시 무효화(Cache Invalidation)에 대해 완벽히 설명할 수 있는가? 개발이라는 일은 그 자체로 복잡하고, 어렵고, 도전으로 가득하다. 그럼에도 우리가 매일 소프트웨어를 완성해낸다는 건, 그만큼 끈기와 인내심이 대단하다는 증거다.
dl-itworldkorea@foundryco.com