<div id="readability-page-1" class="page"><cite>Berno</cite>
 2022. 4. 30. 21:11
 <div>
 <blockquote data-ke-style="style1">어디까지나 순전히 제 생각임을 밝히며 틀린 내용일 수도 있습니다</blockquote>

이제 3년 차 개발자이면서 개발을 잘한다고 말할 수는 없는 상태에서 어디 가서 함부로 말하기 위험한 주제일 수도 있지만 개발에 대한 생각을 의식의 흐름대로 작성을 해보고자 한다. 정말 의식의 흐름대로 작성할 거라 갑자기 옆길로 샐 수 있는 점 미리 말한다.



<h3 data-ke-size="size23">1. 나는 지금 무엇을 개발하고 있지</h3>
학부생 때 교수님이 내준 과제, 프로젝트를 하거나 회사에서 제품에 대한 개발을 진행하거나 개인 프로젝트를 진행하는 등 개발자는 다양하지만 항상 개발을 하고 있다.(물론 Paper work가 많을 수 있다. 그저 애도를 표한다. 이 부분 또한 다루도록 한다.) 개인 프로젝트의 경우 본인이 원해서 하는 개발이니 넘어가도록 하자. 그렇다면 타인이 맡긴 개발에 대해 우리는 어떤 생각을 가지고 개발을 하는가
<blockquote data-ke-style="style2">'이건 내 제품이 아니다.' '회사 프로그램이지 내 프로그램이 아니잖아'&nbsp;</blockquote>
이 생각을 가지고 개발하는 사람이 적잖게 있을 것으로 생각한다.&nbsp; 실은 이 생각이 틀렸다고는 할 수 없다. 동기부여가 충분히 되지 않은 상태에서 무작정 이 프로그램에 대해 애정과 주인의식을 가지라는 것은 주입식 강요로 생각된다. 그렇다면 주인의식을 가지게 하기 위해 어떤 일들이 있어야 할까. 
이건 더더욱 정답이 없다고 생각한다. 월급이 문제일까? 아니다. 동일 월급을 받는 입장에서 주인의식을 가지는 사람이 있고 가지지 않는 사람이 있다. 그저 개발자의 가치관 차이라고 본다. 다만 큰 범위로 짐작을 해보자면 이 부분에서 차이가 있지 않을까 예상해본다.
<blockquote data-ke-style="style2">어디까지나 퇴사를 하면 이 프로그램은 더 이상 내 프로그램이 아니기 때문이다.&nbsp;</blockquote>
잠시 다른 이야기를 한 것 같지만 이 항목에서 말하고자 하는 건 단 하나다. 내가 주인의식을 가지고 있던 아니던 우리는 무엇을 개발하는지 알고 개발을 해야 한다는 것이다. 목적 없는 개발은 금방 지루해지고 많은 사이드 이펙트를 발생시킬 수 있기 때문이다.


<h3 data-ke-size="size23">2. 이 코드는 어떤 생각을 가지고 만들었을까</h3>
우리가 처음 코드를 작성하던 코드를 생각해보자. (나는 대학교에서 c언어를 첫 언어로 배웠다.)
<pre id="code_1651318026097" data-ke-language="c++" data-ke-type="codeblock"><code>#include &lt;stdio.h&gt;

