Video: AI가 코드를 짜는 시대, 설계 문서가 필요한가 | 개발자 논쟁
Channel: 코딩하는기술사
Duration: 20m 17s
Source: subtitle (auto, ko)
Transcript:
안녕하세요. 코딩하는 기울사입니다. 어, 저는 요즘 매일 아침에이 전 세계 개발과 관련된이 뉴스나이 화제가 되는 글을 자동으로이 리포트로 받아보는 걸 클로드를 활용해서 자동화를 시켜 뒀는데요. 어, 오늘이 리포트 중에서 효과적인 소프트웨어 설계 문서 작성법이라는 글이 눈에 들어와서 어, 여러분들에게 좀 소개를 시켜 드릴까 합니다. 어, 제가 평소에이 아키텍처 설계나 문서와의 관심을 가지고 있기도 하고 또 관련 콘텐츠도 만들고 있잖아요. 그래서이 글을 한번 읽어 봤습니다. 어, 그리고이 글이이 해커 뉴스라는데도 올라와서이 상당히 많은 다른 개발자들하고 활발이이 글과 관련된 의견이 나눠지고 있더라고요. 자,이 글에 대한 해커 뉴스 댓글드립니다. 300점 넘는 포인트하고 그리고 140개 정도 코멘트가 달려 있네요. 현재 기준으로. 어, 그런데이 댓글을 읽어 보니까 뭐 단순히 뭐 좋은 글이다 뭐 이런 반응만 있는 것은 아니고요. 설계 문서를 왜 만드냐? 그냥 코딩해서 프로덕을 바로 만들면 되지 않느냐라는 의견부터 해서 AI 시대에는 설계 문서가 또 어떻게 달라져야 하는가까지 꽤 흥미로운이 논쟁들이 이어지고 있습니다.

어 그래서 오늘은이 글의 핵심 내용을 같이 한번 살펴보고이 해커 뉴스의 개발자들은 어이 글에 대해서 어떻게 생각하고 있는지도 어 몇 가지 소개를 드려 보겠습니다. 자 이게 원문 글입니다.이 이 글을 쓴 사람은이 마이클 린치라고 해서 개발자입니다.이 본인 소개를 보면 마이크로소프트하고이 구글에서 커리어 대부분을 보냈다 그러고요. 그리고이 2018년도부터는이 본인 회사를 차려서 사업을 운영하고 있다고 합니다. 그리고 2016년도부터 소프트웨어와 창업에 대한 블로그도 운영하고 있고요. 어이 글은이 마이클 린치가 작성한이 책 리팩토링 engish 소프트웨어 개발자를 위한 효과적인 글쓰기라는이 책의 내용 중 일부라고 하고요. 어 저자는 실제로이 구글과 마이크로소프트 그리고이 자신의 현재 회사에서이 디자인 문서를 계속 작성해 왔다고 하고 있습니다. 자 한글로 먼저이 번역해서 보겠습니다. 자이 글의 시작에서 저자는이 디자인 문서 설계 문서죠.이 이 설계 문서의 가치를 강하게 어필하고 있습니다. 자,이 설계 문서는 개발 시간을 수년씩 전하게 줄 수 있습니다.

구연에 시간 낭비하기 전에 중요한 결정을 신중하게 어 고려하게 되고 그리고이 팀 간의이 설계에 관련된 결정을 조율하는 가장 좋은 방법이라고 하고 있습니다. 어, 그런데 중요한 것은이 모든 개발의 거창한 설계 문서를 작성하라는 이야기는 아닙니다. 자, 조금 내려가 보면 프로젝트가 복잡하거나이 위험할수록 설계 문서를 작성하는 것이 더욱 중요하다고 말하고 있고요. 자, 그 근거로 여러 명이 협력해서 설계를 구현할 것인지 그리고 풀타임으로 3개월 이상 소요되는지 그리고 수년간 문제 없이 작동해야 되는지 그리고 팀간 협업이 포함되어 있는지 그리고 프로젝트 목표와 요구 사항이 뭐한지 어 설계 단계에서 예방할 수 있는 치명적인 위험 요소가 있는지 자이 질문 중에서 하나라도 예라고 답한다면이 설계 문서를 작성할 가치가 있다 그러고요. 두 개 이상 예라고 답했다면이 설계 문서를 작성하는데 드는 노력은 거의 확실히 가치가 있다고 말하고 있습니다. 자, 설계 문서를 작성하는 기준을 나름대로 제시한 것이죠. 자, 그리고이 설계 문서 작성에 얼마나 투자해야 될까?

