또다시 반복되는 기술 만능 프레임

요즘 AI 코딩 열풍을 보면서 몇 년 전이 떠오른다. MSA(마이크로서비스 아키텍처)가 모든 개발 문제의 해답처럼 여겨지던 그 시절 말이다. 당시에는 이랬다. 배포가 복잡하면 "MSA 하면 해결돼", 팀 간 갈등이 생기면 "서비스 분리하면 돼", 코드가 엉켜있으면 "마이크로서비스로 쪼개면 돼". 조직의 구조적 문제와 설계 이슈를 MSA라는 기술로 풀 수 있다고 믿었다. 지금은? 코딩이 어려우면 "AI 쓰면 돼", 학습이 힘들면 "AI한테 물어봐", 경험이 부족하면 "AI가 다 알려줘". 개발자의 역량 문제와 성장 과정의 어려움을 AI라는 도구로 해결할 수 있다고 여긴다. 겉보기에는 완전히 다른 이야기 같다. 하지만 본질은 똑같다. 근본적인 문제를 기술적 선택으로 우회하려는 사고방식이 그대로 반복되고 있다. 그래서 지금의 AI 붐을 단순한 기술 발전으로 보기보다는, 우리 업계에 주기적으로 나타나는 '기술 만능주의 사이클'의 또 다른 버전으로 이해해야 한다. ## 새로운 도구가 등장할 때마다 반복되는 이분법 역사를 돌이켜보면 혁신적인 도구가 나타날 때마다 항상 같은 패턴의 논쟁이 벌어진다. "이걸 안 쓰면 뒤처진다"는 쪽과 "이런 식으로 하면 실력이 늘지 않는다"는 쪽 사이에서. 구글링이 보편화됐을 때도 그랬다. "검색해서 복붙하는 건 진짜 개발이 아니다"라는 비판과 "정보 시대에 암기가 무슨 의미냐"는 반박이 맞섰다. MSA 열풍 때도 "아직도 모놀리식 고수하냐"와 "무작정 분리만 하면 되는 줄 아냐" 사이에서 비슷한 논쟁이 있었다. 지금 AI를 둘러싼 논란도 동일한 구조다. "AI 모르면 도태된다"와 "AI만 쓰면 바보 된다" 사이에서 말이다. 표면적으로는 도구 활용법에 대한 기술적 논의 같아 보이지만, 실제로는 어떤 문제를 누구의 책임으로 규정하느냐에 대한 근본적 관점 차이다. 결국 문제 정의 자체를 둘러싼 논쟁인 것이다. ## MSA 만능론: 구조 문제를 기술로 해결하려던 착각 몇 년 전 MSA 열풍을 자세히 분석해보자. 당시 많은 조직이 직면했던 전형적인 문제들은 이런 것들이었다: 배포 과정이 복잡하고 시간이 오래 걸린다. 여러 팀이 동시에 작업하면서 충돌과 병목이 빈발한다. 장애 발생 시 원인 파악이 어렵고 책임 소재가 불분명하다. 코드베이스가 비대해지면서 유지보수가 갈수록 힘들어진다. 이런 문제들의 실제 원인은 무엇이었을까? 대부분 조직 구조의 문제, 의사결정 프로세스의 문제, 도메인 경계 설정의 문제, 책임과 권한 분배의 문제였다. 즉, 사람과 조직 운영의 문제였다. 그런데 당시 주류 해결책은 어땠나? - 조직 재편? "너무 복잡해" - 프로세스 개선? "시간이 오래 걸려" - 도메인 재설계? "당장 급한데" - MSA 도입? "바로 시작할 수 있어!" 결과는? 기술적 복잡도만 폭증했을 뿐 원래 문제들은 더 악화됐다. 분산 시스템 특유의 복잡성, 네트워크 지연과 장애, 데이터 정합성 문제, 모니터링과 디버깅의 어려움까지 보너스로 얻게 됐다. 핵심적인 부분은 MSA가 필요하다고 느껴질 정도면 이미 조직과 설계가 상당히 엉망인 상태인 것이다. 그 상황에서 기술적 분리만 강행하면 문제가 해결되는 게 아니라 더 복잡해질 뿐이다. 기술은 이미 존재하는 구조적 문제를 마법처럼 해결해주지 않는다. ## AI 만능론: 역량 문제를 도구로 해결하려는 착각 이제 현재 상황을 보자. AI 코딩과 학습을 둘러싼 전형적인 상황들은 이렇다: 개발 학습 곡선이 가파르다. 실무에서 요구하는 기술 수준이 높다. 경험을 쌓으려면 긴 시간과 수많은 시행착오가 필요하다. 빠른 성과를 내야 한다는 압박이 크다. 이런 문제들의 실제 원인은? 개발자 개인의 역량 부족, 체계적인 학습 경험의 부재, 사고 과정의 미숙함, 문제 해결 경험의 부족 등이다. 즉, 개인의 성장과 역량 개발 과정의 문제다. 그런데 지금 주류가 되고 있는 해결책은? - 기초부터 체계적 학습? "너무 지루해" - 시행착오를 통한 경험 축적? "비효율적이야" - 단계적 역량 개발? "시간이 오래 걸려" - AI 활용? "바로 완성!" 결과는? 코드는 빨리 만들어지지만 본인의 이해도와 판단력은 전혀 늘지 않는다. 더 심각한 건 스스로 문제를 진단하고 해결하는 능력 자체가 퇴화된다는 점이다. MSA 사례와 구조가 정확히 같다. 그때는 조직 문제를 기술로 덮으려 했고, 지금은 개인 역량 문제를 기술로 덮으려 한다. AI가 MSA보다 더 위험한 이유는 사고 과정 자체까지 대체할 수 있을 만큼 강력하기 때문이다. ## AI는 왜 구글링이나 컴파일러와 본질적으로 다른가 "AI도 결국 더 좋은 도구일 뿐 아니냐"는 반론이 있을 수 있다. 하지만 중요한 차이가 있다. 구글링의 본질부터 보자. 구글링을 할 때는 검색 → 비교 → 이해 → 적용 → 디버깅이라는 과정을 거쳤다. 여러 검색 결과를 비교하고, 내 상황에 맞는지 판단하고, 실제 적용해보면서 문제를 해결해야 했다. 핵심은 최종 판단과 책임이 여전히 개발자에게 있었다는 점이다. 구글링은 정보 접근성을 높이는 도구였지, 사고를 대신하는 도구가 아니었다. 컴파일러 비유도 생각해보자. 일부에서는 AI를 "새로운 패러다임의 컴파일러"라고 부르기도 한다. 어셈블리에서 고급 언어로, 컴파일러 등장으로 개발 방식이 바뀐 것처럼 AI도 그런 전환점이라는 것이다. 하지만 컴파일러는 표현 방식의 추상화만 제공했다. 개발자는 여전히 알고리즘을 설계하고, 자료구조를 선택하고, 로직을 구성해야 했다. 컴파일러는 저수준 구현의 복잡함을 감춰줬을 뿐, 무엇을 어떻게 만들지는 여전히 개발자가 결정해야 했다. AI의 질적 차이는 명확하다. AI는 질문 → 완성된 답안으로 직접 점프할 수 있게 해준다. 코드 작성은 물론이고 설계 방향, 구현 방법, 디버깅 전략까지 전 과정을 대체할 수 있다. 학습과 사고 과정 전체를 건너뛸 수 있게 하는 최초의 도구인 셈이다. 그래서 AI는 단순한 생산성 향상 도구가 아니라 사고와 학습의 구조 자체를 바꾸는 기술이다. ## 경험이 축적되지 않는 생산성 실제 현장에서는 어떤 일이 벌어지고 있을까? 전형적인 패턴을 보자: 문제 발생 → AI에게 질문 → 완성된 코드 수신 → 작동 확인 → 다음 작업으로 이동. 이 과정에서 "왜 이런 방식으로 해결됐는지", "다른 접근법은 없었는지", "이 해법의 장단점은 무엇인지" 같은 고민은 생략된다. 결과적으로는? 완성된 기능의 개수는 늘어나고 개발 속도도 빨라지지만, 문제를 스스로 분해하고 해결하는 능력은 전혀 늘지 않는다. 비슷한 문제를 다시 만나도 여전히 AI에 의존할 수밖에 없고, 조금만 예외적이거나 복잡한 상황이 되면 속수무책이 된다. 이는 개인의 의지력이나 성실성 문제가 아니다. 인간 본성의 자연스러운 결과다. 사람은 본능적으로 고통스러운 과정은 피하고 즉각적 보상을 추구한다. AI의 "질문하면 바로 답변" 구조는 이런 인간 본성과 완벽하게 들어맞는다. 따라서 이는 개인의 도덕적 해이 문제가 아니라 도구 자체가 만드는 구조적 유혹의 문제다. ## 역설적으로 더 중요해지는 기초 AI가 발전할수록 기초가 더 중요해진다는 건 역설처럼 들리지만, 논리적으로 당연한 귀결이다. AI가 여러 해답과 접근법을 제시할 때 필요한 능력들을 보자: - 어떤 접근이 현재 상황에 적합한지 판단하는 능력 - 장기적으로 문제가 될 수 있는 설계를 걸러내는 능력 - 제시된 솔루션을 구체적 맥락에 맞게 조정하는 능력 - AI 응답이 틀렸거나 부적절할 때 이를 발견할 수 있는 능력 계산기 비유로 이해해보자: - 산수를 잘한다 = 기본 계산을 빠르고 정확하게 수행 - 계산기를 잘 쓴다 = 도구를 효율적으로 활용해서 복잡한 계산 처리 - 수학을 잘한다 = 어떤 계산이 필요한지 판단하고 문제를 수학적으로 모델링 이 세 능력은 분명히 연관되어 있지만 본질적으로 다른 영역이다. AI 코딩도 마찬가지다. AI로 코드를 생성하는 것과 어떤 코드가 필요한지 판단하는 것은 완전히 별개의 능력이다. 진짜 개발 실력은 결국 문제 정의, 접근법 선택, 결과 검증에서 갈린다. 이런 능력들은 AI가 주입해줄 수 없고, 오직 반복적인 사고 경험을 통해서만 축적될 수 있다. 과거를 돌아보면 흥미로운 사실이 있다. 구글링이 보편화된 후에도 주니어가 갑자기 시니어로 승격되는 일은 없었다. 주니어와 시니어의 실제 차이는? - 주니어: 구글링으로 코드 조각 찾아서 복붙하고 "일단 작동한다"로 끝 - 시니어: 구글링으로 반복 작업 시간을 절약해서 더 본질적 문제에 집중 시니어는 절약한 시간을 전체 아키텍처 설계, 장기적 유지보수성 고려, 비즈니스 요구사항을 기술로 번역하는 작업 등에 투자했다. 하지만 그러려면 "무엇이 핵심이고 무엇이 부차적인지"를 구분할 수 있는 안목이 필요했고, 이는 탄탄한 기초에서만 나왔다. 노코드 툴로 드래그앤드롭해서 앱을 만들어 스토어에 올렸다고 해서 모바일 개발자가 되지는 않는다. 진짜 개발자와 "툴 사용자"의 차이는 "필요할 때 더 깊은 레벨까지 파고들어 문제를 해결할 수 있는 능력"이다. 이는 하루아침에 생기지 않으며, 기초부터 차근차근 쌓아올린 이해에서만 나온다. ## 도구가 아니라 접근 방식을 바꿔야 한다 AI 자체가 문제가 아니다. 동일한 AI를 사용해도 완전히 다른 결과가 나올 수 있다. 핵심은 어떤 방식으로 접근하느냐다. AI와 함께 사고하는 방식: 1. "이 문제를 어떻게 접근하는 게 좋을까?" → AI에게 조언 요청 2. 제시된 여러 방법을 비교하고 각각의 장단점 분석 3. 현재 제약조건과 맥락을 고려해서 최적안 선택 4. 구현하면서 발생하는 이슈들을 스스로 판단하고 조정 5. 결과를 검증하고 다음번에 응용할 수 있는 원리 추출 AI에게 사고를 맡기는 방식: 1. "이거 해결해줘" → AI 코드를 그대로 복사 2. 작동하면 통과 3. 왜 그렇게 됐는지는 관심 없음 4. 다음 문제도 똑같이 AI에게 의존 이 둘의 차이는 단순히 생산성 차이가 아니라 성장 구조의 차이다. 전자는 AI를 활용해 경험과 역량을 확장하지만, 후자는 AI로 성장 과정 자체를 회피한다. 과거 구글링 시대의 시니어들이 검색으로 절약한 시간을 더 핵심적인 아키텍처 고민에 투자했던 것처럼, AI 시대의 진정한 전문가들은 AI로 절약한 시간을 더 높은 차원의 설계와 판단 능력 개발에 사용할 것이다. ## 기술은 구조도 실력도 만들어주지 않는다 결론적으로, MSA가 조직을 성숙하게 만들어주지 못했듯이, AI도 개발자를 자동으로 성장시켜주지는 않는다. 기술은 언제나 이미 갖춰진 구조와 역량을 증폭시킬 뿐, 없던 것을 무에서 창조해내지는 못한다. 탄탄한 기초와 올바른 접근법이 있는 상태에서 AI를 활용하면 놀라운 시너지를 낼 수 있다. 하지만 기초도 접근법도 잘못된 상태에서 AI를 쓰면 문제만 더 커진다. 그래서 정말 중요한 질문은 "어떤 도구를 쓸 것인가"가 아니라 "그 도구가 우리 사고를 확장시키고 있는가, 아니면 대체하고 있는가"다. 10년쯤 후에는 "AI 네이티브 세대가 기존 개발자들보다 훨씬 뛰어나다"는 말이 나올지도 모른다. 그리고 그때 또 새로운 혁명적 기술이 등장하면, 지금과 똑같은 논쟁이 다시 벌어질 것이다. 확실한 것은 올바른 접근 방식과 탄탄한 기초가 없다면, 어떤 기술이 나와도 결국 같은 실패 패턴을 반복하게 된다. 계산기를 쓰면서도 수학적 직관을 잃지 않는 수학자처럼, AI를 적극 활용하면서도 설계하고 판단하는 핵심 역량을 지속적으로 키워나가는 개발자가 되어야 한다. 그리고 그런 역량은 결국 탄탄한 기초 위에서만 자랄 수 있다. --- 과거에는 조직과 설계의 문제를 MSA라는 기술로 해결하려 했고, 지금은 개발자의 역량과 경험 문제를 AI라는 도구로 해결하려 한다. 대상은 달라졌지만, 기술로 본질을 덮으려는 사고방식은 전혀 변하지 않았다.