[우아한테크코스] 레벨3 레벨로그 인터뷰 후기

우테코에서는 각 레벨이 끝날 때마다, 그 레벨에서 배웠던 내용을 기록하여 제출한다. 그리고 이 내용을 바탕으로 20분동안 크루 4~6명과 함께 코치님 또는 캡틴과 자유롭게 얘기를 나누는 시간을 가진다. 모의 면접이라고 생각하면 된다. 담당코치님은 랜덤으로 배정된다.

 

나의 경우는 레벨4를 시작하자마자 바로 다음 날에 레벨로그 인터뷰를 진행됐다. 나의 레벨로그 인터뷰를 맡아줄 코치님은 구구였고, 레벨3 때에도 함께한 알파, 리버도 있었으며, 릭, 렉스와도 함께 진행했다. 지금 생각하면 내 레벨로그 인터뷰 담당 코치님들은 다 빡센 분들과 함께 했던 것 같다 ㅎㅎ 이 날은 코치 구구가 컨디션이 좋지 않아 살살해준다고 말씀하시긴 했다.

 

내 레벨3 레벨로그는 여기서 확인할 수 있다.

https://clean-nutria-44b.notion.site/4-d507789a37254d04b4f41767943186f6

레벨4 레벨로그

---

전체적인 질문 흐름 및 후기

아무래도 레벨3가 프로젝트 기간이었기 때문에 팀 문화, 팀에서의 역할, 자신이 생각하는 백엔드 개발자에 대한 질문이 많았다. 레벨1, 2때는 자바, 스프링, 객체지향 관련 질문이 많았다면, 레벨3는 CI/CD 관련 질문이 나오기 시작했다. 기술적인 질문으로 빡세게 물어보시지 않아 다행이라고 생각이 들긴 했지만, 열심히 준비한 부분에서 질문이 나오지 않아 아쉽기도 했다. (근데 꼬리질문 들어왔으면 탈탈 털렸을 것 같기도 하고, 그런 걸 생각하면 다행인 듯 ㅎㅎ)

 

트러블 슈팅 및 다양한 경험을 많이 해야겠다는 생각이 들었다. 그러한 경험을 바탕으로 면접에서 내 실력도 보여주고, 나만의 가치관도 더 확고하게 설립할 수 있겠다는 생각이 들었기 때문이다. 인터뷰는 무난무난하게 잘 본 것 같다. 레벨3 때 받은 피드백으로 '말의 속도가 빠르다'는 부분이 있었는데, 해당 부분이 많이 완화됐다는 걸 나 스스로도 느낄 수 있었다. 또한, 듣는 사람이 피로감을 느끼지 않도록 기술적인 답변을 할 때 두괄식으로, 너무 길지 않게 대답하려고 노력했다.

 

앞으로 책을 많이 읽고 CI/CD, 트러블 슈팅 관련 경험 기록을 꼼꼼히 해야겠다고 다짐하게 됐다. 이제 블로그에 학습기록보단 트러블슈팅 관련 경험, 개발 후기 관련 내용을 많이 작성하지 않을까 싶다.

---

질문 및 답변

20분동안 진행된 인터뷰이기 때문에 간단하게 요약해서 작성하도록 하겠다.

인터뷰 질문은 릭이 꼼꼼하게 기록해준 덕분에 잘 복기할 수 있었다. (Thanks To 우테코 4기 BE 릭)

 

검은색은 인터뷰 답변, 초록색은 해당 질문을 받으면서 떠오른 생각을 적어보았다.

 

Q. 자기소개

 

우아한테크코스 4기 백엔드 크루 케이. 취미로 알고리즘, 자전거타기 좋아함.

 

Q. 프로젝트 소개 부탁

 

(짧게 설명해도 괜찮을 것이다. 20초를 넘기지 말자)

모임 기반 롤링페이퍼 서비스 플랫폼. 모임 기반이라는 느낌을 강조했다.

 

