개발자의 멘토링 활동

Wang_Seok_Hyeon·2023년 9월 24일
0
post-thumbnail

Intro | 무소속 개발자

아직 소속이 없지만 이제 나는 나를 개발자가 되고 싶은 사람이라 칭하지 않고, 개발자라고 이야기 한다.

현재는 개발을 할 줄 알고, 그것들을 바탕으로 새로운 것을 만들고자 할 때 무엇을 찾아보고 어떤 것을 필요로 하는지 알기 때문이다.

특히나 현재 Process가 진행 중인 임베디드 개발자 취업이 진행 중이다.

나는 제로베이스 백엔드 스쿨 9기 과정 6개월을 마쳤고 웹 개발자가 되는 길로 가는 게 가장 좋겠지만, 임베디드로 새로운 나의 커리어를 쌓아도 괜찮을 것 같다는 생각을 하고 있다.

근본적으로 내가 하고자 했던 개발이 무엇인지를 돌이켜 보면, 나는 코딩으로 밥 벌어 먹고 사는 개발자.
이게 내가, 최초에 생각한 나 자신이 부트캠프를 수료하기 전의 개발자의 모습이었다.

하지만 현재에 와서는 웹 개발을 할 수 있게 되며, 많은 것들이 새롭게 보였다.

왜 한국은 이토록 자바를 많이 사용하게 되었는가로 시작된 의문과 답변을 찾아 나가고, 자바의 장점과 단점에 대한 이해.

더 나은 해결책을 위해 나온 것들(Python, JavaScript, Go, Kotlin) 와 같은 것들을 찾게 되고 소프트웨어 개발자는 항상 학습을 해야 한다는 말을 실감하면서도

무엇 보다 중요한 것은 방향성이라는 것을 생각하게 된다.

무턱대고, Python의 문법, JavaScript의 문법, GoLang의 문법, Kotlin의 문법을 배운다고 해도 각각의 차이와 숙련도를 쌓기 위해서는 2개월 이상의 시간이 각각 소요가 될 것이다.

이렇게 8개월 뒤에는 다양한 언어를 사용할 수 있는 능력을 갖춘 사람이 될 수 있겠지만,

그간의 내 생활은? 이외에도 프로젝트와 같은 서비스 개발에 힘 쏟아야 할 무언가, 그리고 영어와 같은 부수적인 필수 교양의 능력을 쌓는 것 역시 개발자에게 중요한 역량이고 필요한 능력이다.

이러한 과정 속에서 방향키를 가지고 하나에 집중할 수 있는 시간을 가지는 것은 너무나 중요하고 이러한 방향키를 잡고 하나를 점 찍어 가거나 지금 시점에 무엇을 해야 하는가를 결정하기 위해서

개발자는 늘 멘토링을 받으며, 더 나은 개발자가 되기 위해 노력해야 한다.

멘토링은 누구에게 받아야 하는가?

멘토링은 자신이 생각했을 때, 자신보다 낫다고 생각하는 동료가 될 수도 있다.
하지만, 개인적인 추천은 자신이 가고자 하는 분야에 5년 이상의 경력을 가지고 있는 개발자 분과 특히나 개발에 관한 소통을 나눌 수 있는 기회가 주어지고 제한된 시간 안에 이루어지는 형태가 좋다.

나 같은 경우에는 제로베이스 백엔드 과정을 수료하고, 이러한 멘토링을 적극적으로 이용하는 편이다.

기술 면접에 관한 동료 학습의 진행과 더불어, 책의 학습, 멘토링 모두를 받으며, 내가 나아갈 방향성과 지식의 축적을 한다.

멘토링이 좋은 이유는 내 관점에서는 전혀 연결되어 있지 않은 개념들이 멘토 분의 입장에서는 모두 연결된 하나의 관점이고,

책 보다 유익한 이유는 책에는 이러한 개념이 있다. 중요하다. 수준으로 말을 하고 끝난다면,

멘토링에서는 이러한게 유리 천장처럼 작용할 수도 있지만 실제 개발에 들어가서 3년 이상의 경력이 쌓이면서 확연히 실력 차이가 드러난다라는 이야기를 들으면 책 속의 중요하다라는 단어와는 격이 다른 흡수를 할 수 있고,

