나의 개발 마인드 변화기 (feat. CDN)

1️⃣. 햇병아리 과거를 떠올리며

때는 바야흐로 개발을 시작한지 3개월... 🐥

나는 Palmspring 을 개발하면서 완전한 서비스를 위해 기능 구현 에 매진하고 있었다.

MIND23 컨퍼런스에 참여해 Palmspring에 관심을 가져주는 여러 개발자 분들에게 홍보를 하다가도

당시의 나는 개발을 시작한지 오래되지 않았고, 그에 반해

컨퍼런스에 오는 분들은 현업 개발자 분들이셨기 때문에 어떻게 하면 가격을 더 적게, 안전한 기능을 만들 수 있을지 경험 공유를 부탁드리기도 했다.

그래서 지금 보면 꽤나 햇병아리 같은 이런 글을 작성하게 됐다. 물론 지금도 햇병아리

당시 나에게 관심있던 주제는 기술 기능 포트폴리오 였다.

글을 보면 알 수 있듯이 내부 로직을 만드는 것에만 집중하고 있다.

특히 이미지 용량은 사용자에겐 전혀 관심 없는 주제가 아닐까?

왜 사용자를 위한 개선은 없지?

그리고 이 글은 기술의 도입과 기능만을 생각하던 마인드가 요즘은 어떻게 변화되었는지를 중심으로 서술해보려고 한다.

2️⃣ . "완벽한"은 존재하지 않는다.

서비스를 정식으로 배포하고 한 유명 IT 단톡방에서 소개되면서,

모 앱에서 며칠간 트렌딩 1위를 차지하며 실제 "유저" 를 받을 수 있게 되었다.

🐥햇병아리🐥 같은 개발자에겐, 실제 유저란 꿈만 같은 일이 아닐 수 없었다.

그러나 그 뒤부터 유저가 몰림으로 인한 불안정한 서버, OOM 을 비롯해서, 찾지 못했던 케이스들까지

여러 피드백들이 유저로부터 날라왔고 고쳐야 할 점들이 수두룩 발견되기 시작했다.

(이때 정말 OOM은 원인을 찾느라 고생을 많이 해서 이 경험으로 테코톡을 했다.)

당시에 나는 이 에러들이 코드를 좀 더 잘 짜지 못하고 떠올리지 못했던 내 탓 이라고 생각하며

에러가 올라오면 굉장히 괴로워했다.

여행을 가도, 친구와 만나도 잠을 자기 전까지도 거의 노트북과 연애를 하는 것 마냥 꼭 안고 다니며

에러가 나면 놀다가도 근처 카페에 앉아 처리하곤 했다.

" 서버가 내려가든 오류가 생기든 고치면 되지~ "

라는 마인드가 더이상은 적용되지 않았고

완벽해야 한다, 에러를 누군가가 실제로 마주하고 그것이 서비스의 이미지로 갈 수 있다는 그 생각과 책임감이 너무 무겁게만 느껴졌다.

그렇게 긍정적인 멘탈을 가지고 급급하게 틀어막기 시작했다.

나는 Palmspring 을 개발하면서 완전한 서비스를 위해 기능 구현에 매진했었다.

그러나 앞서 표현했듯이, 그 당시의 우리 팀원들은 모두 미쳐있었다.

그 보다 더 할 수 있었을까? 를 생각하면 나는 아니라고 대답할 것 같다.

당시에는 그게 최선이었고, 내가 당시에 겪었던 경험에서의 한계였다고 생각한다.

3️⃣ . 마법의 수정구슬은 없다.

내가 서비스를 올리기 전,

한 대표님으로부터 자문을 구하며 이런 얘기를 들은 적이 있다.

"개발쪽은 이런 말이 있어요 마법의 수정 구슬은 없다. 앞일은 누구도 예측할 수 없기에 상황에 맞게 대응해야 오버엔지니어링이 생기지 않는거죠"

"기술은 뽐내려는게 아니고 비즈니스 문제를 기술로 해결해야 하기에 기술이 오버엔지니어링이 되면 안됩니다."

"창업을 생각한다면 무조건 배포해서 고객에게 두드려 맞아봐야 합니다"

새로운 기술과 기능, 가격 절감에만 집중했지 정작 사용자가 느낄 수 있을 문제가 있을지는 크게 고민해본 적 없음을 깨달았다.

유저는 내가 멋드러진 기술을 쓰든, 깡으로 코드를 쓰든 관심없지 않을까?

내 기술 선택의 목적은 무엇인가? 무엇을 해결하려고 했던 것이지? 문제가 명확했었나?

이후 내가 기술을 굉장히 동경하고 있었다는 사실을 알았다.

기술은 언제든 학습만 한다면 배울 수 있는 것이다.

중요한 것은 문제의 우선 순위를 정하고 핵심을 파악하고,

그 문제에 어떤 도구를 사용하는게 좋겠냐는 고민을 하는 것이라고 생각하게 되었다.

문제에 대해 고민해보았더라도 내가 코드에, 기술에, 기능에 고민하는 만큼의 시간을 소모했을까?

부끄럽게도 그동안은 아니었던 것 같았다.

그 순간부터는, 먼저 어떤 기술을 사용할지 생각하기 보다는

문제의 핵심을 먼저 파악하고,

이 문제를 해결하기 위해서 어떤 것이 가장 적절할지에 대해 먼저 생각하기 시작했다.

4️⃣ . 수치로 알아보는 문제

