Video: 개발자여 아키텍트로 오라 | 너드콘 발표 영상
Channel: 코딩하는기술사
Duration: 21m 38s
Source: subtitle (auto, ko)
Transcript:
안녕하세요. 고등하는 기우사입니다. 어 제가이 토요일 날 너드콘에서 어 세션 단 하나를 맡아서 발표를 하고 왔습니다. 자이 너더콘은 넥스트 디벨로퍼라고 하고요. 8월 22일 날 진행을 했습니다. 이렇게 예 훌륭한이 발표자분들이 세션을 하나씩 맡아서 발표를 해 주셨고요. 어, 제가 한 발표를 현장에 참석하지 못하신 제 채널에이 구독자분들을 위해서 따로 영상으로 한번 만들어 봤습니다. 자, 이번 너콘의이 주제가 AI 시대의 개발자 성장과 커리어를 말하다. 자, 이게 주제라서 저는 AI가 코드를 자는 시대 아키텍터가 더 중요한 이유에 대해서 저의 생각을 말씀을 드리고 왔습니다. 자, 저는이 실무 개발 현장에서 약 25년간 직접이 소프트웨어를 개발하고 운영을 해 왔습니다. 어, 또 그리고 또 한편으로는 다른 사람이 만든이 시스템을 어, 일정한 기준을 가지고 심사하고 검정하는 일에도 관심을 가지고 어, 공부를 하고 활동을 하고 있습니다. 어 그래서 오늘이 주제는 저이 두 가지 경험과 관점을 바탕으로 해서 AI 시대의 우리 개발자들이 어떤 관점과 어 방장성을 가지고 성장하면 좋을지에 대해서 저의 개인적인 의견을 드리는 강의입니다.

자, 먼저 질문을 좀 드려 보겠습니다.이 바이브 코딩에만 의존해서 어, 어플리케이션을 만들어 보신 분. 자, 다음으로 어, 그 어플리케이션을 다른 사람이 쓸 수 있게 매포까지 해 보신 분. 자, 마지막으로 어 개인 정보 즉 해운 가입을 받고 또 결제도 받고 즉 돈을 그 어플리케이션으로 돈도 벌고 그리고 어 장애까지 책임지면서 운영을 하고 계신 분. 요즘이 바이브 코딩으로 어 비발자도 어플리케이션을 만들어서 뭐 돈 볼 수 있다. 이런 마케팅이 많은데요. 어 그게 실제로 쉬운 일은 아니죠. 자, 그러나 지금은 어 AI 코딩 시대입니다. 자, 여기 로봇이 삽질을 하고 있습니다. 우리 보통 개발자들이 과거에이 코딩으로 고생하는 것을 삽질한다고 표현을 많이 했죠. 자, 이렇게이 AI가 지금은 코딩을 너무 잘해 주죠. 뭐 사실이 코딩뿐만 아니죠. 뭐 테스트, 문서, 뭐 리팩토링, 또 개발 분야뿐만 아니라 뭐 영상, 이미지, 번역, 뭐 글 쓰기, 주제 찾기 이런 것들도 모두 AI가 엄청난 생산 능력과 생산성을 보여주죠.

자, 이렇게 우리 코딩 분야에도이 AI가 굉장히 빠른 그리고 퀄리티 높은 코드를 만들어 주는데요. 자, 여기 보시면 이때 우리 인간도 삽질를 해야 될까요? 코딩을 해야 될까요? 어, 저는 기본적으로 AI가 더 잘하는 일은 AI에게 맡기면 된다라고 생각합니다. 자, 그러나 어, 삽지를 해 주는데 어디에 무엇을 얼마나 깊게 삽질를 할지는 누가 결정을 해야 될까요? 자, 여기 조건문이 있습니다. if프 AI 코딩 결과가 서비스 가능한가? 자, 이게 참일까요? 거짓일까요? 자, 여러분들이 모델 하우스 한번쯤가 보셨죠?이 이 모델 하우스를가 보면 어 정말 깔끔하고 진짜이 사람이 살 수 있는 집 같이 보이죠. 그러나 실제 우리 사람이 사는 집은 많이 다르죠. 뭐 수도, 전기, 단열, 소방, 하중 이런 눈에 보이지 않는 요소들이 다 중족이 돼야 되고 또 이런 것들이 오랜 기간 안전하게 유지가 되어야 하죠. 자, 우리 바이브 코딩으로 만든이 소프트웨어도 기본적으로 깔끔하게 보이고 그리고 작동도 잘하죠. 자, 그런데이 작동한다는 것이 곧 서비스 할 수 있다는 것일까요?