앞서 말했듯 해당 개념의 연결되고 통합되는 개념들의 키워드, 방향성을 얻을 수 있기 때문에 스스로 학습 가이드를 세울 수 있다.

덤으로, 생각도 해 보지 못한 비교군에 관한 고민을 가질 수 있다.

가령, 데이터베이스와 엑셀의 호출에서 차이가 없을 것 같은데 왜 데이터베이스에서 데이터를 읽어 왔느냐?와 같은 질문을 멘토님이 하셨고, 한 동안 헤매고 다른 동료들과도 여러 번 해당 질문을 이야기 했는데 한 동료가 굉장히 납득 가게 잘 설명해주셨고 또 다른 관점에 관해 소통한 것이 결합되며 나 스스로도 개념을 강화할 수 있었다.

좋은 동료의 벨로그를 추천합니다.
해당 개발자 분의 답변은 다음과 같았다. RDBMS의 경우 데이터의 변화가 발생한다면 상태, 개수의 변화에 대한 데이터 변화를 DB보다 빠르게 할 수 있지만, 엑셀의 경우 이러한 변화가 아니라, 단순 데이터 호출, 검색만 하는 경우에는 차이가 없을 거 같다는 이야기였다.

또 다른 개발자 분은 RDBMS를 사용하는 이유를 생각해 보면 테이블 간의 관계를 맺고, 이를 통해 데이터 호출을 각각의 테이블의 JOIN을 통해 할 수 있지만 엑셀은 이러한 호출 방식이 어렵기 때문에 RDBMS의 강점이 있다고 생각한다고 하셨고,

나는 위 두 가지의 개념을 합쳐서,

RDBMS의 테이블 간 관계를 맺으며 데이터의 변화와 각각의 데이터를 독립되고 안전하게 관리함과 더불어 데이터의 변화가 발생하는 경우가 빈번하게 비즈니스에서 발생한다면 데이터의 PK를 가지고 PK의 요소를 통해 값을 찾기 쉬운 RDBMS가 엑셀 보다 강점이 있다고 생각합니다.
하지만, 만약 데이터의 단순 조회만을 한다면 적은 데이터의 경우에는 분명 엑셀에도 강점이 있다고 생각합니다.

정도가 현재 내 머릿 속에 정리된 내용이다.

이러한 내용들이 동료 학습과 멘토링에서 질의자인 멘티의 역할을 통해 개념을 강화해 간다.

이외에도 멘토링에서 나 스스로가 멘토가 되어 활동하는 것도 중요하다. 내가 배운 것들, 내가 학습한 것들을 더 나은 방향성을 제시하고 내가 알고 있던 것이 정말, 내가 익힌 것인지 단순히 그냥 외운 것인지를 알 수 있게 되고 더 발전해 가기 때문이다.

멘토 활동

나 역시 완벽한 개발자는 아니지만 앞서 말했듯이, 현재 나는 나를 개발자로 정의하고 분명 현재의 나에 미치지 못하는 개발자 분들도 있다고 생각한다.

건방진 말이라기 보다는 단순하게 현재 개발에 대해 아무것도 모르지만 개발을 도전하고자 하는 개발의 첫 발걸음을 뗀 사람이 있다고 생각해 보자.

나의 멘토 활동도 대체로 이렇게 이루어진다. 하지만 결코 그 내용이 부족하게 이루어지지는 않는다.
다만, 단순히 자바에 대한 내용을 다루는 것이 아니라 컴퓨터 프로그래밍 전체 내용을 다루게 된다.

가령, 나는 이런 질문을 자바스크립트로 개발에 입문한 분에게 받게 된다.

function getTwice(number) {
  return number * 2;
};

let x = getTwice(5);
let y = getTwice(4);

console.log(x * y);

위의 코드와 아래의 코드의 차이에 대한 설명이었다.

let x = getTwice(5);
let y = getTwice(4);

function getTwice(number) {
  return number * 2;
};

console.log(x * y);

해당 질문자에게 처음 답변을 할 때는 잘못된 답변을 했다. C언어의 관점으로 이야기를 했고, 이 때 아래의 코드는 function이 밑에 있어서 작동을 안 하지 않을까라고 생각했다.

이와 같은 설명은 잘못되었고 호이스팅 개념을 알고 있는 JS 개발자는 웃을 것이다.

하지만 임베디드 개발자를 준비하며 C언어를 학습하고 이를 통해 스택 개념에 대한 레지스터 이동을 학습했다.

