기술적 부채에 대해 생각할 때, 부적합한 아키텍처의 결과를 깨닫게 해 준 첫 번째 애플리케이션이 아직도 기억납니다. 제가 처음 컨설턴트로 일을 시작하던 1990년대 후반에 그런 일이 일어났습니다.  클라이언트는 고객을 위한 조달 시스템을 구축하기 위해   플랫폼 사용을 요청했습니다. Lotus Notes 클라이언트와 사용자 정의 애플리케이션을 사용하여 최종 사용자는 애플리케이션에서 추적하고 제품 소유자 팀에서 이행하는 요청을 할 수 있습니다. 이론적으로는 정말 멋진 아이디어였습니다. 특히 웹 개발 애플리케이션이 널리 보급되지 않았고 모든 사람이 매일 Lotus Notes를 사용했기 때문에 더욱 그렇습니다. Lotus Notes  핵심 문제는 데이터가 설계상 매우 관계형이라는 것입니다. 그리고 Lotus Notes는 관계형 데이터베이스가 아닙니다. 솔루션 설계에는 모든 Lotus Notes 문서 내의 스키마 관리가 필요했으며 일련의 다중 값 필드를 활용하여 데이터 속성 간의 관계를 시뮬레이션했습니다. 그것은 엉망이었다.  더 나은 플랫폼이 권장되었다면 Lotus Notes 애플리케이션에 많은 로직이 필요하지 않았을 것입니다. 소스 코드는 지원하기가 복잡했습니다. 데이터 구조의 향상으로 인해 기본 코드가 대대적으로 리팩토링되었습니다. 기존 데이터를 변환하기 위해 서버 기반 작업을 실행하는 것은 말할 것도 없습니다. 보고서 작성에 필요한 노력을 시작하지 마세요.  저는 경력 초기부터 더 나은 솔루션을 제공하기보다는 클라이언트가 원하는 솔루션을 제공하는 데 중점을 두었습니다. 이것은 확실히 제가 경력 초기에 배운 교훈이었지만, 그 프로젝트 이후 몇 년 동안 저는 건축 기술 부채의 결과가 우리 모두가 직면한 불행한 현실이라는 것을 깨닫게 되었습니다.  아키텍처 기술 부채의 개념을 거시적 수준에서 좀 더 살펴보겠습니다.  건축 기술 부채(ATD)  Carnegie Mellon University의 ATD(Architectural Technical Debt) 라이브러리는 ATD에 대해 다음과 같은   제공합니다. 정의를  건축 기술 부채는 단기적으로는 편리한 설계 또는 건설 접근 방식이지만 동일한 작업에 아키텍처 재작업이 필요하고 지금 수행하는 데 드는 비용보다 나중에 수행하는 데 더 많은 비용이 발생하는 기술적 상황을 생성합니다(시간에 따른 비용 증가 포함). .  Gartner Group은 "빠른 답변: 아키텍처 기술 부채 관리 방법"(2023년 9월 22일 게시)에서 ATD를 다음과 같이 정의합니다.  아키텍처 기술 부채는 아키텍처 드리프트, 최적이 아닌 아키텍처 결정, 정의된 대상 제품 아키텍처 및 확립된 업계 아키텍처 모범 사례 위반, 더 빠른 소프트웨어 제공을 위한 아키텍처 절충으로 인해 발생하는 기술 부채 유형입니다.  두 경우 모두 단기적인 축하를 주는 이점이 장기적인 문제에 직면할 수 있습니다. 이는 소개에서 언급한 Lotus Notes 예제와 유사합니다.  문제를 더욱 복잡하게 만드는 것은 소프트웨어 개발의 다른 측면에 비해 소프트웨어 아키텍처에 대한 기술 부채를 식별하고 관리하는 데 도움이 되는 도구가 누락되었다는 점입니다. 코드 품질, 관찰 가능성 및 SCA를 위해 Sonarqube, Datadog, New Relic, GitHub 및 Snyk와 같은 제품에 입증된 도구가 있습니다. 그러나 소프트웨어 아키텍처 부문은 검증된 솔루션이 없어 뒤처져 왔습니다.  “   섹션에서 볼 수 있듯이 ATD가 지속적으로 가장 크고 가장 피해가 큰 기술 부채 유형이라는 사실을 고려하면 이는 유감스러운 일입니다.   ” Carnegie Mellon이 발표한 2015년 연구. 측정하세요?” 관리하시겠습니까? 무시해? 소프트웨어 실무자와 기술 부채  다음 그림은 해당 보고서의 그림 4를 요약하여 잘못된 아키텍처 선택이 기술 부채 원인의 확실한 선두주자라는 결론을 내렸습니다.  관리하지 않으면 ATD는 다음의 간단한 그림에서 볼 수 있듯이 시간이 지남에 따라 계속해서 증가하는 속도로 증가할 수 있습니다.  완화가 없으면 아키텍처 부채는 결국 측정되는 기본 솔루션의 한계점에 도달하게 됩니다.  ATD 관리  ATD를 관리하기 전에 먼저 문제를 이해해야 합니다.   한때 "코끼리를 먹는 방법은 한 번에 한 입씩 먹는 것"이라고 현명하게 말했습니다. Desmond Tutu는  Shift-Left 접근 방식은 주어진 측면을 수명주기의 끝이 아닌 시작 부분에 더 가깝게 이동시키는 개념을 포함합니다. 이 개념은 테스트 단계를 개발 완료 후 완료해야 하는 별도의 이벤트가 아닌 개발 프로세스의 일부로 이동하는 테스트용 Shift-Left로 인기를 얻었습니다.  Shift-왼쪽은 ATD 관리에서 두 가지 방법으로 구현할 수 있습니다.  복원력을 위한 왼쪽 이동 - 복원력에 영향을 미치는 소스를 식별한 다음 성능에 나타나기 전에 수정합니다.  보안을 위한 Shift-Left — 개발 수명 주기 동안 보안 문제를 감지하고 완화합니다.  테스트를 위한 Shift-Left와 마찬가지로 개발 단계에서 복원력과 보안에 우선적으로 초점을 맞추면 예상치 못한 사고가 발생할 가능성이 줄어듭니다.  아키텍처 관찰 가능성  아키텍처 관찰 가능성을 통해 엔지니어링 팀은 서비스 내의 아키텍처 드리프트를 거시적 수준에서 점진적으로 해결할 수 있습니다. 실제로 Wall Street Journal은 "보이지 않는 1조 5200억 달러의 문제: 투박한 오래된 소프트웨어"   에서 올해 초 기술 부채를 해결하는 데 드는 비용이 1조 5200억 달러에 달한다고 보고했습니다. 기사  성공하려면 엔지니어링 리더십이 다음 조직 목표와 완전히 일치해야 합니다.  탄력성 — 예상치 못한 사고로부터 신속하게 복구합니다.  확장성 — 고객 요구에 맞게 적절하게 확장합니다.  Velocity — 제품 기대치에 맞춰 기능과 개선 사항을 제공합니다.  클라우드 적합성 — 레거시 솔루션을 효율적인 클라우드 기반 서비스 제공으로 전환합니다.  저는 최근 다음 결과물에 초점을 맞춘   의 AI 기반 아키텍처 관찰 플랫폼을 발견했습니다. vFunction  정적 및 동적 분석을 통해 솔루션의 실제 아키텍처를   . 살펴보세요  서비스가 어떻게 발전하는지 실시간 보기를 통해 아키텍처 드리프트를   . 방지합니다  불필요한 종속성을 제거하고 애플리케이션 도메인과 관련 리소스 간의 개선을 통해 애플리케이션의   높입니다. 탄력성을  AI 기반 관측성을 통해 기술 부채를 관리하고   . 해결합니다  또한 vFunction 플랫폼은 모놀리스에서 클라우드 네이티브 솔루션으로 전환하기 위한 마이그레이션 경로를 제공하는 부수적인 이점을 제공합니다. 팀이 플랫폼을 현대화하면 진행 중인 드리프트를 지속적으로 관찰할 수 있습니다. 기업에 이미 마이크로서비스가 있는 경우 vFunction을 사용하여 분산 애플리케이션의 복잡성을 감지하고 탄력성과 확장성에 영향을 미치는 종속성을 해결할 수 있습니다. 두 경우 모두 일단 구현되면 엔지니어링 팀은 한계점에 도달하기 훨씬 전에 ATD를 완화할 수 있습니다. 위 그림에서 엔지니어링 팀은 vFunction 플랫폼 구현과 기본 Shift-Left 접근 방식으로 인해 각 릴리스의 일부로 기술 부채를 완화할 수 있습니다.  결론  독자들은 제가 모든 IT 전문가에게 적용할 수 있다고 생각하는 다음 사명 선언문에 중점을 두었다는 것을 기억하실 것입니다.  “지적 재산의 가치를 확장하는 특징/기능을 제공하는 데 시간을 집중하십시오. 다른 모든 것에 프레임워크, 제품 및 서비스를 활용하세요.” - J. 베스터  vFunction 플랫폼은 엔지니어링 팀이 거시적 수준에서 서비스의 탄력성과 보안에 대해 Shift-Left 접근 방식을 채택할 수 있도록 지원함으로써 저의 사명 선언문을 준수합니다. 이러한 도구가 없으면 팀은 미시적 수준에서 완화하여 조직 관점에서 실제로 중요하지 않은 기술 부채를 해결할 가능성이 높기 때문에 이는 중요한 차이점입니다.  기술 부채 문제를 깨닫게 해준 해당 애플리케이션을 되돌아보면, 도입된 각 기능의 이점보다 해당 솔루션이 어떻게 더 많은 문제를 야기했는지 생각하지 않을 수 없습니다. 확실히 복원력을 위해 Shift-왼쪽을 사용하는 것만으로도 대안을 고려하는 비용이 실현 가능한 지점에서 기본 아키텍처의 문제를 표면화하는 데 도움이 되었을 것입니다.  vFunction 솔루션에 대해 더 자세히 알아보고 싶다면   자세히 읽어보세요. 여기에서  정말 좋은 하루 보내세요!

