1인 스타트업 대표가 ‘엔지니어링’으로 비용을 절약하는 법

이력서 멘토링을 인연으로 저와 멘토/멘티 관계를 맺은 유남주 님은 주니어 백엔드 개발자입니다. 포트폴리오용 프로젝트를 하느라 바쁜 나날을 보낸다던 유남주 님이 어느 날 커피챗을 신청해 왔습니다. 커피 한 잔이야 기꺼이 사줄 수 있지만, 만나는 목적을 도통 말해주지 않네요.

시각에 맞춰 도착한 그는 다짜고짜 게릴라 인터뷰를 해도 되겠냐고 묻습니다. 인터뷰 받는 사람에게 주제를 알리지 않고 즉석에서 날 것 그대로 대답을 받기 위한 방식이라고 하는데, 왜 그런 인터뷰를 하는 걸까요? 별로 내키지 않아 하는 저를 유남주 님이 설득합니다. 스타트업 대표로서 ‘비용을 절감하기 위한 엔지니어링적 시도’를 주제로 이야기 나누고 싶었다고 하네요. 인터뷰 방식은 긴장되지만, 주제가 흥미로웠습니다.

어디 한 번 이야기 나눠볼까요?

엔지니어링으로 비용을 절약할 수 있을까?

유남주 개발자(이하 유남주): 멘토님은 ‘푸딩캠프’를 혼자서 개발하고 운영하잖아요. 왜 팀을 만들지 않으세요?

푸딩캠프는 제가 개발하고 운영하는 웹 서비스이자 전체 브랜드의 이름입니다. 푸딩캠프라는 웹사이트를 포함해 디스코드 커뮤니티, 뉴스레터 등 여러 서비스를 제공하죠.

한날: 저는 혼자 창업했고 외부 자본 없이 서비스를 꾸려가고 있어요. 아직 적자지만, 비용을 최소화한 상태로 매출을 내서 자기 자본으로 운영할 계획이죠. 즉, 팀을 꾸릴 돈이 없다는 뜻이에요.

이런 방식으로 스타트업이 회사를 성장시키는 전략을 ‘부트스트래핑(Bootstrapping)’이라고 합니다. 제가 하는 사업 분야에서 초기에 가장 많은 돈이 들어가는 영역은 인건비입니다. 그래서 팀을 꾸릴 엄두를 못 내고 있죠. 또한 사업의 비전과 방향은 일관성 있지만, 세부 실행 계획은 다양한 실험으로 꾸준히 조정하고 있습니다. 이 피할 수 없는 혼란기를 혼자 치러내는 것이 더 효율이 좋다 생각하기도 하죠. 여러모로 제겐 부트스트래핑 전략이 적합합니다.

유남주: 자연스럽게 비용을 줄이려고 많이 노력해야겠네요. 어떤 노력을 하고 계세요? 엔지니어링 측면에서 비용을 줄이는 노력도 있나요?

기다리고 반복하는 일의 자동화로 ‘시간’을 아끼다

한날: 제게 가장 비싼 비용은 시간이에요. 혼자 일하니까요. 그래서 시간을 아끼기 위한 결정을 많이 하고 있어요. 특히, 자동화 도구를 여러 개 유료로 쓰고 있어요.

유남주: 하나만 소개해 주실 수 있나요?

한날: 푸딩캠프는 이렇게 온라인에서 무료 커피챗 서비스를 운영하고 있잖아요. 개발자 이력서나 포트폴리오 멘토링을 많이 하고, 웹페이지에서 신청할 수 있죠. 사용자가 커피챗을 신청하면 세 가지 항목이 만들어져요. 첫 번째는 당연히 푸딩캠프 미팅 데이터고, 두 번째는 줌(Zoom) 미팅 일정이죠. 세 번째로 구글 캘린더 일정이 만들어져 저와 신청자에게 초대장을 보내요. 이 초대장에는 줌 미팅 정보도 들어가요. 이제 신청자는 구글 캘린더 일정에 첨부된 줌 미팅으로 시간을 맞춰 들어올 수 있어요.

커피챗을 마치면 이때부터 자동화 작업 흐름(Workflow)이 수행돼요. 줌에서 진행하는 커피챗은 자동으로 녹화가 이뤄지거든요. 미팅이 끝나고 기본 처리를 마친 줌 녹화본 영상은 자동으로 두 곳에 보내지는데, 하나는 영상을 텍스트로 요약하는 인공지능 서비스예요. 꽤 잘 요약해 줍니다. 또 다른 곳은 유튜브예요. 영상을 유튜브에 미공개로 업로드한 다음 커피챗 신청자에게 제공하죠. 이러면 신청자가 유튜브 영상 URL을 외부에 공개하지 않는 한 다른 사람에게 노출되지 않아요.

