이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
사이드 프로젝트에서 처음으로 파이프라인을 혼자 구축해봤습니다. 처음에는 배포할 때마다 수동으로 서버에 접속하여 명령어를 입력하고 있었습니다. 어느 날 실수로 잘못된 버전을 프로덕션에 올린 뒤로 자동화가 절실해졌습니다.
깃허브 액션을 처음 사용해보았는데, yaml 파일 문법을 잘 몰라서 초반에 워크플로우를 수십 번 돌려보았습니다. 빌드는 성공했지만 배포 단계에서 환경 변수 설정 문제로 계속 실패했습니다. 결국 시크릿 설정 방식을 바꾸고 나서야 전체 흐름이 연결되었습니다.
이후에는 PR을 올리면 자동으로 테스트가 실행되고, 머지되면 스테이징 배포되는 흐름을 만들었습니다. 완벽하진 않지만 배포 실수가 확실히 줄어들었습니다. 가장 힘들었던 것은 설정 자체보다 실패 로그를 읽고 원인을 찾는 것이었는데, 그 과정이 오히려 도움이 되었습니다.
팀 프로젝트에서 팀원 3명이 각자 다른 방식으로 서버에 올리는 상황이 있었어요. 한 명은 FTP, 한 명은 SSH 직접 접속, 저는 스크립트 실행이었는데 매번 충돌이 났어요.
제가 젠킨스 환경을 팀 서버에 세팅하고, 공용 배포 흐름을 정의하자고 제안했어요. 설득하는 게 생각보다 오래 걸렸어요. '굳이 이걸 배워야 하냐'는 반응도 있었거든요. 그래서 제가 먼저 간단한 예시 파이프라인을 만들어 시연했어요.
팀원들이 쓰기 시작하면서 배포 문제로 서로 따지는 일이 줄었어요. 가장 큰 수확은 배포 자체가 아니라 '이 서버에 지금 뭐가 떠 있는지'를 모두가 알게 됐다는 거예요. 실패 사례도 있었는데, 처음 만든 파이프라인이 너무 복잡해서 팀원 중 한 명이 중간에 그냥 직접 올려버린 일이 있었어요. 단순하게 만들어야 다들 쓴다는 걸 배웠어요.
개인 프로젝트에서 배포하고 나서 버그를 발견하는 패턴이 반복됐어요. 테스트는 해놨는데 막상 배포 전에 안 돌리고 올리는 게 습관이었어요.
깃랩 파이프라인에 테스트 단계를 추가해서, 테스트가 통과해야 다음 단계로 넘어가도록 바꿨어요. 처음엔 기존 테스트 중 3~4개가 환경 차이로 파이프라인에서 실패했어요. 로컬에서는 됐는데 파이프라인에서 안 되는 거라 원인 찾는 데 꽤 걸렸어요. 환경 변수랑 파일 경로 문제였어요.
이후엔 배포 후 버그 발생이 확실히 줄었어요. 수치로 비교하면 이전엔 배포 직후 수정 커밋이 주 2~3회였는데, 이후엔 주 1회 이하로 줄었어요. 파이프라인을 쓰는 게 좋다기보다, 테스트를 강제로 돌리게 만드는 장치로 쓰는 게 핵심이었어요.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 넥스트증권 프론트엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.