This story contains new, firsthand information uncovered by the writer.

2022 - HackerNoon Contributor of the Year - Cloud Computing

2022 - HackerNoon Contributor of the Year - Design

2022 - HackerNoon Contributor of the Year - Heroku

2022 - HackerNoon Contributor of the Year - Javascript

2022 - HackerNoon Contributor of the Year - Salesforce

2022 - Hackernoons Tech Storyteller of the Year

I ♥ writing code. Find me on GitLab.

Nominated for 2022 - HackerNoon Contributor of the Year - Javascript

Nominated for 2022 - Hackernoons Tech Storyteller of the Year

Nominated for 2022 - HackerNoon Contributor of the Year - Cloud Computing

Nominated for 2022 - HackerNoon Contributor of the Year - Heroku

Nominated for 2022 - HackerNoon Contributor of the Year - Design

Nominated for 2022 - HackerNoon Contributor of the Year - Salesforce

이 오디오는 이야기의 원래 언어로 제작되었습니다!

너무 오래; 읽다

건축 기술 부채 관리

건축 기술 부채 관리

About Author

코멘트

태그 걸기

이 기사는 다음에서 발표되었습니다.

Related Stories

디지털 유목민 들어보기: 태국의 새로운 DTV 비자에 대해 알아야 할 사항

독특한 생태계를 강화하는 비트코인 UTXO 모델

사용자 중심의 암호화 제품 만들기: 고객 피드백의 중요성

디지털 유목민 들어보기: 태국의 새로운 DTV 비자에 대해 알아야 할 사항

독특한 생태계를 강화하는 비트코인 UTXO 모델

사용자 중심의 암호화 제품 만들기: 고객 피드백의 중요성

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps