개발자는 어떤 언어를 익혀야 할가요? 에 대한 개인적인 답 MTO

개발자가 되고 싶은 취준생 혹은 이미 현업에 있는 개발자 분들이 자주 하는 질문은

아마 어떤 언어를 익혀야 할까요? 일 것이다. 

 

언어에 따라 취업할 수 있는 회사도 달라지고 그에 따른 연봉 차이가 나서 개발자들은 고민을 많이 하게 된다.

 

필자 또한 어떤 걸 익혀야 할지 에 대한 고민을 많이 했었다.  

(현재 유행하는 언어를 배워하나? 아니면 많은 사람들이 사용하는 언어를 배워야 하나? 등등)

 

새로운 언어 에 대해 흔히 하는 착각은 갑자기 없던 기술이 뿅(?) 하고 나왔다는 환상을 가지고 있다

사실은 원천 기술을 가지고 기존에 있던 문제에 대해 개선을 해서 나오는 형태 이므로  

새로운 기술을 익힌다고 해서 근본이 되는 기술을 배제하고 익힐 순 없는 노릇이다.

 

도식화하자면 아래와 같은 형태가 될 것이다.

* 원천기술(CS)  -> 레거시 언어 -> 현대 언어 

 

간단한 예로 자바스크립트를 모르는데 Vue, React 같은 언어가 유행하니 그것만 익히면

될 거라고 생각하는 것과 비슷하다. 

 

본론으로 돌아와서 어떤 언어를 익혀야 할지에 대한 답은

특정 언어를 익히는 것보다 개발자 능력 원천이 되는 "MTO(메카니즘, 최적화, 테스트) 이 3가지" 를 익혀 보라고 추천하겠다

 

개발자에서 중요한 것: MTO(메커니즘, 최적화, 테스트)

 

# 메커니즘 (작동원리)

메커니즘 즉 어떤 방식으로 시스템이 작동되는지  작동원리를 이해해야 한다. 

이 부분을 자세히 알기 위해선 컴퓨터 사이언스 (기초지식) 이 요구된다.

 

이점: 프레임웍 튜닝 및 장애 조치 향상 (= 문제 해결 능력 향상)

 

방법:

-CS(컴퓨터 사이언스)

- 공식문서 (대다수 기술들은 외국에서 나오기 때문에 영어로 되어있음)

- 샘플 코드로 직접 구현해보기

 

: 컴퓨터 전공 혹은 자격증 시험에서 나 볼 법한 지식들이 실무에서는 실제로 

사용되지 않을 줄 알았지만 아래 단계인 프레임웍 이해하는데 나 특히 시스템 운영에 있어서

원인 모를 장애를 조치하는 데 있어서 필요한 지식이다.

 

CPU 예시:

CPU가 다수의 쓰레드에 대해 작업을 할당하고 처리할 때 일어 나는 여러 문제점(병목현상, 데드락 등) 이 있는데

컨텍스트 스위칭(=문맥을 전환 하면서 일을 처리하는 것)을 이해하고 있으면 이런 현상이 왜 일어나는지 자세히 알 수 있다.

 

CPU는 쓰레드 하나만 작업이 가능해서 여러 쓰레드를 처리하려면 작업을 전환하면서 처리해야 한다 그리고 그 전환할 때는

상태 정보를 저장을 해야 작업을 넘어갔다가 다시 돌아올 때 앞전에 하던 일을 진행할 수 있다.

 

상태 전환시 작업을 PCB(Proess Control Block) 곳에 기록하는데 이 때  I/O가 발생하기 때문에 오버헤드가 발생한다.

이런 내용을 알아야 멀티 프로세스 환경에서 왜 공통으로 데이터를 처리하는 곳에 락을 걸어 처리해야 하는지

오버헤드가 왜 생기는지 이해할 수 있다.

 

메모리 예시:

예전 메모리는 프로세스 크기만큼 연속적으로 공간을  할당하여 프로세스를 처리했는데

그로 인해 여유 공간이 남더라도 신규로 들어오는 프로세스를 처리할 수가 없었다

 

예를 들어 1~4번까지 메모리 공간이 있다고 가정해보자

1,3번 공간에 프로세스가 작업 중이고 2,4번 공간에는 남는 공간이다 신규로 프로세스를 할당하려면 2,4번을 합쳐야 되는데

지금 구조로썬 분할해서 할당할 수 없기 때문에 신규 프로세스가 작업을 못하고 대기해야 한다.

이런 단편화 문제를 해결하기 위해 메모리를 페이징 단위로 분할하여 프로세스를 적재하여 성능 효율을 높였다.

자세한 내용은 이 블로그를 참고하면 이해를 도울 수 있다. https://jhnyang.tistory.com/264

 

이렇게 분할하여 남는 공간에 작업을 할당하는 기술은 다른 곳에서도 비슷한 경우를 볼 수가 있다.

