[NCloud 1기] 5주차 회고

5주차 회고

작성일: 2025.11.25

학습 주제: 3-Tier 아키텍처 설계 및 구현 미니 프로젝트

실습 환경: NCP Console + PuTTY + WinSCP

작성자: 황수진_컴퓨터과학부

 

이번 주차에서는 3-Tier 아키텍처를 직접 구성해보는 팀 프로젝트를 진행했다.
3명으로 팀을 구성했고, 역할은 아키텍처 설계 / 백엔드 / 프론트엔드로 나눴다.
나는 백엔드를 맡아서 API 설계, 구현, 배포까지 담당했다.

---

1. KEEP (유지할 점)

1-1. 피드백을 바로 반영한 아키텍처 구조도 개선

프로젝트 결과를 발표했을 때,

강사님께서 전체적인 완성도는 좋다고 칭찬을 해주셨다.
다만 보완할 점으로,

우리 팀의 아키텍처 구조도가 눈으로 보기에 너무 복잡하다는 지적을 받았다.

• 선이 지나치게 많이 교차하고 있고
• 각 계층이 한 번에 눈에 들어오지 않으며
• 처음 보는 사람이 보면 흐름을 파악하기 어려운 그림이었다.

다른 팀들의 아키텍처 다이어그램이 생각보다 훨씬 깔끔해서,

발표를 들으면서 많이 반성했다.
아키텍처 구조 자체만 맞으면 된다고 생각했는데,

실제로는 이 구조도를 보는 사람(고객사, 다른 팀원, 운영자)이 한눈에 이해할 수 있게

그려져 있는지가 더 중요할 수 있다는 점을 깨달았다.

 

그래서 발표가 끝났다고 그냥 넘기지 않고,

수업이 끝난 뒤에 구조도를 스스로 다시 그려보았다.

• 불필요하게 교차하는 선 정리
• WEB / WAS / DB / Edge / Security / Monitoring 등 역할별 영역 재배치
• 관리자 경로(SSL VPN, IDS, Cloud Insight)의 흐름도 따로 눈에 띄게 정리

이렇게 다시 그려보는 과정에서, 나 스스로도 아키텍처를 더 잘 이해하게 되었다.
이미 우리 팀 아키텍처 구조를 잘 이해하고 있다고 생각했지만,

보기 좋은 그림으로 재구성하다 보니 세부 흐름이 더 선명하게 정리되는 경험을 했다.
앞으로도 아키텍처를 설계할 때는

"맞게 만드는 것"과 동시에

"보기 좋게 설명할 수 있는 것"까지 항상 함께 고민해야겠다고 느꼈다.

 

1-2. 배운 내용을 꾸준히 기록으로 남긴 습관

5주차는 단순히 기능만 구현하는 것으로 끝내지 않았다.
로드밸런서, Auto Scaling, SSL VPN, Object Storage, Image Optimizer 등

과금 걱정없이 다양한 NCP 서비스를 동시에 다루는 경험이 너무 소중하다 보니

이 경험, 배운 내용, 문제점을 모두 기록하고 싶었다.

 

그래서 프로젝트를 진행하면서 다음과 같은 습관을 유지했다.

• 각 단계에서 콘솔 화면을 캡처
• 문제가 생긴 에러 메시지를 그대로 저장
• 해결 과정을 티스토리 글로 정리

사람은 금방 잊어버리는 존재라,

"지금은 당연히 기억하겠지"라고 생각한 내용도 며칠 지나면 흐릿해진다.
나중에 비슷한 인프라를 다시 구성하거나,

3-Tier 구조를 발전시킬 일이 생겼을 때

이 기록들이 큰 도움이 될 것 같아서 꾸준히 남겨 두었다.

 

아래 글들은 이번 3-Tier 프로젝트를 진행하면서 남긴 기록들 중 그 일부를 공유한다.

 

전체 아키텍처를 어떻게 설계하고,

어떤 순서로 구성했는지 정리하였습니다.

👉 [NCloud 1기] Naver Cloud Platform으로 3-Tier 아키텍처 구성하기

 

SSH 세션에 종속된 프로세스,

nohup 실행 방식 등을 정리하였습니다.

👉 [NCloud 1기] PuTTY를 끄고 나니 NCP 서버의 Spring Boot가 죽어버린 문제

 

재부팅 후 프로세스 자동 실행, 서버 이미지에 대한 오해,

systemd 도입까지 정리하였습니다.

👉 [NCloud 1기] 서버를 껐다 켰더니 백엔드가 사라졌다

 

이 습관은 앞으로

"단순히 공부를 하면서", "다른 프로젝트를 하면서"도 유지하고 싶은 부분이다.

---

2. PROBLEM (어려웠던 점)

2-1. 예상보다 훨씬 많은 시간과 에너지를 쏟아야 했던 미니 프로젝트

처음 이영태 강사님의 안내를 들었을 때는

"부담 갖지 않고 경험 위주로 진행해도 된다"라는 말이 있어서,

