Trillions Spent and Big Software Projects Are Still Failing
AI won’t solve IT’s management problems
Why worry about something that isn’t going to happen?”
KGB Chairman Charkov’s question to inorganic chemist Valery Legasov in HBO’s “Chernobyl” miniseries makes a good epitaph for the hundreds of software development, modernization, and operational failures I have covered for IEEE Spectrum since my first contribution, to its September 2005 special issue on learning—or rather, not learning—from software failures. I noted then, and it’s still true two decades later: Software failures are universally unbiased. They happen in every country, to large companies and small. They happen in commercial, nonprofit, and governmental organizations, regardless of status or reputation.
수조 달러를 지출했지만 대규모 소프트웨어 프로젝트는 여전히 실패하고 있습니다.
AI는 IT 관리 문제를 해결하지 못합니다.
" 일어나지 않을 일에 대해 왜 걱정하는가 ?"
전 세계 IT 지출은 2005년 이후 2025년 기준 1조 7천억 달러에서 5조 6천억 달러로 세 배 이상 증가했으며, 앞으로도 계속 증가할 것으로 예상됩니다. 지출 증가에도 불구하고 소프트웨어 성공률은 지난 20년 동안 눈에 띄게 개선되지 않았습니다. 결과적으로 소프트웨어가 급속도로 확산되고 우리 삶의 모든 측면에 스며들며 상호 연결됨에 따라, 실패로 인한 기업 및 사회적 비용은 계속해서 증가하고 있습니다.
AI 소프트웨어 도구와 코딩 부조종사가 대규모 IT 소프트웨어 프로젝트를 빠르게 성공으로 이끌기를 바라는 사람들은 잊어버리세요. 가까운 미래에는 AI가 시스템 엔지니어링 , 프로젝트, 재무, 경영, 특히 대규모 소프트웨어 프로젝트에 관련된 조직 정치 등 수많은 교차점과 상충 관계를 제어하고 관리하는 데 있어 어떤 역할을 할 수 있는지에 대한 명확한 한계가 있습니다. AI가 학습할 수 있거나 학습해야 하는 합리적인 의사 결정의 모범 사례가 되는 IT 프로젝트는 거의 없습니다 . 소프트웨어 실무자들이 알고 있듯이, IT 프로젝트는 AI 없이도 경영진의 환각과 망상에 시달리고 있습니다.
20년 전에 언급했듯이 소프트웨어 실패의 원인은 인간 상상력의 실패, 비현실적이거나 구체화되지 않은 프로젝트 목표, 프로젝트의 복잡성을 처리할 수 없는 능력 또는 관리되지 않은 위험 등 오늘날에도 여전히 정기적으로 IT 실패를 일으키는 몇 가지를 들 수 있습니다 . 많은 다른 원인은 수십 년 전으로 거슬러 올라가며, 빌라노바 대학교 경영대학원 의 비즈니스 기술 학과장인 스티븐 안드리올이 아래 다이어그램에서 2021년 포브스 에 처음 게재한 것과 같습니다 .독특하고 이전에는 문서화되지 않은 방식으로 궤도를 벗어난 소프트웨어 시스템 실패를 발견하는 것은 놀라운 일입니다.소프트웨어 관련 실패의 압도적 다수는 수십 년 동안 수백 개의 사후 보고서, 학술 연구, 기술 및 관리 서적에 기록된 피할 수 있고 알려진 실패 유발 요인과 관련이 있기 때문입니다.실패 데자뷰가 문헌을 지배합니다.
문제는, 우리가 반복적으로 배워야 했던 것을 왜 적용하지 않았는가 하는 것입니다
결코 일어나지 않는 불사조
지난 20년 동안 제가 분석한 많은 IT 개발 및 운영 실패 사례 들은 체르노빌 사고와 같은 붕괴를 겪었고, 그로 인해 평판에 악영향을 미치는 방사능 이 곳곳에 퍼져 수년간 피해를 입은 사람들의 삶을 오염시켰습니다 . 각 사례는 일반적으로 믿기 어려운 이야기를 담고 있습니다 . 대표적인 사례로, 캐나다 정부의 3억 1천만 달러 규모의 피닉스 급여 시스템이 있습니다 . 이 시스템은 2016년 4월에 가동을 시작했지만 얼마 지나지 않아 초임계 상태에 빠졌습니다.
최악의 IT 실패
Phoenix 급여 지급 실패는 지금까지 최악의 운영 IT 시스템 실패인 Fujitsu 가 제공한 영국 우정국의 전자 판매 시점(EPOS) Horizon 시스템에 비하면 아무것도 아닙니다 . 1999년에 출시된 Horizon은 의도적으로 숨겨진 내부 소프트웨어 오류 로 가득 차 있었고 , 이로 인해 우정국은 3,500명의 지역 우정 지점 관리자를 허위 회계, 사기 및 절도 혐의로 부당하게 고발했습니다 . 이 관리자 중 약 900명이 유죄 판결을 받았고 , 1999년과 2015년 사이에 236명이 투옥되었습니다 . 그때쯤이 되어서야 일반 대중과 지점 관리자들 스스로가 마침내 Computer Weekly 의 기자들 (2008년부터 Horizon의 문제에 대해 끈질기게 보도해 온)과 합류하여 Horizon의 소프트웨어에 심각한 문제가 있다는 것을 알게 되었습니다. 그 후 10년 동안의 법정 소송 , 독립적인 공개 법정 조사, ITV 미니시리즈 " Mr. Bates vs. The Post Office "를 거쳐서야 스캔들이 어떻게 발생했는지 밝혀낼 수 있었습니다.
피닉스처럼 호라이즌도 기술, 경영, 조직, 법률, 윤리적 실패로 인한 문제들로 골머리를 앓았습니다 . 예를 들어, 핵심 전자 POS 시스템 소프트웨어는 통신 및 데이터 전송 미들웨어 기반으로 구축되었는데, 이 미들웨어 자체에도 버그가 있었습니다. 게다가, 호라이즌의 기능은 끊임없이 무분별하게 범위를 확대하는 관행 으로 인해 제대로 작동하지 않았습니다. 개발 및 프로젝트 관리 프로세스가 비효율적이거나 누락 되었고 , 테스트가 부족했으며, 숙련된 전문 인력, 기술 인력, 관리 인력이 부족 했습니다.
우정국 고위 경영진은 호라이즌 소프트웨어가 완전히 신뢰할 만하다고 거듭 주장하며, 이에 의문을 제기하는 우체국장들에게 적대적인 태도를 취했고, 이는 오히려 악순환을 더욱 심화시켰습니다. 결과적으로, 우체국 경영진은 모든 법적 수단을 동원하여 세계적인 수준의 은폐 공작을 벌였습니다. 여기에는 무죄를 입증하는 정보의 적극적인 은폐 도 포함되었습니다 . 이를 통해 우정국은 우체국장들을 적극적으로 기소하고 호라이즌의 정직성에 의문을 제기하는 모든 반대 의견을 탄압할 수 있었습니다.
놀랍게도, 억울하게 고발된 사람들은 파괴된 삶에 대한 정당한 보상을 받기 위해 여전히 싸워야 합니다 . 고발자 중 약 350명이 사망했으며, 그중 최소 13명은 자살로 추정됩니다 . 그들은 부당한 대우에 대한 보상도 받지 못했습니다. 안타깝게도 2016년 과 2021년 에 Horizon 시스템을 대체하려는 시도가 실패로 돌아갔지만, 우정국은 적어도 현재로서는 Horizon 시스템 을 계속 사용하고 있습니다 . 정부는 새로운 시스템에 4억 1천만 파운드를 투자 할 계획 이지만, 시스템 구축에는 훨씬 더 많은 비용이 소요될 것으로 예상됩니다. 우정국은 2025년 여름 새로운 POS 소프트웨어 시스템 입찰을 접수했으며, 2026년 7월 1일까지 최종 결정을 내릴 예정입니다.
캐나다 정부가 피닉스 오류로 인한 적체 문제를 최종적으로 해결하겠다고 약속했던 2025년 3월 말까지 34만 9천 건 이상이 아직 해결되지 않은 상태였으며, 그중 53%는 1년 이상 계류 중입니다. 6월, 캐나다 정부는 2026년 6월까지 적체 문제를 크게 줄이겠다고 다시 한번 약속했습니다 . 이전 약속들을 고려하면 회의적인 시각이 정당합니다.
피닉스 사태와 관련된 캐나다 납세자들의 재정적 비용은 현재까지 51억 캐나다 달러 (미화 36억 달러)를 넘어섰습니다. 이 사태의 최종 비용을 계산하는 데는 수년이 걸릴 것입니다. 정부는 피닉스 대체 시설 건설을 결정하기 전에 최소 1억 캐나다 달러(미화 7,100만 달러)를 지출했는데, 정부는 대체 시설 건설에 수억 달러의 추가 비용이 발생하고 시행까지 수년이 걸릴 것이라고 인정했습니다 . 고(故) 마이클 퍼거슨 캐나다 감사원장 은 피닉스 사태에 대한 감사 보고서에서 이 노력을 "이해할 수 없는 프로젝트 관리 및 감독 실패"라고 설명했습니다 .
프로젝트 관리 및 감독 측면에서는 재앙일지 몰라도, 피닉스는 상상도 할 수 없는 실패는 분명 아닙니다 . IT 업계는 수십 년 동안 이 이해하기 어려운 일상을 더욱 이해하기 쉽게 만들기 위해 힘써 왔습니다 .
소프트웨어 실패 로 인한 기회 비용은 계속 쌓이고 있습니다.
캐나다 국경 남쪽에 위치한 미국 에서도 2005년 이후 IT 관련 개발 및 운영 실패로 인한 총 비용이 수조 달러에 달해 잠재적으로 10조 달러를 넘어섰습니다. 정보소프트웨어품질컨소시엄 ( CISQ) 의 보고서에 따르면 , 2022년 미국에서 운영 소프트웨어 실패로 인한 연간 비용은 1조 8,100억 달러에 달했으며, 소프트웨어 개발 실패에 추가로 2,600억 달러가 지출되었습니다. 이는 같은 해 미국 국방 예산 총액인 7,780억 달러 보다 큰 규모입니다 .
문제는, 우리가 반복적으로 배워야 했던 것을 왜 적용하지 않았는가 하는 것입니다.
CISQ 보고서는 미국 내 조직이 매년 레거시 소프트웨어 시스템을 지원하는 데 5,200억 달러 이상을 지출하고 있으며, 조직 IT 예산의 70~75%가 레거시 유지 관리에 사용된다고 추정합니다. 서비스 회사 NTT DATA 의 2024년 보고서 에 따르면 조직의 80%가 "부적절하거나 오래된 기술이 조직의 진보와 혁신 노력을 저해하고 있다"고 인정했습니다. 나아가 보고서는 사실상 모든 C급 임원이 레거시 인프라가 시장에 대응하는 능력을 방해한다고 생각한다고 말합니다. 그럼에도 불구하고 레거시 시스템을 교체하는 비용이 일반적으로 지원 비용의 여러 배이기 때문에 기업 임원은 더 이상 운영상 실행 가능하거나 비용 효율적이지 않을 때까지 교체를 주저합니다 . 또 다른 이유는 교체하면 Phoenix나 다른 사례 처럼 대참사 가 될 것이라는 근거 있는 두려움 입니다 .
그럼에도 불구하고 소프트웨어 개발 및 유지 관리 프로세스를 개선하기 위한 노력은 꾸준히 이어져 왔습니다. 예를 들어, 애자일(Agile) 접근 방식, DevOps 방법론 및 기타 관련 관행을 통해 소프트웨어 시스템을 개발하고 유지하기 위한 반복적이고 점진적인 전략의 채택이 증가하고 있습니다.
목표는 최단 시간 내에 최종 사용자에게 사용 가능하고 신뢰할 수 있으며 저렴한 소프트웨어를 제공하는 것입니다. DevOps는 소프트웨어 수명 주기 전체에 걸쳐 이를 지속적으로 달성하기 위해 노력합니다. Agile 과 DevOps는 많은 조직에서 성공을 거두었지만, 논란과 반발 또한 존재합니다. Agile 프로젝트의 실패율이 최대 65%에 달한다는 도발적인 보고서가 있는 반면, DevOps 이니셔티브의 최대 90%가 조직의 기대치를 충족하지 못한다는 주장도 있습니다 .
이러한 주장에 주의를 기울이는 동시에, 애자일이나 DevOps 방식을 성공적으로 구현하려면 일관된 리더십, 조직 규율, 인내심, 교육 투자, 그리고 기업 문화 변화가 필요하다는 점을 인지하는 것이 가장 좋습니다. 하지만 새로운 소프트웨어 플랫폼을 도입할 때도 이러한 요구 사항은 항상 존재해 왔습니다. 검증된 관행을 도입하려는 조직의 의지가 역사적으로 부족했던 점을 고려하면, 아무리 효과적이라 하더라도 점점 더 복잡해지는 소프트웨어 시스템을 개발하고 유지하기 위한 새로운 접근 방식 역시 종종 부족함을 드러냅니다.
사회 전체가 안정적인 소프트웨어에 거의 전적으로 의존하고, 실패 사례가 광범위하게 기록되어 교훈을 얻을 수 있음에도 불구하고, 소프트웨어 개발 및 운영 과정에서 기본적인 IT 프로젝트 관리 및 거버넌스 실수가 왜 그토록 자주 발생하는지에 대한 답답하고 끊임없는 의문이 제기됩니다. IT가 점점 상호 의존적인 관계로 통합되고 있는 전기 인프라와 더불어, 컴퓨팅 시스템의 고장은 현대 사회에 존재론적 위협이 됩니다.
실망스럽게도, IT 업계는 이전 실패에서 교훈을 얻지 못하는 경우가 많습니다 . IT 프로젝트 관리자들은 자신의 프로젝트가 어떻게든 다르거나 독특하기 때문에 이전 실패에서 얻은 교훈은 무의미하다고 주장합니다 . 이는 오만한 자들의 변명일 뿐, 무지한 자들의 변명은 아닙니다. 예를 들어 피닉스 프로젝트의 경우, 정부의 두 번째 급여 시스템 교체 시도 였는데 , 첫 번째 시도는 1995년에 실패로 끝났습니다. 피닉스 프로젝트 관리자들은 첫 번째 실패의 명확한 이유를 무시했습니다. 교훈이 적용되지 않는다고 주장했기 때문입니다. 하지만 이는 관리자들이 실패를 반복하는 것을 막는 데 아무런 도움이 되지 않았습니다. 흔히 말하듯이, 우리는 성공보다 실패에서 더 많은 것을 배우지만, 반복되는 실패는 엄청난 대가를 치르게 합니다.
모든 소프트웨어 개발 실패가 나쁜 것은 아닙니다. 어떤 실패는 바람직하기까지 합니다. AI 관련 활동처럼 새로운 유형의 소프트웨어 제품, 기술 또는 관행을 개발하는 과정에서 한계를 뛰어넘을 때, 잠재적 실패는 용인될 수 있는 가능성입니다. 실패를 통해 경험이 쌓이고, 새로운 통찰력을 얻고, 해결책을 찾고, 제약 조건을 더 잘 이해하며, 기술 혁신과 진보가 지속됩니다. 그러나 오늘날 대부분의 IT 실패는 컴퓨팅 기술의 혁신적 한계를 뛰어넘는 것과 관련이 없으며, 오히려 일상적인 것의 경계에서 발생합니다. 오스트리아 경제학자 요제프 슘페터가 말한 " 창조적 파괴의 강풍 "을 의미하는 것이 아닙니다. 오히려 재정적 파괴의 강풍에 가깝습니다. 성공이 일상이 되려면 얼마나 더 많은 ERP(Enterprise Resource Planning) 프로젝트 실패가 필요할까요? 이러한 실패는 IT 실패라고 불러야 마땅합니다. 이러한 실패에서 새로운 것을 배우는 것은 아무리 좋게 봐도 미심쩍기 때문입니다.
피닉스는 실패였을까요, 아니면 실수였을까요? 저는 후자라고 강력히 주장하지만, 피닉스는 최소한 IT 프로젝트 관리 부실 의 대가라고 할 수 있습니다. 문제는 캐나다 정부가 1995년 급여 지급 프로젝트 실패에서 얻은 교훈보다 이번 경험을 통해 더 많은 것을 배웠는지 여부입니다 . 정부는 피닉스 실패가 정치적으로 큰 주목을 받고 있다는 점을 고려하면, 아마도 사실일지도 모릅니다. 하지만 피닉스의 교훈이 교체 또는 현대화가 필요한 수천 개의 노후된 캐나다 정부 IT 시스템 에까지 적용될 수 있을까요 ? 바라건대, 희망은 방법론이 아니며, 목적 의식 있는 조치가 필요합니다.
IT 커뮤니티는 수십 년 동안 이해할 수 없는 일상을 만들기 위해 힘써 노력해 왔습니다.
같은 실수를 반복하면서 다른 결과를 기대하는 것은 배우는 것이 아닙니다. 우스꽝스럽고 터무니없는 일입니다. 헨리 페트로스키 의 저서 『엔지니어는 인간이다: 성공적인 설계에서 실패의 역할』 (빈티지, 1992)에서 인용하자면, 우리는 위험으로 인한 소프트웨어 실패를 계산하는 방법은 배웠을지 몰라도, 마음의 실패를 제거하는 계산 방법은 배우지 못했습니다. 피닉스처럼 부실한 관리로 인해 실패한 프로젝트 사례는 많지만 , 전문적으로 관리된 소프트웨어 프로젝트에서도 여전히 실패한 사례를 찾는 것은 극히 어렵습니다. "IT 영웅적 실패"라고 부를 수 있는 사례를 찾는 것은 마치 디오게네스가 정직한 한 사람을 찾는 것과 같습니다 .
실수에서 교훈을 얻지 못하면 사회가 인공지능 , 더 정확히는 소프트웨어 시스템에 내장된 "지능형" 알고리즘 의 영향력이 커짐에 따라 훨씬 더 크고 은밀한 결과를 초래할 것입니다 . 과거의 교훈을 무시할 경우 어떤 일이 벌어질지 보여주는 단서는 미시간 주의 MiDAS 실업 수당 시스템 과 호주 센터링크의 "로보빚" 복지 시스템 에서 초기 자동화된 의사결정이 실패했던 놀라운 사례에서 찾아볼 수 있습니다 . 두 시스템 모두 인간의 감독 없이 사기성 지급 청구를 적발하기 위해 의심스러운 알고리즘을 사용했습니다. 주 정부 관리들은 MiDAS를 이용하여 수만 명의 미시간 주민을 실업 수당 사기 혐의로 고발했고, 센터링크 관계자들은 수십만 명의 호주인을 복지 수당 사기 혐의로 거짓 고발했습니다. 이 사건으로 인해 헤아릴 수 없이 많은 사람들의 삶이 예전과 같지 않을 것입니다. 미시간과 호주 정부 관리들은 이러한 알고리즘을 지나치게 신뢰했습니다. 소프트웨어의 신뢰성이 명백히 입증되었음에도 불구하고, 그들은 무언가 잘못되었다는 것을 인정하기 위해 발길질과 비명을 지르며 끌려다녀야 했습니다. 그럼에도 불구하고, 공무원들은 실수가 국민에게 미치는 영향을 축소하려 했고, 그 실수의 피해를 입은 사람들에게 보상하는 데 반대했습니다. 이러한 행위는 법적으로는 "행정 부실"로 규정되지만, 현실적으로는 행정적 악행이 더 가깝습니다
정부 기관에서 이런 일이 발생한다면, AI 기반 시스템이 제대로 작동하지 않는 이윤 추구 기업들이 더 잘 대처할 수 있다고 생각하십니까? AI가 점점 더 많은 IT 시스템, 특히 정부 시스템 과 개인이 사용할 수밖에 없는 디지털 공공 인프라 에 내장됨에 따라 , 이러한 시스템의 의사 결정 방식이 불투명해지면서 이의를 제기하기가 더욱 어려워질 것입니다. 유럽 연합은 순전히 알고리즘에 의한 결정이 자신에게 불리할 경우 개인에게 법적 " 설명을 받을 권리 " 를 부여했습니다 . 모든 자동화 시스템에 대한 투명성과 책임성이 근본적인 세계 인권이 되어야 할 때입니다.
따라서 우리에게는 명백한 사실을 다시 한번 강조해야 할 직업적, 개인적 의무만이 남았습니다. IT 시스템 구축에 착수하기 전에 자신이 무엇을 알고, 무엇을 알아야 하는지, 그리고 그 둘 사이의 격차가 얼마나 큰지 자문해 보세요. 만약 다른 누구도 당신이 요청한 일정, 예산, 그리고 기능으로 당신의 시스템을 성공적으로 구축한 적이 없다면, 당신의 조직이 왜 그렇게 할 수 있다고 생각하는지 설명해 주세요. 소프트웨어는 본질적으로 취약합니다. 복잡하고 안전하며 복원력이 뛰어난 소프트웨어 시스템을 구축하는 것은 어렵고, 세부적이며, 시간이 많이 걸립니다. 작은 오류는 엄청난 결과를 초래하며, 사소한 기능 오류부터 시스템 중단, 사이버 보안 위협의 시스템 침투까지 거의 무한한 방식으로 나타날 수 있습니다. 시스템이 복잡하고 상호 연결될수록 오류와 그 악용의 가능성은 더 커집니다. 좋은 시작은 예산을 통제하는 고위 경영진이 소프트웨어 및 시스템 개발 , 운영 및 유지 보수 노력을 마땅히 존중하는 것입니다. 이는 인력, 재정 자원, 리더십 지원 및 헌신을 제공하는 것뿐만 아니라, 그들이 요구하는 전문적, 개인적 책임을 다하는 것을 의미합니다.
정직, 회의주의, 그리고 윤리가 프로젝트 성공에 필수적이라는 것은 잘 알려져 있지만, 이러한 요소들은 종종 부재합니다. 오직 고위 경영진만이 이러한 요소들을 요구할 수 있습니다. 예를 들어, 정직은 모든 IT 사업에 수반되는 수많은 위험에 대한 합리화가 아닌, 솔직한 설명 에서 시작됩니다 . 문제가 있는 소프트웨어 개발 프로젝트를 해결하기 위한 자금을 확보하는 것이, 관련 위험 해결에 필요한 것을 미리 요구하는 것보다 훨씬 쉽다는 것은 누구나 아는 "비밀"입니다. 공급업체의 허세는 합법적일 수 있지만, 이는 IT 고객이 공급업체의 전형적인 허황된 약속에 대해 건전한 회의론을 가져야 한다는 것을 의미합니다. 계약이 체결되면 이미 너무 늦습니다. 더욱이 컴퓨팅의 유연성, 복잡성, 속도, 저렴한 비용, 그리고 정보 복제 및 저장 능력은 개인과 사회에 미치는 컴퓨팅의 결과에 대한 깊은 성찰을 요구하는 윤리적 상황을 만들어냅니다 . 안타깝게도 기술 발전과 수익 창출에 있어 윤리적 고려 사항은 종종 뒤처져 왔습니다 . 특히 AI가 자동화 시스템에 일상적으로 도입되고 있는 상황에서 이러한 관행은 반드시 바뀌어야 합니다.
AI 커뮤니티에서는 인간 중심 AI , 즉 인간의 필요, 가치, 그리고 웰빙을 우선시하는 AI 시스템을 지향하는 움직임이 있어 왔습니다 . 이는 AI가 언제 어디서 잘못될 수 있는지 예측하고, 이러한 상황을 제거하기 위해 노력하고, 만약 문제가 발생한다면 그 영향을 완화할 수 있는 방법을 구축하는 것을 의미합니다. 이 개념은 AI뿐만 아니라 모든 IT 시스템에 적용되어야 합니다.
입증된 관행을 주입하려는 조직적 결의가 역사적으로 부족했기 때문에... 점점 더 복잡해지는 소프트웨어 시스템을 개발하고 유지하기 위한 새로운 접근 방식... 역시 종종 부족할 것입니다.
마지막으로, 소프트웨어 개발의 프로젝트 비용-편익 정당화는 문제가 발생했을 때 IT 시스템 최종 사용자에게 발생하는 재정적, 정서적 고통을 거의 고려하지 않습니다 . 여기에는 장기적인 실패 후유증이 포함됩니다 . Phoenix, MiDAS, Centrelink의 경우처럼 이러한 비용을 완전히 고려해야 한다면 성공적인 소프트웨어 시스템을 만드는 데 필요한 관리적, 재정적, 기술적, 경험적 요구 사항에 대해 더 현실적인 견해가 있을 수 있습니다 . 그것은 절망적인 요청일 수 있지만, IT 커뮤니티가 적어도 1968년 " 소프트웨어 위기 "라는 용어가 만들어진 이후로 반복해서 저지른 똑같은 어리석은 실수를 저지르는 것을 멈춰야 할 때입니다. 새로운 실수를 하세요, 젠장. 로마의 웅변가 키케로가 필리피서 12장 에서 말했듯이 , "누구나 실수를 할 수 있지만, 오직 바보만이 자신의 실수를 고집합니다."
![[멍청대전] 이재명 정청래 찌라시](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhvj8NLPYJ1gEisr6Ot9i-Yl14SuFAj6-b7TFzqN-3IklvY01O5sL4dR5Kpqn9rJXoIyVQWvDlZw6iIGuI1sZID_ZeNsyTL72bBrNXaTM6JrNLm5GZjjK5wEgNILRV3mPG02G-KlMaCXHXxHZgC5XFrSOMDw6Qm802sOv9WIy187fs3FSisLSS-6LYgSVQ/w72-h72-p-k-no-nu/ttt.jpg)
댓글 없음:
댓글 쓰기