수많은 기능 요청에 관해서
안녕하세요. 코드아키텍트입니다.
최근 많은 고객들을 만나며 건축 분야에서 SaaS 플랫폼과 그에 대한 기능 요청(Feature Request) 이야기를 꾸준히 듣고 있습니다.
저도 항상 설명을 드리긴 하지만, 이번 글에서는 이를 조금 더 직관적인 비유로 정리해보려 합니다.
네이버, 구글, 카카오 등과 같은 제품은 각자 고유한 철학과 방향성을 가지고 움직입니다.
여러 사람이 하나의 비전을 중심으로 제품을 개발하고, 그 비전에 맞춰 기능을 설계합니다.
따라서 이 방향성과 맞지 않는 기능을 무리하게 추가하면, 제품은 누더기처럼 복잡해질 수 있습니다.
이처럼 큰 철학을 바탕으로 움직이는 제품은 화물선에 비유할 수 있습니다.
화물선의 항로는 쉽게 바꿀 수 없습니다.
방향을 틀기로 결정하더라도 실제로 그 변화가 눈에 보이기까지는 시간이 걸립니다.
이것이 바로 IT 업계에서 말하는 기능 요청(Feature Request)에 해당합니다.
예를 들어, 오토데스크의 클라우드 제품인 ACC(Autodesk Construction Cloud)는
다양한 기업이 각자의 요구에 맞게 기능 요청을 하지만,
제품의 기본 철학과 방향성에 부합하지 않으면 반영되기 어렵습니다.
심지어 요청이 채택되더라도 실제 기능이 추가되기까지는 보통 1년 이상이 걸리죠.
요트를 타고 세계여행을 하는 사람들의 이야기를 들은 적이 있습니다.
항해 중에는 요트를 연안에 정박시켜 두고, 작은 고속정(보트)을 타고 그 나라의 항구로 들어가 물건을 사고 돌아옵니다.
화물선도 마찬가지입니다.
커다란 배(모선)는 자신만의 항로를 유지하면서, 필요할 때마다 작은 고속정들을 띄워 세부적인 일을 처리합니다.
이걸 제품 관점에서 보자면,
화물선은 SaaS 플랫폼 자체이고,
고속정은 API나 SDK를 이용해 구현하는 커스텀 기능 또는 확장 개발에 해당합니다.
API(Application Programming Interface)는 “이 기능을 요청하면, 이런 정보를 돌려줄게”라는 통신 규약이고,
SDK(Software Development Kit)는 그 API들을 묶어 더 쉽게 쓸 수 있도록 구성한 개발 도구 세트입니다.
비유하자면,
API는 식당 메뉴판의 단품 메뉴,
SDK는 그 메뉴들을 조합한 세트 메뉴입니다.
즉, 화물선(제품)의 항로는 바꿀 수 없지만,
그 위에서 API와 SDK를 활용하면 제품의 자원을 공유하면서도,
내가 원하는 기능을 고속정처럼 빠르고 유연하게 만들어낼 수 있습니다.
건축에 특화된 SaaS는 건축이라는 도메인 철학 위에서 만들어졌습니다.
이런 제품을 기반으로 기능을 확장하면 성공 확률이 높습니다.
반대로, 전혀 다른 철학(예: 의료용 소프트웨어)에 기반해 건축용 기능을 만들려 하면
연결성 자체가 맞지 않아 개발 난이도가 급격히 높아집니다.
화려한 그래픽보다 중요한 것은 핵심 기능이 문제를 얼마나 명확히 해결하느냐입니다.
너무 많은 기능을 욕심내기보다,
“우리가 해결하려는 한 문장짜리 문제”를 정의하고 거기에 집중하는 것이
가장 빠르고 효과적인 접근입니다.
제품이 진화하면서 그 철학이 바뀔 수 있고,
내가 만든 커스텀 기능의 목표도 변할 수 있습니다.
둘의 방향이 멀어지면 통합이 깨지고, 유지보수도 어려워집니다.
제품과 커스텀의 항로를 나란히 유지하는 것이 장기적 성공의 조건입니다.
좋은 기획은 훌륭한 설계도와 같습니다.
하지만 실제 구현이 따라오지 않으면 아무 소용이 없습니다.
한국에서는 종종 “기획은 대기업, 구현은 협력사”로 나뉘는 경향이 있습니다.
그러나 기획과 구현이 같은 철학 안에 있을 때만
품질과 속도, 그리고 유지보수가 함께 발전합니다.
산업은 느리게 변하는 것처럼 보이지만, 분명히 변하고 있습니다.
AI와 클라우드 시대에는 개발 지식이 곧 경쟁력입니다.
이제 건축업에서도 ‘기획하는 사람’이 곧 ‘만드는 사람’이 되어야 합니다.
오늘의 글이
API, SDK, 그리고 커스텀 개발의 방향성에 대해 조금이라도 감을 잡는 데 도움이 되었길 바랍니다.