인프런 커뮤니티 질문&답변
안녕하세요~
해결된 질문
작성
·
26
0
안녕하세요! 자바 강의 듣다가 요즘 제가 고민하던 주제를 다뤄주셔서 바로 듣고 있습니다
개인적으로 궁금한 점이 있어 댓글 남깁니다.
강의에서는 RDB로 PostgreSQL을 선택하셨는데, 다른 RDB들과 비교해 보신 뒤 결정하신 걸까요? 아니면 실무 경험이 익숙해서 선택하신 걸까요?
저도 공부 겸 티켓 예매 서비스를 사이드 프로젝트로 만들어 보려 하는데, 말씀하신 것처럼 기술 선택부터 고민이 많아지더라고요.
사이드 프로젝트 수준에서도 RDB를 꽤 깊게 비교해 보고 고르는 게 맞는지, 아니면 목적에 맞는 선에서 빠르게 선택하고 구현에 집중하는 게 더 좋은지 감이 잘 안 잡힙니다.
나중에 포트폴리오로도 활용할 생각이라 제대로 만들고 싶어서요.
주제가 티켓팅이라 이걸 사이드 프로젝트로써 정하는게 맞나 싶기도 하지만(실 서비스만큼의 환경을 AWS에서 혼자 구성하기에는 환경적인 한계가 있을수도 있다고 생각해서....)선생님 정도 경력이시면, 이런 기술 선택(특히 DB)은 보통 어느 정도 깊이까지 고민하시는지도 궁금합니다. 수업은 실제 나만의 서비스라고 말씀 하셨지만 결국 웹서비스를 진심으로 만들어서 배포까지 생각하는 사람으로써 질문합니다. 감사합니다.
답변 2
1
실무 경험이라 할 수는 없을 것 같습니다. 개인적으로 C/C++ 기반 개발을 자주 했었고 웹 서비스를 직접 만들어 본 것은 책에서 예제를 따라하는 정도 였기 때문입니다. 그런 이유로 여러 상황을 기반없이 고민했던 것 같습니다. 그러던 중 다음 몇 가지 이유로 PostgreSQL을 선택했습니다.
유연한 데이터 타입: JSON, 배열, 범위 타입 등 다양한 데이터 타입을 네이티브로 지원하는데 그 중 JSON 형식은 웹에서 흔히 등장하는 형이이라 일반 TEXT와 구별 할 수 있다는 점이 마음에 들었습니다. 어쩌면 NoSQL이 가진 장점을 일부 가질 수 있다 판단했습니다.
MVCC(Multi-Version Concurrency Control): 읽기와 쓰기가 서로를 간섭하지 않는 구조를 제공해 동시성 환경에서 안정성이 높습니다.
라이선스: 상업적 사용에 제약이 거의 없습니다. 이 점은 상용 서비스를 개발해야 하는 입장에서 의미가 크다 하겠습니다.
그 외에도 여러 장점이 있겠습니다만...지금 말씀드린 정도가 가장 직접적인 이유였습니다. 만일 정말 고성능 시스템을 구축하겠다고 작정한다면 AWS 환경에 올리기에 앞서 물리적 환경에서 다양한 입/출력 테스트를 해볼 것 같습니다. 실제 서비스에서 회원 수가 10만 명 정도가 되지 않는 이상 어지간한 문제를 서비스에서 경험하기는 쉽지 않을 것으로 생각하고 있습니다. 아무튼 성능에 관한 이슈는 AWS 환경에서 향후 얼마든지 대응 할 수 있으리라 판단했습니다.
그리고 AWS에서 이미 Read Replica를 지원하기 때문에 어지간한 문제는 없으리라 예상한 것도 있습니다. 개인적으로 가장 고민하지 않았던 부분은 의외로 API 서버 부분입니다. ALB를 적용해 스케일 아웃만 잘 해줘도 될 것이며 무엇보다 멀티스레딩 구조를 만들 이유가 거의 없고 높은 성능을 내기 위해서는 OS의 지원을 받는 비동기 입/출력 구조로 가는 것이 적절하다고 판단했습니다.
포트폴리오로 확장할 생각을 가지고 있다면 무조건 DB에 과부하를 걸어 성능을 개선하는 것에 대해 경험해 보시기를 권합니다. 그래야 캐싱에 대해서도 고민하게 될 것입니다. 만일 카카오톡 같은 것을 만들겠다면 프론트 수준에서 부하를 분산하는 문제도 고민해야 할 것입니다. 그러나 그것은 특수한 경우가 아닐까 싶습니다.
이 답변이 조금이라도 도움이 되기를 진심으로 바랍니다. 아직 시간이 있으니 얼른 취업도 잘 해내시기를 응원합니다. 😄
0
안녕하세요, 인프런 AI 인턴입니다. 매운세데스님.
여러 데이터베이스 옵션 중 PostgreSQL을 선택한 이유는 실무 경험과 해당 데이터베이스의 강점에서 비롯될 수 있습니다. PostgreSQL은 비교적 강력한 SQL 파서, 확장성, ACID 준수성, 오픈 소스 커뮤니티의 활발한 지원 등 여러 면에서 우수하기 때문에 많은 개발자들 사이에서 선호되고 있습니다. 실무 경험에 따라 매끄럽고 익숙한 도구를 선택하는 것은 자연스러운 일이기도 합니다.
사이드 프로젝트에서의 RDB 선택에 대한 고민은 공감이 갑니다. 장기적으로 포트폴리오로 활용할 계획이라면, 기술 선택은 중요한 문제일 수 있습니다. 그러나 다음과 같은 요소들도 함께 고려해보세요.
목표 우선: 포트폴리오로 활용할 것이라면 시간과 리소스로 인해 모든 RDBMS를 테스트하는 것은 비효율적일 수 있습니다. 목표와 요구사항에 가장 부합하는 도구를 선택하는 것이 우선입니다.
기술 탐색과 실행 균형: 기술 탐색이 중요한 만큼, 구현 과정에서 마주하게 될 다양한 문제 해결 및 실험에 더 많은 시간을 투자하는 것이 일반적입니다.
확장성 고려: AWS 같은 클라우드 서비스는 확장성과 실 환경에 필수적인 여러 요소를 제공합니다. 다만, 초기에는 작은 규모로 시작하되 추후 확장성을 지원할 수 있는 기반을 마련하는 것도 중요합니다.
이와 관련된 유사 질문과 답변들이 있어 소개합니다:
- PostgreSQL과 다른 RDBMS의 비교: 포스트그레스의 장단점을 비롯한 다양한 RDBMS에 대한 설명이 포함되어 있습니다.
- 사이드 프로젝트에서 DB 선택 기준: 사이드 프로젝트에서의 기술 스택 선택에 대한 더 많은 의견을 확인할 수 있습니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.