void main(){
printf("hello world!");
}</code></pre>
hello world! 컴퓨터 세상아 안녕! 등 우리를 환영하는 의미로 적힌 문구로 나는 생각한다.&nbsp; 이 코드를 시작으로 개인의 필체, 지문처럼 우리는 서로 다른 스타일의 코드를 작성하기 시작한다. 점점 개발을 하기 시작하며 오픈 소스, 라이브러리, 회사에 입사하고 전임자가 작성한 코드 등 다양한 코드를 보게 되며 여러 감정을 느끼게 된다. 어떨 때는 감탄을, 어떨 때는 지루함을, 어떨 때는 화남을 느끼는 등 다양한 감정을 느끼게 되는데 이 코드를 보며 우리는 생각해야 한다.
<blockquote data-ke-style="style2">어떤 생각으로 이 코드를 작성했을까</blockquote>
전임자가 코드를 개판으로 작성해뒀다고 무작정 욕을 할 수 도 있다. 근데 정말 시간이 없어서 리팩토링이나 예쁜 코드를 신경 쓸 겨를이 없이 개발을 했을 가능성도 있다. 클린 코드, 리팩토링 등 좋은 책들이 존재하고 OOP에 대한 원칙(무조건 신봉하면 안 되겠지만..)이 존재한다. 우리가 개발을 하며 처음부터 코드를 착착착 예쁘게 작성할 수 있는 능력이 있다면 얼마나 좋을까. 특히 주니어 때는 그러기 힘들 것이다. 주니어기 때문에 개발을 하면서 마감 시간에 대한 압박이 있을 수도 있고 어떻게 작성해야 예쁜 코드인지 모를 수도 있다. 그러나 예쁘지 않은 코드에서도 어떤 생각으로 이 함수, 변수, 클래스를 작성했는지 짐작을 해볼 수 있다. 생각 없이 작성한 코드는 위험하다. 코드는 이 개발자에 대해 추측을 할 수 있는 가장 큰 증거물이며 레거시로 남게 되면 코드의 author와 scm committer에 내 이름과 함께 영구 박제가 되기 때문이다. 코드에는 개발자의 생각과 철학이 담겨있다.&nbsp;


<h3 data-ke-size="size23">3. 남들이 보기에 좋은 코드일까?</h3>

보기에 좋은 코드는 어떤 코드일까. 맨 처음 프로그래밍을 입문했을 때는 절차 지향적으로 하나의 파일에 소설책 읽듯이 다 나열되어있는 코드가 읽기 좋은 코드였다. 점점 모듈화, OOP, MVC 등 개발에 대한 철학을 접하게 되며 파일이 많아지게 된다. 이때부터 각 기능이 잘 구분되어 있는 코드가 보기 좋은 코드가 되기 시작했다. 그러면 결국 잘 구분되어 있는 코드가 좋은 코드일까? 이 또한 아닌 것 같다. 
하나의 예시를 들어보자. 
<blockquote data-ke-style="style3">하나의 클래스를 작성하더라도 내부적으로 함수형 프로그래밍을 하는 개발자가 있고 그렇지 않은 개발자가 있다. 협업을 하는 개발자가 5명인데 4명은 함수형 프로그래밍에 대해 모른다. 1명은 함수형 프로그래밍에 자신이 있고 기능 또한 완벽하게 구현해낸다. 리뷰를 하며 설명을 할 수는 있겠지만 다른 4명이 이 코드에 대해 이해를 하지 못한다.&nbsp;</blockquote>
이 예시에서 함수형 프로그래밍을 모르는 4명은 어떤 생각을 가져야 할까. 여러 상황이 있을 수 있다. 
<ol data-ke-list-type="decimal">
<li>함수형 프로그래밍에 대해 공부를 시작한다.</li>
<li>기능이 정상 동작하고 테스트 코드까지 통과했으므로 일단 넘어간다.</li>
<li>리뷰 할 때 저 함수가 어떤 건지 설명을 듣긴 했지만 난 내 스타일대로 작성할 거라 공부하지 않을 거다.</li>
<li>무작정 함수형 프로그래밍을 사용하지 말라고 한다.</li>
</ol>
더 많은 상황이 있을 수 있지만 이렇게 정의를 해보자. (물론 4번은 너무 극단적이긴 하지만 정말 혹시나, 만약을 가정했다.)
1번은 이 코드에 대해 감명을 받거나 이해하기 위해 공부를 시작한 개발자이다. 내가 선호하는 유형이며 개발자가 지녀야 할 자세라고 생각한다.
2번과 3번은 개발자의 생각이 강한 경우다. 내가 저걸 몰라도 개발만 잘하면 되는 거지 라는 생각으로 일단 동작을 하니까 넘어가는 케이스다.
4번은 함수형 프로그래밍을 했던 개발자가 욕을 해도 합법인 경우라고 생각한다.