자,이 질문에는이 설계 문서가 간단한 한 페이지 문서일 수도 있고 그리고 50페이지짜리 방대한 문서일 수도 있다고 하고요. 어, 경우에 따라서는이 설계 문서에 투자해야 하는 시간이 전혀 필요하지 않을 수도 있다고 하고 있죠. 절대적으로 필요하다, 필요하지 않다 하는 것이 아니고요. 팀의 목표, 뭐 리스크, 마감밀, 조직, 문화에 따라 달라진다 하고 있죠. 어, 저도 개인적으로 어,이 부분은 상당히 공감합니다. 설계 문서이 자체를 만드는게 목적이 아니죠. 좋은 프로덕을 만들기 위해서 설계 문서가 필요한 것이고 그 설계 문서가 좋은 프로덕을 만드는데 역할을 할 때만이 가치가 있는 것이죠. 자, 그리고이 설계 문서에는 무엇이 포함돼야 되는지 말하고 있는데요.이 설계 문서에 너무이 모든 세부 사항을 다 적으면 뭐 그것이 구현하고 똑같기 때문에 본래 목적 자체가 무의미해진다고 하고 있고요. 어, 그래서 일반적으로이 설계 문서에 어떤 내용을 포함할지 판단하는 기준을 제시하고 있습니다. 자, 그 기준 중에 핵심적인게 잘못 판단했을 때 비용이 얼마나 들지를 한번 생각해 보는 것이죠.

어, 예를 들어서 어떤 프로그래밍 언어를 선택하고 수십만 줄의 코드를 작성한 뒤에 아, 이거 다른 언어 뭐 다른 프레워로 했어야 되는데라고 생각하게 되면 나중에 변경하기가 굉장히 어렵죠. 뭐 데이터베이스나 데이터의 저장 구조 같은 것도 마찬가지고요. 그런데 반면이 화면에 목록을 한 번에 100개를 보여 줄 건지 뭐 25개를 보여 줄 건지 뭐 리드 뭐 같은 버튼을 둘 건지 이런 문제는 지금 잘못 선택해도 언제든지 변경할 수 있는 문제죠. 그런 결정을 가지고 설계 리뷰에서 몇 시간씩 토론할 필요가 없다는 말을 하고 있고요. 어,이 취지는이 제가이 멤버십 강의에서 아키텍처 정규 이론 강의를 하고 있는데요. 자, 거기서 아키텍처하고 상세 설계 개발 무엇이 다른가라는이 세션에서 아키텍처 설계하고 상세 설계를 나누는 그런 어떤 기준과 관점하고도 유사합니다. 자, 아키텍처하고 상태 설계를 나누는 기준 중에 변경 비용이 있었죠. 자, 나중에 변경하려면 큰 비용을 유발하는 것. 자, 그것이 아키텍처 설계라고 할 수 있고요.

어, 상대적으로 빠르게 수정 가능하다. 자, 그것은 상세 설계로 나름 분류를 해서 설명을 드렸는데요.이 마이클 린치도이 설계 문서에는이 모든 구연 세부 사항을 미리 적어 놓는 문서가 아니라 나중에이 잘못 결정했을 때 그 결정을 되돌리기에 너무 많은 비용이 드는 그런 문제를 어,이 설계 문서로 포함해라 하고 있습니다. 자, 그리고이 설계 문서에 실제로 어떤 내용을 포함해야 되는지 그 항목 템플릿을 제공하고 있고요. 자, 제목부터 해서 뭐 메타데이터 목표 배경 관련 문서 뭐 비목표 시나리오 그리고 중요한 다이어그램 뭐 용어집 제약 조건 그리고 서비스 수준 목표 자라고 하는데요. 자, 성능이 좋아야 된다. 보안이 좋아야 된다. 이런 모한 추상적인 표현이 아니라 정확한 수치로 관리를 해야 된다고 하고 있고요. 또 그것을 설계 문서에 이렇게 표현을 해야 된다 하고 있고요. 그리고 모니터링, 타임라인, 뭐 일정까지 그리고 중요한 인터페이스 그리고이 종속성, 보안, 개인 정보, 법적 고려상 로깅 어 미해결 문제까지 그리고 해결된 문제에 또 대한 자, 상당히 많죠, 항목이.