두 가지 작업이 끝나면 푸딩캠프 서버에 완료 사실이 전해져요. 작업별로 관련 데이터를 저장하고 커피챗 신청자에게 이메일을 보내죠. 푸딩캠프 디스코드 서버인 ‘푸딩까페’, 웹사이트 뉴스피드로도 이에 대한 소식이 올라와요.

유남주: 자동화라기보다는 일반적인 기능 구현 같이 느껴지기도 하는데요?

한날: 이를 자동화라고 한 이유가 있어요. 줌 녹화 영상 처리, 유튜브 업로드, AI 텍스트 요약에 모두 시간이 걸리기 때문이죠. 이를테면 한 시간짜리 녹화 영상을 다운로드할 수 있도록 줌이 처리하는 데 짧게는 몇십분, 길게는 몇 시간이 걸려요. 각각 작업이 끝나는지 지켜보다 완료되면 필요한 데이터를 가져와 후속 작업을 해야 하는 거죠. 전체 과정을 마치는 데만 해도 한 시간에서 세 시간 정도 들어가고요.

유남주: 대기 시간이 없으면 시간 절약이 엄청 크겠어요.

한날: 그뿐만 아니에요. AI 도구로 자동화를 구현하는 데 들인 시간도 많이 절약했어요. 3:7 정도 비율로 도움을 받았죠. 제가 구현한 게 3 정도고, 나머지는 자동화 작업 흐름 도구로 처리했어요. 자피어(Zapier)나 메이크(Make.com) 같은 서비스죠.

유남주: 메이크는 처음 들어봐요. 어떻게 활용하세요?

한날: 자피어에 비하면 비교적 신생 서비스인데요. 시각화가 잘 되어 있어요. 제가 활용하는 방식으로 예를 들게요.

인공지능 도구가 줌 녹화 영상을 텍스트로 요약하면, 이 요약본을 제가 지정한 구글 스프레드시트에 추가해요. 또, 이 시트를 15분마다 확인해 새 행(Row)이 만들어 지면 후속 작업을 시작하죠. 두 가지 작업을 설정했어요. 하나는 새로 추가된 행의 Published 열에 ‘1’을 추가해, 중복으로 발행되지 않도록 막아 주는 일이에요. 두 번째 작업은 푸딩캠프 서버로 요약본을 보내는 거예요. 이때는 JSON 데이터로 보내야 하기 때문에, 개행 문자열과 따옴표를 이스케이핑(escaping) 처리하고 HTTP로 푸딩캠프 서버에 보내요.

유남주: 시각화가 왜 잘 되어 있다고 하신지 알겠어요. 흐름이 일목요연하게 눈에 딱 들어와요. 문자열 가공 같은 작업도 해주면 프로그래밍으로 처리할 많은 작업이 줄겠어요. 그래도 굳이 유료로 쓸 필요가 있을까요? 멘토님이 코드로 직접 구현하면 금방 끝날 것 같은데요.

한날: 이런 작업 흐름 도구를 만들려면 손이 많이 가요. 전에 유남주 님이 구글 소셜 로그인(OAuth2) 연동하는 데만 해도 이틀인가 사흘 걸렸다고 했죠? 로컬 연동은 몇 시간 만에 해도 실 서버에 올리니 예상 못 한 문제가 발생해서 시간이 생각보다 많이 걸렸다고요. 사실 그렇게 시간이 들어갈 일은 아닌데, 어느 지점에서 시간이 많이 걸렸나요?

유남주: 코딩할 때와 다르게 오류 상황이 생겨도 그다지 도움이 되지 않는 오류 메시지가 오더라고요. 그나마도 피드백을 받는 데 시간이 걸리고요. 프로젝트 배포할 때와 비슷했어요. 도움이 되지 않는 오류 메시지나 피드백 받는 데 걸리는 시간이요.

한날: 그런 외부 서비스 연동 작업을 적게는 몇 개, 많게는 몇십 개씩 해야 한다고 생각해 보세요. 메이크의 가격은 1년에 110 달러 정도인데, 그것만 고려해도 충분한 값어치를 하죠.

