현재 공부중인 학생이므로 이 글이 혹시라도 잘못된 정보가 있더라면, 댓글로 잘못된 부분을 지적해주신다면 수정하겠습니다. 앞으로 잘못된 부분을 잘 지적해주셔서 제가 올바르게 성장이 할수 있게 도와주십시오

여는글

최근 코딩 교육이 열풍이라는 뉴스나 소식을 많이 듣는다. 나는 평범한 중학교 1학년 학생이다. 그래서 그런지 내 주변 친구들도 한두명씩 코딩 학원이나 과외를 받는 친구들이 늘어난거 같다. 나는 현재 웹쪽을 이제 5개월 정도 공부를 해봤고 지금부터 나는 내가 5개월동안 코딩과 프로젝트를 만들어 보면서 느꼈던 것을 한번 적어보려한다. 아직 중학교 1학년 인지라 많이 부족한 말이 많겠지만 너그러운 마음으로 이해를 해주면 좋겠다.

나의 코딩 시작

나의 컴퓨터 시작

나는 초등학교 2학년때부터 게임을 무척 좋아했다. 그래서 그런지 게임 관련된 영상을 많이 보기도 했고 많이 하기도 했다. 하지만 나는 게임 체질이 아닌건지 도통 게임 티어가 오르지 않았다. 내가 좋아했던 게임은 스타크래프트였는데 내 주변 초등학생때는 스타크래프트를 하는 사람들이 많이 있지 않았다. 그래서 나는 다른 게임을 온라인에서 만난 사람들과 같이 플레이 하곤 했었다. 그때부터 나는 컴퓨터라는 세계에 더욱더 흥미를 느끼게 됬던거 같다.

나의 코딩 시작

나는 초등학교 5학년 말까지 게임을 하루에 6시간이상 할 정도로 많이 하고 있었다. 그 중간에 부모님한태 많이 혼나기도 했고 컴퓨터에 비밀번호도 걸리게 되었다. 그렇게 시간이 흐르고 초등학교 5학년 겨울방학때 부모님이 나에게 코딩학원을 가보라고 했었다. 나는 그때 코딩이 뭔지도 몰랐기에 컴퓨터를 할수 있다는것에 들떠서 바로 가자고 했던거 같다. 이때부터 나의 코딩의 시작이다.

코딩을 하면서

막상 코딩 학원에 갔을때는 모든것이 새로웠고 신기했다. 컴퓨터를 할수 있는 학원이 있다는것에 놀랐었던것 같다. 코딩 학원에 흥미를 가지게 된 뒤부터 나는 코딩학원을 다녔다. 하지만 나는 코딩이란것을 영화에서 나오는 해커처럼 뭔가가 실행되고 코드를 보면서 엔터를 치면 무언가가 엑세스 되고 이런것을 코딩이라고 생각을 했다. 하지만 현실은 달랐다. 처음에는 아두이노를 가지고 블록코딩을 했었다. 블록코딩은 내가 상상했던 것과는 완전히 다른것이였고 그다지 흥미를 느끼지 못했다.

나의 막연했던 과거

나는 그런 블록코딩의 흥미를 느끼지 못해 수업시간에는 블록코딩을 배웠고 자율시간에는 내가 하고 싶은걸 하려고 했다. 나는 웹해킹 책을 무작성 사서 웹해킹을 공부했었다. 그때는 아무것도 모른상태에서 책을 읽고 해봤던 것이라 웹해킹에서 무언가가 터미널에서 명령어를 치면 실행되고 고급스러워 보이는 코드를 보면서 나는 해킹이라는것이 단순하게 재밌고 쉬운것이라는 막연한 생각을했었다.

코딩의 진짜로 들어온 계기

나는 그러한 해킹을 계속해서 아무것도 모른상태로 명령어만 치면서 실행되는걸 보면서 즐겼던거 같다. 그러면서 학원에 자율시간에만 집중을했고 수업시간에는 집중을 하지 않게 되었다. 그러한 생활이 거의 1년을 다다를 때쯤 학원에 새로운 선생님이 왔다는것을 봤다. 그때가 올해 3월이고 그때부터 그 선생님이랑 대화를 많이 했었다. 그 선생님은 게임 스타트업 회사 팀장자리까지 갔다가 학생들에게 코딩을 알려주고 싶어서 코딩 선생님을 하게 됬다고 한다. 선생님이랑 계속해서 얘기를 하면서 나의 벽이 점점느껴지게 되었다 웹해킹이라는것이 얼마나 어려운지 진짜 개발이 뭔지를 느끼게 되었던 나의 터닝 포인트였던거 같다. 그때부터 나는 진짜 코딩을 해보겠다는 결심을 하게 되었다.