전혀 다른 문제죠. 서비스 할 수 있다는 것은 기능만 적당히 동작한다고 해서 되는 것이 아니라 보완, 성능, 확장성, 유지보수성, 뭐 장애 대응 각종 운영 요소들이 다 준비가 돼야 되는 거죠. 어, 그리고 또 한편으로는 서비스 할 수 있다는 것과 책임질 수 있다는 것은 또 다른 차원의 문제일 수 있습니다. 어, 내가 만든 서비스가 개인 정보를 받고 뭔가 크리티클한 업무를 수행한다고 했을 때 거기에서 어떤 문제가 생겼을 때는 누가 책임을 질까요? 내 서비스를 개발해 준 개발자가 책임을 질까요? 아니면 AI가 책임을 지까요? 자, 대표적인 사례 하나를 가져와 봤습니다. 자,이 몰트북이라고 해서 올해 1월에이 런칭된 AI들의 소셜 플랫폼이죠. 여기 창업자이 매출릭이 이렇게 얘기했습니다. 나는 코드를 한 줄도 쓰지 않았다. 기술 아키텍처의 비전만 제시했고 AI가 그것을 현실로 만들어 줬다고 했습니다. 어, 한마디로 바이브 코딩에 의존해서 만든 소프트웨어라는 거죠. 자, 그런데 오픈한지 며칠 만에 보안 사고가 터졌습니다.

자, 여기 보시는 바와 같이이 프라이빗한 중요한 정보들이 많이 노출이 되었는데요. 어, 월인은 단순했습니다.이 슈퍼베이스라는 데이터베이스 플랫폼의이 로우레벨 시큐리티라고 하는 접근 제어 정책의 누락입니다. 그래서이 프로덕션 TV가 웹로 노출된 거죠. 어, 물론 이것을 코딩 실수라고 할 수는 없겠죠. 하지만 저는이 사례가 그래서 더 시사하는 바가 크다고 생각합니다. 왜냐하면이 서비스를 한다는 것은 단순히 코딩만으로 끝나는 문제가 아니라는 것을 보여주고 있거든요. 자, 몰트 북만의 사례는 아닙니다. 여러 분석과 조사에서이 AI가 만든이 코드가 어 품질과 보안 문제가 지속적으로 관찰되고 있다는 것을 보여주고 있습니다. 또 그리고이 개발자들도 어 AI를 이용한이 코딩을 거의 대부분 사용하지만 그 코드에 대한 신뢰는 절반 정도밖에 하고 있지 않다라고 스택 오버플로우의 조사 결과도 있습니다. 자, 그런데 이게 AI가 문제일까요? AI가 문제라는 것은 어 무책임한 결론이라고 생각합니다. 어 저는 지금이 AI가 코드를 짜면 무조건 위험하다라는 말씀을 드리고 싶은 것이 아닙니다.

어 진짜 우리가 해야 될 질문은 이것입니다. 누가 품질의 경계와 기준을 정하고 또 누가 그것을 검증했는가 그리고 또 누가 최종 책임을 지는가입니다. 자 구현은 AI한테 위임할 수 있어도 어 책임까지 위임할 수는 없습니다. 자 여기 1 + 1이 있습니다. 답이 뭐죠? 예, 당연히 2죠. 자, 이것은 어떤 시스템이어도 2가 되어야 되는 정답이 있는 계산 문제죠. 어플리케이션이 게임이든 쇼핑몰이든 커뮤니티 어떤 시스템에서도 1 + 1은 2가 돼야 된다는 거죠. 자, 근데이 질문은 어떻습니까? 우리 서비스의 MSA 아키텍처 구조가 적합한가? 자, 여기에 정답이 있나요? 사업의 목표, 일정, 예산, 팀의 규모와 특징, 레거지 시스템과의 어떤 연동 관계, 심지어 큰 조직이라면 조직의 어떤 정치적인 감각까지 이런 것들을 다 고려해서 결정을 해야 되는이 아키텍처 설계 구조의 문제인 거죠. 자, 우리는 이런 조건들을 맥락 또는 제약 또는 트레이드오프라는 표현을 쓰는데요. 이런 맥락과 제약들을 고려해서 여러 대안을 검토하고 그중에서 우리한테 가장 맞는 것을 결정하는 적 판단과 결정 그리고 책임의 영역인 거죠.

