안녕하세요. 로워드 Front-end Division의 Lead를 담당하고 있는 이정호입니다.
로워드 팀은 검색어 빅데이터 분석 서비스인 로워드 서비스와 누적 거래액 200억에 달하는 노코드 기반 강의 호스팅 LMS 서비스와 워드프레스 관리형 호스팅 서비스인 로워드 브릿지를 개발하고 운영하고 있어요.
이번 글에선 로워드 팀에서 추구하는 개발 방식과 단순히 기능을 구현하는 팀이 아닌, 어떤 자세로 상품 개발에 임하고 있는지에 대해서 이야기를 남겨보려고 합니다.
나에게 주어진 일이 무엇인지 정확히 알고 시작해요
로워드는 단순히 하나의 서비스를 만드는 팀이 아니에요.
키워드 분석 플랫폼 로워드, LMS 강의 호스팅 플랫폼 ledu, 그리고 호스팅 서비스 로워드 브릿지까지, 세 가지 도메인을 동시에 개발하고 있어요. 각각의 서비스는 역할도 다르고, 사용자도 다르고, 해결하려는 문제도 달라요.
이런 환경이다 보니 신규 입사자나 중간에 합류한 분들은 모든 도메인을 완전히 이해하기 전에 일을 시작해야 하는 상황도 자연스럽게 생겨요. 그러다 보면 이런 생각이 들 수도 있어요.
“일단 만들고 나서 이해하면 되지 않을까?”
하지만 우리는 그렇게 일하지 않아요.
어떤 기능이 주어지면, 단순히 구현하는 것부터 시작하지 않아요.
이 기능이 왜 필요한지, 어떤 문제를 해결하려는 건지, 서비스 안에서 어떤 역할을 하는지부터 먼저 이해하려고 해요. 기능 하나가 전체 흐름 안에서 어떤 위치에 있는지를 아는 게 훨씬 중요하다고 생각하기 때문이에요.
그래서 작업을 시작하기 전에 팀원이나 리더와 충분히 이야기하는 시간을 꼭 가져요. 요구사항을 다시 정리하고, 놓친 부분은 없는지 확인하고, 서로 같은 방향을 보고 있는지를 맞추는 과정이에요.
우리는 결과를 만드는 속도보다, 제대로 이해하고 만드는 과정을 더 중요하게 생각해요. 이해 없이 만든 결과는 결국 다시 돌아오지만, 이해하고 만든 결과는 오래 남는다고 믿어요.
반복되는 일을 줄이고, 기준은 맞추려고 해요
로워드 브릿지는 여러 도메인으로 나뉘어 있고, 각 서비스가 독립적으로 보이지만 결국 하나의 제품 경험으로 이어져요. 만약 각 도메인을 따로따로 관리하게 되면 어떤 일이 생길까요?
같은 UI를 여러 번 만들게 되고, 비슷한 로직을 계속 반복하게 되고, 스타일과 컴포넌트가 점점 서로 달라지게 돼요. 결국 팀 전체의 기준이 흐려지고, 유지보수 비용은 계속 올라가요.
그래서 우리는 모노레포(Monorepo)를 도입했어요.
공통으로 사용하는 컴포넌트와 스타일을 하나의 구조 안에서 관리하고, 한 번 수정하면 전체 서비스에 반영되도록 만들었어요. 이렇게 하면 중복 작업을 줄일 수 있을 뿐만 아니라, 서비스 간 일관성도 자연스럽게 유지할 수 있어요.
또한 Loword Design System을 구축했어요. 단순한 UI 가이드가 아니라, 실제 코드와 연결된 기준이에요. 누가 작업하더라도 비슷한 고민을 반복하지 않고, 자연스럽게 같은 기준 위에서 작업할 수 있도록 돕는 역할을 해요.
우리는 매번 새로 만드는 팀이 아니라, 한 번 잘 만들어서 계속 사용하는 팀이에요. 반복을 줄이고, 기준을 맞추는 것이 결국 더 빠른 길이라고 생각해요.
코드를 작성할 때는 항상 ‘왜?’가 붙어요
로워드 FE 팀에서는 코드를 작성할 때 항상 하나의 질문을 가져요.
“왜 이렇게 작성했을까?”
단순히 동작하는 코드만으로는 충분하지 않다고 생각해요.
왜 이 구조를 선택했는지, 왜 이 라이브러리를 사용했는지, 왜 이 방법이 더 적절한지 스스로 설명할 수 있어야 해요.
같은 결과를 만드는 방법은 항상 여러 가지가 있어요. 그중에서 어떤 선택을 했는지가 중요하고, 그 선택에는 반드시 이유가 있어야 한다고 생각해요.
그래서 팀에서는 자연스럽게 이런 질문이 오가요.
“왜 이렇게 작성했어요?”
이 질문은 누군가를 지적하기 위한 게 아니에요. 더 나은 선택이 있는지 함께 고민하기 위한 대화예요. 한 사람의 판단을 검증하는 과정이 아니라, 팀 전체의 기준을 더 단단하게 만드는 과정이에요.
우리는 정답을 찾는 팀이 아니라, 이유 있는 선택을 계속 쌓아가는 팀이에요. 그 과정이 결국 더 좋은 코드와 더 좋은 제품으로 이어진다고 믿어요.
실수는 할 수 있지만, 반복하지 않으려고 해요
일을 하다 보면 실수는 누구나 해요.
버그를 만들 수도 있고, 놓치는 부분이 생길 수도 있어요.
우리는 그걸 개인의 문제로 보지 않아요. 대신 이렇게 생각해요.
“왜 이 실수가 다시 발생했지?”
같은 실수가 반복된다면, 그건 개인이 아니라 시스템의 문제일 가능성이 높다고 봐요. 그래서 우리는 문제를 발견하면 그 원인을 개인이 아니라 프로세스에서 찾으려고 해요.
테스트도 단순히 “동작하느냐”만 확인하지 않아요.
엣지 케이스까지 고려해서 실제 사용 환경에서 발생할 수 있는 문제를 최대한 미리 잡으려고 해요.
그리고 필요하다면 구조를 바꾸고, 프로세스를 개선하고, 도구를 도입해요. 실수를 줄이기 위한 방향으로 팀 전체를 계속 업데이트해 나가요.
우리는 실수를 없애는 팀이 아니라, 실수에서 배우고 더 나은 구조를 만들어가는 팀이에요.
기술은 유행이 아니라 필요로 선택해요
프론트엔드는 변화가 정말 빠른 분야예요.
새로운 프레임워크, 라이브러리, 패턴이 계속 등장해요.
하지만 우리는 “좋아 보이니까”, “유행이니까”라는 이유로 기술을 선택하지 않아요.
항상 기준은 하나예요.
“왜 이 기술이 필요한가?”
현재 문제를 해결하는 데 정말 도움이 되는지, 장기적으로 유지보수에 유리한지, 팀 전체에 어떤 영향을 주는지를 충분히 고민해요.
필요하다면 새로운 기술을 적극적으로 도입해요. 하지만 필요하지 않다면 굳이 바꾸지 않아요. 변화 자체를 목표로 하지 않아요.
우리는 기술을 쌓는 팀이 아니라, 문제를 해결하는 팀이에요. 기술은 목적이 아니라 도구라고 생각해요.
협업은 일을 넘기는 게 아니라, 같이 맞추는 과정이에요
우리는 협업을 단순히 “일을 넘기는 과정”이라고 생각하지 않아요.
“이거 해주세요” 하고 끝나는 관계가 아니라, 함께 방향을 맞춰가는 과정이라고 생각해요.
특히 백엔드와 협업할 때는 작업 전에 충분히 이야기하는 걸 중요하게 생각해요.
이 기능이 전체 흐름에서 어떤 위치인지, API는 어떻게 설계할지, 데이터 구조는 어떻게 가져갈지 미리 맞춰요.
이 과정을 생략하면 개발 중간에 계속 수정이 발생하고, 결국 더 많은 시간이 들게 돼요. 반대로 처음에 충분히 맞춰두면 개발 과정이 훨씬 부드러워져요.
또한 직군에 상관없이 누구나 의견을 자유롭게 이야기해요.
더 좋은 방향이라면 그게 누구의 아이디어인지는 중요하지 않아요.
우리는 빠르게 만드는 팀이 아니라, 헛수고 없이 제대로 만드는 팀이에요. 협업은 속도를 높이기 위한 수단이 아니라, 방향을 맞추기 위한 과정이라고 생각해요.
로워드 FE 팀은
속도보다 방향을,
감보다 이유를,
결과보다 이해를 중요하게 생각해요.
그래서 우리는 계속 질문하고, 계속 고민하고, 계속 개선해요.
그 과정 속에서 더 나은 기준을 만들고, 더 좋은 제품을 만들어가고 있어요.
완벽한 답을 찾기보다는, 더 나은 답에 가까워지기 위해 움직이는 팀.
그게 우리가 일하는 방식이에요.
로워드 팀은 단순히 SaaS, PaaS를 만드는 조직에 머무르지 않아요.
각각의 서비스를 연결하고, 더 큰 가치를 만들어내는 하나의 생태계를 구축해 나가는 여정을 이어가고 있어요.
아직 완성된 상태가 아니라, 계속 만들어가는 과정에 있어요.
그래서 더 많은 고민이 필요하고, 더 많은 도전이 필요해요.
만약 글로벌 서비스를 직접 만들어보고 싶다면,
단순히 기능을 만드는 것을 넘어 문제를 정의하고 해결하는 경험을 하고 싶다면,
그리고 함께 방향을 고민하며 성장하는 팀에서 일하고 싶다면
지금 바로 로워드 팀에 합류해보세요.