몇 가지 코멘트 남깁니다. * 이번 영상의 핵심은 byte-stream protocol과 message-oriented protocol의 차이를 이해하는 것입니다. TCP가 byte-stream protocol을 기반으로 어떻게 reliable하게 동작하는지는 추후 영상들을 통해서 설명드릴 예정입니다. * 01:25 UDP header + payload 라고도 표현할 수 있습니다. (마찬가지로 09:01 에서도 TCP header + payload 라고 표현할 수 있습니다) * 03:23 sendto는 TCP에서도 쓸 수 있습니다만 주로 UDP에서 사용되는 시스템콜입니다. * 09:01 TCP segment의 TCP header를 보면 TCP가 reliable하게 동작할 수 있도록 하는 필드들이 많이 있음을 알 수 있습니다. * 09:51 '나이브하다'는 느슨하다는 의미로 사용했습니다. * 10:33 유실되거나 손상되는 일이 일어나지 않을거라는 의미는 전혀 유실되거나 손상되지 않는다는 의미가 아니라 유실이 되거나 손상이 됐을 때도 TCP는 다시 재전송 하는 기능이 있어서 결과적으로는 유실되거나 손상되지 않는다는 의미입니다. * 12:11 실제로 테스트를 해보면 한번에 메시지를 읽을 수도 있고, 두번이나 세번에 걸쳐서 읽을 수도 있습니다. 이유는 앞에서 말씀드렸던 것처럼 TCP 스펙에서는 바이트들을 어떻게 TCP segment에 담아서 전송해야할지는 편의에 따라 구현하도록 했기 때문에 OS에서 어떻게 구현했는지에 따라서는 약간의 차이가 있을 수 있습니다. * 12:18 최대 1KB의 데이터를 한번에 읽겠다는 의미입니다. 만약 1KB 보다 적게 쌓여있다면 쌓여있는 만큼 읽게 됩니다. * 설명을 위해 TCP, UDP를 예제로 사용했는데 혹시 이걸보고 transport layer에 국한된 개념으로 byte-stream protocol이나 message-oriented protocol 을 이해하실 필요는 없습니다. 이 두 개념들은 특정 레이어에 소속된 개념이 아니라 프로토콜의 데이터 전송 방식에 따라 분류될 수 있는 카테고리 개념으로 이해해 주시면 될 것 같아요.
와 아직 내용을 다 이해하지는 못했지만! 이번 프로젝트에서 TCP통신을 다루려니 어려웠는데 15:50 부분을 듣고 아 메세지를 구분하기위해 메세지 사이즈를 먼저 보내고 header와 payload byte 크기도 나눠둔 것이 이해되었어요. 정말 많은 도움이 많이 되었습니다!
MSS는 1440, MTU는 1500이라고 기계적으로 외우고 있던것들을 이렇게 강의로 들으니 훨씬 더 깊게 이해할 수 있게 된 것 같습니다. 쉬운코드님 강의 2~3번 돌려 듣던 제자로서 돌아오신것이 너무나도 반갑습니다! (덕분에 성공적으로 이직도 했었답니다) 혹시 인프런 멘토링도 재개하시는지 궁금합니다! (온라인으로라도 좋으니 꼭 한 번 컨텍해보고 싶었는데 23년 5월까지 한다고 하셔서 너무 슬펐어요 ㅠㅠ)
크~!! 영상 유익하게 봐주셔서 넘 감사해요 :) 2~3번 돌려보실 정도였다니!! 넘 감사합니다!! 그리고 이직도 넘넘 축하드립니다!!! 준비하시느라 고생많으셨을텐데 새 직장에서 훨훨 날아오르시길요! ❤️ 멘토링은 제가 지금 육아도 해야하고 하다보니 잠시 닫아두었는데요, 내년 초에 다시 열게 되면 여기 댓글에 잊지 않고 달아놓겠습니다! 혹시 제가 까먹더라도 커뮤니티에도 다시 공지 할 예정이니 공지도 참고 부탁드려요~!
강연자 공개를 안 했기 때문에 생길 수 있는 권위부재에서 오는 정보 신뢰성에 대한 부분? 같은 부분만 빼면 너무 컨텐츠가 좋네요. 국내외 자료 안가리고 '쉽게' 가르친다는 자료 많이 봤는데 헷갈릴 것 같은거 속 시원히 긁어주는게 대단하네요. 강연자님의 삽질과 노고가 보이는 느낌입니다
크!!! 칭찬의 말씀 너무너무 감사드립니다!! 뿌듯하네요 :) 알아봐주셔서 다시 한번 감사드립니다 ❤ 그리고 너무나 중요한 포인트를 말씀주셨어요~ TIM이지만 사실 제가 유튭을 본격적으로 시작할 때, 다른 어떤 백그라운드 소개 없이 저의 강의 메시지만으로 인정을 받는 것이 목표 중에 하나였습니다. '정말 좋은 메시지, 정말 좋은 설명은 누가 말했는지는 중요하지 않다'는게 제가 가지고 있던 신념이었어서, 유튭 시작하면서 이 신념 하에 저 자신을 테스트해보고 싶었었어요. 써주신 댓글 보면서 저의 첫 마음이 떠올라서 남겨봤습니다ㅎㅎ
@@ezcdMSS보다 큰 메시지를 보내게 되면 TCP 레벨에서 세그먼트들로 나누어 보내지는 것은 이해했습니다. 이와는 다르게 송신자가 작은 메시지를 여러 개 보낼 때 TCP 세그먼트로 병합되어서 보내는 경우가 있는지 궁금하고 그렇게 보낸다면 어떤 알고리즘으로 병합하는지 궁금했습니다.
@@심영인-w4l 넵, 간단하게 설명드리자면, TCP 레벨에서 하나의 세그먼트 안에 여러 메시지들이 한번에 보내지는 경우도 있습니다. 예제도 이미 그런 예제로 설명을 했었구요. 어떤 경우에 여러 메시지들이 하나의 세그먼트에 담겨서 가는지는 OS 레벨에서 어떻게 구현되는지에 따라 차이가 있겠지만, 공통적으로는 Nagle 알고리즘이라는 것을 사용하고 있습니다.
보통은 이렇게 바로 답글을 달진 않습니다만 이번 내용 자체가 좀 심오하기도 하고 매우 중요한 질문을 해주신 것 같아서, 그리고 다른 분들도 비슷한 질문을 하실 것 같아서 빠르게 답변 남겨봅니다. 두괄식으로 말씀드리자면 앞으로 올라올 영상들을 통해서 TCP가 어떻게 reliable하게 동작하는지 설명드릴 예정입니다. 덧붙여 조금 더 추가 설명 드리면, 영상의 질문1에서 설명드린 것처럼, byte-stream protocol은 메시지의 단위를 구분하지 않고 그저 byte들의 흐름으로만 전달하는 프로토콜을 의미합니다. 그래서 이 프로토콜은 reliable한 것과 전혀 상관이 없습니다. (혹시 이 부분이 헷갈리시는 포인트일까 싶어서 다시 한번 언급하게 됐습니다.) TCP를 reliable하게 동작하게 만드는 개념들을 보면 sequence number나 ack number, window 등의 개념들이 있는데, 이 개념들은 데이터를 byte들의 흐름으로 인식하는 배경 하에서 동작하는 개념들입니다. 사실 이 부분은 곱씹어볼수록 심오한 부분이라 사람마다 어쩌면 생각이 다를 수도 있겠지만, 적어도 저는 어느 정도 확신을 가지는 것이, 그 당시 TCP를 설계한 설계자들은 reliable한 transport layer protocol을 정의하기 위해서는 byte-stream protocol 기반으로 설계하는 것이 더 유리(?)하다고 판단했던 것 같 니다. 여하튼 앞으로 TCP가 어떻게 reliable하게 동작하는지는 추후 영상들로 차근차근 설명드리도록 하겠습니다. 이번 영상에서는 byte-stream protocol과 message-oriented protocol의 차이에 대해서 집중만 해주시고 이해만 해주셔도 충분할 것 같습니다. 끝으로 여담이지만, 영상들을 준비하면서 저도 다시 한번 네트워크를 정리하는 중인데, 파면 팔수록 네트워크는 상당히 심오한 영역인 것 같습니다.
우선 제가 백엔드 개발자라 백엔드 관점에서 본다면, 개발자를 완전히 대체하진 못한다고 봅니다. 전체 아키텍처나 비즈니스 스펙을 다 잘 이해하고 구현하기는 아직 어렵다고 보고 있고요, 많이 좋아지고 있지만 여전히 할루시네이션 이슈가 있는데 결국 할루시네이션에 속아 넘어가지 않고 개발하려면 어느 정도 잘 알고 있어야 한다고 봐서 앞으로도 일자리를 심각하게 위협하지는 않을 것 같다고 생각합니다. 다만 1. AI의 등장으로 개발자에게 더 높은 퀄리티를 요구하게 될 것 같고 2. 시장에서는 AI를 잘 써서 더 좋은 퍼포먼스를 내는 개발자를 선호할 것 같고, 3. 1과 2의 이유로 인해 실력있는 시니어 개발자는 더 몸 값이 오를 것 같지만 반면 주니어 개발자나 신입 개발자에게는 더 큰 허들이 생기지 않을까 이 부분을 좀 염려를 하고 있습니다 ㅠ 어떻게 보면 쉬운코드의 역할 중에 하나가 고퀄리티의 영상들을 통해 신입과 주니어 개발자들이 보다 더 빠르게 시니어 개발자로 성장할 수 있도록 돕는 것 아닐까 라는 생각도 해봅니다.
오 네네 그런 느낌으로 이해해주셔도 될 것 같네요~ :) 다만 메시지큐는 FIFO 아웃 느낌이라 순서 보장이 되는 느낌이지만 message-oriented protocol은 순서보장이 되는지 여부와는 전혀 상관 없는 별개의 개념이라 약간의 차이가 있을 것 같습니다. 참고로 byte-stream protocol도 무조건 순서를 보장하는지와는 상관 없는 개념으로 이해하는게 더 적절할 것 같아요. byte-stream protocol을 쓰되 그 protocol이 순서를 완전히 보장하도록 만드는 것은 추가적으로 설계를 어떻게 하느냐에 따라 달라질 수 있을 것 같습니다
![[2부-실제편] 표준과 일부 다르게 동작하는 소켓(Socket), 포트(Port)의 실제 개념을 소개합니다! 특히 소켓 식별 방식을 유심히 봐주세요!](http://i.ytimg.com/vi/WwseO8l8rZc/mqdefault.jpg)
몇 가지 코멘트 남깁니다.
* 이번 영상의 핵심은 byte-stream protocol과 message-oriented protocol의 차이를 이해하는 것입니다. TCP가 byte-stream protocol을 기반으로 어떻게 reliable하게 동작하는지는 추후 영상들을 통해서 설명드릴 예정입니다.
* 01:25 UDP header + payload 라고도 표현할 수 있습니다. (마찬가지로 09:01 에서도 TCP header + payload 라고 표현할 수 있습니다)
* 03:23 sendto는 TCP에서도 쓸 수 있습니다만 주로 UDP에서 사용되는 시스템콜입니다.
* 09:01 TCP segment의 TCP header를 보면 TCP가 reliable하게 동작할 수 있도록 하는 필드들이 많이 있음을 알 수 있습니다.
* 09:51 '나이브하다'는 느슨하다는 의미로 사용했습니다.
* 10:33 유실되거나 손상되는 일이 일어나지 않을거라는 의미는 전혀 유실되거나 손상되지 않는다는 의미가 아니라 유실이 되거나 손상이 됐을 때도 TCP는 다시 재전송 하는 기능이 있어서 결과적으로는 유실되거나 손상되지 않는다는 의미입니다.
* 12:11 실제로 테스트를 해보면 한번에 메시지를 읽을 수도 있고, 두번이나 세번에 걸쳐서 읽을 수도 있습니다. 이유는 앞에서 말씀드렸던 것처럼 TCP 스펙에서는 바이트들을 어떻게 TCP segment에 담아서 전송해야할지는 편의에 따라 구현하도록 했기 때문에 OS에서 어떻게 구현했는지에 따라서는 약간의 차이가 있을 수 있습니다.
* 12:18 최대 1KB의 데이터를 한번에 읽겠다는 의미입니다. 만약 1KB 보다 적게 쌓여있다면 쌓여있는 만큼 읽게 됩니다.
* 설명을 위해 TCP, UDP를 예제로 사용했는데 혹시 이걸보고 transport layer에 국한된 개념으로 byte-stream protocol이나 message-oriented protocol 을 이해하실 필요는 없습니다. 이 두 개념들은 특정 레이어에 소속된 개념이 아니라 프로토콜의 데이터 전송 방식에 따라 분류될 수 있는 카테고리 개념으로 이해해 주시면 될 것 같아요.
와 아직 내용을 다 이해하지는 못했지만! 이번 프로젝트에서 TCP통신을 다루려니 어려웠는데 15:50 부분을 듣고 아 메세지를 구분하기위해 메세지 사이즈를 먼저 보내고 header와 payload byte 크기도 나눠둔 것이 이해되었어요. 정말 많은 도움이 많이 되었습니다!
오 현업에서 TCP를 직접 쓸일이 잘 없는데 어떻게 보면 특별한 경험을 하고 계시는군요 👍
도움을 드릴 수 있어서 뿌듯합니다 ㅎㅎ 오늘도 시청해주셔서 감사합니다 :)
복귀하셨군요.
순간 눈을 의심했습니다
지식공유 재개해주셔서 너무너무 감사해요
헤헿 환영해주셔서 넘넘 감사합니다 :) 앞으로도 열심히 파이팅해볼게요!
크흐...2024년 뒤숭숭한 가운데 희소식 be back! 늦은 나이 그냥 즐겨보고있습니다. 가정 좋은일 가득하세요~
히히 반갑게 맞아주셔서 감사합니다 :) 2025년 새해 복 많이 받으세요~!
헉… 돌아오신 줄 몰랐어요… 돌아와주셔서 감사해요❤
환영해주셔서 감사합니다 ❤
MSS는 1440, MTU는 1500이라고 기계적으로 외우고 있던것들을 이렇게 강의로 들으니 훨씬 더 깊게 이해할 수 있게 된 것 같습니다.
쉬운코드님 강의 2~3번 돌려 듣던 제자로서 돌아오신것이 너무나도 반갑습니다! (덕분에 성공적으로 이직도 했었답니다)
혹시 인프런 멘토링도 재개하시는지 궁금합니다! (온라인으로라도 좋으니 꼭 한 번 컨텍해보고 싶었는데 23년 5월까지 한다고 하셔서 너무 슬펐어요 ㅠㅠ)
크~!! 영상 유익하게 봐주셔서 넘 감사해요 :) 2~3번 돌려보실 정도였다니!! 넘 감사합니다!!
그리고 이직도 넘넘 축하드립니다!!! 준비하시느라 고생많으셨을텐데 새 직장에서 훨훨 날아오르시길요! ❤️
멘토링은 제가 지금 육아도 해야하고 하다보니 잠시 닫아두었는데요, 내년 초에 다시 열게 되면 여기 댓글에 잊지 않고 달아놓겠습니다!
혹시 제가 까먹더라도 커뮤니티에도 다시 공지 할 예정이니 공지도 참고 부탁드려요~!
@@ezcd
감사합니다! 한번도 뵌적은 없지만, 제 마음속에는 최고로 감사한 스승님들 중 한 분이십니다!
새해 복 많이 받으시고 항상 건강하세요!
@@엄윤섭-o4i 흐흐 넘 쑥쓰럽습니다!ㅎㅎ 윤섭님도 새해 복 많이 받으셔요~! 항상 행복과 기쁨이 가득하길 응원할게요 :)
쉬운코드님을 마음속 스승님으로 모시는 1인 추가입니다 ㅎㅎ top-down 책으로 공부중인데, 쉬운코드님 영상 보면서 파편적인 지식들이 스토리로 잘 엮여지는 것 같습니다😊 항상 감사합니다!
와 꿀잼이네요ㅋㅋㅋㅋ 학부때 대충 공부했던 퍼즐조각들이 이제서야 맞춰지는 느낌.. 허허
헤헿 재밌게 봐주셔서 넘 감사합니다 :)
강연자 공개를 안 했기 때문에 생길 수 있는 권위부재에서 오는 정보 신뢰성에 대한 부분? 같은 부분만 빼면 너무 컨텐츠가 좋네요.
국내외 자료 안가리고 '쉽게' 가르친다는 자료 많이 봤는데 헷갈릴 것 같은거 속 시원히 긁어주는게 대단하네요. 강연자님의 삽질과 노고가 보이는 느낌입니다
크!!! 칭찬의 말씀 너무너무 감사드립니다!! 뿌듯하네요 :) 알아봐주셔서 다시 한번 감사드립니다 ❤
그리고 너무나 중요한 포인트를 말씀주셨어요~ TIM이지만 사실 제가 유튭을 본격적으로 시작할 때, 다른 어떤 백그라운드 소개 없이 저의 강의 메시지만으로 인정을 받는 것이 목표 중에 하나였습니다. '정말 좋은 메시지, 정말 좋은 설명은 누가 말했는지는 중요하지 않다'는게 제가 가지고 있던 신념이었어서, 유튭 시작하면서 이 신념 하에 저 자신을 테스트해보고 싶었었어요. 써주신 댓글 보면서 저의 첫 마음이 떠올라서 남겨봤습니다ㅎㅎ
너무 반갑네요 지인들한테 가장 추천하는 유튜브였는데 영상 많이 기다리겠습니다
인프런강의같은걸로 수익도 더 챙기셧음 좋겟네요
우왕 ㅠㅠㅠ 좋게 봐주시고 주위에 가장 추천해주시는 채널로 꼽아주셔서 넘넘 감사해요 ❤️❤️❤️
언젠가는 인프런에서도 도전해보겠습니다!!ㅎㅎ :)
네트워크 영상 반복해서 시청하고 있습니다. 양질의 강의 감사드립니다!!
영상들을 좋게 봐주셔서 정말 정말 감사합니다 :)
내용과는 관계없는 질문이지만 혹시 아웃트로에 사용하는 사진들 어디서 구하시는 건가요? 다 제 취향이라...ㅋㅋ 영상 잘 보고 있습니다ㅎㅎ
앜ㅋㅋㅋ 저는 여기 무료 사이트에서 골라서 쓰고 있어요
pixabay.com/
격하게 감사합니다!!!
저도 시청해주셔서 격하게 감사합니다!!!
TCP 프로토콜 관련 질문 있습니다. 수신자가 여러 메시지가 병합된 세그먼트를 받기 위해서는 송신자가 여러 메시지를 병합하는 작업이 필요할 것입니다. Os 마다 구현이 다르겠지만 보통 어떤 알고리즘으로 병합하는지 궁금합니다.
오.. 약간 질문하신 내용이 제가 조금 헷갈리는데요, 혹시 14:55 에 설명드린 내용과는 다른 결의 질문인가요?
@@ezcdMSS보다 큰 메시지를 보내게 되면 TCP 레벨에서 세그먼트들로 나누어 보내지는 것은 이해했습니다. 이와는 다르게 송신자가 작은 메시지를 여러 개 보낼 때 TCP 세그먼트로 병합되어서 보내는 경우가 있는지 궁금하고 그렇게 보낸다면 어떤 알고리즘으로 병합하는지 궁금했습니다.
@@심영인-w4l 넵, 간단하게 설명드리자면, TCP 레벨에서 하나의 세그먼트 안에 여러 메시지들이 한번에 보내지는 경우도 있습니다. 예제도 이미 그런 예제로 설명을 했었구요. 어떤 경우에 여러 메시지들이 하나의 세그먼트에 담겨서 가는지는 OS 레벨에서 어떻게 구현되는지에 따라 차이가 있겠지만, 공통적으로는 Nagle 알고리즘이라는 것을 사용하고 있습니다.
@@ezcd 감사합니다. Nagle알고리즘에 대해 알아보겠습니다.
딱 궁금했던 게 올라왔네요
오오! 이 영상이 조금이라도 이해하시는데 도움이 될 수 있으면 좋겠네요 :)
그러면 어떻게 tcp는 신뢰성을 보장하게될까요?
바이트스트림으로 데이터형식을 한 것이 신뢰성을 보장하는 내용과 어떤 관계인지
어렵습니다
혹시 이후 영상에서 다룰까요?
보통은 이렇게 바로 답글을 달진 않습니다만 이번 내용 자체가 좀 심오하기도 하고 매우 중요한 질문을 해주신 것 같아서, 그리고 다른 분들도 비슷한 질문을 하실 것 같아서 빠르게 답변 남겨봅니다.
두괄식으로 말씀드리자면 앞으로 올라올 영상들을 통해서 TCP가 어떻게 reliable하게 동작하는지 설명드릴 예정입니다.
덧붙여 조금 더 추가 설명 드리면, 영상의 질문1에서 설명드린 것처럼, byte-stream protocol은 메시지의 단위를 구분하지 않고 그저 byte들의 흐름으로만 전달하는 프로토콜을 의미합니다. 그래서 이 프로토콜은 reliable한 것과 전혀 상관이 없습니다. (혹시 이 부분이 헷갈리시는 포인트일까 싶어서 다시 한번 언급하게 됐습니다.)
TCP를 reliable하게 동작하게 만드는 개념들을 보면 sequence number나 ack number, window 등의 개념들이 있는데, 이 개념들은 데이터를 byte들의 흐름으로 인식하는 배경 하에서 동작하는 개념들입니다. 사실 이 부분은 곱씹어볼수록 심오한 부분이라 사람마다 어쩌면 생각이 다를 수도 있겠지만, 적어도 저는 어느 정도 확신을 가지는 것이, 그 당시 TCP를 설계한 설계자들은 reliable한 transport layer protocol을 정의하기 위해서는 byte-stream protocol 기반으로 설계하는 것이 더 유리(?)하다고 판단했던 것 같 니다. 여하튼 앞으로 TCP가 어떻게 reliable하게 동작하는지는 추후 영상들로 차근차근 설명드리도록 하겠습니다.
이번 영상에서는 byte-stream protocol과 message-oriented protocol의 차이에 대해서 집중만 해주시고 이해만 해주셔도 충분할 것 같습니다.
끝으로 여담이지만, 영상들을 준비하면서 저도 다시 한번 네트워크를 정리하는 중인데, 파면 팔수록 네트워크는 상당히 심오한 영역인 것 같습니다.
@ 너무 감사합니다!
AI에 관한 견해도 궁금합니다. O3가 AGI에 근접했다는 평가가 있던데요.
이제 AI를 사용해야 하는 시기일뿐만 아니라 저희 일자리를 위협해서 걱정이 되네요.
우선 제가 백엔드 개발자라 백엔드 관점에서 본다면, 개발자를 완전히 대체하진 못한다고 봅니다. 전체 아키텍처나 비즈니스 스펙을 다 잘 이해하고 구현하기는 아직 어렵다고 보고 있고요, 많이 좋아지고 있지만 여전히 할루시네이션 이슈가 있는데 결국 할루시네이션에 속아 넘어가지 않고 개발하려면 어느 정도 잘 알고 있어야 한다고 봐서 앞으로도 일자리를 심각하게 위협하지는 않을 것 같다고 생각합니다.
다만
1. AI의 등장으로 개발자에게 더 높은 퀄리티를 요구하게 될 것 같고
2. 시장에서는 AI를 잘 써서 더 좋은 퍼포먼스를 내는 개발자를 선호할 것 같고,
3. 1과 2의 이유로 인해 실력있는 시니어 개발자는 더 몸 값이 오를 것 같지만 반면 주니어 개발자나 신입 개발자에게는 더 큰 허들이 생기지 않을까 이 부분을 좀 염려를 하고 있습니다 ㅠ
어떻게 보면 쉬운코드의 역할 중에 하나가 고퀄리티의 영상들을 통해 신입과 주니어 개발자들이 보다 더 빠르게 시니어 개발자로 성장할 수 있도록 돕는 것 아닐까 라는 생각도 해봅니다.
byte-stream protocol vs message-oriented protocol의 차이는 파이프와 메시지큐의 차이와 비슷한것 같은데 올바르게 이해한거 맞나요?
좋은 강의 감사합니다! :)
오 네네 그런 느낌으로 이해해주셔도 될 것 같네요~ :)
다만 메시지큐는 FIFO 아웃 느낌이라 순서 보장이 되는 느낌이지만 message-oriented protocol은 순서보장이 되는지 여부와는 전혀 상관 없는 별개의 개념이라 약간의 차이가 있을 것 같습니다.
참고로 byte-stream protocol도 무조건 순서를 보장하는지와는 상관 없는 개념으로 이해하는게 더 적절할 것 같아요. byte-stream protocol을 쓰되 그 protocol이 순서를 완전히 보장하도록 만드는 것은 추가적으로 설계를 어떻게 하느냐에 따라 달라질 수 있을 것 같습니다
@@ezcd 와 순서보장 여부까지는 생각을 못했는데,, 정말 감사합니다 !! 한마디 한마디가 도움이 되네요 :)
잘 봤습니다
시청해주셔서 감사합니다 :)