면접관이 이 한 문장으로 확인하려는 것들. 각 갈래를 알면 답의 뼈대가 잡혀요.
B2B 플랫폼을 설계할 때 저는 고객사마다 다른 요구사항을 개별 대응하지 않고 설정 가능한 옵션으로 구조화하는 것이 중요하다고 생각합니다. 캡스톤 프로젝트에서 여러 매장을 대상으로 한 관리 시스템을 만들 때, 매장마다 다른 운영 방식(할인 정책 등)을 요구받았습니다.
초반에는 매장별로 코드를 분기해 대응했는데, 매장이 늘어날수록 코드가 복잡해졌습니다. 이후 할인 정책을 설정값으로 관리하는 구조로 리팩터링해, 새로운 매장이 추가되어도 코드 변경 없이 설정만으로 대응할 수 있게 됐습니다.
이 경험으로 B2B 플랫폼은 개별 대응이 아니라 확장 가능한 구조로 설계해야 한다는 것을 배웠습니다.
시스템을 리플랫폼화할 때 저는 기존 시스템과 새 시스템을 한 번에 전환하지 않고 점진적으로 옮기는 전략이 중요하다고 생각합니다. 동아리 서비스를 새로운 프레임워크로 옮기는 프로젝트를 진행했을 때, 처음에는 전체를 한 번에 교체하려 했지만 예상치 못한 오류가 한꺼번에 발생할 위험이 컸습니다.
저는 기능 단위로 나눠 일부만 먼저 신규 시스템으로 옮기고, 문제가 없는지 확인한 뒤 다음 기능을 옮기는 방식으로 진행했습니다. 이 방식 덕분에 문제가 생겨도 영향 범위가 작아 빠르게 원인을 찾을 수 있었습니다.
이 경험으로 리플랫폼화는 속도보다 안전한 전환 경로를 설계하는 것이 더 중요하다는 것을 배웠습니다.
플랫폼 엔지니어링에서 저는 그 플랫폼을 사용할 다른 개발자의 경험까지 설계 범위에 포함해야 한다고 생각합니다. 팀 프로젝트에서 여러 개발자가 공용으로 쓰는 내부 API를 설계했을 때, 초기에는 저 혼자 이해할 수 있는 방식으로만 문서화했습니다.
다른 팀원이 API를 사용하다 혼란을 겪는 것을 보고, 이후 사용 예시와 에러 상황별 대응 방법을 포함한 문서로 다시 정리했습니다. 이후 팀원들의 문의가 크게 줄었습니다.
이 경험으로 플랫폼은 기능이 완성됐다고 끝나는 것이 아니라, 그것을 쓰는 사람이 쉽게 이해할 수 있어야 완성된다는 것을 배웠습니다.
같은 실수가 반복돼요. 이것만 피해도 절반은 갑니다.
진짜 면접은 두 번째 질문부터예요. 이 답 뒤에 따라올 법한 것들.