Q. 팀 문화 소개 부탁

 

매주 팀 세미나를 통해 분업한 내용을 설명해주는 문화.

github wiki를 이용한 문서화.

지각하면 커피 사기.

필요성을 느낄 때에는 프론트-백엔드 몹 프로그래밍

 

Q. 프론트 & 백 협업하면서 어려웠던 점이 있다면?

 

매일 데일리 회의를 통한 상황공유, 팀 세미나를 통한 지식 간극 좁히기, 몹프로그래밍을 활용한 상호이해를 통해 많이 어려웠던 부분은 없었다.

 

Q. 업무를 분담하는 방식은?

 

(사다리타기로 정했다고 솔직하게 말하자)

업무를 쭉 나열한 다음, 자신이 원하는 업무가 있다면 선점.

그 외에는 사다리타기를 통한 랜덤

 

Q. 사다리타기로 정하는 이유는?

 

해당 업무 난이도가 어떨지 모름. 운의 요소를 포함하여 재미있게 사다리타기로 정하도록 함. 

이후에 팀 세미나를 통한 각자의 분업한 업무 스킬을 소개해주는 시간을 가지도록 하여 모두가 알 수 있도록.

 

Q. 팀에서 의견충돌이 났던 에피소드가 있었나?

 

초기에 테스트 속도 관련 @DirtiesContext를 사용할지 말지에 대한 얘기가 있었음.

옛날의 나는 테스트 속도의 중요성을 크게 느끼지 못해서 @DirtiesContext를 걍 쓰자고 했었음.

당시에 백엔드 크루들끼리 상의한 결과 @DirtiesContext를 사용하기로 함.

 

하지만, 이후에 CI/CD를 사용하면서 테스트 피드백 속도의 중요성을 깨달아 @DirtiesContext를 사용하지 않고 테스트 격리하는 것의 필요성을 느낌.

 

(아, 이제 @DirtiesContext를 사용하지 않고 어떻게 테스트를 격리했는지 물어보겠구나! 또는 CI, CD 질문을 하겠구나! 느낌이 옴. 그리고 바로 이어서 예상한대로 해당 질문이 나옴.)

 

 

Q. @DirtiesContext를 사용하지 않고 (인수) 테스트를 격리시킨 경험

 

AfterPropertiesSet을 오버라이딩하는 메서드를 작성하여 DB를 초기화해주도록 함. 매 테스트 메서드를 실행할 때 빈을 초기화해주므로 InitializingBean의 구현체를 커스터마이징함으로써 테스트가 격리되어 @DirtiesContext를 사용할 때보다 훨씬 빨라짐을 실감함.

 

(이 질문에 답변함으로써 바로 bean cycle 얘기가 나올 줄 알았는데 나오지 않아 살짝 아쉬웠다. 열심히 준비했었는데ㅋㅋ)

 

Q. 인수 테스트와 통합 테스트의 차이

 

(아 이거 지난 레벨로그 인터뷰때도 받았던 질문이네.)

 

인수 테스트는 사용자의 시나리오 관점으로 접근하여 전체적으로 테스트하는 것이고, 통합 테스트는 여러 협력객체의 로직이 포함된 비즈니스 로직이 의도한대로 돌아가는지 테스트하는 것이다.

 

하지만 나는 인수 테스트와 통합 테스트는 BE에서는 같다고 생각한다. 백엔드에서의 시나리오는 결국 API 설계를 의미하며, 이는 여러 비즈니스 로직이 우리가 의도한대로 돌아가는지 확인해보는 것이기 때문이다. (이 부분을 되게 길게 설명했다.)

 

(지금 생각하면 e2e test와 인수테스트에 대한 내 생각을 얘기했다... 나는 인수와 E2E 테스트는 FE를 제외한 백엔드 개발 한정으로는 동일하다고 생각하지만, E2E와 통합테스트는 같다고 생각하지는 않는다. 통합은 여러 비즈니스 로직을, E2E는 스프링 컨테이너를 실행시켜 api를 테스트하는 것이라 생각하기 때문이다. 근데 다행히 인터뷰 시에 나름 괜찮게 잘 말해서 코치님이 잘 넘어가주신 것 같다.)

 