갑작스러운 시작

나는 그 선생님을 만나고부터 내가 무엇을 해야하는지 찾게 되었던거 같다. 그러한 나의 적성에 맞는 분야를 찾아보니 javascript, html, css를 접하게 되었다. 지금까지의 내가 배웠던 c언어는 콘솔에 무언가를 찍히는것이였지만 html은 내가 태그를 넣고 내용을 넣으면 웹사이트 형식으로 텍스트가 찍히고 실행결과가 바로 내눈으로 볼수 있는것에대한 나는 매우 흥미를 느꼈던것같다. 그때부터 나는 점점 웹이라는 세계에 빠져들었던것같다.

내가 느꼈던 점

나는 웹쪽을 하게 되면서 정말많은것을 느꼈고 정말 빠르게 성장하였다. 만약 나는 그 선생님이 없었더라면 지금의 나는 코딩을 하고 있지 않았을수도 있다. 난 하루하루에 대한 정말 많은 감사를 해야겠다는 생각을 하게 되었다. 지금은 웹을시작한지 5개월 정도가 되었다. 현재는 Node.js를 이용한 backend 개발과, 딥러닝(CNN, RNN), 네트워크 통신을 공부하고 있다. 내가 보기에도 정말 빠르게 성장한것 같아서 기분이 좋았던것같다.

이제 코딩을 시작하는 내 친구들에게

나는 위에 설명한 정말 많은 상황을 겪고 코딩을 본격적으로 하게됨으로써 내가 느꼈던점을 이제 코딩을 시작하는 친구들에게 나와 비슷한 상황이 일어나지 않도록 말해주려고 한다.

수학을 하지 않아도 개발자를 할수 있다.

나도 위와같은 생각을 예전에 했었다. 수학을 하지 않아도 물론 코딩을 시작할수 있다. 하지만 내가 장담할수 있는것은 수학을 모르면 결코 내가 원하는 시스템을 만들 수 없다. 나는 인공지능을 이제 공부를 하고 있으며 내가 인공지능을 공부하면서 내가 왜 수학을 하지 않았을까라는 생각을 너무 많이하게 된다. 웹을 처음 시작할때는 수학을 하지 않아도 됬다. 그 때까지만 해도 나는 수학이 필요없다고 생각했었다. 하지만 점점 깊게 파고 네트워크, socket 통신쪽으로 들어가다 보면 정말많이 수학이 들어간다. 나는 현재 수학을 잘하지 못해서 그러한 파트를 이해하지 못하고 있다. 또한 인공지능에서는 정말 모든것이 수학이다. 특히 CNN, RNN 딥러닝 파트에서 정말 많이 수학의 필요성을 느꼈다. 자세하게 설명하기는 어렵지만 확실한것은 내 프로젝트를 만들때는 수학이 필요하다. 수학을 하지 않으면 양산형 개발자가 될 확률이 높으며 진정한 내 프로젝트나 시스템을 설계할수 없다. 수학을 모르면 다른 대형 프로젝트나 시스템을 구현할수 없으며 많은 힘든과정을 거칠수 있다. 땅을 치고 후회하기전에 수학을 시작했으면 좋겠다.

오픈소스를 사용하는것에 대한 두려움

내가 개발하면서 한편으로 오픈소스를 사용하는것에 대해 불편한 마음을 느꼈다. 지금도 오픈소스는 남이 만든것이니 사용하면 안된다는 생각을 하지 말자. 나는 오픈소스라는것이 없었더라면 개발분야가 이렇게 빠르게 성장할수 없었을것같다. 다른 사람들이 만든 소스를 가져다가 분석하면서 점차 수정하는과정을 거쳐가게 된다면 오픈소스는 나만의 고유한 코드가 될 수 있다. 그러니 오픈소스의 두려운 생각을 하지 말자. 하지만 명심해야될것은 오픈소스를 분석하지않고 그냥 가져다가 쓰기만 한다면 그것은 절대로 나만의 코드가 될수 없다. 오픈소스의 장점은 오픈소스를 사용하면 대한 소스를 이해하면서 나만의 방식으로 코드를 수정을 해나가면 더 많은 지식과 배경지식을 얻을수 있다.