어 그런데 이것을 모두 다 쓰라고 말하고 있는 건 아닙니다.이 저자도 프로젝트에 맞는 것만 선택해서 사용하라고 이야기하고 있습니다. 어 참고로이 목표이 목표에는 자못된 목표 쿠버네티스를 인프라에 추가합니다. 자 이건 기술이죠. 기술 자체를 목표로 쓰지 말라고 하고요. 자 목표는 세앱 버전 배포와 관련된 서비스 중단점을 최소화합니다. 이런게 목표가 돼야 된다는 거죠. 자, 그리고이 비목표 넌골이라고 하는데요. 자, 이번 프로젝트에서 무엇을 하지 않을 것인지도 명확하게 기수를 하라고 공고하고 있습니다. 자, 이렇게이 상승한 내용까지 설계 단계에서 이렇게 고려를 해야 되고요. 어, 단순히 구속 요소 박스 그리고 뭐 화살표 연결하고 그게 아키텍처 설계가 아니죠. 자, 그리고이 실제이 설계 문서도 공개하고 있습니다. 자, 여기 리틀 모멘트 설계 문서인데요. 자, 이건 저자가 실제로 만든이 개인 프로젝트에 본인의이 설계 문서의이 원칙과 구성을 실제로이 프로덕에 적용한 사례입니다. 어, 코드를 작성하기 전에이 문서를 만들었고 실제 구연도이 설계를 기준으로 진행하고 있다고 합니다.

자, 문서를 보시면 상당히 구체적이죠. 배경 목표 뭐 비목표도 있고요. 그리고 아키텍처 다이아그램도 있고요. 그리고 프라이버시 보안.이 설계 문서를 직접 한번 쭉 읽어 보시기 바랍니다. 자, 이제이 글에 대한이 다른 여러 개발자들의 의견을 한번 보겠습니다. 자, 오늘 제가 말씀드릴 내용 중에이 핵심은이 개발자들의 의견입니다. 자, 이것도 한글로 한번 바꿔 볼게요. 자, 댓글이 상당히 많죠? 자,이 첫 번째 댓글부터 재밌습니다. 자,이 밥이라는 사람이 조금 부정적으로 말하고 있죠. 자,이 설계 문서가 전체 프로세스에 의미 있게 개선한 적을 본 적이 없다. 기껏해야 비즈니스 부서와 조율을 유지하는데 도움이 될뿐 납기 일은 훨씬 길어질 뿐이다. 자,이 내용은 우리 한국 시장 특히이 SI 시장에서 다들 가지고 있는 생각일 겁니다. 문서를 엄청 만드는데 어, 실제 개발에 도움 되지 않는다는 생각을 많이 가지고 있죠. 자, 그리고 또 이렇게 얘기하고 있습니다. 어, 설계 문서 말고 직접 구현을 해서 결과를 보는게 훨씬 빠르다.

어, 소프트웨어는 원자력 발전소나 해상 석유 시추 플랫폼처럼 미리 많은 것을 증명할 필요가 없다. 그리고 누구의 허락도 필요 없다. 원할 때 언제든 프로토타입 빨리 만들어 본 결과죠.이 프로토타입을 이메일로 보내면 된다. 그게 바로 설계 문서다라고 하고 있습니다. 자, 많은 개발자들이 뭐 공감할 것 같은 내용이죠. 자, 그런데이 댓글에이 저자 마이클 린치가 답변을 직접 했네요. 자, 자기가 작성자로 하고요. 어, 먼저이 설계 문서가 아주 유용하다는 생각을 본인이 가지고 있기 때문에 변경이 있을 수 있다는 점을 인정한다고 먼저 얘기하고 있고요. 그렇지만 사람들이이 설계 문서를 싫어하는 이유는이 다음 두 가지 중 하나라고 하고 있습니다. 첫 번째는 설계 문서가 무의미한 의뢰로 여겨지는 팀에서 일해본 경험이 있다. 앞서 제가 말씀드린 우리 한국의 SI 프로젝 뭐 다 그렇지는 않겠지만 어쨌든 대부분의 SI 프로젝에서이 설계 문서가 실제 구현에 큰 도움이 안 되고 있죠. 자, 그래서 그런 팀에서이 무의미한 일을 하기 위해서 부실한 문서를 작성하고 또 다들 무의미하다고 생각하고 또 관련된 피드백 유용한 피드백도 없고 그래서 설계 문서가 무의미하다는 생각하는 그 이유 하나하고 두 번째는 어 좀 도발적인 의견일 수도 있겠는데요.

