Business first
나도 지금보다 경험이 부족했을 때는 좋은 엔지니어링이란 흔히 말하는 유지보수하기 쉬운 코드를 작성하고, 확장하기 좋은 코드, 왠지 깔끔한 코드를 작성하는 일이라고 생각했는데, 틀린 말은 아니지만 이 걸 좋은 엔지니어링이라고 부르기는 힘들다고 생각한다.
오히려 좋은 엔지니어링은 비즈니스를 우선하여 고려하고, 스펙에서 부족한 부분을 채워넣고, 더 나은 사용성을 제공하는 것을 우선시할 수 있어야 한다. 그 부분이 충족되었을 때가 비로소 앞서 말한 유지보수하기 쉽고, 확장하기 좋은 코드를 고려해야하는 순간이다.
광신적 아키텍처, 과도한 우려
때로 비즈니스의 요구사항보다 아키텍처가 우선시 되는 경우가 있다. 나도 여러번 했던 실수지만, 흔히 말하는 ‘OO 기술을 사용해보고 싶다’ 라는 이름으로 시작되는 것들, 또는 흔히 말하는 MSA, SSR, SPA 등등.
모든 아키텍처, 기술에는 장단점이 있고 어떤 것을 정답이라고 말하기에는 애매하다. 정답처럼 보이는 것들은 몇가지 있다. 예를 들어 프런트엔드에서는 리액트를 쓰는 것이 당연하다는 뉘앙스, 또는 빌드 도구는 Vite 를 사용해야하고, Java를 사용한다면 Spring 을 사용하는 것이 응당 당연한 것이고 등등.
당장 비즈니스의 미래를 파악하지 못한 상황에서 ‘일어나지 않은 일에 대한 과도한 우려’는 오히려 코드를 쓸데없이 복잡하게 만드는 경향이 있다. 이 말은 ‘미래를 우려하지 마라' 라는 것이 아니라, ‘과도하게 우려하지 마라’ 라는 것이다.
당장 하루 트래픽이 1,000명밖에 안되는 서비스에 당장 100,000명을 지탱할만한 시스템을 만들 필요는 없다. 언젠가 100,000명까지 급속 성장할 수도 있겠지만 그 시기가 언제일 지는 아무도 모른다.
왜 그걸 해야하는가?
생각보다 꽤 많은 경우에서 어떤 일을 하는 이유가 하고싶어서인 경우가 많다. 때로는 직감이 시키는 일이 정답일 때도 있지만, 대부분의 경우 직감이 시키는 일은 직감이 시키는 일에서 그친다.
서비스의 안정성을 높이기 위해서 OOO을 하려고 한다. 라는 말을 하려면 지금 상황이 어떠하고, OOO을 하면 미래에 어떤 식으로 서비스의 안정성이 높아지는 지를 파악하여야 한다. 비용 측면을 고려한다면 더욱 좋겠지만, 비용 측면을 당장 고려하기보다는 어떤 문제점을 어떻게 해결할 수 있는가에 대해 더욱 집중하면 좋겠다. 그렇게 하면 방향성을 어느정도 그릴 수 있게된다.
대부분의 사람들의 뇌리에 박혀있는 공통적인 방향성 또한 존재한다. 매일 30분 유산소 운동을 하면 대부분의 경우에는 지금보다 건강해질 것이다. 같은 것들이다.
- 테스트 커버리지를 높이고 테스트 케이스를 치밀하게 작성해둔다면 서비스에 새로운 기능을 추가할 때 더 안정적으로 추가할 수 있다.
- 함수명을 명확하게 지으면 추후 유지보수 과정에서 코드를 파악하는 데 도움이 된다.
- 할 일 관리 도구에서 할 일을 잘게 쪼개고, 매일 작은 업무를 처리해나가는 과정을 반복해나가면 업무 투명성이 높아지고 더 직관적인 업무 진행이 가능하다.
- 새로운 서비스를 구현하기 전에, 미리 문서를 작성하여 시스템 전체에 대해 분석하고 어떤 방향성으로 구현할 지 동료들과 리뷰하면 서비스 구현 과정에서 겪을 이슈를 사전에 파악할 수 있다.
아무리 좋은 코드를 작성해도
서비스가 망하면 크게 의미가 없다. 망한 서비스는 망한 서비스인 것이다. 함수명을 기깔나게 작성했던, 테스트 커버리지를 100%를 유지했던 상관 없다. 개발자 개인에게는 뜨거운 경험으로 남았겠지만, 서비스가 망한다는 건 말 그대로의 의미를 내포한다.
당장 모든 것이 마음에 들지 않아도, 비즈니스를 궤도에 올린 후에 하나씩 뜯어고쳐나가면 된다. 새로운 코드에 대한 테스트 커버리지를 80% 이상으로 고정한다거나, 시스템 전체의 모니터링 환경을 재구축한다거나, 불필요하게 쓰이는 자원이 없는가 등등. 우리에게는 비즈니스가 정상 궤도에 오른 후에도 더 많은 일이 남아있다.
나는 늘 비즈니스가 우선이라고 생각한다. 모든 비즈니스의 요구사항을 들어주기는 어려울 수 있어도, 비즈니스에 이로운 방향을 늘 고려하여 개발해야한다. 적어도 취미 개발자가 아니라면 말이다.