‘누군가 대신 해주면 좋은 일’도 비용을 아낄 수 있다

유남주: 커피챗 내용을 인공지능으로 요약한다고 하셨잖아요. 저도 그렇고 요즘 사람들이 인공지능 서비스를 많이 쓰더라고요. 커피챗 말고 다른 데에도 인공지능 서비스를 활용하세요?

한날: 여러 곳에 쓰고 있죠. 우선 많은 사람이 그렇듯 코딩 작업할 때 사용하고 있고요.

또, 푸딩캠프에서는 커피챗 말고도 몇 군데 더 요약 서비스를 제공해요. 하나만 소개할게요. 디스코드 커뮤니티인 푸딩까페에는 다양한 콘텐츠와 참여형 활동 거리가 올라와요. 여기에 제가 구독하는 유용한 뉴스 사이트나 블로그의 콘텐츠를 소개하고 싶었어요. 그런데 이 작업은 사실 번거로워요. 그래서 인공지능으로 요약해 제공하죠. 아래 이미지도 그중 하나예요.

유남주: 생각보다 괜찮은걸요? 그런데 원문에 없는 참고 자료가 있네요?

한날: 네, 출처가 있는 참고 자료를 3개 이하까지 함께 제시해 달라고 프롬프팅을 했기 때문이죠. 다만 대부분 출처가 정상이어도, 가끔 환각 증상이 일어나 존재하지 않는 URL을 출처로 제시하더라고요. 그래서 관심 있는 사람은 직접 찾아볼 수 있게 아예 참고 자료 출처 URL을 뺐어요.

이런 요약 작업은 프롬프팅을 어떻게 하느냐에 따라 요약 품질이 갈려요. 그런 만큼 꾸준히 프롬프트를 조금씩 손봐야 하죠. 300여 자로 시작한 프롬프트가 이제는 1000자 정도까지 늘어났어요. 초기에 사용한 프롬프트를 공개해 봅니다.

이 자동화로 사용자들에게 콘텐츠를 제공할 때 손이 전혀 들어가지 않아 시간을 절약할 수 있었죠. 그뿐만이 아니에요. 저도 요약본을 읽고 나서 원문을 읽을지 결정하기 때문에 콘텐츠를 소비하는 데 들어갈 시간도 줄였어요.

하지만, ‘디렉팅’ 비용은 절약할 수 없다

유남주: 인공지능 활용이 기대에 못 미친 경우도 있어요? 써보다 더는 사용하지 않는 부분이 있는지도 궁금해요.

한날: 몇 가지 있죠. 대표적인 건 웹 디자인이에요. 사람은 정해진 시간대에 일을 하지만 인공지능은 언제나 저와 함께하고 비용도 저렴하니까, 처음에는 디자인을 맡겼었죠. 푸딩캠프 알파 버전 보신 적 있나요?

유남주: 기억나네요. 겉보기엔 많이 엉성해도, 해키한 구현이 있었던 걸로 기억해요.

한날: 엉성…하긴 했어요. 저는 좋아했지만. 이 디자인, 인공지능이 해준 거예요. 물론 전체를 디자인한 건 아니고, 부분 부분 인공지능이 디자인한 걸 제가 조합한 거죠. 따로 놓고 보면 괜찮아도 합치니 엉성해지더라고요. 사람이 방향성을 가지고 지시해야 한다는 걸 절감했어요. 제가 코드는 디렉팅할 수 있어도 디자인 역량과 감각이 없으니 그쪽 디렉팅은 힘들더라고요. 완성도는 결과물이 말해줬고요.

지금 디자인은 사람 디자이너에게 의뢰한 결과에요. 디렉팅 역량이 안 되는 제가 초기 디자인을 조금씩 확장하다 보니 다소 엉성한 곳도 있지만, 최대한 초기 디자인 컨셉과 디렉팅을 상기하며 만들다 보니 깔끔한 편이에요. 거의 모든 페이지가 새로 생기거나 바뀐 걸 감안하면 말이죠.

홈 서버라고 안 될 이유는 없다

유남주: 시간이 아닌 현금을 엔지니어링으로 절약한 사례도 있어요?

한날: 있죠. 푸딩캠프는 몇 달 동안 홈 서버로 운영했어요. 정확히는 홈 서버라기보다 작업 PC 서버라고 해야겠군요. 서버가 물리적으로 위치한 곳이 제 사무실이었으니까요. 알파 버전부터 꽤 긴 시간 운영했죠.

