사이드 프로젝트 진행 전 기술 스텍을 정하기 위한 나의 생각을 정리한다.
첫 번째로 어떤 환경에 배포할 것 인가에 대해 정리해본다.
온프레미스 : 자체적으로 보유하고 있는 서버에 직접 설치하고 운영하는 방식
클라우드 : 필요한 IT 자원만을 선택해 인터넷을 통해 ‘서비스’ 방식으로 구입해 사용하는 방식
우선 온프레미스와 클라우드의 차이점을 알아보자
클라우드 | 온프레미스 | |
---|---|---|
비용 | 초기투자비용이 저렴함 구독형/충전형 요금제 데이터 증가 시 추가적인 비용 발생 | 높은 초기 구축 비용 데이터로 인한 추가 비용 적음 장기적으로 사용 시 비용 효율 높음 |
보안 | 클라우드 서비스 제공 업체의 보안 시스템 외부망으로 인한 보안 문제가 생길 수 있음 | 기업 자체의 보안 시스템 구축 필요 내부망 사용 시 외부로 인한 보안이 좀 더 안전 할 수 있음 |
구축 및 관리 | 신속한 도입 가능 관리를 위한 별도의 전문 인력 불필요 세세한 설정 변경이 어렵거나 불가능함 특정 클라우드 서비스에 종속됨 | 시스템 구축에 별도의 시간과 지식 필요 필요에 따라 맞춤형으로 구축 가능 인프라를 관리를 위한 전담 인력 및 조직 필요 |
검색을 통해 알아보고 공통적으로 많이 이야기 하는 차이점이 위와 같은 내용이다.
한가지 개인적인 의문점은 클라우드 구축 및 관리에 관리를 위한 별도의 전문 인력 불필요는 아니라는 생각이 들었다.
온프레미스에 비해 적은 인력이 필요 할 뿐이지 일정 수준이 넘어가는 클라우드 환경의 인프라의 경우 데브옵스와 같은 전문가가 꼭 필요하다고 생각한다.
내 생각대로 정정하자면 비교적 적은 인력으로 관리가 가능하다가 좀 더 맞는 이야기 이지 않을까 생각한다.
결론 : 클라우드
AWS와 같은 클라우드 환경이 최근에 많이 쓰이고 최근 래퍼런스가 많다와 같은 자잘한 이유도 있지만 현실적으로 가장 크게 와닿은 이유는 두 가지였다.
해당 글을 작성하는 현재 본인은 개발을 실무로 시작한지 1년 4개월 밖에 되지 않은 응애 개발자다. 팀원들도 크게 편차가 없는 경력을 가지고 있다.
AWS 와 같은 클라우드 서비스도 결코 러닝커브가 적다고 할 수 없는데 온프레미스의 경우 자유도가 높은 만큼 그만큼 더 많은 지식이 필요하다고 생각했다.
마치 내가 프레임워크와 같은 틀이 존재하지 않으면 당장은 뇌정지가 오는 것 처럼...
가능한 빨리 포트폴리오를 완성 하는 것이 목적인 프로젝트 이기에 온프레미스 구축에 대해 공부하는 시간 비용이 너무 크다고 판단했다.
현재 진행하려는 프로젝트는 포트폴리오를 목적으로하는 사이드 프로젝트다.
온프레미스 환경을 구축할 서버를 이미 누군가 가지고 있는게 아니라면 너무나 부담되는 비용이 발생하며 또한 온프레미스는 스케일링 작업이 매우 번거롭기 때문에 필요 사양을 가능한 정확히 측정 하는 것이 중요한데 현재 상황에서는 불가능 하다고 생각했다.
Lightsail | EC2 | |
---|---|---|
사용 | 간단한 웹 애플리케이션 및 웹 사이트에 사용 | 소규모 내지 엔터프라이즈 애플리케이션에 사용 |
성능 | 컴퓨팅 리소스와 시간비용 기준 소규모에서 중간 규모의 프로젝트에 사용 (비교적 성능 낮음) | 컴퓨팅 리소스와 시간비용 기준 복잡한 아키텍처에서 소규모 이상의 프로젝트에 사용 (비교적 성능 좋음) |
편의성 | 서버 구성(설정)이 매우 간단함 서버 구성의 자유도가 적음 다른 AWS 서비스와 연동이 안되는 경우가 많음 | 서버 구성(설정)에 대한 선수 지식이 필요함 서버 구성의 자유도가 매우 높음 다른 AWS 서비스와 연동이 원활함 |
확장성 | 인스턴스 확장/수정 불가능 확장/수정 시 새 인스턴스 구축 필요 (도커를 이용한 이미지 빌드 후 배포 방식 필수) | 인스턴스 확장/수정에 매우 자유로움 Auto Scaling을 통한 자동화도 지원 |
요금 | 가격이 저렴하고 고정 가격 | 사용한 만큼 비용을 지불 하는 방식 (필요한 시간에만 사용 할 경우 Lightsail 보다 저렴 할 수 있음) |
상단의 표는 AWS 공식 사이트에 있는 Lightsail / EC2의 차이점을 참고하여 내가 와닿는 부분만 가져와서 수정한 내용이다.
결론 : Lightsail
결론적으로 내가 생각하는 가장 큰 요점은 진행하고자 하는 프로젝트의 목적이 무엇인가? 이다.
우리 프로젝트의 목적은 구현 도구의 깊은 이해와 협업능력 상승이라고 생각한다.
아직 주니어 연차의 인원이 모여있고 클라우드 지식도 물론 중요하지만 선택과 집중이 필요하다면
협업 능력과 비즈니스 요구사항을 잘 이해하고 좋은 방향으로 구현하는 능력을 키우는 것이
현재는 좀 더 중요하다고 생각했다.
해당 내용을 전제로 선택한 이유 3가지에 대해서 작성해본다.
클라우드 인프라를 본격적으로 공부하려고 한다면 EC2가 명불허전 이라고 생각한다.
EC2는 클라우드 환경 중 가장 많이 사용되고 있는 서비스이고 AWS 에서도 권장하는 서비스이다.
하지만 우리의 목적은 클라우드 공부가 아니라 구현 도구에 깊은 이해와 협업 능력을 키우는데
목적을 두고 있는 프로젝트이다.
이런 관점에서 봤을 때 EC2를 구성하려면 적지 않은 러닝커브가 필요하다.
EC2로 선택하여 EC2를 공부하고 이해하며 사용하게 될 경우
원래 목적에 집중하지 못하고 집중해야하는 요소가 분산된다고 생각했다.
또한 그렇다고 해서 제대로 이해하지 못한 내용을 가지고 일단 EC2로 구성하게 된다면
포트폴리오 목적에서도 좋지 않은 방향이라고 생각했다.
그래서 비교적 구성이 간편한 Lightsail이 적합하다고 판단했다.
EC2를 필요한 시간대에만 사용한다고 한다면 Lightsail보다 금전적으로 저렴하게 사용할 수 있다.
또한 정확하진 않지만 EC2 사용시간을 미리 설정해두고 자동화 하는 것도 가능한 것으로 알고 있다.
하지만 EC2를 선택했을 경우 EC2를 이해하고 공부하는 시간 비용이 발생한다.
또한 서버 구성중 이슈나 배포 중 이슈가 발생하면 더 많은 시간 비용이 발생한다.
EC2를 잘 이해하고 사용 할 경우 Lightsail보다 금전적으로 저렴하게 사용할 수 있다.
위와 같이 EC2는 금전적인 절약이 가능하지만 시간 비용이 발생하고
Lightsail은 금전적으로 좀 더 비용이 나올 수 있지만 시간적 비용이 절약된다고 생각이 들었다.
결론적으로 우리는 빠른 시간 안에 포트폴리오를 완성 시키고 싶은 입장이라면
시간 비용이 더 큰 단점이라고 생각했다.
사이드 프로젝트 특성상 기획, 디자이너들은 초반에 매우 바쁘고 후에는 개발 진행되면서 개발자들이 피드백 주는 것에 대한 회의/수정을 하면서 대기하는 시간이 많아진다.
그러니 개발자는 우리의 목적을 해치지않는 선에서 가능한 빨리 MVP 개발을 마무리하고 배포를 통해 기획, 디자인 등 팀원들의 대기시간이 최소한이 되도록 노력해야 된다고 생각했다.
이런 기준으로 생각을 해봤을 때 EC2를 위한 공부 시간은 기획, 디자인 등 팀원들에게 큰 도움이 될만한 요소가 아니며 대기 시간만 길어지는 요소가 될 수 있다고 생각했다.