이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
사이드 프로젝트에서 알림 기능을 여러 팀이 쓸 수 있도록 모듈화하는 작업을 맡았습니다. 처음엔 내부 코드 그대로 노출했는데, 다른 팀원이 파라미터 이름이 뭔지 몰라 계속 물어봤습니다. 그때부터 인터페이스를 쓰는 사람 입장에서 설계해야 한다는 걸 느꼈습니다. 파라미터 이름을 명확하게 바꾸고, 오류 메시지도 내부 코드 대신 사람이 읽을 수 있는 설명으로 바꿨습니다. 팀원들이 문서 없이도 쓸 수 있다는 피드백을 받았고, 설계가 사용자 경험이라는 걸 그때 처음 실감했습니다.
인터페이스는 기능보다 쓰기 쉬움이 먼저라는 기준이 생겼습니다. 설계가 사용자 경험이라는 걸 그때 처음 실감했고, 이후에도 인터페이스를 만들면 직접 써보는 습관이 생겼습니다.
학교 수업에서 외부 팀과 데이터를 주고받는 인터페이스를 설계했는데, 중간에 상대팀이 스펙을 바꾸면서 저희 코드가 통째로 깨진 적이 있습니다. 그때 버전 관리를 처음 신경 쓰게 됐고, 이후 프로젝트에선 응답 구조에 버전 필드를 넣고 구버전 요청도 처리하는 구조로 바꿨습니다.
2주 뒤 상대팀이 다시 스펙을 바꿨는데, 이번엔 저희 코드가 안 깨졌습니다. 하위 호환성이 외부 연동에서 얼마나 중요한지 삽질로 배웠고, 인터페이스는 한번 공개하면 바꾸기 어렵다는 원칙을 그때 세웠습니다. 하위 호환성이 외부 연동에서 얼마나 중요한지 삽질로 배웠고, 인터페이스는 한번 공개하면 바꾸기 어렵다는 원칙이 생겼습니다.
인턴 때 제가 만든 데이터 변환 스크립트를 다른 팀도 쓰고 싶다는 요청이 왔습니다. 그냥 파일을 줬더니 사용법을 물어보는 메시지가 계속 왔습니다. 그때부터 입력값 형식, 출력 예시, 오류 케이스를 한 문서에 정리했습니다. 문서를 공유했더니 질문이 80% 줄었고, 그래도 남은 질문에서 불분명한 파라미터 2개를 발견해 이름을 바꿨습니다. 모듈 기획에서 가장 중요한 건 쓰는 사람이 실패하지 않도록 설계하는 것이라는 걸 배웠고, 지금도 인터페이스를 만들면 직접 써보는 습관이 있습니다.
가장 중요한 건 쓰는 사람이 실패하지 않도록 설계하는 것이라는 걸 배웠고, 이후에도 인터페이스를 만들면 직접 써봅니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 이스트소프트 서비스 오너 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.