hwangsoojin 2025. 11. 15. 11:51

1주차 회고

작성일:2026.11.15
학습 주제:클라우드 기본 구조 / 계정·콘솔 사용 / VPC·Subnet·ACG / 서버 생성 및 SSH 접속 / 클라우드 특장점 / IP·Port·라우팅 이해
실습 환경:NCP Console + PuTTY
작성자:황수진_컴퓨터과학부


KEEP (유지할 점)

1) 안다고 생각했던 개념을 다시 점검한 태도

학부 전공 수업 덕분에 IP, Port, Subnet, DNS 같은 개념들은 익숙하다고 생각하고 있었다.
그런데 이번 주에는 이 개념들을 책이나 슬라이드가 아니라

실제 Naver Cloud Platform 콘솔에서 직접 다루게 되었다.

 

예를 들어 ACG의 Inbound, Outbound 규칙을 설정하면서
"이 규칙이 지금 정확히 어떤 트래픽을 허용하는 거지?"
라는 생각이 들자, 내가 알고 있다고 믿던 개념들이 갑자기 자신 없어졌다.

 

그래서 그냥 넘어가지 않고 다시 책을 펴고,

검색도 하면서 기초 개념을 처음부터 재점검했다.
단순히 "대충 아는 느낌"이 아니라,
다음 주차에 같은 개념이 나왔을 때 전혀 찝찝함이 없을 정도로 이해하고 싶었다.

 

이 과정에서 자연스럽게 복습 시간이 길어졌지만,
"이미 알고 있는 것 같아도 다시 확인해 보는 습관"은
앞으로 클라우드를 공부하면서 꼭 유지하고 싶은 부분이다.

 

2) 문제를 해결할 때 원인을 끝까지 따라간 점

실습실에서는 잘 되던 서버 접속이 집에서는 전혀 되지 않는 상황을 겪었다.
이럴 때 보통은 검색이나 ChatGPT로 해결 방법만 찾아보고 끝낼 수도 있다.

 

하지만 이번에는 "왜 이런 문제가 발생했는지" 끝까지 이해하고 싶었다.
그래서 콘솔의 메뉴를 하나하나 뒤져 보고,

로그와 설정 화면을 여러 번 확인하면서

문제를 추적하는 데만 오랜 시간을 썼다.

 

그 결과, 단순히
"이 설정을 이렇게 바꿔야 한다"가 아니라

"이 설정이 네트워크 관점에서 어떤 의미를 갖고,
왜 현재 상황에서는 접속이 막혔는지"

까지 연결해서 이해할 수 있었다.

 

이렇게 해결책뿐 아니라 원인과 원리까지 파고드는 학습 방식
시간은 많이 들지만, 네트워크 이해도를 크게 올려주는 것 같아서
다음 주차에도 계속 유지하고 싶다.


PROBLEM (어려웠던 점)

1) 실습실에서는 되던 SSH 접속이 집에서는 안 되던 이유

실습 시간에 만든 서버에 집에서 다시 접속해 보려고 PuTTY를 열었는데,
계속 접속이 되지 않았다.

 

"실습실에서는 분명 잘 됐는데,
집에 와서 시도했을 뿐인데 뭐가 달라진 거지?"

 

처음에는 서버 쪽 설정을 잘못 건드렸나 싶어서
콘솔에서 이것저것 확인해 보았다.

그러다가 ACG Inbound 규칙을 보면서 문제의 원인을 깨달았다.

(접근소스: myip, 포트: 22)

  • 실습 시간에 ACG Inbound 규칙을 만들 때
    접근소스를  myip 로 설정해 두었고
  • 그때의  myip 실습실에서 사용하던 PC의 공인 IP였다.

실습실과 집은 서로 다른 네트워크 환경이기 때문에
집에서 접속을 시도하면 완전히 다른 IP 주소로 보인다.
그런데 ACG 규칙은 "실습실에서의 내 IP 하나만 허용"하고 있었으니,
집에서 접속이 안 되는 것이 당연했다.

 

