기획자가 개발자와 회의할 때 꼭 알아야 할 S3와 서버 이야기
기획자가 개발자와 회의할 때 꼭 알아야 할 S3와 서버 이야기
기획자가 개발자와 회의할 때 자주 듣는 말이 있습니다. “이 파일은 S3에 올리면 됩니다”, “이 처리는 서버에서 해야 합니다”, “이미지는 서버가 아니라 스토리지로 분리하죠”. 이때 S3와 서버의 차이를 모르면 회의가 금방 안개밭이 됩니다.
하지만 기획자가 인프라 엔지니어가 될 필요는 없습니다. 핵심은 단 하나입니다. 무엇은 저장하는 대상이고, 무엇은 실행하는 대상인지 구분할 수 있느냐입니다.
이 글에서는 기획자가 개발자와 회의할 때 꼭 알아야 할 S3와 서버의 차이를 기술 이론보다 실무 대화와 질문 기준으로 설명합니다. 파일 업로드, 이미지 저장, 다운로드 링크, 비용, 보안, 운영 관점까지 회의에 바로 써먹을 수 있게 정리해보겠습니다.
기획자가 S3와 서버를 알아야 하는 이유
기획자는 직접 인프라를 구축하지 않더라도, 기능 요구사항을 정의하고 일정과 우선순위를 조율하며 리스크를 미리 확인해야 합니다. 이때 S3와 서버의 구분이 잡혀 있으면 회의가 훨씬 빨라집니다.
- 기능 정의가 더 명확해집니다. 파일 저장인지, 서버 처리인지 구분하면 요구사항 문장이 선명해집니다.
- 일정 산정이 쉬워집니다. 단순 저장 기능인지, 서버 개발이 필요한 기능인지에 따라 작업량이 달라집니다.
- 비용 포인트를 빨리 찾을 수 있습니다. 저장 비용인지, 서버 운영 비용인지 구분할 수 있습니다.
- 보안과 권한 이슈를 놓치지 않게 됩니다. 누가 파일에 접근하는지, 링크가 공개인지, 인증이 필요한지 판단이 쉬워집니다.
- 운영 관점이 살아납니다. 장애가 났을 때 저장 문제인지, 서버 처리 문제인지 방향을 잡기 좋습니다.
쉽게 말해, 기획자가 S3와 서버를 이해한다는 것은 기술을 깊게 아는 것이 아니라 어디에 질문을 던져야 하는지 아는 것에 가깝습니다.
S3와 서버를 회의용 언어로 쉽게 구분하기
회의에서 가장 쉽게 기억하는 방법은 아래 한 줄입니다.
S3는 저장하는 곳이고, 서버는 처리하는 곳입니다.
S3는 무엇인가
S3는 파일을 저장하고 필요할 때 가져오는 데 적합한 저장소입니다. 이미지, 동영상, 첨부파일, 로그, 백업 파일처럼 “보관하고 내려받는 데이터”를 다루기에 좋습니다.
서버는 무엇인가
서버는 프로그램을 실행하고 요청을 처리하는 환경입니다. 로그인, 주문 처리, 결제 검증, 게시글 등록, 권한 확인처럼 “코드가 실제로 돌아가야 하는 일”은 서버가 맡습니다.
기획자 관점에서 이렇게 외우면 됩니다
- 파일을 담아두는 문제면 S3를 떠올립니다.
- 사용자 요청을 계산하고 처리하는 문제면 서버를 떠올립니다.
- 둘 다 필요한 기능이라면 저장과 처리를 분리해서 설명하면 됩니다.
S3와 서버 차이 한눈에 보기
| 항목 | S3 | 서버 |
|---|---|---|
| 주된 역할 | 파일과 데이터를 저장 | 애플리케이션과 기능을 실행 |
| 대표 예시 | 이미지, 동영상, 첨부파일, 백업 | 로그인, API, 관리자 기능, 결제 처리 |
| 핵심 질문 | 무엇을 어디에 보관할까? | 무엇을 어떻게 처리할까? |
| 비용 관점 | 저장량과 전송량 중심 | 컴퓨팅 자원과 운영 시간 중심 |
| 권한 관점 | 파일 접근 권한, 공개 여부, 다운로드 정책 | 사용자 인증, 로직 권한, 요청 검증 |
| 기획자 체크 포인트 | 저장 기간, 파일 크기, 접근 방식 | 처리 로직, 응답 속도, 오류 처리 |
회의에서 자주 나오는 상황별 이해
1. 파일 업로드 기능을 기획할 때
사용자가 PDF나 이미지 파일을 업로드하는 기능이라면 보통 파일 자체는 S3 같은 저장소에 보관하고, 업로드 권한 확인과 파일 메타데이터 저장, 업로드 정책 검증은 서버가 담당합니다.
기획자는 여기서 “파일은 어디에 저장되나요?”, “파일 크기 제한은 있나요?”, “삭제 시 실제 파일도 같이 지워지나요?”를 물어볼 수 있어야 합니다.
2. 게시판 이미지나 상품 이미지를 다룰 때
이미지 파일은 S3에 저장하고, 게시글이나 상품 정보 같은 비즈니스 데이터는 서버와 데이터베이스가 관리하는 구조가 일반적입니다. 이 차이를 이해하면 “이미지 업로드”와 “게시글 저장”이 서로 다른 작업이라는 점이 보입니다.
3. 다운로드 링크를 제공할 때
기획자는 링크 하나만 보지만, 개발자 입장에서는 그 링크가 누구나 열 수 있는 공개 링크인지, 로그인한 사용자만 일정 시간 동안 열 수 있는 제한 링크인지가 중요합니다. 즉, 다운로드 기능은 단순 파일 제공이 아니라 보안 정책과 연결됩니다.
4. 대용량 파일이나 동영상을 다룰 때
파일 크기가 커질수록 서버에 직접 올리는 방식은 부담이 커질 수 있습니다. 그래서 저장과 전송을 S3 중심으로 설계하고, 서버는 권한 확인과 메타데이터 처리에 집중하는 방식이 많이 쓰입니다.
5. 운영 중 파일 교체가 필요한 경우
관리자 화면에서 배너 이미지나 첨부파일을 교체하는 기능도 자주 등장합니다. 이때 기획자는 “파일을 덮어쓰는지”, “버전 관리가 필요한지”, “예전 파일 복구가 필요한지”까지 생각하면 회의 품질이 올라갑니다.
기획자가 회의에서 꼭 물어봐야 할 질문
아래 질문은 기획자가 S3와 서버를 구분해서 이해하고 있다는 신호이기도 합니다. 회의실 공기가 갑자기 또렷해지는 질문들이라 꽤 쓸모 있습니다.
저장 관련 질문
- 이 파일은 어디에 저장되나요?
- 사용자가 업로드한 원본 파일과 썸네일은 같은 곳에 저장되나요?
- 파일 보관 기간은 어떻게 되나요?
- 삭제 요청 시 실제 저장소에서도 삭제되나요?
처리 관련 질문
- 이 기능은 서버에서 어떤 처리를 하나요?
- 업로드 전후로 검증 로직이 필요한가요?
- 변환, 압축, 리사이징 같은 후처리는 서버가 하나요?
- 실패하면 사용자에게 어떤 메시지를 보여주나요?
보안 관련 질문
- 파일 링크는 공개인가요, 로그인 사용자만 접근 가능한가요?
- 다운로드 URL에 만료 시간이 필요한가요?
- 권한 없는 사용자가 접근하면 어떻게 차단하나요?
비용과 운영 관련 질문
- 사용량이 늘어나면 저장 비용과 서버 비용 중 어디가 먼저 커지나요?
- 대용량 업로드가 많아지면 어떤 운영 이슈가 생기나요?
- 장애가 발생하면 저장소 문제인지 서버 문제인지 어떻게 구분하나요?
기획자가 자주 헷갈리는 표현 번역
“서버에 이미지 올려주세요”
실무에서는 이 표현이 정확하지 않을 때가 많습니다. 실제로는 이미지 파일은 S3에 저장하고, 서버는 이미지 정보만 저장하거나 접근 권한만 제어하는 경우가 많습니다.
“파일 저장 기능을 개발해주세요”
이 문장도 더 쪼개야 합니다. 파일 업로드 화면이 필요한지, 파일 저장 위치가 필요한지, 파일 목록 조회 API가 필요한지, 권한 검증이 필요한지로 나눠야 개발 범위가 선명해집니다.
“링크만 주면 되지 않나요?”
링크 제공은 단순하지 않습니다. 공개 링크인지, 로그인 검증 후 발급하는 링크인지, 일정 시간이 지나면 만료되는 링크인지에 따라 보안과 구현 방식이 달라집니다.
“백업도 같은 곳에 두면 되지 않나요?”
운영 파일과 백업 파일은 목적이 다릅니다. 기획 문서에서도 운영 저장소와 백업 정책을 구분해 두면 장애나 복구 논의 때 훨씬 유리합니다.
실무 회의 예시로 보는 S3와 서버
상황: 사용자가 계약서를 업로드하고, 관리자만 다운로드할 수 있는 기능을 기획하는 경우
기획자가 막연하게 말하면
“계약서 업로드 기능 만들어 주세요. 관리자에서 다운로드되면 됩니다.”
기획자가 구분해서 말하면
- 사용자가 업로드한 계약서 원본 파일은 어디에 저장되나요?
- 파일 저장 후 서버에는 어떤 정보가 남나요? 예를 들면 파일명, 업로드 시간, 사용자 ID 같은 정보입니다.
- 관리자만 다운로드 가능해야 하는데, 파일 링크는 직접 노출되나요 아니면 서버를 통해 권한 확인 후 내려가나요?
- 업로드 가능한 파일 형식과 크기 제한은 어떻게 둘까요?
- 계약서가 교체되면 이전 버전을 보관해야 하나요?
같은 기능이라도 질문 수준이 달라지면 회의 결과가 확 달라집니다. 개발자는 범위를 더 명확히 이해하고, 기획자는 누락되기 쉬운 보안과 운영 포인트를 챙길 수 있습니다.
결론
기획자가 개발자와 회의할 때 꼭 알아야 할 S3와 서버의 핵심은 복잡하지 않습니다.
S3는 저장소이고, 서버는 실행 환경입니다.
파일을 저장하는 문제인지, 요청을 처리하는 문제인지 구분할 수 있으면 회의가 훨씬 쉬워집니다. 그리고 이 구분은 단순한 기술 지식이 아니라, 요구사항을 더 정확하게 쓰고, 일정과 비용을 더 현실적으로 판단하고, 보안과 운영 이슈를 더 일찍 발견하게 해주는 실무 감각입니다.
기획자는 모든 기술을 다 알 필요가 없습니다. 대신 회의에서 이렇게 물을 수 있으면 충분합니다. “이건 저장의 문제인가요, 처리의 문제인가요?” 이 한 문장만 있어도 회의실의 공기가 꽤 많이 정리됩니다.
FAQ
Q1. 기획자가 S3와 서버를 꼭 알아야 하나요?
깊게까지 알 필요는 없지만, 저장과 처리의 차이를 구분할 수 있으면 요구사항 정리와 개발 회의가 훨씬 수월해집니다.
Q2. S3는 서버와 같은 개념인가요?
아닙니다. S3는 파일과 데이터를 저장하는 서비스이고, 서버는 애플리케이션 로직을 실행하고 요청을 처리하는 환경입니다.
Q3. 파일 업로드 기능은 전부 S3로 이해하면 되나요?
파일 자체는 S3에 저장되는 경우가 많지만, 업로드 권한 검증, 메타데이터 저장, 후처리 로직은 서버가 담당하는 경우가 많습니다.
Q4. 회의에서 가장 먼저 물어봐야 할 질문은 무엇인가요?
“이 기능은 저장이 핵심인가요, 처리가 핵심인가요?”라고 묻는 것이 가장 좋습니다. 이 질문 하나로 S3와 서버의 역할을 자연스럽게 나눌 수 있습니다.
Q5. 기획자가 개발자와 이야기할 때 특히 조심할 표현은 무엇인가요?
“서버에 파일 올린다”, “링크만 주면 된다”, “저장만 하면 된다” 같은 표현은 범위가 모호할 수 있습니다. 저장 위치, 접근 권한, 서버 처리 여부를 나눠서 말하는 편이 좋습니다.