여기 댓글도 그렇고 한국에 있는 개발자들이랑 얘기해보면 자기가 경험해보지 못한건 틀린거라는 사상이 깔려있는 것 같아요 아키텍트랑 디벨로퍼를 분담시킬만한 규모의 회사나 프로젝트가 한국에 많이 없다는 걸 간과하는 듯 글로벌 전개하는 공룡기업들 보면 롤이 아주 세분화 되어있답니다 :)
1. 아키텍트를 너무 시스템 전체를 구성할때 위주로 보시는 경향이 있는 것 같습니다. 소프트웨어 자체도 아키텍트가 존재합니다. 주니어개발자 > 시니어개발자 > 아키텍트로 성장하는 것이 올바른 방향이고 이 방향은 프레임워크 소비자 > 프레임워크 설계자 로 바뀌는 과정이기도 합니다. 아키텍트가 없이 개발자들이 자신들에게 주어진 기능적인 요소만 개발한다면 대형프레임워크나 엔진들이 어떻게 나올까요? 2. 소프트웨어 개발 프로젝트에서 개발 경험이 없는데 아키텍트를 잡는건 사상누각이라 생각합니다. 건축가가 실제 건축자체를 하지 않지만 공법이나 소재를 모르고 그림만 그린다고 좋은 건축물이 나올 수 없는 것과 같은 이치라고 봅니다. 고로 엔지니어 출신이나 비개발자 출신이 아키텍트를 하는 프로젝트는 산으로 갈 가능성을 일단 잡고 시작한다고 생각합니다. 개발자 출신임에도 불구하고 내용 년수 찼다고 아키텍트 잡고 구조의 설계가 아니라 꿈속 그림만 그리는 경우가 허다하기 때문에 '오래된 개발자 != 아키텍트' 공식은 성립하기 어렵다고 생각하지만 비개발자가 좋은 아키텍트가 되는 것은 그것보다 더 어려운 문제라고 생각합니다. 하지만 개발자 출신은 좋은 아키텍트가 될 아주 좋은 밑바탕을 갖춘건 두말할 것 없는 사실이라고 생각합니다. 애써서 시간내 좋은 내용 유트로 올려주셔서 감사합니다.
아키텍춰링은 필요하지만 아키텍트라는 전문직은 없습니다. 그냥 그 사람들은 혼돈을 더 만드는 분들일뿐이라고 봐요. 개발에 대한 구체적인 지식 없이 아키텍춰링이 가능하다고 믿는 믿음은 그냥 믿음이란 걸 현장에서 수십년을 경험하고 나서야 이해하게 되죠. 이런 논쟁은 과거 애자일 논쟁에서 이미 끝났다고 봅니다. 과거 개발방법론에서는 전체프로세스를 사전 설계하고 그 설계에 따라 개발이 가능하다고 봤습니다. 마치 건물을 짓기 위해 설계를 먼저하고 그 설계에 따라 건축을 하는 것과 비슷한 개념이라고 생각한겁니다. 또 개발 중에 계속 예상치 못한 것들이 발생하고 계속 수정되고 하는 것들은 설계를 치밀하게 하지 못해서라고 생각을 했고 이런 문제를 해결하기 위해서는 좀더 치밀한 설계를 통해 극복가능하리라고 봤습니다. 수십년 동안 말이죠. 근데 결국 그게 안됀다는 것이 밝혀졌죠. 경험상으로나 논리적으로나 말입니다. 이런 프로그래밍이 건축과 같이 설계과 개발을 분리할 수 있다고 생각은 교수와 학자들의 상상에 의해 제안되고 강압되었습니다. 아무리 새로운 개발방법론이라며 보다 치밀한 설계를 하는 방법론을 들고 나와도 이전보다 더 많은 문서화와 설정만을 요구할뿐 실무에서는 전혀 효용을 발휘하지 못했습니다. 결국 이런 개발방법론에 소수 실무 개발자들이 애자일 선언을 통해 반기를 들었습니다. 설계와 구현이 구분된다는 건 상상일 뿐 실무적이지 않다고 반기들 든거죠. 그리고 수많은 개발자들이 이 애자일 선언에 지지와 동참을 하며 그 이후로 개발방법론은 애자일의 컨셉하에 발전해왔습니다. 애자일이 득세하자 그 수많은 그럴싸하게 주장하던 설계와 구현을 명확히 구별하려던 수많은 개발방법론들은 사라지거나 스리슬쩍 애자일 방법론을 반영하는 지경이 되었습니다. 개발을 구체적으로 관여하거나 이해하지 못하는 아키텍트와 그것을 구현하는 개발자가 구분된다는 생각은 그 구시대의 산물이란 거죠. 전문 아키텍트란 그 설계와 개발을 명확히 구분하려던 과거 설계의 전문가 즉 건축에서 건축가나 설계가와 같은 역할을 하는 사람이 있다는 개념하에 나온 것입니다. 애자일 프로세스에서 밝혀낸(?) 혹은 선언한 몇가지 중요한 개념이 있습니다. 그건 바로 개발은 지속적 통합이란 것이죠. 개발은 설계와 개발의 구분이 명확한 것이 아니라 계속 설계를 해나가고 구현을 해나가면서 계속 설계를 변경해야하는 과정이란 겁니다. 개발 프로세스란 그 설계와 구현을 최대한 가깝게 연결해주는 방향으로 가야지 건축물과 같이 구분짓는 방법으로는 해결이 안되더란 거죠. 왜냐... 프로그래밍에서 설계 변경의 민감성이 건출물과는 완전히 다르더란 거죠. 프로그래밍에서는 최말단 함수 혹은 APi의 인자 하나 바뀌는 것만으로 전체 구조가 들었다 놔야할 수준으로 통채 갈아업어야 하는 민감한 경우가 매우 많더란거죠. 건축에 빛대자면 수십층짜리 건물에서 한층에 문고리가 하나 바뀐것 때문에 전체 건물 설계까 다 변경되어야 하는 상황이 프로그래밍에서는 발생하는 있다는 것이고 따라서 프로그래밍은 건축과 같이 설계와 구현이 명확히 구분되기 힘들다는 것입니다. 거대한 시스템의 구현이 처음 개발하는 시스템이라면... 한발한발 개발해 나감에 따라 아주 사소한 말단의 문제로 수시로 전체 시스템을 갈아업어야 하는 일들이 일어날수 밖에 없습니다. 이를 해결하는 방법? 좋은 아키텍팅으로 해결한다? 그럴수 없다는 거죠. 오히려 설계와 개발을 더욱 밀착시켜 빠르게 대응할수 밖에 없습니다. 따라서 전문 아키텍트보다 개발자가 더 아키텍팅을 잘해나갈겁니다. 만약 처음개발하는 시스템이 아니라면? 그 시스템을 이미 구현해본 개발자가 더 잘 알겠죠. 결국 여기서도 전문 아키텍트보다 직접 구현해본 개발자가 더 효율적일겁니다. 전체적인 시스템의 아키텍춰링은 필요합니다. 하지만 그것은 구체적인 구현의 기반 위에 떠 있는 것이기 때문에 설계와 개발은 아주 가까이 있고 떼내서 전문화하기 힘들다는 거죠. 아키텍팅은 그냥 그 시스템의 개발에 직접 관여하며 처음 설계부터 발끝설계까지 모두 이해할수 있는 고참 개발자들에 의해 되어야 행해질 수 밖에 없습니다. 개발 모르는 그냥 전문 아키텍트가 할 수 있는 건 그냥 이 개발자 저 개발자 의견들어서 조율하는 수준에 불과하고 그 조차도 첨외하고 충돌되는 문제를 만나면 제대로 해결하지 못하는 것이 현실입니다.
오~ 멋진 글입니다. 건축과 비슷하다고 봤던 과거의 사고와 프로세스가 아마도 그때 당시 개발을 할 때 코드 수정이 조금 어렵다고 보고, 또는 치밀한 설계가 정확한 제품을 만든다고 봤던거 같네요. 그리고 지금도 어떤 제품을 만드는데 있어서는 자로 잰듯한 치밀함은 여전히 필요한 영역이 있는거 같구요. 애자일과 가장 맞는 접근은 서비스인거 같아요. MVP모델을 만들고, 오픈하고 지속적으로 발전시키는 모델이요. 좋은 의견 감사하네요!
아~ 우리나라같은 현실에서 평생 개발자... 아직은 좀 꿈같은 얘기인거 같네요. 조금씩 길어지고 있고, 개발자가 개발만 더 할 수 있게 한다고는 하지만, ... 본인 스스로도 한계를 느끼는 경우가 많기때문에 말이죠. 그래도 자기 스스로 계속 개발만할 수 있게 미래를 계속 준비한다면 불가능하진 않을거 같아요. 그런데, 하다보면 본인 스스로가 개발에 흥미가 조금 떨어진다든지 조금 더 넓은 범위로 일하고 싶다던지 하는 경우도 많이 생기는거 같아요. 그래서 지금 시작하신다면 난 평생 개발자로 살꺼야 보다 현재 주어진 일에 최선을 다하면서 본인의 마음을 가끔 확인해보는 것도 좋을거 같아요. 시간이 지나면 생각도 조금 변할 수 있어서요.
잘하는 개발자를 아키텍쳐라고 해야 맞는데 뭔가 다른 신분이 있는 것처럼 말하는 사람들이 많아서 본인이 아키텍쳐라고 하는 사람에 반감이 있습니다. 그냥 잘하는 개발자가 되면 시스템을 만들수 있고, 그러면 아키텍쳐이자 잘하는 개발자가 되는 걸, 한국에서는 코드 안짜고 파워포인트 그림그리면서 아키텍쳐라 착각하는 이들이 많더이다. 다이어그램이던 글이던 파워포인트이던 그게 코드로 구현되는 경우의 수가 너무 다양해서 결국 코드로 말하지 않는 자들은 다 그냥 혀로그래머인 경우가 많더이다.
아키텍트 = CTO 라고 하기엔 CTO가 아닌 아키텍트들이 너무 많구요. ^^ 그리고 CTO가 아키텍트만 알아서는 안될 거 같구요. 전체 회사 관점의 기술 리더로써 비지니스 관점, 비용 관점, 등등으로 경영 관점도 최고 경영자와 대화를 할 수 있어야 할 거 같아요. 그런데 많은 경우 CTO는 아키텍트 역할을 합니다.
아키텍트 역할이 참 중요하네요. 예를 들어 안드로이드 앱을 만들고 구글스토어에 런칭하고자 할때, 앱에 들어가는 핵심 엔진(라이브러리) 따로, 안드로이드 GUI따로 이런식으로 따로 따로 그에 맞는 외부 개발자에 의뢰하고 최종 취합해서 어플을 만드는걸 목표로 햇을때 개발용 언어들(예를 들면 라이브러를 활용하기 기본적인 언어, 최종 취합하여 어플을 만들기 위한 안드로이드 스킬 또는 언어)은 어느정도 수준까지 공부해야 하고 어떻게 준비하는게 좋을가요?
아 화면 개발이나 모듈 개발을 의뢰하시고, 조합해서 만드실 생각이신가봐요. 이게 전체를 한쪽에 의뢰하는 것보다 어려울 수 있는데요. 실제 소스를 보고 머지를 하시는 것이라면 소스 레벨로 프로그램이 가능할 정도 또는 그 이상으로 하셔야 할거 같습니다. 누군가가 만든 것을 이해한다는게 스스로 개발하는 거보다 때로는 어려울 때도 있거든요. ^^;
@@with2511 안녕하세요 제조기술자에서 이직하려고 요새 알아보고있습니다만. 만약 시니어 개발자가 없고 신입이 혼자 일을 습득하며 발전하려면 si회사처럼 프로젝트가 많은 회사를. 가서 내부설계를 자기가 직접만들어가는 것(개척) vs sm회사에서 내부에서 만들어진 프로그램을 열어보며 설계의도나 세부시스템을 파악하고 문제를 수정하는 것 (분석) 둘 중 무엇이 앞으로의 개발자 역할에 더 많은 도움이 될까요?
아~ 궁금했던 내용을 다루게 되어서 더 좋네요~! 개발자, 아키텍트 진로, 진출, 연봉 요거 그냥 넘어가기 어렵네요. 제가 전부도 아니고 정답도 아니지만, 어떻게 살아가는지에 대해서 한번 다뤄보고 싶네요. 간단히 말씀드리면, 개발자들은 개발 전문으로 계속 가다가 국내의 경우는 팀장이나 PM으로 가는 경우도 있구요. 개발만으로 요즘은 좀 더 하는 경우가 많기는 해요. 근데, 본인 스스로가 한계를 느끼는 경우도 많구요. 그리고 아키텍트는 좀 더 넓어지기는 하는거 같아요. 컨설팅이라든가 기업마다 아키의 니즈는 많고, 또 하나의 언어에 국한되지 않으니 가는 곳이 좀더 넓긴해요. 연봉도 아무래도 아키가 좀 더 받기는 하는데요. 개발로 완전히 특화된 사람의 경우는 좀 더 대우가 좋을거 같긴 합니다~
![[마틴 파울러] 소프트웨어 아키텍처의 중요성 (한글 자막)](http://i.ytimg.com/vi/4E1BHTvhB7Y/mqdefault.jpg)
여기 댓글도 그렇고 한국에 있는 개발자들이랑 얘기해보면 자기가 경험해보지 못한건 틀린거라는 사상이 깔려있는 것 같아요
아키텍트랑 디벨로퍼를 분담시킬만한 규모의 회사나 프로젝트가 한국에 많이 없다는 걸 간과하는 듯
글로벌 전개하는 공룡기업들 보면 롤이 아주 세분화 되어있답니다 :)
그렇게 얘기해야 본인이 쉽게 살수있으닠가요ㅎㅎ
1. 아키텍트를 너무 시스템 전체를 구성할때 위주로 보시는 경향이 있는 것 같습니다. 소프트웨어 자체도 아키텍트가 존재합니다.
주니어개발자 > 시니어개발자 > 아키텍트로 성장하는 것이 올바른 방향이고 이 방향은 프레임워크 소비자 > 프레임워크 설계자 로 바뀌는 과정이기도 합니다.
아키텍트가 없이 개발자들이 자신들에게 주어진 기능적인 요소만 개발한다면 대형프레임워크나 엔진들이 어떻게 나올까요?
2. 소프트웨어 개발 프로젝트에서 개발 경험이 없는데 아키텍트를 잡는건 사상누각이라 생각합니다.
건축가가 실제 건축자체를 하지 않지만 공법이나 소재를 모르고 그림만 그린다고 좋은 건축물이 나올 수 없는 것과 같은 이치라고 봅니다. 고로 엔지니어 출신이나 비개발자 출신이 아키텍트를 하는 프로젝트는 산으로 갈 가능성을 일단 잡고 시작한다고 생각합니다. 개발자 출신임에도 불구하고 내용 년수 찼다고 아키텍트 잡고 구조의 설계가 아니라 꿈속 그림만 그리는 경우가 허다하기 때문에 '오래된 개발자 != 아키텍트' 공식은 성립하기 어렵다고 생각하지만 비개발자가 좋은 아키텍트가 되는 것은 그것보다 더 어려운 문제라고 생각합니다.
하지만 개발자 출신은 좋은 아키텍트가 될 아주 좋은 밑바탕을 갖춘건 두말할 것 없는 사실이라고 생각합니다.
애써서 시간내 좋은 내용 유트로 올려주셔서 감사합니다.
내용 하나 하나 모두 공감하고 인정합니다. 제가 그러고 보니 소프트웨어 아키텍트를 빼먹었네요~그러고 보니 솔루션 아키텍트도 있고 하네요~ 좋은 내용으로 보충 설명해주셔서 넘 감사해요!
공감합니다
제 개인적으로 아키텍트 개념이 모호했는데 넓은 의미에서 하는 일과 역할을 잘 알려주셔서 덕분에 확실히 알게되었네요. 감사합니다
도움이 되셨다니 다행입니다.
아키텍춰링은 필요하지만 아키텍트라는 전문직은 없습니다. 그냥 그 사람들은 혼돈을 더 만드는 분들일뿐이라고 봐요.
개발에 대한 구체적인 지식 없이 아키텍춰링이 가능하다고 믿는 믿음은 그냥 믿음이란 걸 현장에서 수십년을 경험하고 나서야 이해하게 되죠.
이런 논쟁은 과거 애자일 논쟁에서 이미 끝났다고 봅니다.
과거 개발방법론에서는 전체프로세스를 사전 설계하고 그 설계에 따라 개발이 가능하다고 봤습니다.
마치 건물을 짓기 위해 설계를 먼저하고 그 설계에 따라 건축을 하는 것과 비슷한 개념이라고 생각한겁니다.
또 개발 중에 계속 예상치 못한 것들이 발생하고 계속 수정되고 하는 것들은 설계를 치밀하게 하지 못해서라고 생각을 했고 이런 문제를 해결하기 위해서는 좀더 치밀한 설계를 통해 극복가능하리라고 봤습니다. 수십년 동안 말이죠.
근데 결국 그게 안됀다는 것이 밝혀졌죠. 경험상으로나 논리적으로나 말입니다.
이런 프로그래밍이 건축과 같이 설계과 개발을 분리할 수 있다고 생각은 교수와 학자들의 상상에 의해 제안되고 강압되었습니다.
아무리 새로운 개발방법론이라며 보다 치밀한 설계를 하는 방법론을 들고 나와도 이전보다 더 많은 문서화와 설정만을 요구할뿐 실무에서는 전혀 효용을 발휘하지 못했습니다.
결국 이런 개발방법론에 소수 실무 개발자들이 애자일 선언을 통해 반기를 들었습니다.
설계와 구현이 구분된다는 건 상상일 뿐 실무적이지 않다고 반기들 든거죠.
그리고 수많은 개발자들이 이 애자일 선언에 지지와 동참을 하며 그 이후로 개발방법론은 애자일의 컨셉하에 발전해왔습니다.
애자일이 득세하자 그 수많은 그럴싸하게 주장하던 설계와 구현을 명확히 구별하려던 수많은 개발방법론들은 사라지거나 스리슬쩍 애자일 방법론을 반영하는 지경이 되었습니다.
개발을 구체적으로 관여하거나 이해하지 못하는 아키텍트와 그것을 구현하는 개발자가 구분된다는 생각은 그 구시대의 산물이란 거죠.
전문 아키텍트란 그 설계와 개발을 명확히 구분하려던 과거 설계의 전문가 즉 건축에서 건축가나 설계가와 같은 역할을 하는 사람이 있다는 개념하에 나온 것입니다.
애자일 프로세스에서 밝혀낸(?) 혹은 선언한 몇가지 중요한 개념이 있습니다.
그건 바로 개발은 지속적 통합이란 것이죠. 개발은 설계와 개발의 구분이 명확한 것이 아니라 계속 설계를 해나가고 구현을 해나가면서 계속 설계를 변경해야하는 과정이란 겁니다.
개발 프로세스란 그 설계와 구현을 최대한 가깝게 연결해주는 방향으로 가야지 건축물과 같이 구분짓는 방법으로는 해결이 안되더란 거죠.
왜냐... 프로그래밍에서 설계 변경의 민감성이 건출물과는 완전히 다르더란 거죠.
프로그래밍에서는 최말단 함수 혹은 APi의 인자 하나 바뀌는 것만으로 전체 구조가 들었다 놔야할 수준으로 통채 갈아업어야 하는 민감한 경우가 매우 많더란거죠.
건축에 빛대자면 수십층짜리 건물에서 한층에 문고리가 하나 바뀐것 때문에 전체 건물 설계까 다 변경되어야 하는 상황이 프로그래밍에서는 발생하는 있다는 것이고 따라서 프로그래밍은 건축과 같이 설계와 구현이 명확히 구분되기 힘들다는 것입니다.
거대한 시스템의 구현이 처음 개발하는 시스템이라면...
한발한발 개발해 나감에 따라 아주 사소한 말단의 문제로 수시로 전체 시스템을 갈아업어야 하는 일들이 일어날수 밖에 없습니다.
이를 해결하는 방법? 좋은 아키텍팅으로 해결한다? 그럴수 없다는 거죠. 오히려 설계와 개발을 더욱 밀착시켜 빠르게 대응할수 밖에 없습니다. 따라서 전문 아키텍트보다 개발자가 더 아키텍팅을 잘해나갈겁니다.
만약 처음개발하는 시스템이 아니라면?
그 시스템을 이미 구현해본 개발자가 더 잘 알겠죠. 결국 여기서도 전문 아키텍트보다 직접 구현해본 개발자가 더 효율적일겁니다.
전체적인 시스템의 아키텍춰링은 필요합니다. 하지만 그것은 구체적인 구현의 기반 위에 떠 있는 것이기 때문에 설계와 개발은 아주 가까이 있고 떼내서 전문화하기 힘들다는 거죠.
아키텍팅은 그냥 그 시스템의 개발에 직접 관여하며 처음 설계부터 발끝설계까지 모두 이해할수 있는 고참 개발자들에 의해 되어야 행해질 수 밖에 없습니다.
개발 모르는 그냥 전문 아키텍트가 할 수 있는 건 그냥 이 개발자 저 개발자 의견들어서 조율하는 수준에 불과하고 그 조차도 첨외하고 충돌되는 문제를 만나면 제대로 해결하지 못하는 것이 현실입니다.
좋은 말씀 입니다만 너무 “소프트웨어”만 놓고 생각하시는거 아닐까요?
오~ 멋진 글입니다. 건축과 비슷하다고 봤던 과거의 사고와 프로세스가 아마도 그때 당시 개발을 할 때 코드 수정이 조금 어렵다고 보고, 또는 치밀한 설계가 정확한 제품을 만든다고 봤던거 같네요. 그리고 지금도 어떤 제품을 만드는데 있어서는 자로 잰듯한 치밀함은 여전히 필요한 영역이 있는거 같구요. 애자일과 가장 맞는 접근은 서비스인거 같아요. MVP모델을 만들고, 오픈하고 지속적으로 발전시키는 모델이요. 좋은 의견 감사하네요!
오..
아키텍트 자체를 부정하기보다는 개발자의 방향성의 한 부분 이라고 보면 될 것 같네요.. 관점(view) 자체가 다르기 때문에 현업 개발자가 담당하기에는 어려워 보입니다.
편협된 사고라는건 본인만 모를테지...ㅋ
좋은설명 감사해요.
소프트웨어 아키텍처, 인프라 아키텍처 관리 하지 않는 환경에 몸 담고 있으면 너무너무 힘듭니다. 그곳은 인간이 곧 Document이기 때문에 갑질도 엄청 심하더라구요😅
항상 이게 궁금했었는데 좋은 영상 감사합니다ㅎㅎ
궁금해 하시던 것을 얘기하게 되어서 좋네요!
또 궁금하신거 있으시면 얘기하시구요~ !
와 궁금햇엇는데.. 속시원… 구독 세번하고갑니다…❤
국내 스타트업은 CTO가 아키텍쳐를 잡아나가는 경우가 많고 실력 있는 분들은 모두 개발자 출신이시더라구요
네, CTO 역할 중 아키텍쳐 잡는 것이 중요한 역할이죠. 개발자 출신인 경우가 많아요. 아무래도 아키텍쳐와 가장 가까운 것은 개발이 아닐까 싶구요.
4년차 개발자로 일했었다가 건강 문제로 지금 쉬고있습니다. 지인의 추천으로 솔루션 아키택트(SA)에 들었을때 관심이 생겨 알아보고 있는중에 정확히 정의된 정보가 없어 헤매고 있었는데 이번 영상으로 제대로 정의가 된 것 같아서 너무 감사합니다!!!
도움이 되셨다니 다행입니다~
건강 회복하시구요! 지나보니 건강이 가장 중요하더라구요.
궁금해하던 부분을 많이 알게 되었습니다~ 개인적으로 드는 생각은 평생 개발자를 할 수 있을지 여부네요... 한 분야만 전문적으로 하려면 연차 쌓이고 정말 넘사벽아니면 힘들것으로 보입니다... 무얼하든 지금 어떤 목적의식을 갖고 지내야겠어요..
아~ 우리나라같은 현실에서 평생 개발자... 아직은 좀 꿈같은 얘기인거 같네요. 조금씩 길어지고 있고, 개발자가 개발만 더 할 수 있게 한다고는 하지만, ... 본인 스스로도 한계를 느끼는 경우가 많기때문에 말이죠. 그래도 자기 스스로 계속 개발만할 수 있게 미래를 계속 준비한다면 불가능하진 않을거 같아요. 그런데, 하다보면 본인 스스로가 개발에 흥미가 조금 떨어진다든지 조금 더 넓은 범위로 일하고 싶다던지 하는 경우도 많이 생기는거 같아요. 그래서 지금 시작하신다면 난 평생 개발자로 살꺼야 보다 현재 주어진 일에 최선을 다하면서 본인의 마음을 가끔 확인해보는 것도 좋을거 같아요. 시간이 지나면 생각도 조금 변할 수 있어서요.
잘하는 개발자를 아키텍쳐라고 해야 맞는데 뭔가 다른 신분이 있는 것처럼 말하는 사람들이 많아서 본인이 아키텍쳐라고 하는 사람에 반감이 있습니다. 그냥 잘하는 개발자가 되면 시스템을 만들수 있고, 그러면 아키텍쳐이자 잘하는 개발자가 되는 걸, 한국에서는 코드 안짜고 파워포인트 그림그리면서 아키텍쳐라 착각하는 이들이 많더이다.
다이어그램이던 글이던 파워포인트이던 그게 코드로 구현되는 경우의 수가 너무 다양해서 결국 코드로 말하지 않는 자들은 다 그냥 혀로그래머인 경우가 많더이다.
너무 유익한 내용이 많아요 감사합니다.
아키텍트가 CTO라고 생각하면 되는건가요??
아키텍트 = CTO 라고 하기엔 CTO가 아닌 아키텍트들이 너무 많구요. ^^ 그리고 CTO가 아키텍트만 알아서는 안될 거 같구요. 전체 회사 관점의 기술 리더로써 비지니스 관점, 비용 관점, 등등으로 경영 관점도 최고 경영자와 대화를 할 수 있어야 할 거 같아요. 그런데 많은 경우 CTO는 아키텍트 역할을 합니다.
이야 자칫하면 실루엣만 그려지고 모호한 개념이 될 수 있는 부분들에 대한 설명이 명확하고 이해하기 쉬워서 처음부터 끝까지 시간 가는 줄 모르고 몰입하면서 봤네요.
도움이 되시고, 즐겁게 보셨다니 좋습니다~ 종종 관련 얘기들을 해봐야겠네요^^
클라우드 분야로 진출하게 된다면 sql 능력은 필수일까요?
클라우드 분야로 진출한다고 해서 sql을 잘알아야 할 거 같진 않구요. 백앤드 개발자가 되려고 한다면 잘 알아야 해요. 클라우드 엔지니어는 sql 모르고도 할 수 있는 일이 많구요.
항상좋은영상감사합니다 :)
그래서 개발자와 아키텍쳐 차이가 뭔지 서두에 명확하게 말해줘야할듯 계속 예시만 줄줄줄
아키텍트 역할이 참 중요하네요.
예를 들어 안드로이드 앱을 만들고 구글스토어에 런칭하고자 할때, 앱에 들어가는 핵심 엔진(라이브러리) 따로, 안드로이드 GUI따로 이런식으로 따로 따로 그에 맞는 외부 개발자에 의뢰하고 최종 취합해서 어플을 만드는걸 목표로 햇을때 개발용 언어들(예를 들면 라이브러를 활용하기 기본적인 언어, 최종 취합하여 어플을 만들기 위한 안드로이드 스킬 또는 언어)은 어느정도 수준까지 공부해야 하고 어떻게 준비하는게 좋을가요?
아 화면 개발이나 모듈 개발을 의뢰하시고, 조합해서 만드실 생각이신가봐요. 이게 전체를 한쪽에 의뢰하는 것보다 어려울 수 있는데요. 실제 소스를 보고 머지를 하시는 것이라면 소스 레벨로 프로그램이 가능할 정도 또는 그 이상으로 하셔야 할거 같습니다. 누군가가 만든 것을 이해한다는게 스스로 개발하는 거보다 때로는 어려울 때도 있거든요. ^^;
@@with2511 네.. 그렇군요.. 흠.. 조합하려면 결국은 소스를 분석하고 수정할 능력까지 갖춰야 되는거겟네요. 그럼 c언어부터 java나 koltin까지 순차적으로 공부를 해나가야 하는거네요... 그럼 아키택트도 실제로는 소스코드를 분석하고 다른 사람이 짠 코드가 잘된건지 평가할려면 소스코드를 분석하는 능력도 갖춰야 된다는 말이겟죠? 답변 감사합니다.
@@with2511 안녕하세요 제조기술자에서 이직하려고 요새 알아보고있습니다만. 만약 시니어 개발자가 없고 신입이 혼자 일을 습득하며 발전하려면
si회사처럼 프로젝트가 많은 회사를. 가서 내부설계를 자기가 직접만들어가는 것(개척) vs sm회사에서 내부에서 만들어진 프로그램을 열어보며 설계의도나 세부시스템을 파악하고 문제를 수정하는 것 (분석) 둘 중 무엇이 앞으로의 개발자 역할에 더 많은 도움이 될까요?
좋아요!
오 제가 요즘 너무나 궁금했던 내용이에요! 감사해요 ㅎㅎ추가로 궁금한점이, 개발자와 아키텍트로 갈때 각각 어떤 방향으로 진로가 형성되는지? 진출분야나 연봉등등이 궁금합니다!
아~ 궁금했던 내용을 다루게 되어서 더 좋네요~! 개발자, 아키텍트 진로, 진출, 연봉 요거 그냥 넘어가기 어렵네요. 제가 전부도 아니고 정답도 아니지만, 어떻게 살아가는지에 대해서 한번 다뤄보고 싶네요. 간단히 말씀드리면, 개발자들은 개발 전문으로 계속 가다가 국내의 경우는 팀장이나 PM으로 가는 경우도 있구요. 개발만으로 요즘은 좀 더 하는 경우가 많기는 해요. 근데, 본인 스스로가 한계를 느끼는 경우도 많구요. 그리고 아키텍트는 좀 더 넓어지기는 하는거 같아요. 컨설팅이라든가 기업마다 아키의 니즈는 많고, 또 하나의 언어에 국한되지 않으니 가는 곳이 좀더 넓긴해요. 연봉도 아무래도 아키가 좀 더 받기는 하는데요. 개발로 완전히 특화된 사람의 경우는 좀 더 대우가 좋을거 같긴 합니다~
개발로 특화된 사람이라면 개발자아닌가요? 마지막 말씀이 잘 이해가 안됩니다 😢
비즈니스모델로 부터 비즈니스 아키텍쳐->애플리케이션/데이터 아키텍쳐->솔루션/인프라 아키텍쳐 설계•표준 제정으로 이어지는 부분을 너무 배제하고 설명하시는게 아닌가 싶네요. 취업준비생 분들이 혼동하지 않을까 싶어서 죄송스럽지만 답글하나 남깁니다 ㅠㅎㅎ
좋은 영상감사합니다
좋은 부연 설명 감사해요~ 조금 세분화 하면 그럴 수 있을거 같네요.
아키텍트를 꿈꾸는 백지의 뇌를 가지고 있는 대학생은 어떤 순서, 단계로 그리고 어떤 부분을 집중적으로 공부를 하면 좋다하는 것이 있을까요??
아 좋은 질문이네요...
아키텍트는 어떻게 어떤 것을 준비할 것인가... 제가 한번 요 주제는 고민해보겠습니다. !
@@with2511 안녕하세요.이 주제로 영상 올라왔나요?
❤
이 양반 설명 잘하네
좋은 내용 설명해주셔셔 감사합니다!