물론 뭐가 잘못되었다고는 딱 자르지 못한다. 다만 이 예시에서 알 수 있는 건 나한테 잘 작성된 코드일 수 있지만 다른 사람에게는 아닐 수 있다는 것을 받아들여야 한다는 것이다.&nbsp;

<h3 data-ke-size="size23">4. 나는 그저 맹목적으로 업무에 충실한 개발자인가</h3>

1번 항목과 가장 밀접한 항목이다. 실은 맹목적으로 업무에 충실한 개발자가 되는 것이 당장 업무를 맡긴 입장에서는 좋을 수 있다. 이 사람은 내가 만들라고 하는 기능, 프로그램을 뚝닥 뚝닥 만들어내기 때문이다.(물론 시행착오와 버그가 엄청 많을 수 있다.) 근데 이게 과연 정말 업무와 개발자 둘 다에게 좋은 현상일까?

내 생각을 먼저 말한다.
<blockquote data-ke-style="style2">다양한 경험이 좋은 개발자를 만들고 좋은 개발자는 회사에 좋은 기능과 코드를 가져다준다.&nbsp;</blockquote>

업무 외적으로 개발과 공부를 지속한 개발자를 성장하는 개발자라고 말한다. 
업무에 맹목적으로 충실했던 개발자는 항상 하던 개발 스택이 아닌 다른 개발 스택으로의 개발이 요구된 경우 전환을 하기 어려울 수 있다. 그러면 이 업무를 맡긴 사람 입장에서는 어떻게 생각할까.
<ol data-ke-list-type="decimal">
<li>이건 새로운 거라 이 사람은 못하는 거구나.</li>
<li>아니 그래도 비슷해 보이는데 왜 못하는 거지.</li>
</ol>

아마 이 2가지 생각이 있을 것 같다(2번의 경우를 만나면 이건 도망치자). 그래도 외적으로 계속해서 공부를 했던 사람은 어쩌다 운 좋게 본인이 공부했던 내용에서 걸릴 수 있다. 그러면 더 좋은 인상을 남길 여지가 충분해진다.

개발자는 평생 공부를 해야 하는 직종 중 하나다. 계속해서 새로운 기술이 나오고 과거에 묶여서는 더 나아갈 수 없다. 
물론 무작정 회사에서 사용하던 거랑 다른 거 공부하란 말이 아니다. 회사에서 사용하는 기술에 대해 내가 파악이 되고 개발을 할 줄 아는 수준이 된 후의 이야기다. 어떻게 마무리해야 할지 모르겠는데 그냥 딱 한 문장으로 정리해보자.
<blockquote data-ke-style="style3">회사에서 쓰는 기술 스택 어느 정도 공부하고 난 이후에 본인이 하고 싶은 공부 하자.</blockquote>

<h3 data-ke-size="size23">5. 나는 어떤 방향으로 가고 있을까</h3>
자신이 좋아하는 공부를 하며 기술 스택을 쌓게 되고 회사에 취업하면서 커리어를 쌓게 되며 우리는 스스로에 대해 어떤 개발자인지를 정의하게 된다. 커리어 패스라는 말에서 패스라는 단어는 말 그대로 경로, 길을 나타낸다. 내가 어떠한 길을 걸어왔는지 사람들은 확인하고 나를 평가하게 된다. 개발자의 가치를 올릴 수 있는 방법은 여러 가지가 있겠지만 그걸 누군가 대신해줄 수는 없다. 스스로 해야 하고 그게 맞는지 아무도 보장은 못한다. 
<blockquote data-ke-style="style3">다만 내가 어떤 방향으로 어떤 길을 걸어왔고 걸어갈지는 계속해서 확인을 하며 걸어야 한다고 생각한다. </blockquote>