이를 통해 동료 학습을 하며 C언어는 call by value인가 call by reference인가에 대한 질문도 재정리 할 수 있었고

고맙게도 멘티 분이 나의 잘못된 답변으로는 납득이 가지 않아 다시 질문해 주셨고,

스택 개념이 더 견고해진 나는 해당 개념을 이 때에도 호이스팅이 아닌 스택의 개념으로 설명했다.

하지만 결과적으로 호이스팅 역시 내가 아래에 설명하는 과정과 크게 다르지 않은 근본적인 구성을 먼저 수행하는 것이기 때문에 큰 차이는 없다고 생각한다.

질문자는 아래의 코드가 수학적으로 변수를 먼저 선언해 주어서 좋은 개념이라고 생각한다고 했고, 위의 코드는 어색하게 느껴진다는 의견을 주었다.

둘 다 결과에는 차이가 없는데 어떤 차이가 발생하는지가 궁금하다는 것이 문제였다.

스택의 개념으로만 해당 내용을 설명했고, 인터프리터/컴파일러의 개념을 의도적으로 이야기하지 않고 소개를 했다. 물론 그러던 중에도 인터프리터 언어기 때문에 해당 용어를 사용하긴 했다.

첫 번째 함수를 먼저 선언한 경우, 스택은 함수에 관한 내용을 기록하고, 변수가 들어올 때 이에 대한 함수 getTwice(5)를 만남으로써 다시 스택에 저장해 둔 함수로 가서 해당 결과를 만들어 옴으로써 let x = 10이 되고 마찬가지로 let y = 8이 된다.
그리고 마지막 결과로 80을 반환하게 된다.

두 번째에 변수가 먼저 있는 경우, 스택은 변수를 저장한다. 이때 변수의 getTwice에 관한 내용을 모르는 컴퓨터는 에러를 반환할 수도 있다. 하지만 에러를 반환하지 않는다면 이건 함수의 형태기 때문에 나중에 다시 와서 해당 함수를 처리하겠다는 표시를 남기고 값이 진행된다.
y도 마찬가지이며, 이후 함수를 만나면 해당 함수가 작동해야 하는 변수가 있다는 정보를 스택은 가지고 있기 때문에 해당 변수들을 초기화 해 주고 이를 통해 변화된 x, y는 결과적으로 80의 값을 가지고 오게 된다.

두 번째 설명이 더 길다는 것을 알 수 있다.
이를 현재 호이스팅의 개념을 적용해 더 단순화가 가능한데,

자바스크립트에는 코드가 작동하게 만들기 위해 인터프리터가 먼저 코드 전체를 읽는 작업이 발생한다. 이 때, 해당 코드를 정상적으로 작동 시키기 위해 변수, 함수에 관해서 필요한 것들을 먼저 위로 끌어 올리는 작업이 이루어진다. 이를 통해 아래의 코드도 실제 코드 내부에서는 첫 번째 함수가 먼저 선언 되어 있는 형태로 바뀌어 작동하게 된다.

이렇게 설명할 수 있는데, 멘티 분께서 내가 처음 위의 개념을 설명 드렸을 때 꽤나 크리티컬한 질문을 해 주셨다.

두 코드에 차이가 없다는 걸까요?

이 질문은 단순했지만 단순하게 답변하기는 어려웠다. 그리고 더욱 좋은 설명을 할 수 있도록 나 자신을 발전시킬 수 있었다.

나의 답변은 다음과 같았다.

두 코드의 결과는 80으로 같지만, 첫 번째 코드는 컴퓨터 친화적인 글이고, 두 번째 코드와 같은 유형은 조금 더 사람의 사고 방식에 가깝다고 할 수 있다.(사람 중에 또 다르게 생각할 수도 있지만 우선 여기의 포인트는 컴퓨터의 사고가 아니라는 점이다.)

우리가 맛있다.라고 간단하게 표현할 수 있는 것과
이 맛은 내가 여지껏 먹어 보지 못한 맛이고, 쉽게 표현하기는 어렵지만 감칠맛이... 와 같이 길게 설명할 수 있는 것처럼
컴퓨터가 이해할 수 있는 이진코드에서 첫 번째는 짧지만 두 번째는 긴 이진 코드를 만들게 되는 코드다.