자, 그리고이 설계의 구조뿐만 아니라 보안의 수준, 성능의 목표, 확장성의 기준 이런 것도 마찬가지입니다. 자, 우리가 이런 것들을 품질 요소라고 하는데요. 자, 보안 수준이 무조건 높은게 좋은 걸까요? 그럼 성능 손해는 어떻게 하죠? 또이 성능 목표, 성능 수준이 무조건 좋으면 빠르면 좋은 건가요? 그러면 거기에 드는 비용은 어떻게 하죠? 확장성도 마찬가지고요. 자, 그래서 이런 아키텍처적 구조, 설계, 품질, 비기능 요소들은 정해진 답이 있는 것이 아니라 이런 다양한 맥락과 제약 속에서 우리 상황에 맞는 최선의 선택을 해야 될 문제입니다. 어, 미국의 유명한이 소프트웨어 아키텍트인 마크 리처즈는 이렇게 얘기했습니다. 소프트웨어 아키텍처란 구글에서 검색할 수 없는 것들이다. 자, 그런데 이런 일들을 해오던 사람들이 있습니다. 자, 바로 아키텍트입니다. 어, 아키텍트가 하는 일은 뭘까요? 자, 당연히 설계죠. 어 그런데이 설계라는 것이 다소 주상적이어서 저는이 설계라는 것을 구체적인네 가지 활동으로 정리해 봤습니다.

첫 번째 정의한다입니다. 비즈니스 요구 사항은 항상 모호합니다. 통합해 주세요. 빠르게 해 주세요. 안전하게 해 주세요. 유지보수 쉽게 해 주세요. 자 이런 모호한 요구를 어 시스템의 구조와 품질 목표 경계와 명확한 기준으로 구체화를 하죠. 그리고 두 번째 제약을 합니다. 어떤 기술 스택을 쓰고 어떤 보안 경계를 가지고 어 그리고 코딩 컨벤션 그리고 또 개발 가이드 이런 제약과 규칙을 정하죠. 다음으로 판단한다입니다. 앞서 보셨던 그런 다양한 맥락과 제약 속에서 여러 대안을 검토하고 트레이드오프를 판단하고 최종적으로 중요한 설계를 결정합니다. 마지막으로 검증한다입니다. 시스템이 설계대로 구현이 되었는지 그리고 합의한 품질대로 구현이 되었는지 검증하고요. 리뷰하고요. 그리고 최종적인 책임을 줍니다. 자, AI가 코딩을 대신해 준다고 해서 이런 것들을 온전히 다 맡길 수 있을까요? 물론 도움을 받을 수는 있습니다. 그러나 AI에게 모든 걸 맡길 수 없기 때문에 AI 시대에도 이런 아키텍터가 하는 일은 여전히 필요하다고 보고 있습니다.

자, 그러나이 아키텍트의 업무의 형식은 조금 변화되었습니다. 자, 기존에는 아키텍트가 고객과 PM 개발자들하고 협업을 했다면 여기에 AI 에이전트라는 새로운 실행 주체가 들어왔죠. 그러므 일하는 방식에도 변화가 생겼는데 어 기존에이 프로젝트의 맥락이나 개발 표준과 가이드 어떤 금지 규칙 뭐 테스트 설계 이런 것들을 개발팀 또는 사람인 이해 관계자들에게 문소화로 보여주고 설명하고 조율를 해 왔다면 AI 에이전트에게는 컨텍스트 룰 가드레일 이런 형태의 실행 지침으로 실행 조건으로 제시가 되어야 하는 거죠. 자, 이렇게 AI 에이전트라는 AI 개발자가 새롭게 등장하면서 아키텍터가 이렇게 일을 정의하고 경계를 나누고 그 결과를 검정하는 능력이 더 확장되고 중요해졌다고 볼 수 있는 거죠. 그래서 저는 AI 시대에는 더 많은 개발자가 단순 코딩이 아니라 아키텍처럼 이해돼야 한다고 생각합니다. 자, 그러면이 아키텍트로 어 성장하려면 어떻게 해야 될까요? 자, 연주자에서 지휘자로 되는 관점의 변화가 필요한데요.