이 경험을 통해
"ACG의 접근소스를  myip 로 제한한다는 것은,
그 순간 내 컴퓨터의 공인 IP만 허용한다"
는 사실을 몸으로 이해했다.
단순히 이론으로 아는 것과, 실제로 접속이 막혀서 헤매 본 것의 차이를 느낄 수 있었다.

 

2) 왜 Outbound 규칙은 대부분 다 열어두는지에 대한 궁금증

 

실습 때는

"Inbound는 상황마다 규칙을 잘 설정하고,
Outbound는 보통 전부 허용해 둔다."

 

라는 설명을 듣고 그대로 따라만 했다.

 

그런데 집에서 복습을 하다 보니
"왜 Outbound는 이렇게 대충(?) 열어두는 거지?"
라는 생각이 갑자기 들었다.

 

그래서 ChatGPT와 문서를 뒤지면서 이유를 찾아봤고,
그 과정에서 ACG와 Network ACL의 차이까지 함께 이해하게 되었다.

  • ACG는 Stateful
    • Inbound에서 허용된 트래픽에 대해서는
      그에 대한 응답이 Outbound로 나갈 때 별도의 규칙 없이 자동 허용
    • 즉, "누가 먼저 말을 걸어왔는지"를 기억하는 방화벽
  • Network ACL은 Stateless
    • Inbound와 Outbound 규칙을 각각 따로 작성해야 함
    • 들어올 때 허용했다고 해서,
      나갈 때 자동으로 허용되는 것이 아님

이걸 이해하고 나니
"ACG에서 Outbound를 넓게 열어두는 이유"가 훨씬 명확해졌다.

 

ACG는 어차피 "누가 먼저 들어왔는지 기억하고 응답을 허용"하는 구조라,
일반적인 웹 서비스 시나리오에서는 Outbound를 과하게 막을 필요가 없다.
대신 Inbound를 촘촘하게 관리하는 것이 더 중요하다는 점을 배웠다.

 

3) PuTTY가 무엇을 해 주는 도구인지 처음에는 감이 오지 않았던 점

[사진3: PuTTY에서 Host Name에 공인 IP를 입력하고, Connection type을 SSH로 선택한 화면]

[사진4: SSH 접속 후 서버에 로그인한 CLI 화면]

수업 시간에 PuTTY를 처음 실행했을 때 느낌은 이랬다.

"Windows CMD나 Linux Bash 터미널처럼 생겼는데,
도대체 이건 무슨 프로그램이지?"

 

 

강사님이 알려주신 대로

  • Host Name에 서버의 공인 IP를 입력하고
  • Connection type을 SSH로 맞춘 뒤
  • Open을 눌러서
  • username과 password를 입력하니

터미널에  NCLOUD 라는 커다란 로고가 뜨면서
뭔가 서버에 입장한 느낌이 들었다.

 

그런데 막상 화면을 보고 있자니
"지금 이 검은 창이 내 컴퓨터인지, 서버인지"
직관적으로 와 닿지 않았다.

 

평소 같으면 바로 질문했을 텐데,
주변을 둘러보니 다들 당연하다는 듯이 실습을 하고 있어서
그 자리에서는 그냥 넘어갔다.

대신 집에 가자마자 꼭 정리해 보자고 마음먹고,
까먹지 않으려고 일정 알람에 "PuTTY 조사"라고 적어 두었다.

 

집에서 검색을 해보며 정리한 결론은 이렇다.

  • CMD나 Bash는 "내 로컬 컴퓨터" 에 명령을 내리는 터미널
  • PuTTY는 "네트워크를 통해 원격 서버" 에 명령을 전달하는 터미널
    (SSH 프로토콜을 사용해 암호화된 통신)

그래서

  • CMD에서  java -jar ...  를 입력하면 내 PC에 있는 JAR 파일이 실행되지만
  • PuTTY에서 같은 명령을 입력하면 SSH로 접속해 있는 리눅스 서버의 JAR 파일이 실행된다.

이 차이를 명확히 이해하고 나니,
앞으로 클라우드 실습에서  내가 어디에서 어떤 환경에 명령을 내리고 있는지 
의식적으로 구분할 수 있게 되었다.


