백엔드 스쿨에서 현직자 분을 초청해서 특강해주셨다.
카카오뱅크 분이셨고 핀테크 쪽의 백엔드를 주제로 설명해주셨다.
핀테크 백엔드 개발자는 주로 3분야 중 한 곳에서 일하게 된다고 한다.
개발현장에서 실제로 구현을 시작하기까진 꽤 시간이 걸린다는 듯하다.
기획 + 디자인 과정을 거친후 실제 개발 착수. 후에 QA, 배포로 진행된다.
기획단계에서는 기획자와 개발자가 토론을 한다. 각자의 기대소요시간이 다르기 때문에 이과정에서 계획을 수정하는 등의 토론을 거치게 된다.
신입 개발자의 경우 이런 과정도 유심히 살펴보는 것이 나중에 시니어 개발자가 되었을 때 도움이 될 것이라는 강사님의 말씀이 있었다.
현장에서의 업무분배는 '지라'라고 하는 것을 통해 이루어진다고 한다. 일종의 해야할 일을 적어놓은 포스트잇과 같은 개념이라고 한다.
그리고 깃플로우 전략을 당연히 사용하기 때문에 미리 숙지해두고 실제 포폴용 프로젝트에 접목해놓으면 큰 도움이 될 수 있다고 하셨다.
다른 도메인과는 다르게 핀테크 도메인은 망분리를 한다. '업무망'과 '외부인터넷망'으로 분리하여 보안을 높이는 방법이다. 이게 국가마다 법이 달라서 망분리를 하지 않는 나라도 있다고 한다.
핀테크 도메인에 취업 지원을 할 때 주의할 점이 계정계, 정보계, 채널계를 잘 보고 들어가야 한다는 것이다. 앞의 두 개는 흔히 금융 IT하면 생각나는 '로우레벨 코딩'하는 곳이고 나와 같은 자바 프레임워크로 작업하는 곳은 채널계라고 한다.
추가적으로 핀테크에서는 트랜잭션에 대한 이해도를 요한다고 한다.
둘의 결과는 같지만 결과의 history는 하나의 라인으로 나온다.
git rebase main bugFix #bugFix가 main뒤로 움직임
깃플로우는 브랜치를 이용한 협업 방식 중의 하나이다. 메인 브랜치에 대해 안전하게 개발을 진행할 수 있다는 장점이 있으나 작업의 진행이 너무 오래 걸린다는 단점도 존재한다.
이러한 단점을 보완해서 나온 것이 깃헙플로우이다. 깃헙플로우는 여러 feature브랜치가 작업물을 main에 직접 커밋한다.
그럼 메인이 CI/CD를 이용하는 경우 배포되버려서 위험한 것 아니냐는 생각이 들 수도 있다. 깃헙 자체에 커밋의 승인 권한을 설정할 수도 있고, CI/CD는 자체적으로 해당 커밋을 테스트해보고 테스트가 하나라도 실패하면 배포하지 않는다. TDD가 필수적인 방식이라고 할 수 있다.
git pull origin main --rebase
현재 나의 작업 브랜치(로컬의 enhance/1)에 원격main에 있는 최신본을 끌어와서 최신화하는 작업이 필요
git push origin enhance/1
내 작업물을 원격의 main으로 올림