Q. CI vs CD

 

(조금만 답변 잘못해도 바로 꼬리질문이다. 조심하자)

 

CI는 빌드 및 테스트를 자동화하여 자동으로 병합해주는 지속적 통합을 의미한다.

CD는 자동으로 해당 프로젝트를 배포가능한 jar파일로 생성해주고 인스턴스로 보내주는 지속적 배포를 의미한다.

 

(휴, 나름 괜찮게 잘 말한 듯. 이제 CI, CD를 사용한 이유에 대해서 묻지 않을까?)

 

Q. CI/CD를 하는 이유는?

 

(역시나 이 질문이 나왔군. CI/CD를 적용하지 않았던 레벨2 때에 비해 레벨3 때 CI/CD를 적용하면서 편리했던 경험을 그대로 얘기하자.)

 

직접 쉘 스크립트를 짜서 배포 서버에 보내주는 번거로운 작업을 덜 수 있어서 편리했음.

PR을 보내면 github actions가 자동으로 테스트를 돌려주고 이후에 병합할 때 충돌이 발생하는지 직접 확인가능했으며, 머지하면 자동으로 Jenkins가 배포해주므로 매번 리눅스 명령어를 입력할 때에 비해 비즈니스 로직 작성에만 집중할 수 있었음.

 

(github actions, jenkins 얘기를 했으니 이제 이걸 사용한 이유를 묻지 않을까?

 

Q. (Ci 한정) Jenkins를 두고 Github Actions를 활용한 이유가 있다면?

 

원래는 CI/CD 모두 Jenkins를 활용했었음.

그렇지만 사용해보고 나니 문제점이 있었음.

 

우테코에서는 t4g.micro aws 인스턴스를 사용하게 해주었는데, 해당 인스턴스는 램이 1기가로 굉장히 작음.

Jenkins에게 빌드 및 테스트 자동화까지 맡기니 젠킨스의 cpu 할당량이 매우 높은 것을 확인할 수 있었음.

부하를 줄이기 위해 빌드 및 테스트 자동화를 github actions에게 맡김. github actions는 러닝커브도 낮고 편리했어서 변경하는 데에 어려움이 적어 팀원과의 합의 후에 변경했음.

 

Q. Swagger를 두고 REST Docs를 쓴 이유는?

 

(바로 REST Docs 질문이 나올줄이야. 그래도 예상범위 내 질문이다.)

 

Swagger과 REST Docs 중 가독성이 후자가 더 낫다고 팀원들과 합의됐던 것이 제일 큼.

프로덕션 코드가 지저분해질 수 있는 Swagger과 달리 REST Docs는 테스트 코드의 변경만 존재하며, 테스트 코드가 성공해야 API 문서 자동화가 된다는 점도 좋았음.

 

(이제 인프라 관련 질문들 슬슬 많이 나오겠다. 아니면 REST Docs 관련 MockMvc, RestAssured가 나올 수도?)

 

Q. flyway 간단 설명 부탁

 

DB 형상관리 툴.

flyway 적용 전엔 프로덕션 코드 모두 작성 후에 테이블 변경사항을 한꺼번에 배포 서버에서 직접 테이블 컬럼을 변경했었어야 됐음.

그렇지만 flyway를 사용하면 로컬에서 프로덕션 코드를 작업하면서 동시에 db table 스키마 변경사항을 작성할 수 있어 편리했음.

변경된 스키마를 버전에 따라 확인할 수 있어 스키마 버전관리에도 용이했음.

 

flyway는 U (rollback) 기능이 유료기 때문에 해당 기능이 무료인 liquibase를 적용할까도 고민했었지만,

liquibase는 러닝커브가 높고 레퍼런스를 찾기가 쉽지 않다는 단점이 존재해 팀원들과 합의 후에 flyway를 적용하기로 결정함.

 

Q. JPA를 쓰면서 객체 검증 로직은 어떻게 처리했나요?

 

(오잉 이 질문이 나올 줄은 몰랐는데? 어떤 답변을 원하는건지 잘 모르겠다.)

 

DTO 단에서 Valid 어노테이션으로 앞단에서 1차적으로 검증.

도메인에서도 검증 로직을 작성함.

 

Q. 값 객체를 쓰면서 발생한 이슈는? (e.g. Password를 값 객체로 포장하는 경우 -> 평문은 1q2w3e4r인데 이걸 해시로 만들면 길이가 길어진다. 어떻게 해야할까?)

 

(뭔 소리지?)

 

일단 비밀번호 인터페이스 객체를 만들고 PlainPassword, EncodedPassword 구현체를 만들어서 따로 검증할듯.

 

(잘 대답한건지 모르겠음 ㅋㅋ)

 

Q. Spring Data JPA에서 Spring AOP 프록시 동적 생성 설명 부탁

 

(어려운 질문이 나왔네...)

 

Spring Data JPA에서 어떻게 인터페이스만으로 여러 CRUD 메서드를 제공해줄 수 있는지 고민해봤음.

알고보니 프록시를 동적 생성했었고, 해당 프록시의 target으로 SimpleJpaRepository를 삼고 있었음.

프록시를 빈으로 스프링에서 관리하고 있었기 때문에 인터페이스를 빈으로 등록하지 않아도 되는 거였음.

 

프록시 동적 생성 방법으론 jdk 다이나믹 프록시와 CGLIB 방식이 있음.

전자의 방식은 인터페이스가 존재해야 가능, 후자의 방식은 인터페이스 없어도 가능한 오픈소스 라이브러리.

옛날엔 CGLIB 생성 방식의 단점이 있었지만, 요즘은 스프링이 공식적으로 단점을 극복했다고 말해줬기 때문에 CGLIB만으로 프록시 동적 생성을 하도록 설정하는 옵션도 있을 정도임.

 

(꼬리질문 나올만한 부분이 꽤 많은데... 여기까지가 내 프록시 동적 생성 지식의 한계니까 더 어렵게 나오면 모른다고 해야겠다.)

(그리고 다행히 그 이후로 aop 질문이 더 깊게 나오진 않았다.)

 

Q. 프로젝트 서비스 아키텍처를 그려주세요.

 

보드에 아래 그림을 그림.

여기에 추가로 NGINX, DB를 그려줌.

local, dev, prod에 따른 아키텍처도 추가적으로 그려주었음.

 

Q. 배포 전략 (브랜칭 전략)

 

main, develop, feature, hotfix.

feature/{issue 번호}-{issue 내용} 명명 설명. 한 2분 정도 설명함.

 

Q. CORS 이슈는 없었나요?

 

(음... 없었는데...? ㅋㅋㅋ 어떡하지)

없었음...

 

(아! 이걸 원한 거였구나.)

백엔드 서버는 서브도메인을 활용했기 때문에 CORS 이슈가 없었음.

(휴 늦게라도 떠올려 다행)

---

피드백

다행히 좋은 피드백들이 꽤 있었다.

아쉬운 점은 프로젝트를 하면서 트랜잭션 관련 트러블슈팅이 없었다는 점이다.

해당 부분에 대해 인터뷰질문은 없긴 했다.

하지만, 다른 크루들이 트랜잭션 관련 트러블 슈팅에 대해 얘기하는 걸 보고 부러웠다는 생각이 들었고 나도 DB 트랜잭션 쪽을 공부하면서 프로젝트 구현을 통해 다양한 경험을 해보고 싶다는 생각이 들었다.

 

이후에 실제로 면접을 볼 때엔 더 성장한 상태길 바라며 열심히 해야겠다.