자, 개발자가 다른 사람들이 자신의이 엔지니어링 선택에 대해 질문하는 것을 좋아하지 않는다고 합니다. 그래서 팀원들이 설계 문서보다 완성된 코드에 대해서 어떤이를 제기하기가 어렵다는 것을 알고 있기 때문에 설계 문서를 싫어한다고 하고요. 그리고이 설계 변경 전에 구현에 많은 시간을 투자하면 나중에 이상적인 구현이 제기된다고 하더라도이 이미 구현된 것을 계속 유지하고 싶어 하는 생각을 가지고 있다고 하고요. 또 그리고이 1만 줄짜리 코드 설계 결정을 검토하는 것은 5페이지짜리 설계 문서를 검토하는 것보다 팀온이 더 어려워한다고 하고 있습니다. 어떻게 공감을 좀 하시나요? 자, 그리고 댓글들이 상당히 많은데요. 어,이 중에서 몇 가지 한번 줄여 봤습니다. 자, 앞서 말씀드린 밥 아저씨가 한 말이죠. 자, 밥 아저씨는이 차라리 빠르게 만들어 보자.이 이 버티컬 슬라이스 프로토타입을 만들어서 비즈니스에 보여 주자 하는 내용인데요. 자,이 버티컬 슬라이스 프로타입이 뭐냐면 어 기능이 이렇게 있으면 UI부터 해서 뭐 어플리케이션 데이터베이스까지이 버티컬하게 전체이 핵심 기능의 흐름을 한번 빨리 개발해서 보여 주자는 거죠.

이거 자체가 설계 문서라고 얘기하고 있는 거죠. 자, 이글에이 저자가 뭐 구현한 뒤에는 설계를 바꾸기 더 어렵다고 얘기하고 있고요. 자, 설계 문서 싫어하는 이유도 두 가지 얘기했죠. 어, 또 그리고 한 개발자가 저자의 의견에 대체로이 동의를 하면서도이 여러 사람이 함께 설계하는 것 자체가 어려운 기술이다라고 이야기하고 있습니다. 어, 또이어서 다른 개발자는 더 현실적으로이 팀원들의 영량하고이 도메인에 대한 이해도가 비슷비슷해야이 공동 설계가 제대로 동작한다고 말하고 있습니다. 그렇지만 현실에서는 그런 조건이 갖춰지는 경우가 드물기 때문에이 본인은 오히려 프로토타입을 먼저 만들고 설명하는 쪽을 선호한다고 말하고 있습니다. 자, 그리고 또 다른 개발자는 문서를 쓰는 것이 목적은 아니다. 예, 맞는 말이죠. 설계 문수 자체가 목적이 되면 안 된다. 중요한 것은 설계를 생각하고 다른 사람에게 도전받고 공유하는 과정이라고 하고 있습니다. 그리고이 AI 코딩 시대에이 논리가 조금 낡은게 아닌가라는 문제 제기를 하는 사람도 있습니다.

자, AI 코딩 시대는 기존 설계 문서를 옹호하던 이유 중 일부가 유효하지 않을 수 있다라고 하고 있고요. 또 다른 한편으로는 오히려 AI 시대라서이 설계 문서가 더 중요하다라는 의견도 있네요. AI가 많은 코드를 작성할수록 설계 문서는 오히려 더 중요하다. AI가 어떤 약점이 있기 때문에이 좋은 설계 문서의 역할은 무엇이 범위에 포함되고 무엇이 제외되는지를 명확하게 하는 것이 그 역할을 한다고 하고요. 그리고 또 다른 개발자는 코드는 싸졌다고 하고요. 그래서이 어려운 엔지니어링 문제는 코드 작성 자체보다는 요구 사항을 제대로 정의하고 고수준의 아키텍처를 결정하는 쪽이 어 더 많이 남는다고 합니다. 그래서 문서하의 중요성이 커진다는 의견을 말하고 있고요. 어, 또 다른 분은이 설계 문서보다 그냥 AI한테 여러 대안을 직접 구현하게 해보고 그 결과를 비교하면 되지 않느냐라고 하고 있습니다. 어, AI가이 코드를 굉장히 저렴하게 만들어 줄 수 있기 때문에 옛날에는 문서를 가지고 대안을 비교를 했다며 이제는 AI한테 실제 구현을 시켜보고 그 결과를 직접 보고이 트레이드오프를 판단하면 된다고 하고 있죠.

