좋은 내용 설명해주셔셔 감사합니다!

항상 이게 궁금했었는데 좋은 영상 감사합니다ㅎㅎ

이야 자칫하면 실루엣만 그려지고 모호한 개념이 될 수 있는 부분들에 대한 설명이 명확하고 이해하기 쉬워서 처음부터 끝까지 시간 가는 줄 모르고 몰입하면서 봤네요.

너무 유익한 내용이 많아요 감사합니다.

와 궁금햇엇는데.. 속시원… 구독 세번하고갑니다…❤

아키텍춰링은 필요하지만 아키텍트라는 전문직은 없습니다. 그냥 그 사람들은 혼돈을 더 만드는 분들일뿐이라고 봐요. 개발에 대한 구체적인 지식 없이 아키텍춰링이 가능하다고 믿는 믿음은 그냥 믿음이란 걸 현장에서 수십년을 경험하고 나서야 이해하게 되죠. 이런 논쟁은 과거 애자일 논쟁에서 이미 끝났다고 봅니다. 과거 개발방법론에서는 전체프로세스를 사전 설계하고 그 설계에 따라 개발이 가능하다고 봤습니다. 마치 건물을 짓기 위해 설계를 먼저하고 그 설계에 따라 건축을 하는 것과 비슷한 개념이라고 생각한겁니다. 또 개발 중에 계속 예상치 못한 것들이 발생하고 계속 수정되고 하는 것들은 설계를 치밀하게 하지 못해서라고 생각을 했고 이런 문제를 해결하기 위해서는 좀더 치밀한 설계를 통해 극복가능하리라고 봤습니다. 수십년 동안 말이죠. 근데 결국 그게 안됀다는 것이 밝혀졌죠. 경험상으로나 논리적으로나 말입니다. 이런 프로그래밍이 건축과 같이 설계과 개발을 분리할 수 있다고 생각은 교수와 학자들의 상상에 의해 제안되고 강압되었습니다. 아무리 새로운 개발방법론이라며 보다 치밀한 설계를 하는 방법론을 들고 나와도 이전보다 더 많은 문서화와 설정만을 요구할뿐 실무에서는 전혀 효용을 발휘하지 못했습니다. 결국 이런 개발방법론에 소수 실무 개발자들이 애자일 선언을 통해 반기를 들었습니다. 설계와 구현이 구분된다는 건 상상일 뿐 실무적이지 않다고 반기들 든거죠. 그리고 수많은 개발자들이 이 애자일 선언에 지지와 동참을 하며 그 이후로 개발방법론은 애자일의 컨셉하에 발전해왔습니다. 애자일이 득세하자 그 수많은 그럴싸하게 주장하던 설계와 구현을 명확히 구별하려던 수많은 개발방법론들은 사라지거나 스리슬쩍 애자일 방법론을 반영하는 지경이 되었습니다. 개발을 구체적으로 관여하거나 이해하지 못하는 아키텍트와 그것을 구현하는 개발자가 구분된다는 생각은 그 구시대의 산물이란 거죠. 전문 아키텍트란 그 설계와 개발을 명확히 구분하려던 과거 설계의 전문가 즉 건축에서 건축가나 설계가와 같은 역할을 하는 사람이 있다는 개념하에 나온 것입니다. 애자일 프로세스에서 밝혀낸(?) 혹은 선언한 몇가지 중요한 개념이 있습니다. 그건 바로 개발은 지속적 통합이란 것이죠. 개발은 설계와 개발의 구분이 명확한 것이 아니라 계속 설계를 해나가고 구현을 해나가면서 계속 설계를 변경해야하는 과정이란 겁니다. 개발 프로세스란 그 설계와 구현을 최대한 가깝게 연결해주는 방향으로 가야지 건축물과 같이 구분짓는 방법으로는 해결이 안되더란 거죠. 왜냐... 프로그래밍에서 설계 변경의 민감성이 건출물과는 완전히 다르더란 거죠. 프로그래밍에서는 최말단 함수 혹은 APi의 인자 하나 바뀌는 것만으로 전체 구조가 들었다 놔야할 수준으로 통채 갈아업어야 하는 민감한 경우가 매우 많더란거죠. 건축에 빛대자면 수십층짜리 건물에서 한층에 문고리가 하나 바뀐것 때문에 전체 건물 설계까 다 변경되어야 하는 상황이 프로그래밍에서는 발생하는 있다는 것이고 따라서 프로그래밍은 건축과 같이 설계와 구현이 명확히 구분되기 힘들다는 것입니다. 거대한 시스템의 구현이 처음 개발하는 시스템이라면... 한발한발 개발해 나감에 따라 아주 사소한 말단의 문제로 수시로 전체 시스템을 갈아업어야 하는 일들이 일어날수 밖에 없습니다. 이를 해결하는 방법? 좋은 아키텍팅으로 해결한다? 그럴수 없다는 거죠. 오히려 설계와 개발을 더욱 밀착시켜 빠르게 대응할수 밖에 없습니다. 따라서 전문 아키텍트보다 개발자가 더 아키텍팅을 잘해나갈겁니다. 만약 처음개발하는 시스템이 아니라면? 그 시스템을 이미 구현해본 개발자가 더 잘 알겠죠. 결국 여기서도 전문 아키텍트보다 직접 구현해본 개발자가 더 효율적일겁니다. 전체적인 시스템의 아키텍춰링은 필요합니다. 하지만 그것은 구체적인 구현의 기반 위에 떠 있는 것이기 때문에 설계와 개발은 아주 가까이 있고 떼내서 전문화하기 힘들다는 거죠. 아키텍팅은 그냥 그 시스템의 개발에 직접 관여하며 처음 설계부터 발끝설계까지 모두 이해할수 있는 고참 개발자들에 의해 되어야 행해질 수 밖에 없습니다. 개발 모르는 그냥 전문 아키텍트가 할 수 있는 건 그냥 이 개발자 저 개발자 의견들어서 조율하는 수준에 불과하고 그 조차도 첨외하고 충돌되는 문제를 만나면 제대로 해결하지 못하는 것이 현실입니다.

