레거시 시스템의 숨겨진 특성은 재작성 실패로 이어집니다
원본 영상 9:33코드베이스에는 종종 문서화되지 않은, 틈새 행동 및 '특성' 또는 개별 사용자를 위해 구현된 특정 패치들이 많습니다. 이러한 '끔찍한' 해결책들은 시간이 지남에 따라 시스템에 깊이 뿌리박히고 중요하지만 모호한 기능을 수행합니다. 이러한 종속성을 철저히 이해하지 않고 전체 시스템을 교체하려는 시도는 재작성 실패의 흔한 원인입니다.
복잡한 소프트웨어 개발에서는 어느 누구도 전체 코드베이스를 완전히 파악할 수 없으므로 부분적인 이해가 필수적인 기술입니다.
이 채널 새 영상도 이렇게 정리해 드릴까요?
코드베이스에는 종종 문서화되지 않은, 틈새 행동 및 '특성' 또는 개별 사용자를 위해 구현된 특정 패치들이 많습니다. 이러한 '끔찍한' 해결책들은 시간이 지남에 따라 시스템에 깊이 뿌리박히고 중요하지만 모호한 기능을 수행합니다. 이러한 종속성을 철저히 이해하지 않고 전체 시스템을 교체하려는 시도는 재작성 실패의 흔한 원인입니다.
성공적인 재작성 전략은 전체 시스템 교체 대신 반복적인 프로세스를 선호합니다. 이 방법은 기존 코드베이스를 작고 고립된 청크로 분할하는 것으로 시작합니다. 그런 다음 한 번에 하나의 청크를 수정하고 교체하며, 전환 과정 내내 이전 시스템이 작동 상태를 유지하도록 하는 것이 중요합니다.
재작성을 고려하기 전에 기존 코드베이스에 대한 충분한 이해를 갖추어 의미 있는 기여를 하는 것이 중요합니다. 여기에는 현재 코드베이스에서 적극적으로 작업하여 직관을 구축하고 팀 역학을 평가하며, 진정으로 문제가 되는 영역을 정확히 찾아내는 것이 포함됩니다. AI 도구가 도움을 줄 수 있지만, 인간의 근본적인 이해 필요성을 없애지는 못합니다.
많은 개발자들이 '평균적인 재작성자'의 함정에 빠져, 깊은 이해보다는 성능에 대한 피상적인 가정에 기반하여 (종종 Rust와 같은 언어로) 재작성을 옹호합니다. 이는 종종 Electron과 같은 기본 기술이 실제로 어떻게 작동하는지에 대한 오해에서 비롯되어 좋지 않은 아키텍처 결정을 초래합니다. 원래 문제를 해결하지 않고 코드를 맹목적으로 교체하는 것은 불필요한 복잡성만 초래할 뿐입니다.
대규모 조직에서는 원래 개발자가 더 이상 참여하지 않아 코드가 유지 관리되지 않는 코드베이스를 자주 접하게 됩니다. 이러한 코드베이스의 소유권을 가지려면 처음부터 흐름에 대한 새로운 이론을 구축해야 합니다. 이 복구 프로세스의 가장 효과적인 시작점은 시스템 내에서 하나의 종단 간 흐름을 완전히 이해하는 것입니다.
AI는 주로 코드 출력에 대한 직접적인 질문에 답함으로써 레거시 코드베이스에 대한 지식 습득 과정을 크게 단순화합니다. AI는 역사적 맥락이 부족하지만, 새로운 개발자가 시스템 작동 방식에 대한 자신만의 이론을 구축하는 데 도움이 되는 귀중한 통찰력을 제공할 수 있습니다.
충분히 크고 복잡한 코드베이스에서는 어떤 개인도 전체 시스템에 대한 완벽하고 정확하며 포괄적인 이론을 가지고 있지 않다는 것이 보편적인 진리입니다. 매우 숙련되고 경험이 풍부한 엔지니어조차도 특정 구성 요소가 어떻게 작동하는지에 대해 '우스꽝스러운' 오해를 가지고 있는 경우가 많습니다. 코드베이스의 모든 측면에 대한 완전한 이해를 가장하는 것보다 이러한 내재된 한계를 인정하는 것이 훨씬 더 현실적이고 생산적인 접근 방식입니다. 이러한 부분적인 지식을 수용하면 불완전한 정신 모델에 기반한 가정을 하기보다는 엔지니어가 질문하고 명확화를 요청하도록 장려하므로 더욱 효과적인 협업 및 문제 해결이 가능합니다.
개인의 고성능 선호도에도 불구하고, 비즈니스 요구 사항과 프로젝트 마감 기한은 종종 최적화되지 않은 또는 '느린' 코드 생성을 필요로 합니다. 광범위한 코드베이스의 완전하고 완벽하게 정확한 정신 모델을 유지하는 것은 비슷한 균형을 제시하며, 여기서 절대적인 이해는 종종 실질적인 진행과 적시 납품을 위해 희생됩니다.
개인적으로 성능에 얼마나 신경 쓰든 간에, 직장에서 느린 코드를 작성해야 할 때가 있다는 것은 잘 알려져 있을 것입니다.
부분적인 이해만으로 코드에 대해 국지적으로 추론할 수 있는 능력은 컴퓨터 과학이 시작된 이래로 핵심 목표였습니다. 이 현실은 '좋은 엔지니어가 나쁜 코드를 작성한다'는 이전 연구에서 강조되었는데, 이는 완전히 투명하지 않은 시스템 내에서 효과적으로 기능해야 하는 실질적인 필요성을 강조합니다. 전문 표준은 완전한 이해가 종종 달성 불가능하며 항상 필요한 것은 아니라는 점을 점점 더 인식하고 있습니다.
엔지니어는 테크 리더와 관리자가 전달하는 요구 사항과 기대를 명확하게 이해할 수 있는 능력을 갖춰야 합니다. 여기에는 강력한 소프트 스킬과 팀 목표와의 조화가 포함되며, 이는 순수한 기술력만큼이나 중요합니다. 이러한 의사소통 및 협업 기술이 부족하면 엔지니어는 고급 언어 모델보다 효과적이지 못할 수 있습니다.
당신에게 작업을 주는 사람은 당신이 이해할 수 있어야 합니다. 당신은 팀이 무엇을 요구하는지 알아야 합니다.
인간의 인지적 한계는 개인이 전체 프로그램을 마음에 담아두는 것을 방해하며, 특히 AI가 가능하게 한 코드 볼륨의 기하급수적인 증가로 인해 더욱 그렇습니다. 이러한 엄청난 규모는 심층적인 구현 세부 사항에 깊이 파고들지 않고 높은 수준의 이해에 초점을 맞추는 접근 방식인 '바이브 코딩'이 기본 프로그래밍 패러다임이 될 것임을 시사합니다. 따라서 불완전한 정보로 효과적으로 작업하는 것이 개발자에게 필수적인 새로운 기술로 부상하고 있습니다.
실제 사례는 React Native에서 SwiftUI로 T3 모바일 애플리케이션을 기존 소스 코드를 한 줄도 읽을 필요 없이 성공적으로 재작성하는 것을 보여줍니다. 이러한 성과는 특정 코드 구현을 꼼꼼히 분석하는 것보다는 데이터 흐름과 일반적인 실패 패턴에 대한 깊은 이해에 뿌리를 두고 있었습니다. 광범위한 이전 아키텍처 경험은 코드베이스를 효과적으로 탐색하고 궁극적으로 변환하는 데 중요한 요소임이 입증되었으며, 줄별 검사보다 시스템 통찰력의 가치를 강조합니다.
현대 개발자들은 동시에 코드베이스에 대한 더 깊은 이해를 얻으면서도 특정 세부 사항으로부터 점점 더 단절되는 흥미로운 이중성을 경험하고 있습니다. 이러한 심오한 패러다임 변화는 새로운 개발자가 되는 것과 흡사하며, 새로운 도구와 방법론에 대한 적응을 필요로 합니다. 이러한 산업 변화는 스트레스의 원인이라기보다는 성장의 기회로 받아들여져야 하며, 현대 개발자의 역동적이고 진화하는 역할을 육성해야 합니다.
자막에서 근거가 되는 대목을 찾아 답합니다.
이 채널 새 영상도 이렇게 정리해 드릴까요?
Theo - t3․gg에 새 영상이 올라오면, 방금 읽으신 것처럼 정리해서 메일로 보내 드릴게요.
이 채널은 지난 7일 동안 4편 올렸어요.
숏츠는 빼고 보내 드려요. 메일이 필요 없어지면 언제든 구독을 끄실 수 있어요.