기존에 우리 개발자들의 성장 방식은 이랬습니다. 특정 언어를 깊이 있게 공부하고 어 그 프레임워크에 익숙해져서 어 여러 소프트웨어 프로덕을 만드는 전문가가 되는 길이었죠. 음악으로 치자면 훌륭한 연주자가 되는 길입니다. 특정 악기를 아주 잘 자유자재로 연주하는 연주자죠. 자, 그런데 AI 시대에는이 연주는 AI 에이전트들이 잘 해줍니다. 그래서 우리 개발자들은 여러 AI 에이전트들이 코딩한 결과물을 좋은 소프트웨어로 만드는 지위자의 어떤 관점을 가져야 된다고 봅니다. 여러 악기가 조화롭게 연주가 되어서 좋은 음악이 탄생하듯이 여러 소프트웨어 구속 요소들이 AI 에이전트로 인해서 잘 유기적으로 결합해서 좋은 신뢰할 수 있는 소포트가 될 수 있도록 지휘하는 지휘자로서의 개발자인 거죠. 자, 그러면 좋은 지휘자가 되기 위해서 어떻게 해야 될까요? 조금 진부한 얘기일 수도 있는데요. 기본이 아주 중요합니다. 자, 여기 보시면 대왕 카스테라, 흑당 버블티, 탕후루, 두종쿠 이것들의 공통점이 뭘까요? 바로 한 때 유행했다가 사라지거나 혹은 사그라진 것들이죠.

우리 개발에도 변하는 것과 변하지 않는 것이 있습니다. 새로운 언어와 도구, 프레임, 요즘에는 각종 AI 툴들 계속 새롭게 나오고 계속 변화하고 발전하죠. 그렇지만이 시스템 소프트웨의 구조의 원리, 보안의 원칙, 성능과 확장성에 따른 설계 패턴, 네트워크 프로토콜 같은 또는 데이터 모델링 이런 것들은 시간이 지나고 기술이 발전해도 잘 변하지 않는 것들이죠. 그래서 지휘자로서의 우리 개발자들은 이런 변화는 도구는 따라가되 중요한 것은 이런 원리는 파고 들어야 된다는 거죠.이 이 도구들은 전부 다 할 필요가 없이 자기가 다룰 수 있는 도구를 공부하면 되는 것이고요. 그리고이 변하지 않는 원리들을 끝내고 뭔가 해야 된다는 말은 아니고요.이 원리들은 항상 지속적으로 관심을 가지고 학습을 해 나가야 된다는 말씀입니다. 자, 다음으로 하나는 깊이 있게 끝까지 해 봐라입니다. 특히 개발에 입문하시는 분들에게 강조하고 싶은 내용입니다. 자, 작은 것이라도 좋으니까 처음부터 끝까지 직접 주도해서 만들어 보는 경험을 꼭 가져가십시오.

물론 중간중간에 AI 도움을 받을 수는 있습니다. 그러나 도움을 받는 것이지 주도권을 AI한테 줘서는 안 된다는 거죠. 자, 직접 코딩도 해보고 DV 설계도 해보고 코리도 짜보고 버그도 만나서 수정해 보고 배포도 해보고 AI 도움을 받아서 이런 것들을 처음부터 끝까지 자기 손으로 직접 해보는 경험을 해 봐야 우리이 프로그램이 어떤 구조로 그리고 어떤 형태의 동작 방식을 가지고 동작을 하는지 알 수 있으며 또 문제가 생겼을 때 어떻게 접근해야 되는지 이해할 수가 있거든요. 자, 그래서 아키텍트로 성장하실 우리 개발자 분들은 반드시 하나쯤은 깊이 있게 끝까지 주도적으로 해 보는 경험을 가져가셔야 됩니다. 자, 이렇게 변하지 않는 것과 깊이 있는 경험을 하고 난 다음에는 기술적 너비를 주구를 해야 됩니다. 자,이 그림은 아까 말씀드린이 마크 리처저라는 분이 본인의 책에서 제시한 지식 피라미드인데요. 자, 제일 위에 있는 것이 내가 알고 있는 지식입니다. 즉 기술적 깊이를 얘기합니다. 그렇지만 피라미드의 가장 상단에 가장 작은 부분을 차지하죠.