다시 처음으로 돌아가보자.

이미지 저장 이라는 기능만 바라본다면

사진을 한 두장 올려 이미지가 정상적으로 저장되는가? 를 확인하는 것 만이 중요한 태스크가 될 것이다.

그렇지만 블로그라는 도메인이라면? 역시나 유저가 생기고 문제가 발생했다.

블로그의 핵심은 "글" 이다.

그런 글이 로딩되는 것에 길게는 4초 이상의 시간을 소모하게 되자 많은 주요 유저들을 이탈하게 만들었다.

이 맘때쯤 왜 진작 고려안했지? 같은 생각이 들겠지만 그런건 나중에 생각하자.

지금이라도 고민해보자.

현재의 문제는 무엇이지? 우리의 도메인은 무엇이 중요할까?

어디서부터 비롯되었지?

5️⃣ . 혼자 고민하지 말기

처음 Palmspring 과 함께 했을 때는

무슨 문제가 생겼을 때 공유하는 것에 힘들어 했었다.

내가 요청할 부분이 팀원에게 부담스러운 일이 아닐지 걱정이 돼 이왕이면 모든 것을 혼자서 처리해보려고 했었다.

그래서 웃기게도 산학연계 프로젝트 에서 백엔드가 아닌 프론트를 맡아도 나쁘지 않겠다고 생각했고

내가 프론트 지식을 조금이라도 알고 있다면, 의사소통에 편안함이 있지 않을까

싶었다.

혼자 깊게 고민해보는 것도 좋지만 이렇게 생각해보자.

나만이 그 로직과 코드에 대해 알고있다면, 문제가 생기더라도 그 문제를 해결할 수 있는 사람은 나 뿐이라는 소리다. (지옥 시작)

그래서 이전과는 다르게 상황을 공유하고, 문제가 무엇일지 그리고 무엇을 할 수 있을지 고민했다.

• Base64 로 들어갔던 이유를 파악한다.

• 지금 현재 이미지의 로딩 속도가 몇인지 측정한다.

우선 앞서 언급한 바와 같이 로딩 속도는 측정했고, Base64 로 들어간 원인도 프론트와 파악했으니

압축 로직을 포함한 S3 만을 사용한 이미지의 로딩 속도가 사용자에게 만족스러운가?를 고민해야했다.

답은 NO 였고, 유저가 더 빠져나가기 전에 빠르게 해결을 적용하기로 했다.

• ✅ 속도가 얼마나 감소 되는가?

• ✅ 가격이 얼마나 들어가는가?

• ✅ 빠르게 적용이 가능한가?

그렇게 이 3가지를 두고 도구를 고민하기 시작했다.

그리고 백엔드에서 결정하게 된 것이 이 얘기의 제목인 CDN 이다.

(물론 이 외에 많은 로직들이 변경되었지만 글의 주제는 아니니 언급하지 않겠다.)

8️⃣ . 도입 후 결과

이후 비슷한 속도가 걸리던 페이지를 접속했을 때, 이와 같은 결과가 나왔다.

무려 약 3s 이상이 걸리던 글이 144.34 ms 로 줄었다. 🥹

(물론 그 외 부가적인 로직들도 추가했지만)

이로써 아티클이 로딩되는 속도로 인한 유저의 탈퇴는 막을 수 있었고 더이상 그러한 피드백이 들어오지 않았다.

9️⃣ . 이로써 끝..?

물론 기존에 존재하던 응답이 느리다 라는 문제는 어느정도 해결이 되었다.

그러나 언제든 이와 같은 일이 발생할 수 있고, 그때마다 API 를 수정하고 개발하는 방식도 좋지만

앞서 말했듯이, 우리 도메인을 분석하고 유저의 흐름을 파악하며 늘 이유와 원인을 가지고 우선순위를 세워 개발하는 것이 중요하다고 느껴졌다.

특정 직군이 잘 해결할 수 있는 문제는 그 직군과 공유하는 것이 좋다고 생각한다.

또 무조건 적인 기술로 해결보다는 정책을 먼저 탄탄히 잡아가고,

내가 지금 파악한 문제가 정말 사용자가 느끼는 문제가 맞는지 그저 내 개인적인 불편함에서 온 것이 아닌지 파악하는 것이 우선시 되었다.

아무튼 그래서 최근 회의에서는 이런 UX 개선을 제안하고,

제안된 기능들을 반영하여 기존 기능들을 업그레이드 하는 방식으로 스프린트를 이어나가고 있다.

마무리...

이로써 약 일주일동안 작성하던 글이 마무리 되었다.

언젠가는 이 글을 봤을때 한숨을 쉴 수도 있고, CloundFront 라는 도구도 당연히 바뀔 수 있다.

또, CDN 과 캐싱이 답이 아니었을 수 있다.

그렇지만 적어도 지금 내가 정의내린 문제를 해소할 수 있는 도구였다는 것이 확실하고

문제가 해결되었는가?

에 대한 질문이 YES 로 끝난다면 일단은 만족스러운 결론을 내렸다고 생각한다.

일단 문제가 문제인지 파악하고, 해결하고, 개선사항을 찾아보자!

앞으로 또 얼마나 새로운 걸 느낄지 기대된다. 우테코를 하면서도 적용해볼 수 있기를!

글에서 잘못된 부분이 존재한다면 언제나 피드백 환영입니다.

Footer 에 있는 메일로 연락 주세요 ☺️