<h3 data-ke-size="size23">마무리하며</h3>
그저 아무 말 대잔치 일 수 도 있는 이 글을 작성하며 여기저기 굴러다니던 생각을 어느 정도 정리할 수 있었다.
이 글을 시작하면서도 말했지만 정말 3년 차 주니어 개발자가 틀린 생각을 말하는 것일 수 있고 그저 아무 말 대잔치일 수도 있다. 이런 생각을 가진 개발자도 있구나 생각해주기를 바란다.
 
 
 </div></div>

흔한 컴공출신 개발자

bernoyoun

어디까지나 순전히 제 생각임을 밝히며 틀린 내용일 수도 있습니다
 
이제 3년 차 개발자이면서 개발을 잘한다고 말할 수는 없는 상태에서 어디 가서 함부로 말하기 위험한 주제일 수도 있지만 개발에 대한 생각을 의식의 흐름대로 작성을 해보고자 한다. 정말 의식의 흐름대로 작성할 거라 갑자기 옆길로 샐 수 있는 점 미리 말한다.
 
 
 
1. 나는 지금 무엇을 개발하고 있지
학부생 때 교수님이 내준 과제, 프로젝트를 하거나 회사에서 제품에 대한 개발을 진행하거나 개인 프로젝트를 진행하는 등 개발자는 다양하지만 항상 개발을 하고 있다.(물론 Paper work가 많을 수 있다. 그저 애도를 표한다. 이 부분 또한 다루도록 한다.) 개인 프로젝트의 경우 본인이 원해서 하는 개발이니 넘어가도록 하자. 그렇다면 타인이 맡긴 개발에 대해 우리는 어떤 생각을 가지고 개발을 하는가
'이건 내 제품이 아니다.' '회사 프로그램이지 내 프로그램이 아니잖아' 
이 생각을 가지고 개발하는 사람이 적잖게 있을 것으로 생각한다.  실은 이 생각이 틀렸다고는 할 수 없다. 동기부여가 충분히 되지 않은 상태에서 무작정 이 프로그램에 대해 애정과 주인의식을 가지라는 것은 주입식 강요로 생각된다. 그렇다면 주인의식을 가지게 하기 위해 어떤 일들이 있어야 할까. 
이건 더더욱 정답이 없다고 생각한다. 월급이 문제일까? 아니다. 동일 월급을 받는 입장에서 주인의식을 가지는 사람이 있고 가지지 않는 사람이 있다. 그저 개발자의 가치관 차이라고 본다. 다만 큰 범위로 짐작을 해보자면 이 부분에서 차이가 있지 않을까 예상해본다.
어디까지나 퇴사를 하면 이 프로그램은 더 이상 내 프로그램이 아니기 때문이다. 
잠시 다른 이야기를 한 것 같지만 이 항목에서 말하고자 하는 건 단 하나다. 내가 주인의식을 가지고 있던 아니던 우리는 무엇을 개발하는지 알고 개발을 해야 한다는 것이다. 목적 없는 개발은 금방 지루해지고 많은 사이드 이펙트를 발생시킬 수 있기 때문이다.
 
 
2. 이 코드는 어떤 생각을 가지고 만들었을까
우리가 처음 코드를 작성하던 코드를 생각해보자. (나는 대학교에서 c언어를 첫 언어로 배웠다.)
#include <stdio.h>
void main(){
printf("hello world!");
}
hello world! 컴퓨터 세상아 안녕! 등 우리를 환영하는 의미로 적힌 문구로 나는 생각한다.  이 코드를 시작으로 개인의 필체, 지문처럼 우리는 서로 다른 스타일의 코드를 작성하기 시작한다. 점점 개발을 하기 시작하며 오픈 소스, 라이브러리, 회사에 입사하고 전임자가 작성한 코드 등 다양한 코드를 보게 되며 여러 감정을 느끼게 된다. 어떨 때는 감탄을, 어떨 때는 지루함을, 어떨 때는 화남을 느끼는 등 다양한 감정을 느끼게 되는데 이 코드를 보며 우리는 생각해야 한다.
어떤 생각으로 이 코드를 작성했을까
전임자가 코드를 개판으로 작성해뒀다고 무작정 욕을 할 수 도 있다. 근데 정말 시간이 없어서 리팩토링이나 예쁜 코드를 신경 쓸 겨를이 없이 개발을 했을 가능성도 있다. 클린 코드, 리팩토링 등 좋은 책들이 존재하고 OOP에 대한 원칙(무조건 신봉하면 안 되겠지만..)이 존재한다. 우리가 개발을 하며 처음부터 코드를 착착착 예쁘게 작성할 수 있는 능력이 있다면 얼마나 좋을까. 특히 주니어 때는 그러기 힘들 것이다. 주니어기 때문에 개발을 하면서 마감 시간에 대한 압박이 있을 수도 있고 어떻게 작성해야 예쁜 코드인지 모를 수도 있다. 그러나 예쁘지 않은 코드에서도 어떤 생각으로 이 함수, 변수, 클래스를 작성했는지 짐작을 해볼 수 있다. 생각 없이 작성한 코드는 위험하다. 코드는 이 개발자에 대해 추측을 할 수 있는 가장 큰 증거물이며 레거시로 남게 되면 코드의 author와 scm committer에 내 이름과 함께 영구 박제가 되기 때문이다. 코드에는 개발자의 생각과 철학이 담겨있다. 
 
 
3. 남들이 보기에 좋은 코드일까?
 