오류을 해결하는 방법

나는 예전에 오류를 해결할때 오류가 나면 그 오류를 복사해서 해결하는 방법만 가져다가 썼었다. 물론 그렇게 하면 오류는 해결할수 있겠지만. 다음에 또 같은오류가 나게될시 해결방법을 알수없다. 따라서 오류가 나면 오류를 복사해서 그 오류에 대한 답을 찾는것이 아닌 오류가 왜 ** 발생했는지 **내가 무엇을 모르고 있는지 찾아봐야한다. 그렇게 점차 오류의 대한 발생원인을 따져가면서 찾다보면 오류에 대한 발생원인과 왜 발생했는지 내가 무엇을 잘못하고 있었는지 알수있다. 오류가 난다고 샷건만 치고 해결하지 않으려 들면 결코 오류를 해결할수 없다. 내 힘으로 스스로 오류를 찾아보고 해결하면 그보다 더 좋은 기분은 없다. 그 기분을 느끼게 된다면 점차 오류를 피하는것이 아닌 오류의 발생원인을 분석할수 있을것이다. 따라서 오류에 대한 정답만 찾는 방법은 피하도록하자. 모든 개발의 정답은 없다.

코딩을 즐기자.

내 친구들은 부모님의 권유로 코딩을 하는 친구가 많다. 하지만 그런 방식으로 코딩을 하게 된다면 코딩을 일로 생각할것이고 즐길수 없다. 그렇게 된다면 금방 포기하게 되고 결국에는 손을 놓을수밖에 없다. 나는 책에서 이런 글을 본적이 있다 "학생이 공부를 재미없다고 하는 이유는 놀이와 공부를 구분하기 때문이다. 공부와 과제는 일로 생각하고 놀이는 즐거운 것이라고 생각하기 때문에 공부가 재미없어 지는것이다." 나는 이 말이 너무 인상깊었다, 내가 지금까지 코딩을 일로 생각했다면 여가시간과 코딩하는시간을 구분했을것이다. 하지만 나는 여가시간에 침대에 누워있을때 자꾸만 코딩을 하고 싶어지고 개발을 하고 싶어진다. 이것은 나는 여가시간과 코딩을 구분하지 않고 있다는 것이기도 한다. 따라서 코딩을 일로 생각하면 그사람은 정해진 경계선에서 더이상 발전할수 없으리라 생각한다. 코딩을 일로 생각하지 않고 노력하고 즐기는사람은 경계선이 아닌 성장할수 있는 좋은 길이라 생각한다. 코딩을 즐겨보자.

책을 읽자.

나는 예전에 책을 무지하게 많이 샀다 하지만 정작 나는 책을 읽지 않았다. 책을 사서 개발에 대한 지식을 쌓는것은 매우 좋지만 책을 너무 많이 사고 정작 읽지않는것은 쓸대없는 낭비일것이다. 개발은 책을 보고 공부를 하는것이 아닌 직접 느끼고 경험을 쌓아야만 비로소 진짜를 느낄수 있다. 책은 하나의 지식을 쌓을수 있는 부분이고 책만 읽고 정작 프로젝트가 개발을하지 않는다면 그것은 지식만 많이 쌓이고 경험은 부족해지게 된다. 지금 내가 이러한 글을 쓸수 있는것도 전부 경험에서 나오는 것이다. 경험을 해보지 않으면 이러한 충고나 내 코딩인생을 이야기 할수없다. 그러니 책에만 의지하지말고 만들어보자 직접 느끼는것이 가장 좋은 성장방법이다.

협업을 해보자.

나는 학생이지만 초등학교 6학년때와 지금 현재 협업을 진행중에 있다. 회사나 다른 대기업에서는 나 개인만의 프로젝트도 중요하지만 면접때는 자신의 회사와 잘 맞는지를 먼저 판단하게 된다. 아무리 실력이 좋다고 해도 자신의 회사와 잘 맞지 않으면 결코 좋은 팀원이 되지 못한다. 자신이 하고싶은 것만 강조하지 말고 배려하면서 다같이 윈윈하는 커뮤니케이션 능력을 키워보자 나는 프로그래밍의 제 1덕목은 끈기라고 생각하고 제 2덕목은 협업이라고 생각한다. 협업능력이 없으면 팀원에게도 그리 좋은 팀원이 되지 못한다. 학생들을 대상으로 하는 해커톤이나, 다른 대회를 많이 나가서 협업 능력을 키워보자. 협업에 대한 경험은 절대 돈주고도 알려줄 수 없는 것이다. 내가 직접 겪어 보고 해결해야지만 비로소 경험이 쌓인다.