유남주: 클라우드가 아닌 작업 PC에서 실제 서버를 운영하셨다고요? 안전한 환경이 아니지 않아요? IP 주소가 바뀌거나 정전이 날 수도 있잖아요.

한날: 제 작업 PC는 어지간해서는 꺼지지 않아요. 게다가 우리나라 인터넷망과 전력망은 매우 안정적이죠. 한 번 할당된 IP 주소가 잘 바뀌지 않는 편이고요. 또, 사용자가 많지 않아 잠시 서버에 문제가 생겨도 그다지 치명적이지는 않았어요. 그래서 주저하지 않고 작업 PC 하나를 서버로 구성해 푸딩캠프 웹사이트를 운영했죠. 물론 짧은 정전 상황을 대비하는 엔지니어링 구성도 마련했어요. 여태껏 그런 상황은 일어난 적은 없었지만요.

유남주: 정전에 대비할 시간을 들인 만큼, 클라우드에서 서버를 운영하는 것보다 시간 낭비가 있던 것 아니에요? 홈 서버로 운영하는 것이 어떤 장점이 있나요?

한날: 요즘 6개월짜리 토이 프로젝트를 하고 있다고 들었는데, 초반 프로젝트를 배포해서 운영해 보셨나요?

앞서 저는 유남주 님과 멘토링하며 포트폴리오 계획을 세웠습니다. 전체 6개월 계획으로 각각 1개월짜리, 2개월짜리, 3개월짜리 프로젝트를 개발하고 운영하는 것이었습니다. 세 프로젝트 모두 무조건 출시해 운영하는 조건으로, 첫 1개월짜리 프로젝트부터 배포하고 고객을 만나 피드백을 받아야 하죠. 2개월짜리 프로젝트에서는 운영에 필요한 환경을 구축해야 합니다.

유남주: 네, 1개월짜리 프로젝트를 얼마 전에 출시해서 운영하고, 지금은 2개월짜리 프로젝트를 하고 있어요. 그런데 첫 프로젝트 배포에서 엄청 고생했어요. 실 서버에 배포하는 건 처음 해봤거든요. 분명 로컬에서 다 확인했는데, 실 서버에 올리니 생전 처음 보는 문제에 수차례 직면하더라고요. 거의 일주일 걸렸는데, 나중에는 막 울고 싶었어요. 출시 경험이 많은 멘토님은 그런 고생 안 하시죠?

한날: 그럴 리가요. 돌아버리겠네, 라고 중얼거리는 일이 다반사죠. 저는 출시할 때 최대한 각종 도구의 버전을 최신판으로 맞추거든요. 그러니 과거의 배포 경험이 안 통할 때가 많아요. 경험에 비추어 새로운 상황과 환경에 적응하고 활용하지만, 어쨌든 과거의 경험이니 언제나 새로운 환경과 상황에 딱 맞지는 않죠. 그래서 배포와 배치에 시간을 보수적으로 할애해요.

반면 작업 PC는 제가 늘 사용하는 환경이잖아요. 새로운 게 없죠. 조금 압축해서 표현하자면, 서버가 사용할 네트워크 포트 번호만 바꾸면 배포가 끝나요. 모니터링하기도 좋아요. 고개를 옆으로 돌려 모니터를 쳐다보면 되거든요. CPU 코어 8개, 램은 128기가로 사양도 넉넉하죠. 새로운 기능을 배포하기 전, 애플리케이션 서버를 구동해 두고, 새 기능을 적용한 애플리케이션 서버도 구동한 다음, 문제가 발생하는지 체크해요. 문제가 생기면 일단 문제가 없는 이전 버전 애플리케이션 서버로 재빨리 전환하면 그만이에요. 바로 옆에 있는 PC에서 대응할 수 있거든요.

유남주: 수동 엔지니어링 환경이 자동화 환경보다 시간 측면에서 더 저렴할 수도 있군요.

한날: 빈도가 많지 않은 단순한 환경이니까요. 물론 지금은 하루에도 몇 차례씩 배포하니 예전처럼 관리하지는 못해요. 자동화를 했죠. 하지만 당시에는 기왕 늘 켜져 있는 작업 PC, 그리고 늘 구동되어 있는 애플리케이션 서버이니 여기에 인터넷 도메인만 연결하면 배포 끝이었어요. 네트워크나 전기료는 거의 같은데, 제 작업 시간을 많이 줄였으니 비용을 절감한 셈이죠.