다만이 큰 프로젝트는 여전히 사전 협의가 필요하다라고 한계를 말하고 있고요. 일정 규모 이하의 기능이라면 어 설계가 반드시 구현보다 먼저 와야 하는지는 의문이다라고 말하고 있습니다. 자 여기에이 저자 마이클 린치는 AI 프로토타입은 좋지만 설계 이것이 설계 리뷰를 대신하지 않는다는 의견을 말하고 있습니다. AI에게 빠른 프로토타입을 만들게 하고 그 결과를 설계 문서에 작성하는 것은 유용하다라고 인정하고 있고요. 다만이 팀과 설계 결정을 검토해야 한다면 설계 문서의 역할은 여전히 남는다고 합니다. 동료가이 AI로 생성한 방대한 코드를 보내면서 그 안에 있는 설계를 검토해 달라고 하는 방식은 원하지 않는다는 거죠. 어 그런데 또 다른 분은 어 이제 인간팀의 설계 리뷰가 꼭 필요한가라는 의문을 던지고 있습니다. AI가 충분히 잘한다면 왜 여전히 팀원들이 설계 결정을 리뷰해야 하는가라고 묻고 있습니다. 잘 지시된 최신 AI가이 상당수의 개발자보다 더 나은이 설계를 할 수 있다라고 생각하는 거고요. 그렇지만 저자는 AI는 복잡성을 줄이는 판단이 아직 약하다라고 말하고 있습니다.

아직 좋은 인간 개발자보다 복잡성을 제한하는 판단에 약하다고 느낀다고 하네요. 예를 들어서이 요구한 기능이 지나치게 복잡해도 AI는 그거 그대로 구현을 하려고 하지만이 좋은 시니어 개발자는 정말이 기능이 모두 필요한가? 버전 1원에서는 더 단순하게 만들 수 없을까라고 대무를 수 있다는 거죠. 인간이. 그래서 설계 리뷰의 중요한 결과 중에 하나는 이런 불필요한 복잡성을 줄이는 것이라고도 하고 있고요. 자, 그리고 또 다른 물은 앞서 제일 천 밥 아저씨가 말한 거 있죠. 소프트웨어 개발은 원자력 발전소 뭐 이런 거 아니라고. 자, 거기에 대한 반박으로 소프트웨어가 항상 가벼운 것만 아니다라고 지적하고 있습니다. 자, 소프트웨어는 원자력 발전소, 자동차, 석유 플랫폼, 심박 조율기 등 수많은 중요한 시스템에 들어간다. 자, 아주 중요한 얘기죠. 자, 1대성에 가까운 앱이라면 빠르게 그냥 구현하고 바로바로 고쳐도 되겠지만 이런 중요한 시스템은 설계 문서의 가치가 매우 크다라고 하고 있습니다. 자, 자, 제가 늘 강조하고 경제하는 생각이기도 합니다.

자, 그리고이 특정 산업이 규제 산업에서는 문서가 필수다라고 얘기하고 있습니다. 자, 은행과 같이 규제가 강한 환경에서는 프로토타입부터 일단 만들고 잘되길 기대하는 식으로 진행할 수 없다라고 받고 있고요. 요구 사항에서 설계와 구원까지이 추적 가능성을 유지해야 된다고 하고 있고 그래서이 제품이 요구상 설계 문서가 필요하다라고 말하고 있습니다. 그래서이 설계 문서의 중요성은 어떤 도메인과 조직에서 개발하냐에 따라서 크게 달라진다고 말하고 있습니다. 맞는 말이죠. 자, 그리고 또 어떤 개발자는 재밌는 표현을 했습니다. 25년 전에 에자일과 워터풀 즉 에자일 방법론과이 포포스 개발 방법론의 논쟁이 다시 온 것 같다라고 말하고 있습니다. 당시 그 논쟁과 닮아 있다고 하는 거죠.이 이 설계 문서가 필요한지 하는 것과 AI로 먼저 프로타입을 빠르게 만드는 것이 더 현실적이다라는이 의견이 예전에 이과 포포스 개발 방법론과 닮아 있다고 합니다. 자, 그런데 핵심은 모든 것을 미리 설계해야 되는 빅 디자인 업프론트도 아니고 아무 설계도 없이 구형부터 하는 것도 아니라고 하고 있죠.이 이 작은 단위로 실행을 해 가면서 그 과정에서 실제로 어떤 정보를 이용해서 설계를 계속 발전시키는 그런 적절한 지점이 찾는 것이 중요하다라고 하고 있습니다.