비교적 가벼운 미니 프로젝트라고 생각했다.
하지만 실제로는 월요일에 아키텍처 초안이 확정된 이후,

화요일부터 금요일 오전까지 거의 내내 개발과 배포에 시간을 쏟아야 했다.

 

실제 개발 과정에서도 에러도 많이 났었고

로컬에서 되던 것이 클라우드 서버에서는 안 되기도 하였다.

꽤 헤맸던 것 같다.

 

그런데 실제로 에러를 만나고,

로그를 뒤지고,

설정을 하나씩 바꿔가며 트러블슈팅하는 동안

클라우드에 대한 이해도가 이전과 비교도 안 될 정도로 올라갔다.

 

스트레스도 컸지만, 프로젝트가 끝난 뒤에는

"이걸 안 해봤으면 어쩔 뻔했나" 싶을 정도로 성장한 느낌이었다.

 

2-2. Image Optimizer 연동 과정에서의 쿼리스트링 실수 지옥

이번 프로젝트에서는 NCP Image Optimizer를 이용해

업로드된 이미지를 300x300 사이즈로 리사이즈하는 기능을 구현했다.

문제는, 이 Optimizer API를 처음 연동할 때였다.

문서를 자세히 읽었다고 생가하였고 그것을 바탕으로 구현했더니,

계속 이런 식의 에러가 떨어졌다.

• HTTP 400 Bad Request
• 파라미터 누락 오류 메시지

원인은 요구하는 "쿼리스트링"을 제대로 만족시키지 못한 코드를 짰기 때문이었다.

문서를 제대로 읽었다고 생각했는데...

 

내가 미처 읽지 못한 부분에서

쿼리스트링 형식에 대한 디테일이 살아있었다.

이 디테일을 찾지 못해서 헤메다가 낭비한 시간이

4-5시간은 됐던 것 같다... 

 

"API 연동은 문서를 꼼꼼히 읽는 것으로 개발을 시작해야 한다"는

아주 기본적인 사실을 몸소 체험했다.

---

3. TRY (개선할 점 / 앞으로 시도할 것)

3-1. 에러는 당연하되, 스트레스 관리도 함께 가져가기

개발이라는 것은 결국 에러와 로그, 트러블슈팅의 연속이다.
이번에도 여러 문제를 해결하면서 얻은 게 많았지만,

"기한 안에 배포를 못 끝내면 어떡하지?"라는 불안감 때문에

과하게 스트레스를 받기도 했다.

 

앞으로는 에러는 당연한 것으로 인정하고

조금 더 행복하고 여유 있게 프로젝트를 진행하는 연습이 필요하다고 느꼈다.

 

3-2. 초반 설계 단계에서 다이어그램과 API 문서를 더 철저하게

이번 프로젝트를 돌아보면, 초반 설계와 문서 읽기 단계를 좀 더 탄탄하게 가져갔으면 좋았을 것 같다는 아쉬움이 있다.

• 아키텍처 다이어그램은 기능 구현이 어느 정도 끝난 뒤에야
  본격적으로 다듬기 시작했고
• Image Optimizer 연동도 문서를 충분히 읽기 전에 코드를 먼저 짜기 시작했다.

다음에는 이렇게 해보고 싶다.

• 아키텍처 초안을 그릴 때부터 "보기 좋은 구조도"를 목표로 잡고,
  팀원들과 더 많이 리뷰하기
• 설계/문서 단계와 구현 단계를 조금 더 명확하게 분리하기

이렇게 하면 불필요하게 헤매는 시간을 줄이고,

더 중요한 부분에 에너지를 쓸 수 있을 것 같다.

---

4. 느낀 점 (Reflection)

네이버클라우드 아카데미를 수강하기 전과 후를 비교하면,

이론 교육만으로도 이미 클라우드에 대한 이해도는 많이 올라와 있었다.
하지만 5주차 미니 프로젝트는 그 위에 실제 경험을 한 층 더 쌓아 올려 준 시간이었다.

• WEB / WAS / DB로 나뉜 3-Tier 구조를 직접 구성하고
• 로드밸런서, Auto Scaling, SSL VPN,
  Cloud DB, Object Storage, Image Optimizer까지 연결해서
• 실제 외부 사용자에게 노출할 수 있는 형태의 서비스를 만들어 본 경험은,
  학교 수업만으로는 얻기 어려운 경험이었다.

과금 걱정 없이 서버를 만들었다가 지워 보고,
설정을 바꿔 보고, 잘못 구성해서 망가뜨려 보기도 했다.
이 과정이 나를 "설명만 들은 사람"에서 "직접 운용해 본 사람"으로 바꿔 준 것 같다.

 

5주차가 끝난 지금,

클라우드 인프라를 바라보는 시야가 분명히 한 단계 넓어졌다.
이번 경험을 발판 삼아,
앞으로는 더 큰 규모의 아키텍처와 더 복잡한 시스템에도 도전해 보고 싶다.