제 개인적으로 아키텍트 개념이 모호했는데 넓은 의미에서 하는 일과 역할을 잘 알려주셔서 덕분에 확실히 알게되었네요. 감사합니다

항상좋은영상감사합니다 :)

좋아요!

1. 아키텍트를 너무 시스템 전체를 구성할때 위주로 보시는 경향이 있는 것 같습니다. 소프트웨어 자체도 아키텍트가 존재합니다. 주니어개발자 > 시니어개발자 > 아키텍트로 성장하는 것이 올바른 방향이고 이 방향은 프레임워크 소비자 > 프레임워크 설계자 로 바뀌는 과정이기도 합니다. 아키텍트가 없이 개발자들이 자신들에게 주어진 기능적인 요소만 개발한다면 대형프레임워크나 엔진들이 어떻게 나올까요? 2. 소프트웨어 개발 프로젝트에서 개발 경험이 없는데 아키텍트를 잡는건 사상누각이라 생각합니다. 건축가가 실제 건축자체를 하지 않지만 공법이나 소재를 모르고 그림만 그린다고 좋은 건축물이 나올 수 없는 것과 같은 이치라고 봅니다. 고로 엔지니어 출신이나 비개발자 출신이 아키텍트를 하는 프로젝트는 산으로 갈 가능성을 일단 잡고 시작한다고 생각합니다. 개발자 출신임에도 불구하고 내용 년수 찼다고 아키텍트 잡고 구조의 설계가 아니라 꿈속 그림만 그리는 경우가 허다하기 때문에 '오래된 개발자 != 아키텍트' 공식은 성립하기 어렵다고 생각하지만 비개발자가 좋은 아키텍트가 되는 것은 그것보다 더 어려운 문제라고 생각합니다. 하지만 개발자 출신은 좋은 아키텍트가 될 아주 좋은 밑바탕을 갖춘건 두말할 것 없는 사실이라고 생각합니다. 애써서 시간내 좋은 내용 유트로 올려주셔서 감사합니다.