정리하며

나는 지금 개발자를 꿈꾸고 있는 내 친구들에게 또는 지금 코딩을 시작하려고 하는 내 친구들에게 이러한 조언을 하고 싶어서 글을 쓰게 되었다. 내가 이 글을 쓰게 된 이유는 이제 코딩을 시작하는 친구들에게 나와 같은 실수를 반복하지 않았으면 해서 이글을 쓰고 있다. 나도 아직 중학교 1학년 학생이고 이제 5개월밖에 웹쪽을 공부하지 않았지만 내가 그 5개월이라는 시간과 그 전의 나의 잘못된 생각을 정리하고 알려주고 싶었다. 정리하자면 모든지 실전이 중요하다. 직접 경험해보고 나만의 길을 개척해서 꼭 개발자의 꿈을 이룰수 있도록 응원한다.

https://github.com/jun0911-cmyk https://stackoverflow.com/users/16649272/jun0911-dev https://twitter.com/Jun0911D

오랜 만에 글을 쓰는 것 같습니다. 요즘 화상채팅 동작 원리가 궁금하기도 하고 한번 구현해보면 어떨까 해서 글을 쓰게 되었습니다. 또한 현재 공부중인 학생이므로 이 글이 혹시라도 잘못된 정보가 있더라면, 댓글로 잘못된 부분을 지적해주신다면 수정하겠습니다. 앞으로 잘못된 부분을 잘 지적해주셔서 제가 올바르게 성장이 할수 있게 도와주십시오.

Webrtc를 소개하게 된 이유

최근에 실시간 화상 통화를 개발할 일이 생겼는데 "어떻게 하면 쉽게 구현할수 있을까?" 라는 생각을 하게되었다. 그래서 이것저것 블로그와 구글링을 뒤적뒤적 해본뒤 WebRTC라는 API가 있는것을 알게 되었다.

WebRTC를 알게 된 후 WebRTC Documentation을 본격적으로 공부를 하기 시작했다. 일단 제가 네트워크 구조는 별로 접해본적이 없었는데 접하게 되어서 문서를 이해하는데 꾀나 많은 시간을 투자한 것 같았다 ㅜㅜ.

제가 문서를 다 이해한뒤 혹시라도 나중에 또 안만지다 보면 까먹을 것 같아서 블로그로 정리해놓으면 좋겠다라는 생각이 들어서 정리를 하게 됬다.

WebRTC 소개

WebRTC는 (Web Real Time Communications) 라는 뜻을 가지고 있다. 한마디로 정리해 보면 Web(브라우저) RTC(실시간 통신)이라는 뜻으로 웹 브라우저에서 데이터 교환, 실시간 통화, 등을 할수 있도록 해주는 기술이다.

WebRTC의 네트워크는 기본적으로 P2P(Peer To Peer)로 되어 있다. 상황에 따라서 SFU(Selective Forwording Unit)나 MCU(Multi-point Control Unit)를 사용할 수도 있다.

WebRTC의 통신 원리

사진 출처 WebRTC 기술은 P2P 네트워크 통신하는 것에 매우 최적화 되어 있다. WebRTC의 실시간 데이터 교환은 대체적으로 3가지 클래스에 의해서 일어난다.

MediaStream : 비디오 / 오디오 접근 권한부여 RTCPeerConnection : 네트워크 대역폭 관리 및 데이터 암호화 RTCDataChannel : 일반적인 P2P 통신

위와 같은 3가지의 객체를 통해서 실시간 데이터 교환을 이루며, RTCPeerConnection들이 적절하게 신호를 주고 받으면서 데이터 교환을 이루는 것을 Signaling (신호 전달 서버) (이)라고 한다.

또한 데이터가 P2P로 교환 되어야 하므로 2명의 유저가 데이터를 교환해야 한다. 데이터 교환을 요청하는 콜러(Caller)와 교환을 받는 콜리(Callee)에 의해서 2명의 유저의 실시간 데이터 교환이 일어난다.

STUN, TURN 서버

Stun서버와 Turn서버는 미디어를 교환할때 방화벽 뒤에 있거나 교환이 막혔을 때 임시 중개 서버 역할을 하는 서버이다.

