다음에 서비스를 개발한다면 고려해볼것들

이전 경험(게시글 https://jjongguet.tistory.com/240 ) 을 경험한 이후 생각한점을 끄적여보았습니다.

 

 

1. 서비스 개발을 하는 이유

서비스가 ‘매력적’이라고 할 때, 누군가의 사소한 불편함을 해결해줄 수 있어야 의미가 있다고 본다. 즉, “이 서비스를 통해 무엇을 해결할 것인가?”가 명확해야 한다. 특히 하나의 서비스로 여러 문제를 동시에 해결하려다 보면 정작 아무것도 제대로 해결하지 못할 수 있다.

결국, 하나의 문제를 제대로 해결하는 게 훨씬 중요하며, 이는 중구난방으로 기능을 늘리는 것을 막아준다.

 

 

 

2. 기술 스택을 선택하는 기준

해결하고자 하는 문제를 정확히 정의했다면, 그다음으로는 어떤 기술 스택을 쓸지 고민해야 한다. 여기서 중요한 건 문제를 해결하는 데 필요한 최소한의 리소스만 사용하는 것이다.

오버엔지니어링을 지양해야 한다. 서비스 개발은 ‘사용자의 불편을 덜어주는 것’이 목표이지, 내가 배우고 싶은 기술을 마음껏 실험하는 무대가 아니다. “서비스 위에 있는 코드는 없다”라는 말을 떠올리면서, 무조건 복잡한 기술을 적용하기보다 문제 해결에 집중한다.

 

 

3. DB 테이블 설계

가장 고민이 많았던 부분이 DB 테이블 설계다. 특정 불편함을 해결하기 위해 서비스 개발에 착수했고, 문제를 정의한 뒤 가장 먼저 한 일이 테이블 구성이다.

예를 들어 Table1 하나만으로 문제 해결이 가능했다고 치자. 그런데 어느 순간, 추가 기능을 요청하는 고객이 생긴다. 기능 요구가 들어오면, 이를 위해 새로운 테이블(Table2)을 만들 수도 있다. 예컨대, Table2는 val1을 FK로 가져와 Table1과 조인(Join)해 사용하는 구조다.

그러다 보면 또 다른 방식으로 데이터를 합쳐서 관리하고 싶어질 수 있다. 이때 한꺼번에 전부 넣어 Table3처럼 ‘조인이 필요 없는’ 테이블을 만드는 무리수를 둘 수도 있다. 하지만 이런 식으로 모든 데이터를 한 테이블에 몰아넣으면, 확장성과 관리 측면에서 곤란한 상황이 생긴다.

이 과정을 겪으면서 “필요 이상의 데이터를 한 테이블에 다 넣는 건 하지 말자”라고 다짐하게 됐다.

 

 

 

4. 완벽보다 완성이 낫다

읽었던 책 중 ‘후회의 재발견(다니엘 핑크 저)’에서 가장 인상 깊었던 부분은 “사람은 직접 겪지 않은 선택에 대해 후회한다”라는 점이다. 이는 서비스 개발에도 적용된다고 본다.

서비스를 기획하고 개발할 때, 고려해야 할 요소는 무수히 많다. 예를 들어,

• UI/UX는 얼마나 직관적인지
• 요청 처리를 몇 초 내로 마칠 수 있는지
• 로깅은 어떤 방식을 쓰고, 배포 프로세스는 어떻게 구성할지
• 월 유지 비용은 어느 정도나 될지

이런 요소를 전부 완벽하게 맞추려다 보면 서비스 출시 시점이 계속 늦어진다. 하지만 완벽이란 없고, 결국 언제든 미흡한 부분이 생길 수밖에 없다. 차라리 빠르게 완성해 세상에 내놓고, 사용자 피드백을 받아가며 개선하는 편이 낫다.

 

 

마무리

아래의 내용으로 정리할 수 있을거같다.

• 하나의 문제에 집중하는 서비스를 만들어야 한다.
• 기술 스택 선택 시 오버엔지니어링을 피하고, 최소한의 리소스로 문제 해결에 집중한다.
• DB 설계는 확장성을 염두에 두면서, 테이블을 단순화하거나 과하게 합치는 건 지양한다.
• 완벽을 추구하기보다는 일단 서비스를 완성해서 사용자에게 선보이고, 개선점을 찾아가는 과정이 중요하다.

결국, 서비스 개발은 끊임없이 밸런스를 맞추는 일이다. 완벽함을 쫓다 보면 영영 출시하지 못하고, 그렇다고 모든 걸 대충 할 수도 없다. 위 과정을 거치면서 조금씩 나은 서비스를 만들어가는 게 개발자의 역할이라고 생각한다.