확실성의 황혼에서 — 로버트 C. 마틴의 질문에 부치는 답서
Uncle Bob이 던진 질문, 그리고 그 질문이 품고 있는 50년의 무게
“We programmers have been dedicated to certainty. Either the program works or it doesn’t. AIs do not deliver certainty. Perhaps certainty will remain forever outside their domain. Can we live with that?”
— Robert C. Martin (@unclebobmartin)
1970년부터 코드를 작성해 온 로버트 C. 마틴, 우리가 “엉클 밥(Uncle Bob)”이라 부르는 이 소프트웨어 공학의 거장이 던진 이 질문은, 얼핏 보면 AI 시대에 대한 단순한 감상처럼 보입니다. 하지만 클린 코드(Clean Code)의 철학자이자 애자일 선언문(Agile Manifesto)의 공동 저자인 그가 이 질문을 던진다는 것은, 반세기에 걸친 소프트웨어 장인정신의 근본 전제가 흔들리고 있음을 스스로 인정하는 것과 같습니다.
그의 질문을 풀어보면 이렇습니다. 우리 프로그래머들은 “확실성(certainty)”에 헌신해왔다. 프로그램은 작동하거나 작동하지 않거나, 둘 중 하나다. 그런데 AI는 확실성을 제공하지 않는다. 어쩌면 확실성은 영원히 AI의 영역 밖에 머물 것이다. 우리는 그것과 함께 살 수 있는가? 그리고 마지막에 묻습니다 — AI 시대의 미래란, 결국 기계의 불확실한 행동을 “허용 가능한 범위” 안에 가두는 것이 아닌가? 그것이 AI 이전과 과연 다른가?
이 질문에 답하기 위해, 우리는 먼저 “확실성”이라는 단어가 프로그래머에게 무엇이었는지를 되짚어야 합니다.
제1장: 확실성이라는 신화 — 프로그래머가 믿어온 것
프로그래밍의 역사는 확실성을 향한 집요한 행군이었습니다. 찰스 배비지(Charles Babbage)가 해석기관(Analytical Engine)을 구상했을 때, 그가 꿈꾼 것은 인간의 오류를 제거한 완벽한 계산이었습니다. 에이다 러브레이스(Ada Lovelace)가 최초의 알고리즘을 작성했을 때, 그녀가 추구한 것은 입력과 출력 사이의 엄밀한 인과관계였습니다. 앨런 튜링(Alan Turing)이 튜링 머신을 정의했을 때, 그는 계산 가능성(computability)이라는 수학적 확실성의 경계를 그었습니다.
이후 70여 년 동안 소프트웨어 공학은 이 확실성을 체계화하는 방향으로 발전했습니다. 구조적 프로그래밍(Structured Programming)은 goto 문의 혼돈에서 제어 흐름의 예측 가능성을 되찾았습니다. 에츠허르 다익스트라(Edsger Dijkstra)는 “프로그래밍은 수학적 증명의 한 형태”라고 선언했고, 토니 호어(Tony Hoare)는 프로그램의 정확성을 논리적으로 증명할 수 있는 공리적 의미론(axiomatic semantics)을 제시했습니다. 타입 시스템은 컴파일 시점에 오류를 잡아내겠다는 약속이었고, 테스트 주도 개발(TDD) — 바로 엉클 밥 자신이 열렬히 옹호해온 방법론 — 은 “작동한다”는 확신을 코드 한 줄 한 줄에 새겨 넣겠다는 의지의 표현이었습니다.
엉클 밥이 “클린 코드”에서 설파한 모든 원칙 — 단일 책임 원칙(SRP), 개방-폐쇄 원칙(OCP), 의존성 역전 원칙(DIP) — 은 결국 “이 코드가 무엇을 하는지 확실히 알 수 있게 하라”는 명령이었습니다. 함수 이름은 그 함수가 하는 일을 정확히 말해야 하고, 부작용(side effect)은 없어야 하며, 모든 경계(boundary)는 명확해야 합니다. 이것이 프로그래머가 믿어온 “확실성의 교리”입니다.
그런데 여기서 엉클 밥 자신이 아주 정직한 고백을 합니다. “Even we are never entirely certain that our programs work.” 우리조차 우리 프로그램이 작동한다고 완전히 확신하지 못한다. 이것은 겸양의 표현이 아닙니다. 이것은 소프트웨어 공학의 가장 불편한 진실을 직시하는 것입니다.
제2장: 확실성의 균열 — 우리가 외면해온 진실
다익스트라는 이렇게 말했습니다. “테스팅은 버그의 존재를 보여줄 수 있지만, 버그의 부재를 증명할 수는 없다(Testing shows the presence, not the absence of bugs).” 이 한 문장은 프로그래밍에서의 확실성이 본질적으로 불완전함을 선언합니다.
사실 프로그래머의 확실성은 언제나 환상에 가까웠습니다. 우리가 “이 프로그램은 작동한다”라고 말할 때, 실제로 의미하는 것은 “내가 테스트한 모든 경우에서 이 프로그램은 기대한 대로 동작했다”입니다. 하지만 가능한 입력의 공간은 거의 항상 무한하고, 우리가 테스트할 수 있는 것은 그 무한한 공간의 극히 일부에 불과합니다. 100% 코드 커버리지를 달성했다 하더라도, 그것은 모든 코드 라인이 한 번 이상 실행되었다는 것이지, 모든 가능한 상태 조합이 검증되었다는 뜻이 아닙니다.
NASA의 소프트웨어 엔지니어들은 우주 왕복선의 비행 제어 소프트웨어에 형식 검증(formal verification)까지 적용했지만, 그럼에도 불구하고 완벽한 확실성에는 도달하지 못했습니다. 화성 기후 궤도선(Mars Climate Orbiter)은 미터법과 야드파운드법의 단위 변환 오류로 화성 대기에서 산화했습니다. 아리안 5호(Ariane 5) 로켓은 64비트 부동소수점을 16비트 정수로 변환하는 과정에서의 오버플로로 발사 37초 만에 폭발했습니다. 보잉 737 MAX의 MCAS 시스템은 단일 센서 의존이라는 설계 결함으로 346명의 목숨을 앗아갔습니다.
이들은 모두 결정론적(deterministic) 프로그램이었습니다. 같은 입력에 항상 같은 출력을 내놓는, 엉클 밥이 말하는 “확실한” 프로그램이었습니다. 문제는 프로그램 자체의 비결정성이 아니라, 프로그램이 작동하는 맥락의 복잡성, 요구사항 해석의 오류, 그리고 인간 인지의 한계였습니다.
여기서 더 깊이 들어가면, 쿠르트 괴델(Kurt Gödel)의 불완전성 정리가 기다리고 있습니다. 충분히 강력한 형식 체계는 자기 자신의 무모순성을 증명할 수 없습니다. 앨런 튜링의 정지 문제(halting problem)는 임의의 프로그램이 유한 시간 내에 종료하는지를 판별하는 일반적 알고리즘이 존재하지 않음을 증명했습니다. 수학과 논리학의 차원에서조차, 절대적 확실성은 도달 불가능한 것입니다.
그러므로 엉클 밥이 “우리조차 프로그램이 작동한다고 완전히 확신하지 못한다”고 말할 때, 이것은 단순한 겸손이 아니라 수학적 진실의 인정입니다. 프로그래머가 추구해온 확실성은 절대적 확실성(absolute certainty)이 아니라, 실용적 확신(practical confidence) — 충분히 많은 증거에 기반한 합리적 믿음이었습니다.
제3장: AI가 가져온 것 — 불확실성의 본질적 차이
그렇다면 AI가 도입한 불확실성은 기존의 불확실성과 본질적으로 같은 것일까요? 엉클 밥의 마지막 질문 — “Is that any different from before AI?” — 에 대해, 저는 “같으면서도 다르다”고 답하고 싶습니다.
기존 소프트웨어의 불확실성은 인식론적(epistemological) 불확실성이었습니다. 프로그램 자체는 결정론적이지만, 우리가 모든 경우를 확인할 수 없기 때문에 불확실합니다. 원리적으로는 무한한 시간과 자원이 있다면 모든 상태를 검증할 수 있습니다. 불확실성의 원천은 우리의 인지적 한계에 있지, 시스템 자체에 있지 않습니다.
반면 AI, 특히 대규모 언어 모델(LLM)이나 딥러닝 시스템의 불확실성은 존재론적(ontological) 불확실성에 더 가깝습니다. GPT나 Claude 같은 모델은 수천억 개의 매개변수(parameter)가 만들어내는 확률 분포에서 다음 토큰을 샘플링합니다. 같은 프롬프트에 같은 모델이 다른 답변을 내놓을 수 있습니다. 이것은 버그가 아닙니다. 이것이 시스템의 본질입니다. Temperature 파라미터를 0으로 설정하면 결정론적 출력을 얻을 수 있지만, 그것은 확률 분포의 최빈값(mode)만을 선택하는 것이지, “정확한 답”을 보장하는 것이 아닙니다.
더 근본적인 차이가 있습니다. 전통적 프로그램에서 개발자는 모든 로직을 명시적으로 작성합니다. if문의 조건, for문의 범위, 함수의 입출력 — 모든 것이 개발자가 의도적으로 설계한 규칙입니다. 따라서 프로그램이 예상치 못한 동작을 하면, 원칙적으로 코드를 추적하여 원인을 찾을 수 있습니다. 디버깅이 가능합니다.
AI 모델에서는 이 추적이 본질적으로 불가능하거나 실질적으로 무의미합니다. 수천억 개의 가중치가 만들어내는 표현 공간(representation space)에서 왜 특정 출력이 나왔는지를 인간이 이해할 수 있는 인과 사슬로 설명하는 것은, 2025년 현재 해결되지 않은 연구 과제입니다. 설명 가능한 AI(Explainable AI, XAI) 분야가 존재하지만, 그것이 제공하는 설명은 사후적 근사(post-hoc approximation)이지 진정한 인과적 설명이 아닙니다.
엉클 밥의 클린 코드 철학에서 가장 중요한 원칙 중 하나는 “코드는 읽히기 위해 작성된다”는 것입니다. 코드의 의도를 다른 프로그래머가 — 혹은 미래의 자기 자신이 — 읽고 이해할 수 있어야 합니다. 신경망의 가중치 행렬은 읽을 수 없습니다. 거기에는 “의도”가 존재하지 않습니다. 학습 데이터에서 추출된 통계적 패턴이 있을 뿐입니다.
이것은 단순히 정도의 차이가 아니라 종류의 차이입니다. 그리고 이 차이가 프로그래머에게 근본적으로 새로운 도전을 제기합니다.
제4장: “그것과 함께 살 수 있는가?” — 이미 우리가 하고 있는 일
엉클 밥은 스스로 답을 제시합니다. “Of course we do, in virtually every other aspect of our lives.” 물론 우리는 그렇게 살고 있다, 삶의 거의 모든 다른 영역에서.
이것은 매우 깊은 통찰입니다. 우리는 매일 아침 불확실성 위를 걷습니다. 길을 건널 때 차가 멈출 것이라는 확실성은 없지만 신호등을 믿고 건넙니다. 비행기를 탈 때 추락하지 않을 것이라는 보장은 없지만 통계적 안전성을 받아들입니다. 의사의 진단을 따를 때 오진의 가능성을 알면서도 최선의 판단을 신뢰합니다. 사랑하는 사람이 내일도 곁에 있을 것이라는 확실성은 어디에도 없지만, 우리는 관계를 맺고 삶을 함께 합니다.
사실 인간 문명 전체가 불확실성을 관리하는 정교한 시스템 위에 세워져 있습니다. 법률 체계는 “합리적 의심의 여지가 없는(beyond reasonable doubt)” 기준으로 작동하지, 수학적 증명의 기준으로 작동하지 않습니다. 의학은 “근거 중심 의학(evidence-based medicine)”이라는 이름 하에 통계적 유의성과 효과 크기를 바탕으로 의사결정을 합니다. 100%의 확실성을 요구했다면 어떤 약도 승인되지 못했을 것입니다. 공학은 안전 계수(safety factor)를 적용하여 불확실성을 수용합니다. 다리가 예상 하중의 정확히 100%만 견디도록 설계하는 공학자는 없습니다.
그런데 유독 소프트웨어만이 — 적어도 이상적으로는 — 확실성을 추구해왔습니다. 왜일까요? 아마도 소프트웨어가 순수한 논리의 산물이기 때문일 것입니다. 물리적 재료의 불균일성도, 날씨의 변덕도, 인체의 복잡성도 없는, 오직 0과 1만의 세계. 이 세계에서는 “완벽한 정확성”이 원리적으로 가능해 보였습니다. 그리고 이 가능성의 환상이 프로그래머를 확실성의 추구자로 만들었습니다.
AI는 이 환상을 깨뜨립니다. 소프트웨어가 더 이상 순수한 논리의 산물이 아니게 됩니다. 데이터에서 학습한 통계적 패턴, 확률적 추론, 근사적 최적화 — 이것들은 물리 세계의 불확실성을 소프트웨어의 영역으로 끌어들입니다. 그리고 엉클 밥의 통찰대로, 이것은 프로그래머에게 새로운 것이 아닙니다. 다른 모든 전문가들이 이미 하고 있는 것 — 불확실성과 함께 사는 것 — 을 프로그래머도 배워야 한다는 뜻일 뿐입니다.
제5장: 불확실성을 가두는 기술 — 그리고 그것이 이전과 같은지 다른지
엉클 밥의 핵심 질문으로 돌아옵시다. “Is our AI future, therefore, one that constrains the uncertain behavior of our machines to remain within acceptable limits? Is that any different from before AI?”
이 질문에 대한 답은 두 겹입니다.
첫째, 원리적 차원에서는 같습니다. 소프트웨어 공학은 언제나 불확실성을 “허용 가능한 범위” 안에 가두는 일이었습니다. 방어적 프로그래밍(defensive programming)은 예상치 못한 입력에 대한 방어입니다. 예외 처리(exception handling)는 오류 상황의 격리입니다. 서킷 브레이커 패턴(circuit breaker pattern)은 장애의 전파를 막는 울타리입니다. 카나리 배포(canary deployment)는 새 코드의 불확실성을 소수의 사용자에게 먼저 노출하는 전략입니다. 모든 것이 “불확실한 행동을 허용 가능한 범위 안에 가두는 것”입니다.
엉클 밥이 평생 주장해온 클린 아키텍처(Clean Architecture)의 핵심도 결국 이것입니다. 경계(boundary)를 명확히 하고, 의존성의 방향을 관리하고, 변경의 영향 범위를 제한하라. 이것은 불확실성 — 미래의 요구사항 변경이라는 불확실성 — 을 관리 가능한 단위로 분할하는 기술입니다.
이 관점에서, AI 시스템에 가드레일(guardrail)을 설치하고, 출력을 검증하고, 인간의 감독 하에 작동하게 하는 것은 기존 소프트웨어 공학의 원칙을 새로운 맥락에 적용하는 것에 불과합니다. 본질은 같습니다.
둘째, 그러나 실천적 차원에서는 다릅니다. 그리고 그 차이는 상당히 중요합니다.
전통적 소프트웨어에서 불확실성을 가두는 울타리는 “이 코드는 이 이상의 일을 하지 않는다”는 확인 가능한 보증이었습니다. 함수의 시그니처, 타입 시스템의 제약, 계약에 의한 설계(Design by Contract)의 사전/사후 조건 — 이것들은 모두 정적으로 검증 가능하거나, 적어도 실행 시점에 확인 가능한 울타리입니다.
AI 시스템의 울타리는 본질적으로 더 느슨합니다. LLM에 “유해한 콘텐츠를 생성하지 마라”는 시스템 프롬프트를 주는 것은 if (isHarmful) throw new Error()를 작성하는 것과 근본적으로 다릅니다. 전자는 확률적이고 우회 가능하며 맥락 의존적입니다. 후자는 결정론적이고 확실합니다(적어도 isHarmful 함수가 정확하다면). RLHF(인간 피드백 기반 강화학습)나 Constitutional AI 같은 정렬(alignment) 기법은 AI의 행동을 원하는 방향으로 유도하지만, “이 모델은 절대로 X를 하지 않는다”는 수학적 보증을 제공하지 못합니다.
또한 검증의 차원이 다릅니다. 전통적 프로그램의 테스트는 입력-출력 쌍을 검증합니다. assertEquals(expected, actual). 명확합니다. AI 시스템의 출력은 어떻게 테스트합니까? “이 번역이 정확한가?”, “이 요약이 원문의 핵심을 포착했는가?”, “이 코드 제안이 안전한가?” — 이런 질문에 대한 답은 true 또는 false로 떨어지지 않습니다. 평가 자체에 인간의 판단이 개입해야 하고, 그 판단 역시 불확실합니다. 이것은 재귀적 불확실성(recursive uncertainty)입니다.
그리고 규모의 차원이 다릅니다. 전통적 소프트웨어의 결함은 대체로 재현 가능(reproducible)합니다. 같은 조건을 만들면 같은 버그가 발생합니다. AI 시스템의 이상 행동은 특정 프롬프트, 특정 맥락, 특정 샘플링 조건의 조합에서만 나타날 수 있으며, 그 조합의 공간은 사실상 무한합니다. “할루시네이션(hallucination)”이라 불리는 현상 — AI가 자신 있게 거짓 정보를 생성하는 것 — 은 예측 불가능한 시점에 예측 불가능한 형태로 발생합니다.
제6장: 엔지니어에서 정원사로 — 역할의 전환
이 지점에서 저는 엉클 밥의 질문을 한 걸음 더 밀고 나가고 싶습니다. “허용 가능한 범위 안에 가두는 것”이 이전과 같은지 다른지를 넘어서, 프로그래머의 정체성 자체가 어떻게 변하는지를 물어야 합니다.
전통적 프로그래머는 건축가(architect)이자 벽돌공(bricklayer)이었습니다. 설계하고, 한 줄 한 줄 쌓아 올리고, 모든 구조물의 위치와 역할을 알고 있었습니다. 코드의 모든 행위는 프로그래머의 의도에서 비롯되었습니다.
AI와 함께 일하는 프로그래머는 정원사(gardener)에 가까워집니다. 씨앗을 심고(학습 데이터와 아키텍처를 선택하고), 토양을 가꾸고(하이퍼파라미터를 조정하고), 울타리를 치고(가드레일을 설치하고), 가지치기를 하지만(출력을 필터링하고 교정하지만), 정원에서 자라나는 것이 정확히 무엇일지를 완전히 통제할 수는 없습니다. 생명이 가진 자율성과 예측 불가능성이 여기에 있습니다 — 비유적으로 말하자면.
엉클 밥이 2025년 9월에 트위터에서 밝혔듯이, 그는 AI가 프로그래밍을 더 나은 방향으로 바꿀 것이며, 프로그래머를 대체하기보다는 프로그래머에 대한 수요를 늘릴 것이라고 믿고 있습니다. 이것은 기술 역사의 패턴과 일치합니다. 새로운 도구는 기존 역할을 없애기보다는 변형합니다. 스프레드시트는 회계사를 없애지 않았고, CAD는 건축가를 없애지 않았습니다. 하지만 변형은 일어났습니다. 수작업 장부를 기록하던 회계사와 재무 모델링을 하는 회계사는 같은 직함을 가졌지만 실질적으로 다른 일을 합니다.
마찬가지로, AI 시대의 프로그래머는 여전히 프로그래머이지만, 그 역할의 핵심이 “코드를 작성하는 것”에서 “시스템의 행동을 설계하고, 감독하고, 교정하는 것”으로 이동합니다. 이것은 확실성의 영역에서 확률의 영역으로의 이동이며, “증명”에서 “증거 기반 판단”으로의 이동입니다.
제7장: 클린 코드에서 클린 시스템으로
엉클 밥의 클린 코드 원칙은 AI 시대에 무의미해지는 것이 아닙니다. 오히려 그 적용 범위가 확장됩니다.
단일 책임 원칙(SRP)은 코드의 함수에만 적용되는 것이 아니라, AI 시스템의 각 구성 요소에도 적용되어야 합니다. LLM이 모든 것을 한 번에 처리하게 하는 것이 아니라, 생성, 검증, 필터링의 책임을 분리해야 합니다. 개방-폐쇄 원칙(OCP)은 AI 모델을 교체하거나 업데이트할 수 있되 전체 시스템을 수정할 필요가 없도록 설계해야 한다는 뜻이 됩니다. 의존성 역전 원칙(DIP)은 비즈니스 로직이 특정 AI 모델에 직접 의존하지 않고, 추상화 계층을 통해 소통해야 한다는 뜻이 됩니다.
테스트 주도 개발(TDD)도 사라지는 것이 아니라 진화합니다. AI 구성요소의 “테스트”는 더 이상 단순한 assertEquals가 아닙니다. 통계적 테스트(일정 비율 이상의 정확도), 적대적 테스트(adversarial testing), 레드팀 평가(red-team evaluation), 회귀 벤치마크(regression benchmark) 등으로 확장됩니다. 확실성의 수준은 낮아지지만, 체계적 검증이라는 정신은 그대로입니다.
결국 엉클 밥이 평생 옹호해온 “소프트웨어 장인정신(software craftsmanship)”의 본질 — 자기 작업에 대한 책임감, 품질에 대한 헌신, 지속적인 개선 — 은 AI 시대에 더 중요해집니다. 기계가 불확실성을 내포하고 있을 때, 그 불확실성을 관리하는 인간의 역량과 윤리적 책임감이야말로 시스템의 최종 품질을 결정합니다.
제8장: 대답, 그러나 완결되지 않은
엉클 밥의 질문에 대한 제 답은 이렇습니다.
네, 우리는 불확실성과 함께 살 수 있습니다. 우리는 항상 그래왔습니다. 프로그래밍에서의 확실성은 아름다운 이상이었지만, 완전히 도달한 적은 없는 이상이었습니다. AI는 이 사실을 더 명시적으로 드러낼 뿐입니다.
네, AI 시대의 미래는 불확실한 행동을 허용 가능한 범위 안에 가두는 것입니다. 그리고 이것은 원리적으로는 우리가 항상 해왔던 일과 같습니다.
하지만 — 그리고 이 “하지만”이 중요합니다 — 실천의 차원에서는 유의미하게 다릅니다. 울타리의 재질이 다르고, 울타리가 가두는 대상의 본성이 다르며, 울타리가 제대로 서 있는지를 확인하는 방법이 다릅니다. 이 차이를 무시하고 “결국 다 같은 것”이라 말하는 것은 위험한 단순화입니다. 반대로 이 차이를 과장하고 “전혀 새로운 것이니 기존의 모든 것을 버려라”라고 말하는 것도 마찬가지로 위험합니다.
진실은 그 사이 어딘가에 있습니다. AI 시대의 프로그래머는 엉클 밥이 가르쳐온 원칙 — 깨끗함, 책임감, 테스트, 지속적 개선 — 을 간직하되, 확실성에 대한 집착은 내려놓아야 합니다. 대신 “충분한 신뢰(sufficient confidence)”라는 더 겸손하고, 더 현실적이며, 어쩌면 더 정직한 기준을 받아들여야 합니다.
그것은 항복이 아닙니다. 그것은 성숙입니다.
소프트웨어 공학이 반세기 동안 확실성을 향해 달려온 것이 헛된 일이었다는 뜻이 아닙니다. 그 여정에서 쌓아 올린 원칙과 기법과 문화는 — 엉클 밥이 누구보다 열정적으로 전파해온 그것들은 — AI 시대의 불확실성을 관리하는 데 있어 가장 든든한 기반입니다. 확실성을 추구해본 사람만이 불확실성의 무게를 알고, 그것을 겸허하게, 그러나 체계적으로 다룰 수 있습니다.
1970년부터 코드를 작성해온 엉클 밥이 이 질문을 던질 수 있는 것은, 바로 그가 확실성의 가치를 누구보다 잘 알기 때문입니다. 그리고 확실성의 한계를 인정하면서도 그 가치를 포기하지 않는 것 — 그것이 AI 시대를 살아가는 프로그래머의 자세가 아닐까 합니다.
에필로그: 확실하지 않은 것이 확실한 유일한 것
수학자 버트런드 러셀(Bertrand Russell)은 이렇게 말했습니다. “의심할 수 없어 보이는 것을 의심하는 것이 철학의 핵심 과업이다.” 프로그래머는 오랫동안 “프로그램은 확실하게 작동해야 한다”는 것을 의심하지 않았습니다. AI는 이 의심할 수 없어 보이는 전제를 의심하게 만듭니다.
그리고 아이러니하게도, 그 의심 속에서 우리는 프로그래밍의 더 깊은 본질에 다가갑니다. 프로그래밍의 본질은 확실한 답을 만드는 것이 아니라, 불확실한 세계에서 유용한 도구를 만드는 것이었으니까요. 처음부터 그랬습니다. 다만 우리가 잠시 잊고 있었을 뿐입니다.
엉클 밥, 질문에 감사합니다. 답은 아직 완결되지 않았지만, 아마 그것이 바로 요점일 것입니다.
작성일: 2026-02-23