왜냐하면 한 사람이 평생에 걸쳐 깊이 알 수 있는 건 전체 지식에서 한계가 있으니깐요. 두 번째는 모른다는 것을 아는 영역입니다. 어는 받지만 깊이 있는 전문성은 없는 영역이죠. 그리고 세 번째는 모르는 줄도 모르는 영역입니다. 어떤 기술이 있는지조차도 모르는 영역인 거죠. 어 그래서이 마크 리처즈는 아키텍트들에게 1번과 2번을 넓혀 나가야 된다고 얘기하고 있습니다.이 1번과 2번을 기술적 너라고 하는데요. 왜 그러냐면 아키텍터가 어떤 비즈니스의 문제, 요구 사항을 해결하려면 어떤 지식, 어떤 기술, 어떤 기법이 있는지 알아야 그 기술을 적용해 보거나 대안을 찾아볼 수 있는데 아예 어떤 것도 있는줄도 모른다면 대안으로서 활용도 못 하는 거죠. 그래서이 2의 영역을 넓혀서이 3의 영역을 줄여 나가야 된다고 하고요. 그리고 어떤 경우가 되면 2의 영역에 있는 것을 1의 영역으로 올려라고 말하고 있습니다. 어 저는이 논리가 아키텍트뿐만 아니라 AI 시대의 우리 개발자들에게도 똑같이 적용할 수 있는 관점이라고 생각하고 있습니다.

자, 특정 기술에 깊이 있게 요청할 수 있는 AI 에이전트들이 있죠. 그래서 우리 개발자들은 1과 2의 영역을 넓혀 나가고요. 그리고 경우에 따라서는 1의 영역으로 성격시키는 그런 활동을 하시기 바랍니다. 자, 이렇게 관점과 기준을 가지고 있다면 또 하나 중요한 것이 감이 아니라 기준을 배워야 된다는 것입니다.이 전문가의 특징 중에 하나는 개인적인 감이나 경험에만 의존하지 않습니다. 국제적으로 신뢰성 있는 공신력 있는 기준을 본인의 업무에 활용을 하는데요. 우리 소프트웨어 아키텍터 분야에서도 활용할 수 있는 국제적 기준이 많이 있습니다. 자, 그중에 몇 가지만 말씀드려 보면이 품질 기준이라고 하는 ISO 25,10번이 있습니다. 자, 이것은 품질에 대한 왓을 정의한 것이고 또 하우를 정의한 기준도 따로 있습니다. 그리고 두 번째 보완 기준은 OWASP가 있습니다. 국내에는 ISMS 인증 기준이 있죠. 그리고 운영 기준에는 구글 SRE가 참 좋은 기준이 될 수 있습니다. 그리고 개인 정보를 다룬다면 법률 기준으로 관련된 법령이 있습니다.

자, 이렇게 기준을 가지고 있어야 AI한테 일을 시킬 때도 명확하게 기준을 가지고 일을 시킬 수 있고요. 또 AI의 결과를 그 기준을 기반으로 해서 객관적이고 정량적으로 검토할 수 있다는 거죠. 회원 가입이나 로그인 기능 만들 때 안전하게 만들어 줘. 이렇게 모한 요청이 아니라 ASVS의 이런 항목들을 검토해서 어떻게 구현할지 어떻게 테스트할지 적용하지 않은 경우 어떤 사회로 적용하지 않는지 등을 AI한테 구체적으로 지시하고 요청할 수 있다는 거죠. 자, 다음으로는 AI를 공부만 하지 말고 직접 만들어라. 자, 이게 무슨 말이냐면 지금 시대에는 AI를 활용하는 능력이 아주 중요해졌습니다. 그런데 이런 분들이 있습니다. 요즘 컨텍스트 엔지니어링, 하네스 엔지니어링, 어떤 엔지니어링들이 굉장히 나무하고 있죠. 그래서 엔지니어링 공부하다가 지치거나 또는 허리를 느껴서 정작 중요한 소프트웨어는 못 만들고 있다는 거죠. 그래서 저는이 AI로 무조건 만들어 보고 배보해 보고 누군가 사용하게 해보고 개선해 보고 피드백 받아보고 가능하면 과금까지 해보는 이런 경험을 반드시 지속적으로 반복적으로 집중적으로 해야 된다고 생각합니다.