자,이 댓글의 의견들이 상당히 재미있고 또 어떤 의견은 굉장히 또 수준이 높고 또 현실적이죠. 어, 그리고 또이 재밌게 본쟁이 또 있는데요.이 설계 문서를 이렇게 자세하게 만들어 놓으면 결국 코드가 변경되면서이 문서 자체가이 낡은 문서가 되지 않느냐 하는 문제입니다. 어, 실무에서 문서화 하면 항상 나오는 이야기죠. 자, 여기에 저자는 이렇게 답을 합니다.이 설계 문서를 시스템의 현재 모습을 영원히 설명하는이 라이빙 도큐먼트로 보는 것은 적절하지 않다라고 하고 있습니다. 어, 설계 문서가 시스템의 특정 변경을 위한 설계 문서라는 거죠. 그 변경을 구현하는 동안에는 설계 문서도 같이 수정해 나가야 되는 것이고 그 구현이 완료되면 그 문서를 프리징해야 된다고 말하고 있습니다. 그래서이 그 시점에 왜 이런 설계를 했는지를 남겨두는 기록으로 보존하자는 말을 하고 있습니다. 그리고 시스템의 전체의이 현재 아키텍처를 설명하는 문서는 별도로 관리해야 된다는 입장이고요. 우리가 ADR이라는 것을 작성할 때도 그게 계속 업데이트 되는 문서는 아니죠.

중요한 아키텍처 결정을 내릴 그 시점에 결정에 대한 히스토리로 관리를 하는 거죠. 그리고이 아키텍처가 변경되거나 하면 ADR이 또 새롭게 나오는 거죠. 자, 그래서 오늘은 제가 아침에 [콧방귀] 우연히 발견한이 글을 가지고이 개발자들의이 의견도 같이 한번 살펴봤습니다. 자, 오늘 영상에서는 제가이 흥미롭게 본 부분만 몇 가지 골라서 소개를 드렸는데요.이 원문에서는 제가 설명하지 않은 내용도 많이 있고요. 그리고 댓글들도 어, 도움되는 내용들이 많이 있습니다. 그리고 말씀드린 대로이 저자가 직접 실제 설계 문서도 이렇게 공유를 하고 있으니까 어이 글들을 직접 한번 읽어 보시길 권해드립니다. 댓글에 어 링크로 URL을 남겨 놓겠습니다. 자 제 채널에이 구독자분들은 어떻게 생각하시나요?이 이 설 AI 시대의이 디자인 도큐먼트 AI가 코드를 굉장히 빨리 만들어 주기 때문에 어 프로토타입을 먼저 만들어 가면서 하는게 훨씬 낫다라는 것과 AI 시드에도이 중요한 디자인 설계 문서는 있어야 된다. 먼저 만들어야 된다 하는 그런 입장하고 어 실무에서 어떤 식으로 하고 있고 또 어떤 생각을 가지고 계신지 댓글로 남겨 주시면 다른 개발자 분들에게도 많은 도움이 될 것 같습니다.

제 채널에서는 아키텍트를 위한 멤버십을 운영하고 있습니다. 소프트웨어 아키텍처의 정통 이론부터 실무 설계, 프로젝트 관리와 리더십 등 아키텍트로 성장하는데 도움이 될 만한 다양한 콘텐츠를 제공하고 있습니다. [음악] AI 시대에는 단순 구현을 넘어서 시스템 전체를 조망하고 판단하는 역향이 더욱 중요해지고 있습니다. 개발에 머무르지 않고 아키텍트로 한 단계 더 성장하고 싶다면 멤버십에서 저와 함께 공부하고 성장해 보시기 바랍니다. 그리고 지금까지 함께 해 주시는 우리 멤버 여러분 늘 감사드립니다. [음악] 함께 성장하는 멤버십이 될 수 있도록 계속 고민하겠습니다. 감사합니다.