이에 관해, 결과만 중요하다면 괜찮지만, 우리가 개발을 할 때 코드를 작성한 사람의 코드를 보는 것만으로도 이 사람이 어떤 형태로 코드를 학습해 왔고, 어떤 개념을 모를 수도 있고, 또는 알지만 이렇게 작성하는데 익숙해진 사람이라는 요소를 파악할 수 있기 때문에

코드 내외적인 다양한 요소를 알 수 있다는 점에서는 차이가 있다.와 같이 답변을 드릴 수 있었다.

나 역시 모든 코드를 사용할 때 현재에는 단순하게 손에 익은 대로 작성을 하는 게 있을지 모르지만, 처음 학습을 할 때와 지금도 종종 빅오 계산, 내부 동작 원리 등을 고민 해 보며 코드를 작성하고 항상 더 나은 코드에 대한 고민을 하기 때문에

조금 욕심이지만 이러한 방향으로 멘토링을 진행한 것이지 싶다.

멘티분 입장에서는 차이가 없다는 정도가 이해하고 넘어가도 되지만, 차이가 있을 수 있고, 그런 게 있더라 정도만 현재는 알고 넘어가고, 나중에 다시 이러한 개념을 마주하게 될 때 조금 더 빠르게 성장할 수 있지 않을까 생각한다.

Outro. | 개발은 재밌다.

소프트웨어 코딩은 정말 재밌다. 내가 생각하는 것 보다 훨씬 재밌었고, 그래서 더 좋다. 하지만 단순히 좋아하기만 하는 걸로는 잘 할 수 없다. 계속 개념을 갈고 닦고, 그 개념을 적용하며 시도해야 한다.

덤으로 이야기하자면 나는 요리도 좋아한다. 요리에 관한 on Food AND Cooking이라는 1200page에 달하는 요리 서적을 한 페이지에 한 문장, 한 문장 중 중요하다고 생각되는 부분에 밑줄과 메모를 해 가며 봤을 만큼 좋아한다.

하지만 해당 책만을 봤다고 해서 요리를 잘 하게 되는 건 아니다. 지금의 나는 어떤 식재료를 가지고 요리를 하더라도, 기본적인 가공과 조리 방식의 Layer를 쌓을 수 있다.

내가 굳이 이 이야기를 하는 이유는
나의 개발도 이러한 나의 요리에 관한 학습과 발전에 영향을 많이 받았기 때문이다.

책을 읽으며 손으로 직접 써 보고, 코드의 구조를 익히고, IDE를 통해 개발을 해 나가며 기본적인 기술의 숙련도를 올렸다. 웹개발은 조금 더 많은 외부적인 도구들을 이용해야 하는데 이러한 부분은 웹에 대한 개념의 이해가 더 크게 되어야 한다는 점이 요즘 크게 느끼고 이러한 개념을 강화하기 위해 노력하는 중이다.

그 결과 서블릿에 관한 학습, 네트워크의 학습, 컨테이너의 이해 등등 정말 좋은 개발자로 차근차근 나아가고 있다는 생각을 가지고 있다.

미지라는 영역에 있을 때 불쾌하고 답답했던 개념들이 조금씩 이해가 되며, 내가 썼던 코드들의 당위와 목적, 구조를 더욱 긴밀하게 만들 수 있다는 것을 알게 된다.

아는 만큼 보인다. 이 말을 나는 썩 좋아하지 않는다.

모르는 것을 통해 우리가 알게 되는 것의 즐거움을 얻을 수 있기 때문이다.

그렇지만 내가 안다고 생각했던 게 정말 아는 것이 맞는지를 확인하는 게 재밌다. 단순히 개념이라고만 생각했던 게 실제로 동작하는 과정을 보는 것도 좋고, 그것을 조작해 내가 원하는 방식으로 커스텀 하는 것 역시 즐겁다.

이 모든 것을 할 수 있는 게 소프트웨어 개발이고,
정말 누구든지 좋아하지 않을 수 없다고 생각한다.
물론, 어릴 때 레고 블록을 쌓고 가지고 놀거나 10,000pce를 맞추는 걸 좋아했기 때문에 더 이러한 것을 좋아하는지도 모른다.

중요한 건 내가 정말 이러한 걸 좋아하고 발전해 나가고 싶어한다는 점이다.

profile
하루 하루 즐겁게

0개의 댓글