비디오 / 오디오의 미디어를 교환할때 방화벽 뒤에 있어서 연결이 막히는 경우가 있다. 이런 현상을 방지하기 위해서 STUN 서버가 임시 서버로 2명의 미디어스트림을 공유해주는 역할을 한다.

TURN 서버는 다른 외부 노트북으나 다른 기기로 접속하여 테스트를 할때 외부로 접속한 기기의 비디오나 오디오가 검은화면으로 나오는 경우가 있다. 그럴때 TURN서버를 이용하여 접속통로를 열어주는 것이다. 또한 STUN 서버를 사용했는데도 불구하고 연결이 안될 때 TURN 서버로 열어주면 된다.

이렇게 미디어 스트림의 공유가 예기치 못하게 막혔을 때 임시서버로 미디어 스트림을 중개해주는 역할을 하는 서버가 바로 STUN과 TURN 서버의 역할이다.

STUN과 TRUN서버 통신 과정

사진 출처

SFU와 MCU와 P2P

앞서 말했듯이 WebRTC는 P2P와 통신에 최적화 되어있다. 하지만 여러명의 사용자가 접속 해야 할 상황이 생겼을때, P2P로 연결하면 서버에 과부하가 걸리거나 접속중인 사용자 PC에게 엄청난 과부하를 줄 수가 있다.

P2P (Peer To Peer)

P2P는 1:1 연결에 적합하다. 클라이언트간에 서로 1:1로 연결을 주고 받으면서 통신한다.

P2P 통신 방식

사진 출처 이런식으로 서로 간의 1:1 통신을 각자 연결해서 사용한다. 이런 P2P 네트워크는 보통 블록체인 기술에 많이 쓰는걸로 알고있다.

장점 쉽게 구현할 수 있다. 종간단 암호화가 가능하다. 서버의 비용이 들지 않는다.

단점 서버의 과부화가 걸릴 수 있다. 1:N 연결에 적합하지 않다.

따라서 1:N, M:N 통신에 최적화 되어있는 SFU와 MCU를 사용한다.

SFU (Selective Forwording Unit)

SFU는 1:N 연결에 최적화가 되어 있다. 중앙 서버를 두고 클라이언트를 1명씩 중개해주는 역할을 한다.

SFU 통신 방식

사진 출처 이런식으로 4명의 사용자가 있다고 가정하면 중앙서버를 두고 사용자를 받아서 한명씩 클라이언트를 중개해주는 역할을 한다.

장점 P2P 보다 트래픽이 적개 발생함. 대규모 통신연결에 적합. 상황에 따른 미디어의 품질을 바꿀 수 있다.

MCU (Multi-point Control Unit)

MCU는 M:N 연결에 최적화가 되어 있다. 중앙 서버를 두고 클라이언트를 묶어서 한번에 전달하는 방식이다.

MCU 통신 방식

사진 출처 SFU와는 다르게 클라이언트가 중앙서버로 들어오고 중앙서버는 들어온 클라이언트를 묶어서 한번에 전달해준다.

장점 클라이언트의 트래픽을 줄일 수 있다.

단점 관리가 어렵다. 서버의 자원을 많이 사용한다. 한번에 묶어서 보내야 하기 때문에 미디아 품질을 일일히 다 조정해서 보내야한다.

이처럼 상황에 따라서 네트워크 방식을 변경해야 할 때도 있다. 그런 상황이 오면 SFU나 MCU를 이용해서 네트워크 구조를 변경해야 한다.

Singaling 서버

Signaling 서버는 Signal(신호) ing(전달) 이라는 뜻을 가지고 있다. 따라서 Signaling 서버는 미디아 스트림이 통신할때 오고가는 신호를 중개해주는 역할이다. 한마디로 Singaling 서버는 미디아 스트림의 신호 전달만 해주는 서버고, 별다른 처리를 하는 경우는 거의 없다. 보통 Signaling 서버는 Node.js의 Socket.io나 다른 Socket모듈로 구현 할수 있다. 사진 출처 이런식으로 2개의 Peer가 통신하기 위하여 신호를 전달해준다.

정리 하며