가령 네트워크의 라우팅이나 RabbitMQ 에 Exchanger 가 하는 역할이다 둘 다 데이터가 들어오면 상대적으로 덜 바쁜 곳에

작업을 할당하여 일을 시킨다. 이걸 보고 만들었다고 할 순 없지만 이렇게 컴퓨터 사이언스에 대한 지식으로 활용될 수 도 있다.

 

# 테스트

이점: 프로그램 신뢰도가 올라가 클라이언트뿐만 아니라 자신에게도 마음의 안정을 찾을 수 있다.

 

방법:

- 프로그램 요구 사항을 단위별로 자세히 살펴본다. 하나하나가 테스트 코드 대상이다.

- 개발 초기라면 테스트 친화적인 설계 (함수 하나에 는 해당하는 기능 하나만 할당해서 단순하게 설계)

반면에 개발이 이미 되어 있는 코드라면 리팩터링을 통해 테스트를 할 수 있도록 분리 대상인 건 분리 하자

그러 던중 테스트가 깨지거나 사이드 이펙트(다른 코드에 영향을 주는 상황)가 발생할 수 있는지 고려해보자

- 단위 테스트가 되었으면 시나리오 기반으로 프로그램을 전체적인 운영을 한다는 입장에서 앞으로 일어날

상황을 예상하고 통합 테스트해보자 그리고 이를 배치로 등록해서 자동으로 위 과정을 체크하도록 하자 

 

개발 일정도 맞춰야 하고 고려해야 할 부분이 더 늘어나기 때문에 테스트 코드를 작성하는 건 쉬운 일은 아니다. 

그렇다고 간과해서도 안 되는 항목으로 코드 품질을 향상할 수 있도록 트라이해보자.

 

# 최적화

이점: 복잡한 코드로 인해 오래 걸리던 유지보수 혹은 실수에 의한 오류 및 버그 발생률을 줄일 수 있고 자신감에 도취될 수 있다.

방법:

-디자인 패턴

: 필자가 경험한 에피소드 두 개를 가지고 설명하고자 한다

 

에피소드 1.

5년 전쯤에 한 회사에서 면접관의 질문이 디자인 패턴을 왜 쓰는가? 였다.

그때 난 대답을 제대로 하지 못했고 속으론 코드가 간결하고 멋있어서(?)가 솔직한 심정이었다.

면접관의 답은 의외로 간단했다 "문제를 해결하기 위해서"라는 것이다.

그리고 그것에 대해 자세히 설명 해줬는데

 

구루급 개발자들이 고심하여 특정 문제는 이런 식으로 코드를 짜게 되면 효율적이다라고 정의해놓은 게 디자인 패턴 이라는 것이다.

(그때 내머리에서 종소리가 울렸다 ㅎㅎ)

 

크게 생성, 구조, 행위 3가지로 분류되고 그 하위에는 여러 가지 패턴들이 존재한다.

개인적인 경험으론 생성에 (싱글톤, 팩토리 패턴) 행위에 (커맨드, 옵서버, 템플릿 메서드 패턴)을 자주 접하게 되니 알아 두면

도움이 될 것 같다.

 

에피소드 2.

유튜브 영상을 우연히 보게 되었는데 그곳에 강사는 설계에 대해 한마디로 정의했다.

다양한 디자인 패턴으로 같은 프로그램을 다양하게 만들 수 있지만

 

역할과 책임을 어떻게 나눌 건지 의존 관계를 어떻게 정의할 건지 그에 따라 코드 형태가 달라지고

프로그램 유지보수도 달라진다라고 하였다 위 의미를 곰곰이 생각해보면 디자인 패턴을 더 잘 구사 할 것이다.

 

-알고리즘

: 데이터를  어떤 식으로 처리하면 속도나 공간에서 효율적인지를 다루는 기술이다.

 

-코드 리팩터링

: 위 테스트 코드 작성과 연관되는 상황이다. 기존에 짜인 코드를 개선을 잘하기 위해선

첫째로 업무 파악이다. 이 함수는 어떤 기능이고 어떻게 작성되어야 하는지를 잘 알아야 하고

기능별로 단순하게 분리되어 있는지 를 체크해보자 

 

두 번째로 리팩터링 정의는 실행 결과가 변경되선 안된다. 기능 추가나 수정이 일어나선 안된다는 말이다.

안에 내부구조를 개선하는데 목적이 있다. 그 부분을 염두에 두자

 

세 번째로 한군대를 리팩터링 하게 되면 다른 부분에 영향이 갈 수 있는지 확인해보자

 

리팩터링이 완성되면 중복이 제거되고 코드가 간결해지는 걸 느낄 수 있다.

 

필자가 생각 하는 실력있는 개발자가 되는 방법은  위 3가지의 기술을 밸런스 있게 수련해 나가면 되지 않을가 생각 해본다.