이 내용은 많은 책에서도 이미 다루고 있어서 고민했던 주제예요.

하지만 이런 내용을 다뤄달라는 기획자, 디자이너 지인들의 요청으로 포스팅을 만들게 되었어요. 프로젝트 관련해서 회의를 할 때, 기획자와 디자이너와 함께 회의를 할 경우가 있는데요.

실제로 경험한 이슈를 조금 변형해서 왜 백엔드 개발자로 근무하며 기획자의 요청에 안된다고 말한 경험이 있는지 이야기 해볼게요!

아래 요청 사례를 들어서 설명해볼게요.

No에 담긴 의미

이 요청에 대해 개발자의 거절을 여러 가지 의미를 담고 있을 수 있어요. 그래서 서로의 역할을 이해하고 해결할 수 있는 중간지점을 찾아야 해요.

1. 저는 지금 혼자서 이걸 다 할 수 없어요. 😨

먼저 개발에 대한 요청을 받으면 개발자는 현재 담당하고 있는 프로젝트들과 담당 업무와 기한을 먼저 생각해요. 주로 Jira와 같은 협업툴에서 일정 계획을 프로젝트 PM(Project Manager) 또는 PL(Project Leader)과 먼저 정한 기한들을 의미해요.

이렇게 당담하는 업무들과 프로젝트 사이에서 요청된 업무를 할 수 있도록 요청 내용을 협의할 필요가 있어요. 담당하고 프로젝트의 우선순위를 변경하거나 기한을 늘리거나 팀원과 협업이 필요할 수도 있을 것 같아요.

2. 반영하려면 성능 개선이 필요해요. 나에게 돈과 시간을 달라! 🤔

현재 운영 중인 서비스가 유저가 원하는 결과를 낼 수 있어야 한다는게 첫 번째 전제조건인데, 요청으로 인해서 메인 페이지에 데이터를 더 띄우기 위해 많은 정보를 처음부터 불러온다면 페이지 자체가 완벽하게 뜨는 속도가 느려질 수 있어요.

구글 리서치 자료에 따르면 모바일 웹 사이트의 로딩 시간이 증가할 수록 페이지 이탈률이 증가한다고 해요. (3초 이상일 때 32%, 5초 이상은 90%, 6초 이상은 106%, 10초가 넘으면 123% 이탈)

2-1. 돈으로 해결하자 💰💰💰

더 성능이 좋은 고사양의 컴퓨터가 있으면 고퀄리티 그래픽 게임을 할 수 있잖아요?

회사가 지원할 수 있는 예산 범위 내 더 고사양의 서버나 데이터베이스 분리로 안정적인 데이터를 제공할 수 있는 방법이 있어요.

또는 캐시 서버를 구축해서 미리 데이터를 불러온 뒤 다음 조회할 때, 빠르게 데이터를 가지고 오거나 서비스 운영 전에 미리 데이터를 캐싱하는 방법도 있어요.

동료 개발자들과 이야기해보면, 어느 정도는 회사에서 실제 자원(머니)으로 바로 해결한다는 의견도 있지만, 시간이 걸리더라도 비용이 들지 않는 방법이 필요하다는 의견도 있었어요.

위 내용을 더 알아보고 싶다면 다음 키워드에 대해 찾아보면 좋을 것 같아요.

• 클라우드 서버 엔진

• 데이터베이스 Read/Write 분리

• 인메모리 데이터베이스 캐싱전략

• 캐시 워밍 (Cache Warming)

2-2. 가지고 올 정보 자체를 바꾸기

요청한 추가할 'OO에 대한 정보'가 이미지일 때는 첫 페이지에 뜨는 이미지가 너무 많아 속도가 느리다면, 메인 페이지에 나오는 이미지들만 작게 만들어서 보관했다가 용량이 작은 이미지만을 불러오는 방법이 있을거예요.

압축가능한 이미지인지 저장소는 더 추가할 수 있는지 등등 고려해볼 사항들이 있겠죠.

