Video: [강의소개] AI 시대, 개발자여 아키텍트로 오라 | 개발자에서 아키텍트로
Channel: 코딩하는기술사
Duration: 13m 53s
Source: subtitle (auto, ko)
Transcript:
안녕하세요. 코딩하는 기우사입니다. 자, 오늘은 제가이 새롭게 준비한 소프트웨어 아키텍처 정규 강의 AI 시대 개발자여 아키텍터로 오라를 보게 드리려고 합니다. 자, 어떤 생각으로이 강의를 만들었고 또 무엇을 배우게 되는지 말씀을 드리겠습니다. 여러분, 바으로 AI가 코드를 짜는 시대가 왔죠. 자,이 AI로 어플리케이션을 만드는 일은 점점 쉬워지고 있습니다. 그런데 AI가 만들어 준 소프트웨어가 동작한다고 해서 곧 바로 실제를 운영할 수 있는 걸까요? 자, 여기 모델 하우스와 실제 건물이 있습니다.이 모델 하우스는 겉으로 볼 때는 마치이 완성된 집처럼 글을 싸게 보입니다. 자, 그런데이 실제 사람이이 집에 살려면 후도, 전기, 단열, 소방 이런 설비는 물론이고이 건물의 하중과 안전까지 고려가 돼야 됩니다. 자, 우리이 소프트웨어도 마찬가지입니다. 코드가 단순히 작동을 한다는 것과 실제 그것을 서비스로서 운영할 수 있다는 것. 더 나가서 그 서비스에 책임을 질 수 있다는 것은 아주 다른 문제입니다. 실제로 올해 초에이 코드를 직접 작성하지 않았다고 밝힌 한 AI 기반 서비스에서 약 150만 개의 인증 토근이 웹로 노출된 보안 사고가 있었죠.
자, 물론이 문제가 AI로 개발했다는 그 자체가 아닙니다. 중요한 것은 누가 소프트의 품지 기준을 정하고 그 기준을 제대로 충족하는지 검증을 했느냐 하는 것이 중요한 것입니다. 자, 그렇다면 이런 설계와 품질의 기준은 어떻게 배울 수 있을까요? 자, 저는이 소프트웨어 개발 현장에서 소위 아키텍처라는 거 그리고이 아키텍트라는 직무 이것에 대한 오해가 있다고 생각합니다. 자, 첫 번째는 과도한 신격과 신화입니다. 마치이 아키텍트는 범접할 수 없는 대단한 전문가로 생각을 하는 거죠. 또 한편으로는 지나치게 단순화 시키기도 합니다. 시리어 개발자면 올해 개발을 한 사람이면 누구나 아키텍트라고 생각을 한다는 거죠. 그리고 개념이 혼란스럽습니다. 실제이 개발 현장에서는이 아키텍처라는게 제대로 정의되지 않은데 각자 다른 말을 하고 있습니다. 자, 그래서이 아키텍처를 공부를 하고 싶어도 어디서부터 무엇을 배워야 하는지 막막한 경우가 많죠. 자, 사실이 소프트웨어 아키텍처는 오랫동안 연구되고 정리된 세계적인 이론과 기준들이 있습니다.
자, 다만 이러한 지식을 실제 개발 현장과 연결해서 배울 기회가 부족했던 것이죠. 자, 저는 이렇게 생각합니다. 아키텍트는 누구나 될 수 있지만 아무나 할 수는 없다. 다소이 진부한 표현이지만 단순이 개발을 오래 했다고 해서 저절로 갖추지는 영향이 아니기 때문입니다. 기술적인 실력도 필요하고 다양한 조건을 고려해서 판단하는 능력도 필요합니다. 그리고이 자신의 설계를 다른 사람에게 설명을 하고 설득하는 소통 능력도 필요합니다. 자, 하지만 여기서 제가 강조하고 싶은 것은 아키텍트라는 공식적인 직함이 아닙니다. 아키텍트처럼 생각을 하고 판단할 수 있는 능력을 갖추는 것이 중요하다는 것입니다. 자, 그렇다면 아키텍트처럼 생각한다는 것은 구체적으로 어떤 것일까요? 자, 먼저 우리가 해결하려고 하는 문제와 요구 사항을 이해를 해야 됩니다. 그리고이 성능이나 가용성 보안과 같은이 핵심 품질과 그리고 일정 비용 같은 제약 사항을 식별을 해야 됩니다. 그다음에 가능한 아키텍처 구조와 설계 전략 대안들을 탐색을 합니다.
각 대안이 어떤 장점과 단점을 가지는지 그리고 무엇을 얻고 무엇을 포기해야 하는지이 트레이드 오프를 비교하고 결정을 해야 하는 것이죠. 그리고 그 결정의 이유를 기록을 하고 실제로 의도한 대로 결과가 나오는지 검정을 합니다. 자, 물론 이런 과정이 한 번에 끝나는 것은 아닙니다. 필요에 따라서는 다시 앞단계로 되돌아가고 판단을 수정하는 과정을 반복합니다.이 과정 전반에서 우리 아키텍트는 문제를 정의하고 기술과 환경을 결정 및 제약을 하고 맥락과 트레이드오프를 판단하고 결과를 검증하는 일을 합니다. 자, 그런데 AI 역시 설계 대안을 제시해 줄 수 있고 트레이드오프 분석하는데 도움을 줄 수 있습니다. 하지만 프로젝트의 목표와 제약을 고려해서 최종적으로 선택을 하고 결과에 책임지는 것은 여전히 사람의 몫시입니다. 자, 그래서 AI가 만들어 주는 코드의 값은 싸지고 사람의 판단은 비싸질 겁니다.이 판단을 제대로 하기 위해서 더 이상 개발이 아니라 기텍처 접근과 사고 체계가 필요한 것입니다. 자, 한 가지 아주 간단한 예를 들어 보겠습니다.
자, 쇼핑몰을 개발을 하는데 이런 요구 사항이 있다고 해보죠. 사용자는 상품을 검색할 수 있다. 자,이 기능을 구현하려면 어떤 아키텍처가 적합할 거예요? 자, 여기 보시면 모리스, 모듈러, 모리스, 그리고 마이크로소비스 같은 대표적인 아키텍트 스타일이 있죠. 자, 필요에 따라서는 이벤트 기반 연계를 조합할 수도 있겠죠. 자, 그런데이 기능 요구 사항만으로 여기 있는 어떤 구조가 적합한지 결정할 수 있나요? 이것만으으로론 결정하기가 어렵겠죠. 자, 그런데 여기에 두 가지 조건이 추가됩니다. 동시자 1만 명일 때 검색 요청에 95%를 2초 이해 응답을 해야 되고 자, 또 하나는 검색 기능의 장애가 주문 서비스에는 영향을 주지 않아야 된다. 자, 이것은 각각 성능과 신뢰성에 관한 품질 요구 사항이죠. 특히이 두 번째는 자기의 격리를 통해서 가용성을 확보하고자 하는 품질 요구 사항이죠. 자, 이제 어떤가요? 앞서 봤던 그 기능은 그대로인데게 대안을 검토할 때 고려해야 될 것이 달라졌습니다. 자, 모놀리스이라면 캐시나 수평 확장 그리고 리소스 경리로 요구 사항을 충족할 수 있을까요?
모듈용 모너리스에서는 모듈 간 경계를 통해서 어느 수준까지 장애를 격리할 수 있을까요? 마이크로소비스라면 독립적으로 확장할 수 있는 장점이지만 그만큼 분산 운영의 복잡성이 추가되죠. 이벤트 기반을 조합을 한다면 어떤 작업을 비동기로 처리해야 장애 전파를 줄일 수 있을지도 생각을 해야 됩니다. 자, 이처럼 아키텍처 스타일, 아키텍처 구조마다 검토를 해야 할 질문과 트레이드오프가 달라집니다. 품질 요구 사항은 어떤 구조가 정답인지 알려 주는 것이 아니라 끌계 대안을 평가할 기준을 제공하는 것입니다. 자, 그래서 아키텍트는 요구상 문서를 받았을 때 이런 질문을 자신한테 던질 수 있어야 합니다.이 이 요구 사항 중에서 아키텍처에 중대한 영향을 미치는 것은 무엇인가? 성능 목표나 가용성 목표가 중요할 수도 있고 보완 레벨이나 향후 확장 계획이 중요할 수도 있겠죠. 또는 데이터 보존이나 감사 규제와 같은 제약 사항도 아키텍처 결정에 영향을 미칩니다. 결국이 중요한 기능 요구 사항뿐만 아니라 품질 요구 사항과 제약 사항을 함께 고려를 해야 되는 거죠.
자, 이것이 제가 이번 강의에서 강조하는 품지 중심의 설계 사고입니다. 자, 그런데 이런 사고 방식은 AI에게 일을 시킬 때도 마찬가지입니다. 자,이 왼쪽으로 보시면 AI에게 단순히 검색 기능을 만들어 줘라고 요청을 하고 있죠. 물론이 AI가 동작하는 코드를 바로 만들어 줄 수는 있습니다. 자, 그렇지만 그렇게 만들어진 결과가 우리 프로젝트의 요구 사항에 적합한지는 어떻게 판단을 할까요? 여기 오른쪽을 보시죠. 상품 검색 기능을 설계해 달라고 하면서이 필요한 성능과이 장애 격리 조건을 함께 제시하고 있습니다. 그리고이 설계에 대한 두 가지를 비교를 하고 각각의 트레이드오프를 분석한 뒤에이 결정의 이유를 ADR로 기록을 하도록 요청을 합니다. 자, 이렇게 하면 적어도 AI가 제한한 설계를 평가할 근거가 생기겠죠. 자, 이때 활용할 수 있는 것이 아키텍처 드라이버, 품질 모델, 품질 시나리오, 아키텍처 결정 기록 같은 개념과 방법들입니다. 자, 결국 AI에게 일을 잘 시킬 때도 그리고 AI가 내놓은 결과물을 평가할 때도 아키텍처에 대한 이해가 필요한 것이죠.
자, 그렇다면 이런 설계의 원칙과 판단 기준은 어떻게 배울 수 있을까요? 자, 이번 강의는 아키텍처를 단순히 저의 경험이나 감존해서 설명하지는 않습니다. 자,이 왼쪽으로 보시면 ISAQB의이 소프트웨어 아키텍처의 교육 체계 그리고 한기 멜론 대학교의 소프트웨어 공학 연구소의 연구와 평가 방법 그리고 ISO 국제 표준을 창보를 하고 그리고 마크 리처즈와 닐포드 같은 소프트웨어 아키텍처 전문가들의 저술도 함께 살펴봤습니다. 자,이 강의에서 중점을 둔 것은 특정 기술이나 도구의 사용법보다는이 기술이 바뀌어도 오랫동안 활용할 수 있는 설계의 원칙과 판단 기준입니다. 자, 여기에 어, 오른쪽으로 보시면 저의 현장 경험을 더했습니다. 자, 오랜 기간 대형 게임사에서 기술 리더로 그리고 대기업 SI에서 어플리케이션 아키텍트로 그리고 스타트업에서 CTO로 업무를 하면서 어, 다양한 프로젝트를 경험했습니다. 그리고이 기술사 그리고 정보 시스템 수석 감리원 ISMS 심사원 그리고 소프트웨어 보완 약점 진단원 데이터 품질 진단원 PNP 자 이런 라이선스를 바탕으로 다른 사람이 만든 시스템을 제3자 관점에서 검정을 하고 평가하는 업무를 수행하면서 어 시스템을 바라보는 시야를 넓혀 왔습니다.
자 이렇게 공신력 있는 국제적인 지식 체계와 20년 넘은 저의이 경험을 바탕으로이 강의를 만들었습니다. 자, 이러한 내용을 세계적으로 학습을 할 수 있도록 전체 과정을 여덟 개의 섹션 총 59편의 강의로 구성을 했습니다. 자, 크게네 가지로 나눌 수 있습니다. 첫 번째는 아키텍처를 이해하는 단계입니다. 아키텍처의 기본 개념과 품질 요구 사항을 학습을 하고이 요구 사항에 명시되지 않은 품질은 어떻게 찾아낼 수 있는지 살펴봅니다. 자, 그리고 두 번째는 설계 원칙과 해법을 배우는 단계입니다. 자, 아키텍처 드라이브와 아키텍처 전술, 모듈성, 컴포넌트 경계, 인터페이스 설계, 그리고 주요 아키텍처 스타일과 패턴을 다룹니다. 세 번째는 설계하고 검증하는 단계입니다. 자, 포프로스 원뷰 ADR과 같은이 시각화와 문서와 방법, 그리고 아탐과 아키텍처 리뷰 등의 평가 방법을 배우고 다양한 설계 사례를 통해서 판단하는 과정을 살펴봅니다. 마지막으로네 번째는 운영과 성장의 단계입니다. 구글 SR와 모니터링 무중단 배포처럼 운영을 고려한 설계를 알아보고요.
그리고이 설계 결정을 개발자와 경영진 현업 담장자들에게 어떻게이 설명을 하고 설득할 것인지 그리고 아키텍트로 어떻게 성장할 것인지도 함께 이야기를 합니다. 제가 이번 강의를 만들면서 가장 중요하게 생각한 것이 있습니다.이 이 아키텍처 스타일이나 패턴을 많이 아는 것보다 어떤 문제에서 왜 그 구조가 필요한지를 판단하는 능력을 기르는 것입니다. 자, 그래서이 품질 요구 사항과 품질 시나리오에서 출발을 해서이 아키텍처 드라이브하고 전술 그리고 모듈성과 컴퍼넌트의 경계, 인터페이스 설계, 스타일과 패턴, 문서화와 평가, 운영 설계까지 연결해서 이해할 수 있도록 구성을 했습니다. 물론 반드시이 순서대로 공부하실 필요는 없습니다. 처음부터 차근차근 공부를 하셔도 좋고 자신의 경험과 관심에 따라서 필요한 주제부터 골라서 보셔도 아무 상관이 없습니다. 자, 그렇다면이 강의를 통해서 무엇을 얻을 수 있을까요? 자, 첫 번째는 문제를 구조적으로 바라보는 관점입니다.이 비즈니스 요구와 품질 요구 사항 속에서 중요한이 설계 문제를 찾아내는 안목을 배웁니다.
두 번째는 설계 대안을 비교하는 판단 기준입니다. 아키텍처 스타일과 패턴의 장점뿐만 아니라 제약 사항과 트레이드오프를 함께 고려를 하는 것이죠. 두 번째는 설계를 설명하고 검증하는 방법입니다. C와 ADR를 통해서 설계와 그 결정의 이유를 공유를 하고 아과 아키텍처 리뷰를 통해서 아키텍처를 평가하는 방법을 배웁니다. 자,네 번째는 운영까지 고려하는 설계 관점입니다. 신뢰성 목표와 모니터링 배포 방식처럼 실제 서비스를 운영할 때 중요한 요소들도 설계 단계부터 함께 고려하는 방법을 살펴봅니다. 자, 물론이 아키텍트의 영량이이 강의 하나로 완성되는 것은 아니겠죠. 실제 경험과 지속적인 학습이 필요합니다. 자,이 강의는 그 출발점에서 필요한 사고 방식과 판단 기준을 회계적으로 익히는 과정입니다. 자, 이번 강의는 이런 분들께 추천합니다. 먼저이 소프트웨 아키텍처를 제대로 체계적으로 공부하고 싶은 개발자입니다. 그리고 아키텍트나 테크 리더로 성장하는 것을 목표로 하는 분들도 좋습니다. 그리고 AI에게 제대로 된 설계 목표와 검증 기준을 가지고 일을 AI한테 시키고 싶은 개발자.
자, 그리고 이미 오랫동안 현장에서 일을 해왔지만이 자신의 경험을 체계적인 이론과 원칙으로 정리하고 싶은 시니어 개발자 분들에게도 추천합니다. 자, 다만이 강의는 특정 프레임워크의 코딩 실습이나 AI 도구 사용법을 다루는 과정은 아닙니다. 아키텍트의 원칙과 설계 사고 방식 그리고 판단 기준을 배우는 과정입니다. 자, 마지막으로 한 가지 말씀을 드리고 싶습니다. 제가이 개발자들에게 아키텍트가 되라고 말씀을 드리는 것은 반드시 아키텍트라는 공식 직함을 가지라는 이야기가 아닙니다. 개발자라면 누구나 시스템 전체를 바라보고 설계의 근거를 설명하고 자신의 기술적 판단에 책임을 질 수 있어야 한다는 이야기입니다. 자, 아키텍처를 막연하게 아는 개발자에서 진짜 아키텍처럼 판단하는 개발자로 성장하시기 바랍니다. 자, AI 시대 개발자여 아키텍트로 오라. 전체 커리큘럼을 한번 확인을 해 보시고 관심 있으시면 함께 성장하시죠.
![[강의소개] AI 시대, 개발자여 아키텍트로 오라 | 개발자에서 아키텍트로 대표 이미지](/api/thumb?u=https%3A%2F%2Fi.ytimg.com%2Fvi_webp%2FZ2x7WFEjlHY%2Fmaxresdefault.webp&w=640&s=CsxiLx655EMNUBEHQau7suN2)