궁금해하던 부분을 많이 알게 되었습니다~ 개인적으로 드는 생각은 평생 개발자를 할 수 있을지 여부네요... 한 분야만 전문적으로 하려면 연차 쌓이고 정말 넘사벽아니면 힘들것으로 보입니다... 무얼하든 지금 어떤 목적의식을 갖고 지내야겠어요..

4년차 개발자로 일했었다가 건강 문제로 지금 쉬고있습니다. 지인의 추천으로 솔루션 아키택트(SA)에 들었을때 관심이 생겨 알아보고 있는중에 정확히 정의된 정보가 없어 헤매고 있었는데 이번 영상으로 제대로 정의가 된 것 같아서 너무 감사합니다!!!

잘하는 개발자를 아키텍쳐라고 해야 맞는데 뭔가 다른 신분이 있는 것처럼 말하는 사람들이 많아서 본인이 아키텍쳐라고 하는 사람에 반감이 있습니다. 그냥 잘하는 개발자가 되면 시스템을 만들수 있고, 그러면 아키텍쳐이자 잘하는 개발자가 되는 걸, 한국에서는 코드 안짜고 파워포인트 그림그리면서 아키텍쳐라 착각하는 이들이 많더이다. 다이어그램이던 글이던 파워포인트이던 그게 코드로 구현되는 경우의 수가 너무 다양해서 결국 코드로 말하지 않는 자들은 다 그냥 혀로그래머인 경우가 많더이다.

오 제가 요즘 너무나 궁금했던 내용이에요! 감사해요 ㅎㅎ추가로 궁금한점이, 개발자와 아키텍트로 갈때 각각 어떤 방향으로 진로가 형성되는지? 진출분야나 연봉등등이 궁금합니다!

여기 댓글도 그렇고 한국에 있는 개발자들이랑 얘기해보면 자기가 경험해보지 못한건 틀린거라는 사상이 깔려있는 것 같아요 아키텍트랑 디벨로퍼를 분담시킬만한 규모의 회사나 프로젝트가 한국에 많이 없다는 걸 간과하는 듯 글로벌 전개하는 공룡기업들 보면 롤이 아주 세분화 되어있답니다 :)

국내 스타트업은 CTO가 아키텍쳐를 잡아나가는 경우가 많고 실력 있는 분들은 모두 개발자 출신이시더라구요

클라우드 분야로 진출하게 된다면 sql 능력은 필수일까요?

그래서 개발자와 아키텍쳐 차이가 뭔지 서두에 명확하게 말해줘야할듯 계속 예시만 줄줄줄

아키텍트 역할이 참 중요하네요. 예를 들어 안드로이드 앱을 만들고 구글스토어에 런칭하고자 할때, 앱에 들어가는 핵심 엔진(라이브러리) 따로, 안드로이드 GUI따로 이런식으로 따로 따로 그에 맞는 외부 개발자에 의뢰하고 최종 취합해서 어플을 만드는걸 목표로 햇을때 개발용 언어들(예를 들면 라이브러를 활용하기 기본적인 언어, 최종 취합하여 어플을 만들기 위한 안드로이드 스킬 또는 언어)은 어느정도 수준까지 공부해야 하고 어떻게 준비하는게 좋을가요?

비즈니스모델로 부터 비즈니스 아키텍쳐->애플리케이션/데이터 아키텍쳐->솔루션/인프라 아키텍쳐 설계•표준 제정으로 이어지는 부분을 너무 배제하고 설명하시는게 아닌가 싶네요. 취업준비생 분들이 혼동하지 않을까 싶어서 죄송스럽지만 답글하나 남깁니다 ㅠㅎㅎ 좋은 영상감사합니다

아키텍트를 꿈꾸는 백지의 뇌를 가지고 있는 대학생은 어떤 순서, 단계로 그리고 어떤 부분을 집중적으로 공부를 하면 좋다하는 것이 있을까요??

아키텍트가 CTO라고 생각하면 되는건가요??

❤

이 양반 설명 잘하네