[SI] 신입 개발자와 5년차 개발자는 무엇이 달라야 할까?

 

👋 

안녕하세요~ 위대한 개취비입니다!
오늘은 회사에서 점심을 먹으며, 동료 분들과 대화를 하다가 나온 주제에 대해서 다뤄보려고 합니다.

최근에 회사에 들어온 신입 A.

A가 잘 하는 지, 모르는 것이 있으면 가르쳐주는 임무를 받은 선임 B!

그러나, 최근에서야 빌드센터로 온 B가 봤을 때, A가 개발을 잘 하는 것 같아서 "잘 하셨는데요? 👀"라고 전했다고 한다. 심지어 본인보다 더 잘하는 것 같다고 한다...!

그래서 나온 질문!

우리 선임들은 신입에 비해 잘하는 게 뭐죠?

 

 

1. 잘하는 신입 A 😎

최근 입사하시는 신입 분들이나 인턴 분들은 중고신입도 많으시고, 부트캠프 등으로 실무에서 필요한 기술 스택을 상당히 체계적으로 탄탄히 쌓고 오신 분들이 많으시죠. 그래서 입사 후, 주어진 업무를 굉장히! 잘! 빠르게! 해내곤 합니다. 신입 열정 버프도 한 몫 하구요.

 

2. 당황한 선임 B 👀

많은 분들이 스마트팩토리, 공공, 통신 등 DX 쪽에서 진정한 개발을 하고 싶다는 이유로 빌드센터, 론치센터 등의 Cloud AM으로 MCU를 통해 넘어오시는데요. 선임 B도 동일하게 최근에 넘어왔습니다.

 

주로 비즈니스 로직이 더 중요한 DX와는 달리, Cloud AM에서는 비즈니스 로직들을 신기술로 전환하는 데 초점이 있다보니 두 간극이 생각보다 크게 있더군요.

 

3. DX(도메인 중심)와 Cloud AM(기술 중심)의 간극

DX에서는 '기술' 자체에 대해서 큰 고민을 할 여유나 관련 업무가 없으며, 치명적인 기술 결함이 정말 발생했을 때는 주로... 큰 프로젝트라면, 아키텍트, DBA, 튜너 분들에게 지원을 요청하는 것이 자연스럽습니다. 작은 프로젝트라면, 협력업체의 경력 많으신 고급 개발자 분들의 경험과 노하우로 해결을 합니다.

 

이에 따라 많은 분들이 비즈니스 로직 외의 '화면'과 '로직적 디테일'에 큰 신경을 쓰지 않습니다. 즉 React를 주축으로 한 프론트엔드 역량 및 스프링, 스프링 부트를 주축으로 한 백엔드의 기술적인 depth가 상대적으로 떨어지는데요. 연차는 높아지는 데에 비해 기술 역량이 신기술이 아닌, 익숙한 legacy 기술, ASIS 복붙에 머물러 있게 됩니다. (물론, DX에서는 이 부분보다 비즈니스 도메인 이해가 더 중요합니다. 가치관의 차이입니다.)

 

두 간극은 Cloud AM에 오면 누구나 접하는 문화, 코드 리뷰에서 수준이 극명하게 갈립니다.

 

4. 선임 B의 코드 리뷰 (도메인 중심)

DX 출신 선임 B는 전 팀에서도 코드 리뷰 경험이 있습니다. 전 팀에서는 형식적으로 있는 코드 리뷰였지만, 센터에서는 코드 리뷰를 진심을 하는 것 같아서 꼼꼼히 체크했습니다.

 

A의 코드를 보니 이렇습니다.

1. [FE] 사용자가 가입 정보를 입력하여 가입 버튼을 누른다.

2. [FE] 각 필드 유효성 검사를 한다.

3. [FE] 백엔드 API를 호출한다.

4. [BE] 컨트롤러에서 서비스로 파라미터(가입 정보)를 넘긴다.

5. [BE] 서비스에서 DB에 접근하여, 가입 기본 테이블에 가입 정보를 넣는다.

6. [BE] 가입 상세 테이블에도 넣는다.

7. [BE] 가입 상세와 연결되는 권한 테이블에도 필요한 권한들을 넣는다.

8. ...

 

음! 코드에는 문제될 것이 없어 보입니다. 승인! Good!

 

5. 선임 C의 코드 리뷰 (기술 중심)

선임 C는 입사 자체를 빌드센터로 한 건 아니었지만, 빠른 조직 이동으로 사원 초기에 센터로 이동하였고, 센터에서 보낸 시간이 더 많습니다. 평소에도 클린 코드, 리팩토링에 진심이고 신기술에 관심이 많습니다.

 

같은 A의 코드를 보니 이렇습니다.

1. FE에서는 각 필드 validation을 하는데, BE에서는 따로 validation 후 예외처리하는 로직이 없습니다.

2. 날짜를 String으로 주고받고 있습니다. LocalDate를 사용하면 더 좋을 것 같습니다.

3. 좀 더 보다보니, String으로 받은 날짜를 처리하는 데에 Date와 Calander가 사용되고 있습니다. LocalDate를 사용하는 게 더 좋아 보입니다.

4. Getter와 Setter, Builder가 모든 DTO 클래스에 공통적으로 전역으로 들어가 있습니다. 복붙을 한 것 같습니다.

5. 객체들이 사용된 코드를 살펴보니, Setter가 사용되지 않는 DTO도 있는 것 같습니다. class보다는 record를 사용하면 더 좋을 것 같습니다.