보기에 좋은 코드는 어떤 코드일까. 맨 처음 프로그래밍을 입문했을 때는 절차 지향적으로 하나의 파일에 소설책 읽듯이 다 나열되어있는 코드가 읽기 좋은 코드였다. 점점 모듈화, OOP, MVC 등 개발에 대한 철학을 접하게 되며 파일이 많아지게 된다. 이때부터 각 기능이 잘 구분되어 있는 코드가 보기 좋은 코드가 되기 시작했다. 그러면 결국 잘 구분되어 있는 코드가 좋은 코드일까? 이 또한 아닌 것 같다. 
하나의 예시를 들어보자. 
하나의 클래스를 작성하더라도 내부적으로 함수형 프로그래밍을 하는 개발자가 있고 그렇지 않은 개발자가 있다. 협업을 하는 개발자가 5명인데 4명은 함수형 프로그래밍에 대해 모른다. 1명은 함수형 프로그래밍에 자신이 있고 기능 또한 완벽하게 구현해낸다. 리뷰를 하며 설명을 할 수는 있겠지만 다른 4명이 이 코드에 대해 이해를 하지 못한다. 
이 예시에서 함수형 프로그래밍을 모르는 4명은 어떤 생각을 가져야 할까. 여러 상황이 있을 수 있다. 
함수형 프로그래밍에 대해 공부를 시작한다.
기능이 정상 동작하고 테스트 코드까지 통과했으므로 일단 넘어간다.
리뷰 할 때 저 함수가 어떤 건지 설명을 듣긴 했지만 난 내 스타일대로 작성할 거라 공부하지 않을 거다.
무작정 함수형 프로그래밍을 사용하지 말라고 한다.
더 많은 상황이 있을 수 있지만 이렇게 정의를 해보자. (물론 4번은 너무 극단적이긴 하지만 정말 혹시나, 만약을 가정했다.)
1번은 이 코드에 대해 감명을 받거나 이해하기 위해 공부를 시작한 개발자이다. 내가 선호하는 유형이며 개발자가 지녀야 할 자세라고 생각한다.
2번과 3번은 개발자의 생각이 강한 경우다. 내가 저걸 몰라도 개발만 잘하면 되는 거지 라는 생각으로 일단 동작을 하니까 넘어가는 케이스다.
4번은 함수형 프로그래밍을 했던 개발자가 욕을 해도 합법인 경우라고 생각한다.
 
