[PM온보딩] 참고자료 8 : 인프라 이해하기
PM을 위한 인프라 이해하기 – AWS, Vercel, Swagger, 도메인
개발을 잘 몰라도 괜찮습니다!
다만, 서비스가 어떻게 만들어지고, 어디에 올라가며, 어떻게 연결되는지는 알아야 합니다.
이것이 바로 기술 이해의 시작점입니다.
1. PM은 인프라 전문가가 아닙니다.
프로젝트에서 사용하는 기술 스택은 팀, 규모, 예산, 담당 개발자에 따라 달라질 수 있습니다. 또한 조직마다 서비스에 따라 다를 수 있습니다.
어떤 팀은 AWS를 쓰고, 어떤 팀은 Vercel을 쓰며, 또 어떤 팀은 로컬 서버나 다른 클라우드를 쓰기도 합니다.
그렇기에 PM이 모든 툴을 직접 다룰 줄 알아야 하거나 다 이해하고 있어야 하는 것은 아닙니다.
대신, ‘왜 이 툴을 사용하는지’, ‘어떤 구조로 연결되는지’를 알고 있어야 프로젝트 전체의 기술 흐름을 이해할 수 있고 그에 따라 문제 해결에 더 가까워질 수 있습니다.
2. 프론트엔드와 백엔드, 그리고 인프라
서비스 하나가 동작하기 위해서는 크게 아래와 같은 세 가지 축이 필요합니다:
1. 프론트엔드 (Front-end) : 사용자에게 보여지는 화면을 만드는 영역 | React, Vue ...
2. 백엔드 (Back-end) : 데이터를 저장하고 처리하는 영역 | Django, Node.js, Spring ...
3. 인프라 (Infra): 위 두 가지를 인터넷에서 ‘작동’하게 해주는 기반 | AWS, Vercel, Netlify ...
PM은 이 세 가지가 각자 무엇을 의미하는지, 그리고 서로 어떤 연결고리로 움직이는지를 이해하고 있어야 합니다.
3. AWS – 인프라의 풀세트
AWS(Amazon Web Services)는 서버, 스토리지, 데이터베이스, 보안, 배포 등 웹 서비스를 만들기 위한 모든 인프라 서비스를 제공합니다.
말 그대로 ‘온라인 서비스의 집 한 채를 짓는 데 필요한 모든 도구들'을 제공하는 플랫폼입니다.
AWS 주요 개념에는 아래와 같이 있으며, 그 외에도 많은 도구들을 제공합니다.
1. EC2 : 서버, 백엔드 코드가 돌아가는 컴퓨터
2. S3 : 파일 저장소, 이미지, 동영상 등을 저장
3. RDS : 데이터베이스, 사용자 정보, 게시글 등 저장
4. IAM : 권한 관리, 누가 무엇에 접근 가능한지를 설정
...
.
.
Tip:
- AWS는 개발자가 직접 구축하고 설정하는 일이 많습니다. 조직에 따라서는 인프라 만을 담당하는 팀이 있을 수 있습니다. 제가 소속된 에이전시의 경우, 프론트엔드 배포는 Vercel로 진행하기에 백엔드 기본 서버 세팅을 위해 백엔드 개발자가 직접 설정합니다.
- 보통은 깃헙 브랜치와 자동 배포를 연결해 놓는 경우가 많기에 dev 브랜치는 개발 서버를 바라보고 main 브랜치는 운영 서버를 바라보도록 연결해 놓습니다.
- PM은 계정 세팅 또는 권한 요청 여부, 도메인 연결 유무, 배포 일정 등을 파악해 두는 게 중요합니다.
4. Vercel – 프론트엔드에 특화된 배포 플랫폼
Vercel은 React, Next.js 같은 프론트엔드 프레임워크에 특화된 배포 플랫폼입니다.
클릭 몇 번이면 코드를 배포하고, 변경 사항이 자동 반영되며, 도메인 연결도 쉽게 할 수 있습니다.
Vercel을 쓰면 좋은 상황
프론트엔드만 개발하는 프로젝트
빠른 테스트 및 반복 배포가 필요한 경우
Tip:
- 개발자가 “Vercel로 배포했어요”라고 하면, 이는 Vercel을 통해 연결되어 있는 url에 배포했다는 의미이니 링크를 모른다면 링크 공유를 요청하고, 링크를 알고 있다면 새로고침을 통해 업데이트된 내용을 확인하면 됩니다.
- 보통은 운영 환경(Production = main)과 개발 환경(Dev)을 구분하여 dev 브랜치에 올리면 자동으로 개발 환경에 배포되고 -> main 브랜치에 올리면 운영 환경에 배포되니 개발 환경에 연결된 url과 운영 환경에 연결된 url을 미리 알고 있으면 좋습니다. (운영 환경은 아무래도 실제 서비스가 운영될 도메인에 연결이 되어 있겠죠?)
- 모바일 청첩장과 같은 서버와의 통신이 필요하지 않은 경우, Vercel로 프론트엔드만 배포하면 되니 아주 편리하겠죠?
5. Swagger – API 문서 자동화 도구
프론트엔드와 백엔드가 협업할 때, 서로 어떤 데이터를 주고받는지를 문서로 정리해야 합니다.
이때 사용하는 것이 바로 Swagger (스웨거)입니다.
Swagger가 제공하는 것
API 목록 정리 (예: /login, /user/info)
요청 방식 설명 (GET/POST 등)
요청/응답에 포함될 데이터 샘플
Tip:
- Swagger 문서를 통해 개발자가 어떤 기능을 만들었는지 파악할 수 있고, QA나 기획 변경 시 API 정의를 바탕으로 커뮤니케이션을 할 수 있습니다.
6. 도메인 – 우리 서비스의 주소
서비스를 런칭하려면 사람들이 찾아올 수 있는 ‘주소’가 필요합니다. 그게 바로 도메인(domain)입니다.
https://brunch.co.kr/ : 브런치 주소와 같이 사람들이 찾아올 수 있게 제공할 주소가 필요합니다.
도메인 구매처: cafe24, 가비아 등이 있고 AWS에서도 구매가 가능합니다.
도메인을 사고, 서버와 연결해야 합니다.
PM은 도메인 정보를 확보하고, 개발자가 배포 시점에 접속 가능한 상태인지 도메인 연결 여부와 SSL(보안인증서) 적용 여부를 확인해야 합니다.
7. PM이 확인할 체크리스트
1. 인프라 : AWS or Vercel 어떤 플랫폼을 사용하는가? 계정 세팅과 권한은?
2. API 문서 : Swagger 문서 작성 여부, 최신화 여부
3. 배포 상태 : 운영/개발 환경 분리 여부 확인 | 깃헙 브랜치와의 연결 확인
4. 도메인 : 도메인 소유자, 네임서버 연결 여부
AWS 계정이 왜 필요하고 AWS를 통해 무엇을 설정하는지, 프론트엔드는 왜 Vercel을 쓰는지, API 문서는 무엇으로 공유되는지를 이해하고 있다면 PM은 기술적인 흐름 속에서 프로젝트를 안정적으로 이끌 수 있습니다.
PM이 모든 것을 직접 설정할 필요는 없습니다.
다만 어떤 흐름으로 서비스가 작동하는지, 서비스 작동을 위해서 놓친 것은 없는지, 누가 어떤 부분을 맡고 있는지, 문제가 생기면 어디를 확인해야 하는지를 이해하고 있다면 이해 관계자와 더 원활한 소통으로 이끌어갈 수 있을 것입니다.
맥락을 이해하고, 상대방의 눈높이에 맞춰 소통한다면 PM으로서의 진짜 경쟁력을 갖출 수 있을 거예요.