6. 코드 값 비교를 할 때, 필드 값이 앞에 있어서 null safe 하려면 코드 값이 앞에 있는 것이 더 좋아 보입니다.

7. for 문 안에 DB 호출이 들어가 있습니다. 하나하나 DB에 insert하는 것으로 보입니다. N개 추가하려면 DB만 N번 왕복해야 할 것으로 보입니다... 성능에 치명적일 것으로 보이며 DB는 한번만 호출하는 것으로 수정이 필요해 보입니다.

8. ...

 

코드에 개선점과 결함이 모두 발견되며, 문제가 있는 것으로 보여집니다.

 

6. 코드를 보는 관점의 차이

위 사례는 실제 사례는 아니고, 예시를 들기 위해서 각색을 했습니다. 위의 2가지 코드 리뷰를 보면 코드를 보는 관점의 차이가 느껴지나요? 선임 B는 비즈니스 로직 관점에서 코드를 리뷰했고, 선임 C는 작성한 코드에 사용된 기술 관점에서 코드를 리뷰했습니다.

 

어떤 코드 리뷰가 정답이다 라고 이야기하는 것이 아닙니다. 둘 다 당연히 필요한 코드 리뷰입니다. 관점의 차이를 나타내기 위함이었습니다.

 

7. WHAT, HOW

아래와 같은 생각을 갖고 계시다면, 다시 한 번 본인의 코드를 되돌아 보시길 바랍니다.

 

'동작만 제대로 되면 문제 없는 거 아닌가?'

'굳이 정상적으로 동작하는 코드를 수정하고 리팩토링 해야하나?'

'기존에 있던 코드 그대로 들고 온건데, 왜 이걸 사용했는 지 물어보지? 필요하니까 기존 코드도 사용했겠지.'

 

저도 위와 같은 생각들을 했었습니다. 예전에도 사용하던 기능이라 ASIS에 구현된 동작이랑 비슷하게 구현하면 그만이었습니다. 비슷한 동작을 하는 기능이 구현된 게 있어서, 복붙을 하면 그만이었습니다. 어노테이션 몇 개가 잘 모르는 것이긴 하지만, 남들 다 사용하고 있길래 붙여야 되는가보다 싶었습니다. 정말 모르는 것은 구글의 도움을 받아 복붙을 했습니다.

 

위와 같은 개발은 신입이 와도, 개발을 배운 지 얼마 안 된 사람들도 할 수 있는 수준입니다. 이렇게만 개발을 한다면, 3년, 5년, 10년, 20년 뒤에도 어떤 기술이 생겨나도 기능 개발 자체는 할 수 있습니다. 누군가는 비슷한 기능을 개발해뒀을테니까요. 하지만, 개인의 기술 역량은 10년, 20년 전에 머물러 있겠죠.

 

8. WHY에 대한 고민

연차가 쌓일 수록 why에 대한 고민이 필요합니다.

모든 필드에 Getter, Setter 붙이면 쉬운데, 왜 필요한 것에만 붙여야 하는지.

모든 필드에 Getter, Setter 붙일 거면 왜 필드를 private로 하는지.

Date 써도 되는데, 왜 LocalDate를 써야 하는지.

불변성을 왜 고려해야 하는지.

왜 상속을 하는지.

인터페이스가 왜 있는 지.

어플리케이션 단에서 있는 건 update, 없는 건 insert 하면 되는데, 왜 merge문을 사용하는 지.

근본적으로 왜 java를 썼는 지. python, node.js로 개발하면 어떤지.

JPA를 왜 쓰는지.

Type 붙이면 개발 속도만 늦어질텐데, Typescript를 왜 쓰는지?

useState로 상태관리하면 되는데, 왜 전역 상태관리를 하는지?

...

 

9. 말하고 싶은 게 뭐야?

개발을 할 때, 왜 이 기술, 라이브러리, 자료구조 등을 사용하고 있는 지
why에 대한 생각을 하면서 개발을 해야한다.

 

이미 why에 대한 고민을 하고 있는 신입 분들도 있을 수 있습니다. 그렇다면, 그 이상은 무엇일까요...? 저는 아직 이 정도 수준인가 봅니다. 저도 선임 B와 같은 상황이었고, 내가 구현을 해야하는 기능, what에만 중점을 뒀었습니다.

 

현재는 why에 대해서 고민을 하고 공부를 하고 있습니다. 코드 리뷰를 왜 해야 하는지. 유명한 오픈 소스들과 같은 좋은 코드를 왜 봐야하는 지. 이제서야 이해하고 그렇게 성장하려고 하고 있습니다.

 

근데, 제 관점도 모든 분들, 개발자에게 필요한 것이 아닙니다. 어떤 것에 좀 더 가치를 두느냐, 가치관에 따라 본인의 성장 방향이 결정되는 것이니까요. 그냥, 지금 제가 하고 있는 고민과 그에 대한 생각을 정리했을 뿐입니다. 😅

 

 

👏

자, 이렇게 5년차 개발자의 생각을 조금 정리해봤습니다. 공감이 되는 분들도 있고, 아닌 분들도 있을 거에요. 한 사람이라도 저와 같은 생각을 하고 있다면, 영광일 것 같아요! 🤗

 

다른 생각, 더 나은 생각을 갖고 계신다면 댓글로 남겨주세요! 🥰