비개발 부서에 API 변경사항을 설명한 경험
마케팅팀에서 배너 클릭 데이터를 요청했을 때, 처음에는 API 응답 구조를 그대로 문서로 넘겼는데 이해하기 어렵다는 피드백을 받았습니다. 이후로는 JSON 필드 하나하나를 스프레드시트의 실제 예시 값과 나란히 정리해서 다시 전달했더니 훨씬 수월하게 소통이 됐습니다. 기술 문서를 그대로 넘기는 것과 상대가 쓸 수 있는 형태로 바꿔주는 것 사이에 큰 차이가 있다는 걸 그때 배웠습니다.
면접관이 이 한 문장으로 확인하려는 것들. 각 갈래를 알면 답의 뼈대가 잡혀요.
마케팅팀에서 배너 클릭 데이터를 요청했을 때, 처음에는 API 응답 구조를 그대로 문서로 넘겼는데 이해하기 어렵다는 피드백을 받았습니다. 이후로는 JSON 필드 하나하나를 스프레드시트의 실제 예시 값과 나란히 정리해서 다시 전달했더니 훨씬 수월하게 소통이 됐습니다. 기술 문서를 그대로 넘기는 것과 상대가 쓸 수 있는 형태로 바꿔주는 것 사이에 큰 차이가 있다는 걸 그때 배웠습니다.
기획팀이 요청한 기능이 운영팀 입장에서는 관리 부담이 크다는 걸 스프린트 중간에 알게 된 적이 있습니다. 저는 개발자 입장에서 두 팀 사이에서 구현 난이도와 운영 리스크를 각각 정리해 회의 자리에서 공유했고, 결국 기능 범위를 줄이는 쪽으로 합의가 됐습니다. 개발자가 요구사항을 그대로 받아 만들기만 하는 게 아니라, 양쪽 입장을 번역해 전달하는 역할도 할 수 있다는 걸 느꼈습니다.
온프레미스 서버를 클라우드로 옮기는 프로젝트에서 저는 애플리케이션 코드의 환경변수 설정을 맡았는데, 초반에는 인프라팀이 구성한 값과 제가 예상한 값이 달라 배포가 몇 차례 실패했습니다. 이후 인프라팀과 매일 짧게 싱크업을 하면서 설정값을 공유 문서에 실시간으로 반영하는 방식으로 바꿨더니 실패가 크게 줄었습니다. 책임 경계가 애매한 작업일수록 문서화와 짧은 주기의 확인이 중요하다는 걸 배웠습니다.
같은 실수가 반복돼요. 이것만 피해도 절반은 갑니다.
진짜 면접은 두 번째 질문부터예요. 이 답 뒤에 따라올 법한 것들.