여기에 홈 서버 도메인 연결하고 네트워크 연결 제어하는 건 클라우드플레어를 이용했어요. AWS보다 편리하게 제어하도록 API와 관련 제품을 제공하거든요. 가령 주 작업 PC에는 새로운 기능을 적용한 애플리케이션 서버가 돌고, 보조 작업 PC에는 이전 버전이 돌고 있을 때, 간단한 스크립트로 도메인에 연결되는 서버를 교체할 수 있게 했어요.

특히 도커를 사용해 동작 환경을 일치시킨 것도 주요했는데요. 아주 작은 차이도 없이 개발 환경과 서버 환경을 완벽히 일치시켰어요. 주 작업 PC의 CPU는 애플 실리콘이고, 푸딩캠프 웹 서버가 구동되던 보조 작업 PC는 CPU가 인텔이었는데 말이죠.

유남주: CPU는 아예 아키텍처가 다른 걸로 아는데, 어떻게 일치하게 만든 거예요?

한날: 보조 작업 PC를 도커 원격 호스트로 만들었거든요. 간단히 말하면 보조 작업 PC에 도커 서버를 구축하고, 주 작업 PC에서 도커를 사용해 실제 컨테이너는 보조 작업 PC에서 구동하도록 만든 거예요. 서버와 작업 PC의 도커 이미지가 같으므로 사소한 차이에서 발생할 문제 소지를 원천 차단한 셈이죠. 그 덕분에 주 작업 PC에서 작업하던 기능에 새롭게 설치하는 라이브러리가 있더라도 마음 편히 보조 작업 PC인 서버로 배포할 수 있었어요. 사실 저도 처음부터 알던 기능은 아니었어요. 홈 서버를 운영하며 시간과 신경을 조금이라도 덜 쓰고 배포할 방법을 고민하다가 떠올린 거죠.

내 서비스에 맞는 ‘인프라 서비스’로 비용을 아끼다

유남주: 지금은 서버를 어떻게 관리하세요?

한날: 아마존 웹 서비스(AWS)의 라이트세일(Lightsail)이라는 상품을 이용해요. 푸딩캠프 서비스 구성은 아직 단순해서 설정할 것이 별로 없는 라이트세일이 제격이죠. 특히 애플리케이션 인스턴스 서버, 데이터베이스 서버를 주로 쓰는데, 다 합쳐서 한 달에 50달러 정도 내요. 이번엔 배포 자동화를 좀 더 구성했는데, 블루 그린 배포(Blue/Green Deployment)* 전략을 따랐어요.

*블루 그린 배포는 소프트웨어를 업데이트하는 배포 전략입니다. 현재 운영 중인 버전을 블루, 동일한 환경에 새로운 버전을 그린이라 하죠. 새 버전이 테스트되고 준비되면, 트래픽을 블루에서 그린으로 순간적으로 전환합니다. 이를 통해 서비스 다운타임을 최소화하고, 문제 발생 시 신속하게 이전 버전으로 롤백할 수 있습니다.

유남주: 정말요? 반응이 빨라서 서버 인프라가 더 고사양일 줄 알았어요.

한날: 지금보다 사용자와 기능이 적었을 땐 더 단순하게 구현했어요. 요청 들어오면 그대로 데이터베이스에서 정보를 가져와 응답하는 구조였죠. 그렇게 운영하다 보면 어느 부분이 잘 안 변하는지, 그러니까 어느 부분이 컴퓨팅 자원을 쓰는지 보여요. 그런 후 우선순위에 따라 점진적으로 캐시(Cache)를 적용해요.

그렇게 야금야금 캐시를 적용하다 보니 지금은 전체 웹페이지 중 80%에 캐시가 적용되어 있어요. 사용자가 접속해 HTTP 요청이 발생해도 새로이 화면을 만들어 반환하는 게 아니라 이미 만들어 놓은 화면을 그대로 반환하는 거죠. 참고로 캐시는 RDBMS, 그러니까 관계형 데이터베이스를 사용하고 있어요.

유남주: 레디스(Redis) 같은 인 메모리(In-memory) 데이터베이스를 사용하지 않고요? 그런 류가 성능이 좋다고 배웠는데요?

