이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
인턴 때 금융 데이터를 다루는 내부 시스템 개발을 잠깐 지원했습니다. 가장 어려웠던 건 규제 때문에 테스트 환경에 실제 데이터를 쓸 수 없다는 제약이었습니다. 마스킹된 더미 데이터로 테스트해야 해서 사전 시나리오 설계의 중요성을 실감했습니다. 감사 요구사항이 개발 중반에 추가됐고, 모든 변경 이력을 로그로 남기는 구조를 처음부터 설계하지 않은 탓에 소급 적용하는 비용이 컸습니다. 이해관계자가 많아서 요건 승인 단계가 여러 번 반복되는 것도 일정에 영향을 줬습니다. 금융 도메인에서는 기능 구현보다 감사 가능성과 추적 가능성을 먼저 설계해야 나중 비용이 줄어든다는 걸 배웠습니다.
규제 환경의 제약이 처음엔 답답하지만 설계를 더 꼼꼼하게 만드는 자리라는 걸 그때 느꼈습니다.
금융권 프로젝트에서 감사 로그 소급 작업을 하면서 왜 이 비용이 생겼는지 뒤돌아봤습니다. 개발 중반에 감사 요건이 추가됐다고 했지만, 이해관계자와 킥오프 단계에서 규제 환경에 대해 더 깊이 물어봤더라면 처음부터 설계에 포함할 수 있었을 요건이었습니다. 규제가 있는 도메인에서는 기능 개발에 앞서 감사·추적·데이터 보안 요건을 먼저 확인해야 한다는 것을 이 경험에서 배웠습니다. 변경이 어려운 시스템일수록 초기 요건 수집이 더 중요한 결이 있습니다.
빠른 개발 시작이 소급 비용으로 돌아오는 결을 직접 겪고 나서, 지금은 새 프로젝트를 시작할 때 도메인 제약을 먼저 목록화하는 결이 생겼습니다. 잘 된 점만 회고하면 다음 실수를 막기 어렵다는 것도 이 경험에서 느꼈습니다.
금융권 프로젝트에서 마스킹된 더미 데이터로 테스트해야 하는 제약이 처음에는 불편했습니다. 실제 데이터로 바로 확인할 수 없으니 테스트 케이스를 미리 꼼꼼히 설계해야 했습니다. 이 과정에서 경계값·예외 케이스·비정상 입력을 사전에 목록화하는 습관이 생겼습니다. 처음엔 번거로웠지만, 이 방식이 정착되니 나중에 발견되는 버그가 줄어드는 결을 확인했습니다. 제약이 있어서 더 많이 생각하는 결이 됐고, 이 습관은 제약이 없는 환경에서도 계속 유지됐습니다.
환경의 제약이 능력을 강제로 기르는 결이 있다는 것을 이 경험에서 느꼈습니다. 불편한 제약이 나중에 설계 직관으로 남는 결이 있었습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 부산은행 SW·IT 일반 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.