코로나 19로 밖에 나가지도 못하고 집에만 틀어박혀 있는 상황이 생겼다. WebRTC를 공부하면서 그런 시간이 훌쩍 지나가버린 것 같다. 또한 WebRTC를 이렇게 정리를 해놔서 나중에 가도 쉽게 까먹지는 않을 것 같다. 이제 더 열심히 공부하여 WebRTC를 열심히 알아놔야 겠다는 생각이 들었다. 이 글을 읽는 분들도 이 글을 읽고 WebRTC가 조금이라도 더 정리가 되었으면 한다. 더 자세한 내용을 알고 싶고 공부하고 싶다면은 아래의 WebRTC 공식 문서를 참고 하길 바란다.

WebRTC 공식 문서

이상으로 WebRTC 정리를 마치겠다.

현재 공부중인 학생이므로 이 글이 혹시라도 잘못된 정보가 있더라면, 댓글로 잘못된 부분을 지적해주신다면 수정하겠습니다. 앞으로 잘못된 부분을 잘 지적해주셔서 제가 올바르게 성장이 할수 있게 도와주십시오.

소개

전에 MVC 디자인패턴에 대해서 정리를 했었다. 이번에는 MVVM 이라는 디자인 패턴에 대해서 정리를 해보려고 한다. MVC 패턴을 모른다면 여기를 클릭하여 보기를 바란다.

MVVM 디자인 패턴이란?

일단 MVVVM 디자인패턴은 대표적으로 Vue.js 에서 많이 사용하는 디자인 패턴이다. MVVM 패턴은 디자인패턴에 포함된다. MVVM 패턴의 요소는 아래와 같이 되어 있다. Model : 모델 View : 뷰 View Model : 뷰 모델 사진 출처

해당 패턴을 이해하려면 위의 3가지 요소의 관계를 알아야 한다. MVC 패턴을 알고 있다면 뷰와, 모델은 알고 있을 것이다. 하지만 MVC 패턴을 알고 있는 유저는 뷰 모델은 생소할것이다.

뷰 모델과 모델이 뷰로부터 독립적인 형태를 만들어서, 위에서 말한 UI로부터 비즈니스 로직과 프레젠테이션 로직을 분리하려는 목적을 해결할수 있게 된 것이다.

View의 정의

MVC 패턴의 글을 아직 읽지않았을수도 있어서 한번 더 설명을 하도록 한다. 뷰는 한마디로 페이지이다. 사이트 접속자가 접속했을때에 보이는 레이아웃, UI, 애니메이션 등을 정의 하는 것이다. 따라서 사이트 접속자가 접속했을때의 보이는 화면, 페이지, 등을 전체적으로 담당하는 것이다. View는 위와 같은것을 담당하므로 비즈니스 로직을 절대로 포함하지 말아야 한다.

Model의 정의

MVC 패턴의 글을 아직 읽지않았을수도 있어서 한번 더 설명을 하도록 한다. Model은 해당 어플리케이션이 어떤것을 할건지를 정의한다. 내부적인 비즈니스 로직을 처리하기 위한 역할을 할 것이다.

처리되는 알고리즘, 처음에서의 상속, CRUD작업등이 예시다.

View Model의 정의

뷰 모델을 들어보지 못했을 수도 있다. 뷰 모델이란 뷰에서 사용할 메서드나 필드를 구현해주며 뷰한태 상태의 변화를 알려주는 역할을 담당하고 처리한다. 뷰 모델에서는 뷰에서 사용할 메서드와 필드가 UI 페이지에서 제공해줄 전체적인 기능을 정의한다, 뷰는 이 기능을 어떤식으로 보여줄지를 최종적으로 결정을 한다.

일반적으로 뷰 모델과 모델은 일대다 관계를 형성한다. 뷰 모델은 뷰가 쉽게 기능을 사용할 수 있도록 모델에 있는 데이터를 가공해서 뷰에게 기능을 제공한다.

뷰 모델에서 두 모델의 데이터를 가공하고 뷰에서는 오직 UI만 다루도록 해야 한다.

MVVM 디자인 패턴을 사용해야 하는 이유

MVC 패턴의 사용이유가 비슷하다. MVVM 패턴을 사용하면 유지보수, 확장성, 유연성 이 증가한다. 또한 중복으로 코딩을 해야하는 문제점도 사라질 것이다.

MVVM 패턴의 장점