물론 뭐가 잘못되었다고는 딱 자르지 못한다. 다만 이 예시에서 알 수 있는 건 나한테 잘 작성된 코드일 수 있지만 다른 사람에게는 아닐 수 있다는 것을 받아들여야 한다는 것이다. 
 
4. 나는 그저 맹목적으로 업무에 충실한 개발자인가
 
1번 항목과 가장 밀접한 항목이다. 실은 맹목적으로 업무에 충실한 개발자가 되는 것이 당장 업무를 맡긴 입장에서는 좋을 수 있다. 이 사람은 내가 만들라고 하는 기능, 프로그램을 뚝닥 뚝닥 만들어내기 때문이다.(물론 시행착오와 버그가 엄청 많을 수 있다.) 근데 이게 과연 정말 업무와 개발자 둘 다에게 좋은 현상일까?
 
내 생각을 먼저 말한다.
다양한 경험이 좋은 개발자를 만들고 좋은 개발자는 회사에 좋은 기능과 코드를 가져다준다. 
 
업무 외적으로 개발과 공부를 지속한 개발자를 성장하는 개발자라고 말한다. 
업무에 맹목적으로 충실했던 개발자는 항상 하던 개발 스택이 아닌 다른 개발 스택으로의 개발이 요구된 경우 전환을 하기 어려울 수 있다. 그러면 이 업무를 맡긴 사람 입장에서는 어떻게 생각할까.
이건 새로운 거라 이 사람은 못하는 거구나.
아니 그래도 비슷해 보이는데 왜 못하는 거지.
 
아마 이 2가지 생각이 있을 것 같다(2번의 경우를 만나면 이건 도망치자). 그래도 외적으로 계속해서 공부를 했던 사람은 어쩌다 운 좋게 본인이 공부했던 내용에서 걸릴 수 있다. 그러면 더 좋은 인상을 남길 여지가 충분해진다.
 
개발자는 평생 공부를 해야 하는 직종 중 하나다. 계속해서 새로운 기술이 나오고 과거에 묶여서는 더 나아갈 수 없다. 
물론 무작정 회사에서 사용하던 거랑 다른 거 공부하란 말이 아니다. 회사에서 사용하는 기술에 대해 내가 파악이 되고 개발을 할 줄 아는 수준이 된 후의 이야기다. 어떻게 마무리해야 할지 모르겠는데 그냥 딱 한 문장으로 정리해보자.
회사에서 쓰는 기술 스택 어느 정도 공부하고 난 이후에 본인이 하고 싶은 공부 하자.
 
5. 나는 어떤 방향으로 가고 있을까
자신이 좋아하는 공부를 하며 기술 스택을 쌓게 되고 회사에 취업하면서 커리어를 쌓게 되며 우리는 스스로에 대해 어떤 개발자인지를 정의하게 된다. 커리어 패스라는 말에서 패스라는 단어는 말 그대로 경로, 길을 나타낸다. 내가 어떠한 길을 걸어왔는지 사람들은 확인하고 나를 평가하게 된다. 개발자의 가치를 올릴 수 있는 방법은 여러 가지가 있겠지만 그걸 누군가 대신해줄 수는 없다. 스스로 해야 하고 그게 맞는지 아무도 보장은 못한다. 
다만 내가 어떤 방향으로 어떤 길을 걸어왔고 걸어갈지는 계속해서 확인을 하며 걸어야 한다고 생각한다.
 
 
마무리하며
그저 아무 말 대잔치 일 수 도 있는 이 글을 작성하며 여기저기 굴러다니던 생각을 어느 정도 정리할 수 있었다.
이 글을 시작하면서도 말했지만 정말 3년 차 주니어 개발자가 틀린 생각을 말하는 것일 수 있고 그저 아무 말 대잔치일 수도 있다. 이런 생각을 가진 개발자도 있구나 생각해주기를 바란다.

개발에 대한 생각이자 아무말 대잔치

댓글