주객이 전도되어서 안 됩니다. AI를 잘 활용하기 위한 엔지니어링 공부는 필요합니다. 그러나 그 공부 때문에 AI를 이용해서 소프트웨어를 만드는 그 일체를 미루면 안 된다는 거죠. 수영을 잘하려면 직접 물에 뛰어 들어가는 수밖에 없습니다. 물에 뛰어 들어가기 전에 책으로 영법 보고 호흡 보고 아무 소용이 없죠. 직접 물에 뛰어들어가 봐야 아 이런 부분이 부족하구나 느낄 수 있고요. 그렇게 됐을 때 어떤 룰 같은 것들을 한번 적용해 보고 이런 식으로 본인의 AI 활용 경험을 반드시 집중적으로 하시기 바랍니다. 자 이렇게 성장한 우리 아키텍트들에게 올 기회에 대해서 제 생각을 말씀드리겠습니다. 자 세상에 흔해져서 비싸지는 건 없죠. 지금이 AI가 코드를 엄청나게 만들어 내고 있죠. 개발자뿐만 아니라 비개발자도 지금 AI를 이용해서 코드를 많이 만들고 있고 앞으로도 더 많이 만들게 될 겁니다. 그래서 코드는 굉장히 흔해질 것입니다. 자, 이렇게 코드가 흔해지면 결국 제대로 검토해야 할 코드, 신뢰성 있게 운영해야 할 시스템, 그리고 유지 보수하고 확장을 해야 될 결정이 필요한 사항들이 함께 늘어날 것입니다.

왜냐하면 비개발자가 만든 혹은 개발을 신경 쓰지 않고 만든 저품질 소프트웨어도 같이 막 늘어날 거거든요. 그래서 저는 코드는 싸지고 판단은 시소성이 생긴다. 그래서 빚 싸진다고 생각합니다. 자, 마지막으로 어 바이브 코딩 지도를 한번 제시해 보겠습니다. 저는이 바이브 코딩을 누가 어떤 걸 만드느냐에 따라서네 가지의 영역으로 나눌 수 있다고 생각합니다. 자, 제일 먼저 비발자가 만드는 가벼운 소프트웨어입니다. 가벼운 소프트웨어라는 것은 개인 유틸리티나 뭐 프로토타입 그리고 경량의 어플리케이션을 말합니다. 자,이 영역은 그야말로 딸각의 영역입니다. 진짜 딸각만으로 충분할 수 있습니다. 다음으로 개발자가 만드는 가벼운 소프트웨어입니다. 어, 개발자의이 실름 속도가 엄청나게 폭발하는 영역이죠. 자, 다음으로는 비개발자가 만드는 상용 소프트웨어입니다. 어, 돈을 받거나 개인 정보 받거나 아니면 크리티컬한 어떤 그런 어플리케이션이라고 생각하시면 됩니다. 위험 지대입니다. 만들 수는 있지만 어떤 문제가 생길지 모르고 또 책임을 질 수도 없는 영역입니다.

자, 마지막으로 개발자가 어 상용 소프트를 만드는 영역입니다. 개발 지식과 명확한 기준을 가지고이 AI를 지휘하면서이 판단하고 결과를 책임지는 영역이죠. 바로 우리 아키텍트들의 영역입니다. 자, 저는 뭐지 하나이 위험 지대에 있는 소프트웨어들이 아키텍터 영역으로 도움을 받게 될 것이며 딸가의 영역도이 소프트웨어가 커지고 많이 유용해진다면 또다시 아키텍터 영역으로 올 수 있다고 봅니다. 이때 우리 아키텍트로 성장한 개발자들의 손이 필요하게 될 것이라고 보고 있습니다. 자, 이렇게 해서 강의를 마치겠습니다. 자, AI에게 코딩은 맡기되 판단까지는 맡기지 마십시오. 자, 여기까지 들으셨다면 어, 아키텍트로 성장하실 준비가 되신 분이실 되고요. 어, 제 채널의 멤버십의 아키텍트 인사이트에서는 아키텍트로 성장하기 위한 정통 아키텍트 지식과 그리고 경험들을 제공하고 있습니다. 어, 관심 있으신 분들은 멤버십에 참여해서 같이 아키텍트로 성장하시죠. 자, 수했습니다.