1. 뷰 모델이 모델과 뷰 사이의 어댑터로서 변경이 생겼을 때 변경을 최소화할 수 있다.
2. 모델과 뷰 모델이 뷰로부터 독립적이다.
3. 뷰 모델과 모델을 플랫폼 독립적으로 개발할 수 있다.
4. 테스트하기 쉽다.
5. 개발 기간 동안 개발자와 디자이너가 동시에 독립적으로(병렬적으로) 작업할 수 있다.
6. UI 디자인이 나오지 않았더라도 미리 정의된 모델과 뷰 모델을 먼저 개발할 수 있기 때문에 병렬적인 업무 프로세스가 가능하다.

MVVM 패턴의 단점

1. 거대하고 복잡한 앱을 위해서 고안된 디자인 패턴인 만큼, 소형 앱에서 사용하게 되면 오버헤드가 커진다.
2. 앱이 너무 거대해지면 앱의 메모리 소모가 데이터 바인딩때문에 커진다.

MVVM 패턴을 사용해야 하는 이유

소형의 프로젝트나 개발을 진행할때에는 디자인 패턴을 사용하지 않아도 그리 문제가 되지 않을 것이다, 하지만 중형에서 대형의 프로젝트를 진행할때에는 더욱 효율적이게 디자인을 만들어야 할 것이다, 따라서 디자인 패턴을 사용하여 더욱 효율적이게 프로그래밍을 해야할 것이다.

정리하며

MVVM 패턴은 상환에 맞게 써아한다. 디자인 패턴은 다양하므로 상황에 맞는 디자인 패턴을 써야 할 것이다. MVVM의 장점과 단점을 잘 고려해서 사용을 하야한다. 따라서 장점과 단점을 잘 확인하며 써야 할 것이다.

참고한 글 출처

현재 공부중인 학생이므로 이 글이 혹시라도 잘못된 정보가 있더라면, 댓글로 잘못된 부분을 지적해주신다면 수정하겠습니다. 앞으로 잘못된 부분을 잘 지적해주셔서 제가 올바르게 성장이 할수 있게 도와주십시오.

MVC가 무엇일까?

MVC패턴이 도저히 무엇인지를 모르겠는데 사람들이 MVC 패턴을 그렇게 얘기를 계속 하여서 궁금해서 검색을 해 보았다. 나 자신과 비슷한 분들이 있을 수 있을것 같아, 이 글을 쓴다. 본 글은 다른 외부의 글을 전부 읽어보며 나 자신만의 방식으로 정리를 한 글이다.

MVC패턴이란?

Model MVC 는 Model, View, Controller의 약자 이며 하나의 애플리케이션, 프로젝트를 구성할 때 그 구성요소를 3가지의 역할로 구분한 디자인패턴이다. 사용자가 컨트롤러를 조작하면 컨트롤러는 모델을 통해서 데이터를 가져오고 그 정보를 바탕으로 시각적인 표현을 담당하는 뷰를 제어해서 사용자에게 띄우게 된다. 사진자료 출처링크

Model의 정리 Model은 해당 어플리케이션이 어떤것을 할건지를 정의한다. 내부적인 비즈니스 로직을 처리하기 위한 역할을 할 것이다.

처리되는 알고리즘, 처음에서의 상속, CRUD작업등이 예시다.

컨트롤러(controller)의 정의 컨트롤러란 모델이 어떻게 처리하지를 알려주는 역할을 담당 할 것이다. 모바일에서는 화면의 로직을 처리하는 부분이다. 화면에서 사용자의 요청을 받아 처리되는 부분을 구현한다. 요청내용을 분석하여 Model과 View에 UPDATE(업데이트) 요청을 하게 될 것이다.

간단하게는 사용자로부터 입력을 받고 Model또는 View를 중개하는 것이다.

View의 정의 View는 화면에 무엇인지를 보여주기 위한 역할을 주로 담당한다.(페이지) 컨트롤러중 가장 하위에 종속되며, 모델이나 컨트롤러가 보여주려고 하는 모든 필요한 페이지를 화면에 로딩시켜 보여줄 것이다.

간단하게는 최종사용자에게 무엇을 UI로 보여준다.

또한 컨트롤러는 Model과 View가 각각 무엇을 해야 하는지를 알고있고 통제하는 역할을 담당하기도 한다. 비즈니스 로직을 처리하는 Model과 UI가 서로 직접 말을 할 수 없게 한다. 또한 컨트롤러는 View와 Model를 서로를 연결해주는 역할을 한다.

MVC패턴의 한계