말 그대로 텍스트 데이터라면 기획자와 함께 메인 페이지에 반드시 필요한 정보만을 새로 정의할 수도 있어요.

실제 데이터베이스 모든 테이블 정보를 모두 가지고 오는 것이 아니라 자주 조회되는 데이터들을 하나의 뷰(view) 테이블로 만들어서 더 빠르게 읽어올 수 있게 하는 방법도 있어요.

2-3. 두뇌를 이용하기 🧠

정보를 불러오고 화면에 보여주는 방법은 개발 언어로 만들어져요. 이 때 어떤 식으로 코드를 작성하느냐에 따라서 성능 차이가 발생해요.

이래서 알고리즘이 개발자에게 중요한 부분이예요.

알고리즘은 컴퓨터가 코드를 처리하는 방법이라고 쉽게 말할 수 있을 것 같아요. 수학문제를 생각해보면 복잡한 풀이를 사용하면 오래 걸리지만 쉬운 풀이방법이 있다면 더 빨리 풀 수 있는 것과 같아요.

상황에 알맞은 알고리즘을 개발이나 적용으로 성능문제를 해결할 수 있어요.

2-4. 가장 아름다운 협업으로 해결하기 💐

이미 운영서버에 평균 및 최대 접속자 수를 고려해서 메인 페이지 로딩 성능을 일정 수준으로 이미 맞춰놓은 상태라면 어떻게 해야할까요? 돈도 지원받을 수 없고, 기술력도 더 추가할 수 부분이 없다면 말이죠.

주로 성능에 대한 우려는 개선방법이 있지만 그 기한 내 바로 적용이 어렵다는 의견일 수도 있어요. A/B 테스트나 테스트 서버에서 안정적 검증을 맞춘 뒤 점차 운영 서버 전체 적용으로 변경하는 방안을 고민해봐야 해요.

3. 이 나비효과 어쩔거야 🦋

3-1. 코드를 많이 변경해야 하는 경우

혹시 아키텍처(Architecture)라는 말을 들으신 적 있나요?

개발 용어에서 아키텍처는 프로젝트 코드의 구성을 정하는 방식으로 생각하면 가장 쉬워요. 어떻게 집을 지을지 고민하는 부분이라고 할 수 있는데, '거실, 안방 순으로 만들지 혹은 동선을 안방에서 드레스룸이 이어지게 할지'와 같이 하나의 방식이예요.

개발을 할 때, 개발자는 모든 코드를 하나의 페이지에 다 작성하는 것이 아니라 여러 파일에 나눠서 작성하는데 이 때 기능과 동작하는 방식들이 나뉘는 기준이 돼요.

이 부분이 정말 개발자로서 설명하기 어려운 부분이예요. 🙄

요청을 받은 개발자는 요청한 프로젝트의 코드를 떠올리고 이 기능을 추가했을 때 반영되어야 하는 모든 부분을 떠올릴거예요.

3-2. 다른 성능도 고려해야 할 때

데이터베이스에는 원하는 정보를 쉽게 가지고 올 수 있도록 인덱스(Index)라는 것을 사용해요.

예를 들어, 어떤 정보에 대해 가장 최신 자료와 작성자의 이름 순으로 데이터를 가지고 오길 바란다고 해볼게요. 그렇다면 정보의 작성일자와 작성자 이름을 인덱스로 만들어서 더 빠르게 정렬할 수 있어요.

하지만 다른 정보를 추가해서 원래 인덱스 변경될 경우에는 어떻게 될까요? 원래 인덱스가 주는 성능 이점이 없어질수도 있어요.

이렇게 변경으로 인해 발생할 수 있는 다른 성능 이슈도 함께 고민해봐야 해요.

저도 적다보니 더 협업을 위해 개발자도 좀 더 이해하기 쉽게 설명하고 대안을 제시할 필요가 있다는 생각이 드네요! 이런 것들이 있구나 이해하고 관계 업무를 하는 분들의 고민을 줄일 수 있는데 도움이 되는 글이었기를 바래요. 🙏🙂