한날: 어차피 대부분 시간 동안 데이터베이스 서버는 쉬고 있어요. 단순히 유니크 속성이 걸려있는 열(Column)에 키로 짝지어진 값을 가져와 그대로 사용자에게 반환하는 건 RDBMS도 충분히 빨라요. 여기서 중요한 건 ‘충분히 빠르다’는 점이에요. 푸딩캠프 사용자들의 활동은 대부분 디스코드에서 이뤄져요. 웹사이트는 콘텐츠를 보러 방문하는 거예요. 그러니 성능이 엄청 빠르다 해도 그다지 체감되지 않아요. 몇십에서 일이백 밀리초를 희생하는 대신 데이터베이스를 캐시 저장소로 써서 얻는 이득이 훨씬 크죠.

우선 기술 스택이 늘지 않아요. 앞서 말했듯 푸딩캠프는 저 혼자 개발하고 운영해요. 지금처럼 멘토링도 하고, 콘텐츠도 만들죠. 얼마 전에는 콘퍼런스를 주최했고, 토이 프로젝트팀도 코칭하고요. 그래서 신경 쓸 게 늘면 곤란해요. 문제가 발생했을 때 추적할 요인이 늘어나면, 그 하나하나가 다 제 시간을 잡아먹죠. 하지만 데이터베이스를 캐시 저장소로 쓰면 데이터베이스 상태만 신경 쓰면 돼요.

무엇보다 편한 점은 운영 도구 페이지(Admin)에서 캐시를 관리한다는 점이에요. Admin 페이지는 데이터베이스 구현 도구인 ORM(Object Relational Mapping) 기반으로 대부분 UI가 자동으로 만들어져요. 그래서 코드 몇십 줄이면 캐시 데이터를 Admin UI로 관리할 수 있죠.

유남주: 하지만 트래픽이 늘어 레디스 같은 다른 저장소로 변경할 때, 구현을 전체적으로 손봐야 하는 비용도 있지 않을까요?

한날: 캐시 구현체를 추상화(Abstraction)했기 때문에 코드 몇 글자만 바꾸면 돼요. 이런 건 한 시간 정도 신경 써서 구현하면 끝나는 일이지만, 관리할 기술 스택을 늘리면 꾸준히 신경 쓰고 시간을 내야 하죠.

유남주: 엔지니어링으로 실질적인 비용을 줄이려는 노력이 인상적이에요. 참, 그런데 왜 AWS로 서버를 옮기신 거예요?

한날: 단순해요. 집에서 컴퓨터가 필요하다고 해서 보조 PC를 빼야 했거든요.

유남주: 앗….

유남주 님의 어색한 답변과 함께 이번 인터뷰는 끝이 났습니다. 곧 자동화 작업 흐름에 따라 텍스트 요약본과 비공개 유튜브 링크가 만들어 전달될 것입니다.

마치며

우리는, 아니 저는 ‘프로그래밍 능력’이라는 망치를 든 채 ‘기능’이라는 못을 찾아다니곤 했습니다. 소프트웨어 엔지니어인 저는 프로그래밍을 포함한 소프트웨어로 문제를 해결해야 했지만, 망치를 너무 사랑한 나머지 프로그래밍만으로 많은 문제를 풀어 보려 했습니다.

그러나 현재 푸딩캠프는 많은 외부 서비스에 의존하고 연동하며 운영되고 있습니다. 물론 최근 업무의 종류가 늘어나며 제가 하루에 쓸 수 있는 시간이 부족해졌는데, 관리할 요소가 늘어난 건 부담이기도 합니다. 하지만 구글 서비스는 뜬금없이 서비스 종료를 하는 경우는 있어도, 제가 만든 기능과 서비스보다 훨씬 안정적으로 동작합니다. 대다수 외부 서비스는 여러 개발자가 개발하고 관리하니까요.

물론 현금 자체를 절약해야 하는 경우도 있습니다. 아니, 그런 경우도 있는 게 아니라 늘 절약해야 하지요. 하지만 서비스 이용료는 대부분 내 인건비보다 월등히 저렴합니다. 홈 서버 역시 궁극적으로는 시간과 신경 쓰는 비용을 줄이는 것이 목적이었지, 지금 나가는 서버 비용 50달러를 절약하는 것이 목적은 아니었습니다. (어느 날부터 새로 서버 비용을 지출하려니 신경 쓰이긴 했지만요.)

여러분의 가장 비싼 자원은 무엇인가요? 그 자원은 엔지니어링으로 절약할 수 있나요? 그렇다면 지금 바로 절약해 보세요.

©️요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.