들어가며: 하나의 장미를 둘러싼 고민
생텍쥐페리의 ‘어린 왕자’를 읽으며 나는 계속해서 한 가지 질문에 사로잡혔다. 어린 왕자의 장미는 정말 특별한 것일까, 아니면 그가 시간을 들였기에 특별하다고 믿게 된 것일까? 이 질문은 단순해 보이지만, 깊이 파고들수록 우리 삶의 근본적인 가치 판단 문제와 맞닿아 있다는 것을 깨닫게 된다.
나는 이 글에서 명확한 답을 제시하려 하지 않는다. 오히려 여러 관점에서 이 문제를 바라보고, 각 관점이 어떤 통찰을 주는지, 또 어떤 한계를 가지는지 함께 고민해보고자 한다. 어쩌면 내 생각이 틀릴 수도 있고, 독자 여러분은 전혀 다른 결론에 도달할 수도 있다. 그것이 철학적 사유의 본질이 아닐까.
첫 번째 관점: 매몰비용의 함정인가?
처음 이 이야기를 접했을 때, 나는 경제학적 렌즈로 장미를 바라보게 되었다. 어린 왕자는 변덕스럽고 까다로운 장미를 돌보는 데 엄청난 시간과 에너지를 쏟았다. 바람막이를 세우고, 물을 주고, 끊임없는 요구를 들어주었다.
경제학에서 말하는 매몰비용(sunk cost)이란 이미 지불했고 회수할 수 없는 비용을 의미한다. 합리적 의사결정을 위해서는 매몰비용을 무시해야 한다는 것이 정설이다. 그렇다면 어린 왕자의 장미에 대한 집착은 비합리적인 것일까?
하지만 여기서 나는 고민에 빠진다. 과연 인간관계와 감정을 경제학적 합리성으로만 판단할 수 있을까? 우리가 사랑하는 사람, 오래 함께한 친구, 평생을 바친 일에 대한 애착을 단지 “매몰비용의 오류"로 치부하는 것이 정당한가?
어쩌면 매몰비용 이론은 인간 존재의 중요한 측면을 놓치고 있는 것은 아닐까. 우리는 단순히 미래 효용을 계산하는 기계가 아니라, 과거와 현재, 미래가 연결된 서사를 살아가는 존재이기 때문이다.
두 번째 관점: 기업가 정신으로서의 헌신
다른 각도에서 바라보면, 어린 왕자의 태도는 오히려 찬양받아야 할 덕목으로 보이기도 한다. 위대한 기업가들을 생각해보자. 스티브 잡스, 일론 머스크, 제프 베조스… 그들은 모두 자신의 비전에 비합리적이라 여겨질 만큼 집착했다.
만약 그들이 매 순간 냉정하게 비용-편익을 계산하고, 더 나은 기회를 찾아 끊임없이 옮겨 다녔다면 어땠을까? 아마도 애플도, 테슬라도, 아마존도 존재하지 않았을 것이다.
그렇다면 집착과 헌신, 어리석음과 위대함의 경계는 무엇인가? 어린 왕자가 까다로운 장미를 돌보는 것이 어리석은 집착인지, 아니면 존중받아야 할 헌신인지 우리는 어떻게 구분할 수 있을까?
나는 이 질문에 명확한 답을 갖고 있지 않다. 결과론적으로 판단한다면, 성공한 집착은 헌신이 되고 실패한 집착은 어리석음이 된다. 하지만 이것은 너무나 불공정한 판단 기준이 아닌가. 행위 당시에는 어떤 기준으로 판단해야 하는가?
세 번째 관점: 소중함은 만들어지는가?
여우는 어린 왕자에게 가장 중요한 진리를 가르쳐준다: “네가 네 장미를 그토록 소중하게 만든 것은 네가 네 장미를 위해 쓴 시간이야.”
이것은 매우 급진적인 가치론이다. 사물이나 관계가 본질적으로 가치를 지닌 것이 아니라, 우리가 투자한 시간과 관심이 가치를 만들어낸다는 것이다. 이는 플라톤적인 본질주의와는 정반대되는 실존주의적 관점이다.
하지만 나는 여기서도 의문을 품게 된다. 만약 모든 가치가 우리가 투자한 시간에 의해 만들어지는 것이라면, 잘못된 관계, 파괴적인 집착, 학대적인 상황에 머무르는 것도 정당화될 수 있지 않을까?
“이미 10년을 함께했으니 이 사람이 소중해"라는 생각이 때로는 우리를 잘못된 관계에 묶어두는 족쇄가 되기도 한다. 시간과 노력의 투자가 자동으로 가치를 창출한다는 명제는 과연 항상 참인가?
네 번째 관점: 장미 정원의 각성
어린 왕자가 지구에서 수천 송이의 장미를 발견하는 장면은 이야기의 전환점이다. 자신의 장미가 우주에서 유일하다고 믿었는데, 똑같은 장미가 셀 수 없이 많았던 것이다.
이 순간은 철학적으로 매우 중요하다. 주관적 가치와 객관적 현실의 충돌이 일어나는 것이다.
내가 소중히 여기는 것이 객관적으로 보면 평범하거나 심지어 열등할 수 있다는 깨달음. 이것은 고통스럽지만 성숙으로 가는 필수적인 과정이 아닐까.
하지만 동시에 나는 반대로 생각해본다. 모든 것을 객관적으로 평가하고 비교하는 태도가 과연 바람직한가? 만약 우리가 늘 “더 나은 선택"을 찾아 헤맨다면, 우리는 결코 어떤 것에도 뿌리를 내리지 못할 것이다.
객관성과 주관성, 비교와 헌신 사이에서 우리는 어떻게 균형을 잡아야 하는가?
내가 도달한 잠정적 사유: 의식적 선택의 중요성
여러 관점을 고민하며 나는 하나의 잠정적 결론에 도달했다. 물론 이것이 정답이라고 확신하지는 않는다.
핵심은 의식적 선택에 있는 것 같다.
매몰비용에 이끌려 어쩔 수 없이 계속하는 것도 아니고, 맹목적으로 헌신하는 것도 아니며, 그렇다고 냉정하게 계산만 하는 것도 아니다. 중요한 것은:
나의 장미가 특별하지 않을 수 있음을 인정한다 세상에는 더 아름답고, 덜 까다롭고, 더 나은 선택지가 있을 수 있다는 것을 안다.
그럼에도 불구하고 선택한다 모든 것을 알고도, “그래도 이것이 나의 장미다"라고 말할 수 있을 때, 그것은 진정한 헌신이 된다.
정기적으로 재평가한다 한번 선택했다고 해서 영원히 묶이는 것이 아니라, 삶의 단계마다 다시 질문한다. “여전히 이것이 내가 시간을 쓸 가치가 있는가?”
어린 왕자가 여행을 떠난 것, 다른 장미들을 본 것, 여우를 만난 것은 모두 중요하다. 그리고 그 모든 경험을 거쳐 여전히 자신의 장미로 돌아가기로 결심했을 때, 그것은 더 이상 무지에서 비롯된 집착이 아니라 앎에서 나온 사랑이 된다.
여전히 남는 질문들
하지만 나는 여전히 확신하지 못한다.
- 만약 어린 왕자가 더 아름답고 순한 다른 장미를 만났다면 어땠을까?
- “나의 장미"를 고집하는 것이 때로는 새로운 가능성을 차단하는 것은 아닐까?
- 변화와 성장을 위해서는 때로 과거의 집착을 내려놓아야 하는 것은 아닐까?
또한 이런 생각도 든다. 어쩌면 정답은 존재하지 않는 것일지도 모른다. 어떤 사람에게는 한 가지에 대한 평생의 헌신이 의미 있는 삶이 될 것이고, 다른 사람에게는 끊임없는 탐색과 새로운 경험이 올바른 길일 것이다.
실천의 영역: 소프트웨어 엔지니어링에서 만나는 장미들
추상적인 철학적 고찰을 여기서 멈출 수도 있다. 하지만 나는 이 문제가 단순히 이론적 사유에 그치지 않고, 실제 우리의 일상적 결정에 깊이 관여하고 있다는 것을 발견했다. 특히 소프트웨어 엔지니어링, 디자인, 제품 설계 영역에서 우리는 매일같이 “나의 장미"를 마주한다.
사례 1: 레거시 코드 - 버릴 수 없는 장미
첫 번째로 떠오르는 것은 레거시 코드(legacy code) 문제다.
수십 년 된 은행 시스템, 대기업의 핵심 ERP, 정부의 주요 시스템들. 이들은 COBOL, 어셈블리, 혹은 초기 Java로 작성되어 있고, 스파게티 코드에 문서도 없으며, 원래 개발자들은 이미 은퇴했다. 모든 엔지니어가 말한다: “이건 다시 작성해야 합니다.”
하지만 조직은 고민에 빠진다. 이 시스템에 이미 20년의 버그 수정과 비즈니스 로직이 축적되어 있다. 겉으로 보기엔 엉망이지만, 그 안에는 수천 개의 엣지 케이스 처리, 비즈니스 규칙, 보안 패치가 녹아있다.
이것이 바로 어린 왕자의 장미다. 까다롭고, 변덕스럽고, 아름답지 않지만, 20년간 “길들여진” 시스템이다.
역사가 내린 판단들
소프트웨어 업계는 이 문제에 대해 여러 답을 내놓았다:
1) “Rewrite from Scratch” 진영 (2000년대 초반)
조엘 스폴스키(Joel Spolsky)는 유명한 글 “Things You Should Never Do"에서 주장했다: 절대 처음부터 다시 작성하지 마라. Netscape가 브라우저를 다시 작성하다가 망했고, 그 사이 IE가 시장을 장악했다.
이는 “매몰비용을 무시하라"는 경제학 원칙에 반대되는 주장이다. 스폴스키는 말한다: 레거시 코드는 추하지만, 그 안에는 수년간의 비즈니스 지식이 담겨있다. 처음부터 다시 쓰면 그 모든 것을 잃는다.
2) “Strangler Fig Pattern” 진영 (2010년대)
마틴 파울러(Martin Fowler)는 중도적 접근을 제안했다. 교살자 무화과나무(strangler fig)처럼, 기존 시스템을 감싸면서 점진적으로 대체하라는 것이다.
낡은 시스템을 한 번에 버리지도, 영원히 유지하지도 않는다. 새로운 부분은 현대적 기술로 만들고, 핵심 레거시는 당분간 유지하되, 시간을 두고 천천히 이전한다.
3) “Microservices & API Gateway” 진영 (2015년 이후)
최근의 답은 더 실용적이다: 레거시를 하나의 블랙박스로 취급하고, API로 감싸서 고립시킨다. 새로운 기능은 모던 기술 스택으로 만들고, 레거시와는 명확한 인터페이스로만 소통한다.
이는 어떤 의미에서 공존의 철학이다. “나의 장미"가 완벽하지 않음을 인정하되, 완전히 버리지도 않는다.
나의 고민: 과연 이것이 정답인가?
하지만 나는 이 모든 접근이 한 가지 가정을 깔고 있다는 것을 깨닫는다: 레거시 시스템이 여전히 가치를 창출하고 있다는 가정.
만약 시스템이 비즈니스를 실제로 방해하고 있다면? 보안 취약점이 심각하다면? 인재 채용이 불가능해진다면? 그때도 “점진적 개선"이 답일까?
어쩌면 우리는 레거시 코드에 대해 감상적으로 접근하는 것은 아닐까. “20년간 쌓인 비즈니스 로직"이라는 표현이 실은 자기합리화는 아닐까?
사례 2: 프레임워크 선택 - 어느 장미 정원으로 갈 것인가
두 번째 사례는 기술 스택 선택의 문제다.
2010년, 당신은 웹 프론트엔드를 만들어야 한다. jQuery가 대세다. 모두가 사용한다. 튜토리얼도 많고, 플러그인도 풍부하다. 당신은 jQuery를 선택하고, 3년간 시스템을 구축한다.
2013년, Angular가 등장한다. 구조화된 프레임워크, 양방향 바인딩, 혁신적이다. 하지만 당신은 이미 jQuery에 투자했다. 옮겨갈까? 아니면 계속 갈까?
2015년, React가 등장한다. 더 빠르고, 더 유연하다. Angular는 벌써 “레거시"가 되었다.
2020년, Vue, Svelte, Solid가 나온다. React조차도 “낡았다"는 목소리가 들린다.
이것이 바로 장미 정원의 딜레마다. 내 장미(jQuery)가 유일하다고 믿었는데, 더 아름다운 장미들(React, Vue…)이 끊임없이 등장한다.
기술 업계의 반응
1) “Hype Cycle” 비판자들
일부 베테랑 개발자들은 경고한다: “새로운 기술을 쫓아다니지 마라. 기본 원칙(HTML, CSS, JavaScript)을 제대로 배워라. 프레임워크는 유행이 지나간다.”
이들은 어린 왕자의 철학에 가깝다. “나의 장미를 길들이는 것이 중요하다. 매번 새로운 장미로 옮겨다니면, 진정한 숙련은 오지 않는다.”
2) “Early Adopter” 진영
반대로 일부 개발자들은 항상 최신 기술을 추구한다. “낡은 기술에 머물면 도태된다. 끊임없이 배우고 적응해야 한다.”
이들은 장미 정원의 발견을 긍정적으로 본다. 더 나은 선택이 있다면 주저 없이 옮겨가야 한다는 것이다.
3) “Boring Technology” 철학 (Dan McKinley)
2015년, Etsy의 엔지니어 Dan McKinley는 “Choose Boring Technology”라는 글을 썼다. 핵심은: 혁신 토큰(innovation token)을 아껴 써라.
모든 부분에서 최신 기술을 쓸 수는 없다. 대부분은 검증된 “지루한” 기술을 쓰고, 정말 중요한 부분에만 새로운 기술을 도입하라.
이것은 균형잡힌 접근이다. 장미 정원의 존재를 인정하되, 모든 장미를 다 가질 수는 없다는 현실적 판단.
내가 경험한 혼란
나 역시 이 딜레마를 겪었다.
한 프로젝트에서 React를 선택했고, 2년간 깊이 학습했다. 그러다 새 프로젝트에서 Vue를 써야 했고, 또 다른 곳에서는 Svelte를 사용했다.
어느 순간 나는 질문했다: 나는 프론트엔드를 배우는 것인가, 아니면 프레임워크를 배우는 것인가?
만약 내가 React에 머물렀다면, 나는 더 깊은 숙련에 도달했을까? 아니면 시장에서 도태되었을까?
반대로, 계속 새 기술을 쫓아다니면서 나는 어떤 것도 진정으로 마스터하지 못하는 것은 아닐까?
이 질문에 나는 여전히 명확한 답이 없다.
사례 3: 마이크로서비스 vs 모놀리스 - 아키텍처의 장미
세 번째 사례는 아키텍처 선택이다.
역사적 흐름
2000년대 중반: 모놀리스의 시대
당시 대부분의 서비스는 하나의 거대한 애플리케이션이었다. Rails 앱 하나, Django 앱 하나로 모든 것을 처리했다. 단순하고, 배포하기 쉬웠다.
2010년대 초중반: 마이크로서비스 혁명
Netflix, Amazon이 마이크로서비스 아키텍처를 전파했다. 작은 서비스들로 쪼개면 확장성, 독립성, 팀 자율성이 생긴다고 했다. 모두가 마이크로서비스로 전환했다.
2010년대 후반: 환멸의 시기
현실이 복잡했다. 분산 트랜잭션, 서비스 간 통신, 배포 복잡도, 디버깅 난이도… 많은 팀이 고통받았다. “마이크로서비스는 분산 모놀리스일 뿐"이라는 비판이 나왔다.
2020년대: 회귀와 재평가
DHH(Ruby on Rails 창시자)는 “The Majestic Monolith"를 주장했다. 대부분의 회사는 마이크로서비스가 필요 없다. 잘 구조화된 모놀리스가 더 낫다.
고민의 본질
이 역사가 보여주는 것은 무엇인가?
기술 커뮤니티 전체가 집단적으로 장미 정원의 딜레마를 겪었다는 것이다.
- 모놀리스(나의 장미)가 문제투성이로 보였다
- 마이크로서비스(새로운 장미 정원)가 해답처럼 보였다
- 막상 가보니 그곳도 문제투성이였다
- 결국 “어디에나 트레이드오프가 있다"는 겸손한 깨달음
그렇다면 우리는 처음부터 틀렸던 것인가?
나는 아니라고 생각한다. 이 여정 자체가 필요했다. 마이크로서비스를 경험해보지 않았다면, 모놀리스의 장점을 제대로 이해할 수 없었을 것이다. 어린 왕자가 장미 정원을 보지 않았다면, 자신의 장미를 제대로 이해할 수 없었던 것처럼.
사례 4: 제품 Pivot - 장미를 바꾸는 결단
마지막 사례는 제품 전략의 pivot이다.
Instagram의 경우
Instagram은 원래 Burbn이라는 위치 기반 체크인 앱이었다. Foursquare 경쟁자를 만들려고 했다. 1년을 투자했다. 하지만 사용자 반응이 미지근했다.
창업자 Kevin Systrom과 Mike Krieger는 고민했다: 1년간 만든 이 앱에 계속 투자할 것인가?
데이터를 보니 사용자들은 체크인보다 사진 공유 기능을 더 많이 썼다. 그들은 과감한 결정을 내렸다: 모든 기능을 제거하고, 사진 공유만 남기자.
8주 만에 Instagram을 만들었고, 2년 후 Facebook에 10억 달러에 인수되었다.
이것은 장미를 바꾼 사례다. Burbn이라는 까다로운 장미를 1년간 돌봤지만, 결국 버렸다. 매몰비용을 무시하고, 더 나은 방향으로 pivot했다.
Slack의 경우
Slack도 비슷하다. 원래는 Glitch라는 온라인 게임을 만들고 있었다. 4년, 1700만 달러를 투자했다. 게임은 실패했다.
창업자 Stewart Butterfield는 게임을 포기하고, 개발 중 내부적으로 쓰던 커뮤니케이션 툴에 집중하기로 했다. 그것이 Slack이 되었고, 현재 시가총액 수백억 달러의 기업이 되었다.
반대 사례: Theranos
반면 Theranos는 어떨까? Elizabeth Holmes는 한 방울의 피로 모든 것을 검사하는 기술을 만들겠다고 했다. 기술이 작동하지 않았다. 과학자들이 불가능하다고 했다.
하지만 그녀는 10년 이상 “비전"을 고집했다. 투자자와 직원, 대중을 속이면서까지. 결국 사기죄로 감옥에 갔다.
이것은 장미에 대한 맹목적 집착의 사례다. 모든 증거가 “이것은 작동하지 않는다"고 말하는데도, “나의 장미는 특별하다"는 망상에 빠졌다.
어떻게 구분할 것인가?
Instagram과 Slack은 pivot해서 성공했다. Theranos는 고집을 부려서 실패했다.
그렇다면 언제 버리고 언제 끝까지 밀어붙여야 하는가?
이것이 바로 핵심 질문이다. 그리고 솔직히 말하면, 사전에 구분할 명확한 방법은 없다.
투자자들 사이에는 이런 말이 있다: “성공한 창업가는 visionary(비전가)고, 실패한 창업가는 stubborn(고집불통)이다. 차이는 결과뿐이다.”
이것이 우리를 불편하게 만든다. 사후적으로만 판단 가능한 것을 사전에 결정해야 한다는 것.
역사가 가르치는 교훈: 그래서 우리는 무엇을 배웠는가?
이 모든 사례를 거쳐 나는 묻게 된다: 소프트웨어와 제품 설계 분야는 “장미 정원의 딜레마"에 대해 어떤 지혜를 축적했는가?
교훈 1: “상황에 따라 다르다” (It Depends)
소프트웨어 아키텍트들에게 질문하면 가장 자주 듣는 대답이 “상황에 따라 다르다(It depends)“다.
처음엔 비겁한 답으로 들릴 수도 있다. 하지만 이것이 가장 정직한 답이라고 생각한다.
- 레거시를 유지할 것인가? It depends (팀 크기, 비즈니스 위험도, 기술 부채 정도에 따라)
- 마이크로서비스를 쓸 것인가? It depends (조직 구조, 트래픽 규모, 팀 숙련도에 따라)
- 새 프레임워크로 이전할 것인가? It depends (프로젝트 단계, 마이그레이션 비용, 채용 시장에 따라)
이것은 상대주의가 아니다. 오히려 맥락의 중요성을 인정하는 것이다.
교훈 2: 측정하고 반복하라 (Measure and Iterate)
Lean Startup 방법론의 핵심은 “Build-Measure-Learn” 사이클이다.
Instagram과 Slack이 성공한 이유는 데이터를 봤기 때문이다. 사용자 행동 데이터가 “사진 공유가 체크인보다 중요하다"고 말했다. 그들은 자존심을 내려놓고 데이터를 따랐다.
Theranos가 실패한 이유는 측정을 거부했기 때문이다. 독립적 검증을 피하고, 데이터를 조작하고, 비전만을 고집했다.
즉, 장미가 정말 특별한지 계속 확인하라는 것이다. 감정이 아니라 증거로.
교훈 3: One-way door와 Two-way door를 구분하라
Jeff Bezos는 의사결정을 “One-way door"와 “Two-way door"로 구분한다.
- One-way door (단방향 문): 한번 들어가면 되돌아오기 어렵거나 불가능한 결정. 신중하게, 충분한 정보를 수집한 후 결정해야 한다.
- Two-way door (양방향 문): 마음에 안 들면 다시 돌아올 수 있는 결정. 빠르게 실험하고, 잘못되면 되돌리면 된다.
프레임워크 선택은 대체로 Two-way door에 가깝다. 비용이 들긴 하지만 바꿀 수 있다. 반면 데이터베이스 선택이나 프로그래밍 언어 선택은 One-way door에 가깝다. 나중에 바꾸기 매우 어렵다.
나의 장미가 One-way door인지 Two-way door인지 파악하는 것이 중요하다. One-way door라면 더 신중해야 하고, Two-way door라면 빠르게 시도해보고 배울 수 있다.
교훈 4: 팀과 조직 맥락이 기술보다 중요할 수 있다
Conway’s Law는 말한다: “시스템 구조는 조직 구조를 따른다.”
마이크로서비스가 실패하는 이유 중 하나는 조직이 준비되지 않았기 때문이다. 여전히 중앙집중식 의사결정, 공유 데이터베이스, 단일 배포 파이프라인… 이런 환경에서 마이크로서비스는 오히려 독이 된다.
즉, 기술 선택은 기술적 요소만으로 결정되지 않는다. 팀의 경험, 조직 문화, 커뮤니케이션 구조, 심지어 리더십 스타일까지 영향을 준다.
어쩌면 “나의 장미"가 객관적으로 좋지 않더라도, 우리 팀에게는 맞을 수 있다는 것이다.
그렇다면 이것이 정답인가? 나의 회의
하지만 나는 여전히 확신하지 못한다.
이 모든 “교훈"들이 사후합리화는 아닐까? 성공 사례를 보고 “아, 저들은 데이터를 봤구나, 가역적 결정을 잘 내렸구나"라고 해석하는 것은 쉽다.
하지만 실패한 수천 개의 스타트업도 데이터를 봤고, 신중히 결정했으며, 최선을 다했다. 그들은 단지 운이 나빴을 뿐인 것은 아닐까?
또한 “It depends"라는 답이 정말 도움이 될까? 실제 결정의 순간에 나는 여전히 혼란스럽다. 모든 것이 상황에 따라 다르다면, 나는 어떤 원칙으로 판단해야 하는가?
어쩌면 소프트웨어 엔지니어링도 어린 왕자의 딜레마를 해결하지 못했다는 것이 답일지도 모른다.
맺으며: 불완전한 결론
나는 이 글을 명확한 답이 아닌 질문으로 마무리하고자 한다.
당신의 장미는 무엇인가?
- 당신의 레거시 코드인가?
- 당신이 깊이 배운 프레임워크인가?
- 당신이 수년간 개발해온 제품인가?
그것이 정말 특별한가, 아니면 당신이 시간을 들여서 특별하다고 믿게 된 것인가?
다른 선택지들을 충분히 탐색해보았는가? 아니면 “장미 정원"에 현혹되어 끊임없이 방황하고 있는가?
그리고 모든 것을 알고도 여전히 그것을 선택하겠는가?
나는 내 삶에서 이 질문들과 계속 씨름하고 있다. 때로는 매몰비용의 오류에 빠진 것 같아 불안하고, 때로는 너무 쉽게 포기하는 것이 아닌가 걱정된다.
프로젝트를 선택할 때, 기술 스택을 고를 때, 리팩토링을 결정할 때, 심지어 커리어를 설계할 때마다 이 질문이 되돌아온다.
아마도 이 긴장 속에서 살아가는 것, 끊임없이 질문하고 재평가하면서도 지금 이 순간의 선택에 충실하려는 것, 그것이 엔지니어로, 인간으로 산다는 것의 의미가 아닐까.
여우의 말을 다시 떠올린다:
“본질은 눈에 보이지 않아. 마음으로 보아야 잘 보여.”
하지만 나는 여기에 한 문장을 덧붙이고 싶다.
“그러나 때로는 눈으로도 보아야 한다. 마음만으로는 자기기만에 빠질 수 있으니까.”
그리고 소프트웨어 엔지니어의 관점에서 하나 더:
“데이터를 보라. 측정하라. 하지만 숫자가 전부는 아니라는 것도 기억하라.”
이것이 맞는 말인지 나는 확신할 수 없다. 다만 지금 이 순간, 내가 도달한 불완전한 생각일 뿐이다.