MVC에서 View는 컨트롤러에 연결되어 화면을 구성하는 단위요소이므로 다수의 View들을 가질 수 있다. 또한 Model은 컨트롤러를 통해서 View와 연결되어지지만, 이렇게 컨트롤러를 통해서 하나의 View에 연결 될 수 있는 모델도 마찬가지로 여러개가 될수 있을 것이다.

View와 모델은 서로 의존성을 띄게 된다.

화면에 복잡한 화면과 데이터의 구성이 필요한 화면일시 컨트롤러에 다수의 모델과 뷰가 복잡하게 연결되어 있는 상황이 생길수가 있다.

Massive View Controller

MVC가 너무 복잡하고 비대해져서, 새 기능을 계속 추가 할 때마다 크고 작은 문제점을 가지고 소스 분석이나, 테스트가 많이 어려울 것이다. 이런 형태의 MVC패턴을 Massive View Controller(대규모의 MVC패턴형식의 애플리케이션) 이라고 부른다. 사진자료 출처링크 MVC의 최대 한계를 표현한 용어 같다.

컨트롤러는 뷰와 라이프 사이클과 강하게 연결되어 있는 관계여서 분리 할 수도 없다. 또한, 코드 분석/수정을 할때 테스트가 모두 힘들어 질 것이다. 그리고 복잡하게 엮어있는 모델과 뷰는 여러 사이드이펙트를 불러와서 프로그램을 운영하기 힘들게 할 것이다.

이런 문제점을 보완하기 위하여 아주 다양한 패턴을 파생시킨 것이다.

( MVP, MVVM, Viper, Clean Architecture, Flux, Redux, RxMVVM 등등

우리는 왜 MVC패턴을 사용해야 하는 것일까?

사용자가 보는 페이지와 데이터처리 그리고 그것을 제어하는 컨트롤 이 3가지로 구성되는 하나의 애플리케이션을 만들면 각각 맡은바에만 집중을 할수 있게 될것이다. 실제 업무에서도 여러 업무를 한 사람이서 처리를 하게 되면 왔다 갔다 할 것이고 잦은 실수도 발생할 것이다. 실제업무에서도 마찬가지로 업무를 분리하여 진행하면 실수도 잦고, 또한 더 일의 능률이나 집중력이 그쪽으로 쏠릴 것이다

서로 분리되어 각자의 담당 역할의 집중을 할수 있게끔하여서 처리를 하고 그러한 로직을 만든다면, 유지보수, 확장성, 유연성이 증가할 것이다 또한 중복으로 코딩을 해야하는 문제점도 바로 사라지게 될 것이다. 사진자료 출처링크

MVC패턴의 의의

MVC패턴은 결과적으로는 "어떻게 나눌 것인가?" 에 대한 답중 하나이다. 어떤 특정한 역할들에 대해 역할분담을 진행할때 하나의 가이드라인을 제시하는 방법중에 하나인 것이 바로 MVC패턴인 것이다. 또한 이 패턴을 사용한 라이브러리, 프레임워크 등으로 코딩을 한다면 더 쉽고 빠리고 재밌는 코딩을 할수 있으며 정말 효율적인 로직이 만들어 질 것이다. 하지만 우리는 그러한 라이브러리와 프레임워크를 만들고 사용할 수 있는 실력또한 우리가 공부를 해야 할 업무중의 하나일 것이다.

MVC패턴의 간단한 이해

A와 B와 모델의 C가 있다고 가정해보자. 만약 우리가 어떠한 특정 로직을 수정한다고 하였을때 모델인 C만 수정하면 될 것이다. 하지만 만약 A,B,C가 분리되어 있지 않으면 어떨것인가? 그렇다면 A와 B를 전부 수정해야 할 것이다. 만약 이렇게 처리를 한다고 하면 비효율적이며 상당한 비용과 시간이 들 것이라 생각한다. 이러한 일을 막기 위해 우리는 MVC패턴이라는 것으로 각각의 부분을 나눠서 처리하는 것이다. 따라서 MVC를 쓴다면 더욱 효율적이며 보다 빠르게 처리할 수 있을 것이다.

간단한 정리

View에서 특정 이벤트를 수행했을 경우에는 컨트롤러에서 이벤트에 해당하는 Method를 Model로 보낼 시 Model에서 처리하여 결과를 가져온뒤 그 처리결과를 서버에다가 적용시키는 것이다.

참고한 글 출처 글을 올린 날짜 : 2021년 04월 06일 화요일