TRY (개선할 점 / 시도할 것)

1) 수업 시간에 바로 질문하기

이번 주에는
"주변 사람들은 다 알고 있는 것 같은데 나만 모르는 것 같아서"
질문을 삼킨 순간들이 있었다.

 

결국 집에 와서 혼자 복습하면서
그때 넘어갔던 질문들을 하나씩 다시 해결해야 했고,
그 과정에서 시간이 훨씬 오래 걸렸다.

 

다음 주차부터는

  • 수업 중에 떠오른 궁금증은
    최대한 그 자리에서 바로 질문하고
  • 옆 친구가 잘 아는 부분이 있다면
    부끄러워하지 말고 적극적으로 물어보기

를 실천해 보려고 한다.


질문을 미루면, 결국 나중에 더 큰 시간을 들여서 복구해야 한다는 걸
이번 주에 확실히 느꼈다.

 

2) NCP 콘솔을 더 자주, 더 넓게 탐색해 보기

이번 교육 계정은 말 그대로 무료로 마음껏 실험해 볼 수 있는 기회인데,
학교 수업과 팀 프로젝트에 치이다 보니
NCP 콘솔을 충분히 만져보지 못한 아쉬움이 있다.

 

다음 주차에는

  • 실습에서 다루는 서비스뿐만 아니라
    다른 메뉴들도 한 번씩 클릭해 보며 구조를 파악하고
  • 서버, 네트워크, 스토리지, 보안 서비스 등을
    "아이콘만 아는 수준"이 아니라
    "어떤 상황에서 쓰는 서비스인지 설명할 수 있는 수준"까지 끌어올리는 것

을 목표로 삼으려고 한다.


느낀 점 (Reflection)

이번 주차를 지나면서 가장 크게 느낀 점은,
과금이 기본인 클라우드 서비스를 이렇게 제약 없이 실습해볼 수 있는 기회가
생각보다 훨씬 더 큰 의미를 가진다는 것
이다.

 

평소에는 “클라우드 서비스는 비싸다”, “실습 계정으로 마음껏 쓰기 어렵다”라는

인식이 강해서 막상 실습을 하려고 해도 비용 걱정이 먼저 들곤 했다.
그런데 이번 교육에서는 NCP의 실제 콘솔을 거의 무한대에 가깝게 사용하며
서버를 만들고, 지우고, 다시 만들고, 네트워크를 갈아엎어 보고,
ACG나 VPC 설정을 반복적으로 만져볼 수 있었다.

 

이런 실습 방식은 단순히 책으로 공부하는 것과는 완전히 다르다.
실수해도 비용 부담이 없다는 안정감 덕분에
“망가뜨려도 괜찮으니 마음껏 실험해보자”라는 태도로 임할 수 있었고,
그 덕분에 오히려 더 깊이 파고들고 이해하려는 마음이 생겼다.

 

특히 네트워크나 인프라 구성은
한 번 실습해보는 것과, 같은 작업을 여러 번 반복해서

몸에 익히는 것 사이의 차이가 정말 크다.
그런데 일반 환경에서는 반복 실습 자체가 부담스러운데,
지금은 제한이 없으니

마치 “클라우드를 내 마음대로 갖고 놀 수 있는 연습 도구”가 생긴 기분이었다.

 

이번 경험을 통해, 단순히 지식을 늘리는 것을 넘어
클라우드 인프라를 실제로 운영하는 감각을 조금씩 익히고 있다는 느낌을 받았다.
이런 환경에서 공부할 수 있다는 건 흔치 않은 기회라는 걸 스스로 잘 알고 있어서,
다음 주차도 “조금 더 부딪혀 보고, 조금 더 많이 시도해보자”라는 마음으로 준비하고 있다.


1주차에서 인프라의 기본기를 다졌다면,
2주차는 실제 네트워크 구성이 본격적으로 시작된다.
다음 글에서 한층 깊어진 학습 경험을 기록한다.

👉 [NCloud 1기] 2주차 회고