<div id="readability-page-1" class="page"><article>
    <div>

                
                

				<h2 id="개요">개요</h2>

<p>보통 힘든 취업 준비 기간을 지나서, 취업을 하면 모든 걸 이룬 거 같겠지만, 사실 개발자로서의 인생은 취업한 시점이 시작이다.</p>

<p>내가 다녔던 모 회사에서 신입 공채 합격자인 신입 사원은 수습 기간 통과 후 팀 배정 뒤 첫 회식에서, 공채 통과 했으니 열심히 일하고 싶지 않다. 이미 성공했다고 생각하며, 앞으론 열심히 보다는 즐기며 살고 싶다는 말을 한 친구도 있었지만, 대부분 이런 친구들은 여유로운 팀과 회사 문화가 아닌 경우 위기가 온다.</p>

<p>운 좋게도 위기가 안오는 회사로 가거나, 한 회사에서의 재직 기간으로 버티며 위기 없이 살 수도 있겠지만, 경쟁력 없는 경력자가 되어 팀에 민폐가 되거나, 책임 떠넘기기식 관리자가 되는 케이스도 적지 않다.</p>

<hr>

<h2 id="필요성">필요성</h2>

<p>하지만 생각보다 위 케이스처럼 무던하게 시간이 흘러가며 시니어까지 가는 것도 그리 쉽지 않으며, 몇년의 신입 기간을 허비 한 뒤 보통 인정 받지 못하는 포지션의 시니어가 되었다가, 그때 가서 발에 불등이 떨어 지는 경우도 꽤 많이 봤다.</p>

<p>그때가서도 남탓만 하거나, 각종 변명과 정치로 연명하고, 위기가 올때마다 팀 옮겨가며 버티는 사람도 많이 봤다.</p>

<p>물론, 버틸 수 없게끔 그 이상의 액션을 취하는 회사도 적지는 않았고 말이다.</p>

<hr>

<h2 id="모든-것에는-시기가-있는-법">모든 것에는 시기가 있는 법</h2>

<p>주니어 시기의 성장이 중요한 것은, 위에 언급한 위기가 경력이 쌓일 수록 올 확률이 높아진다는 점이다.</p>

<p>주니어 시기에는 많은 회사가 실수나 역량에 대한 기회를 많이 준다. 내가 다녔던 어떤 회사는 신입 3년간은 무엇이든 실패해도 되는 시간이라는 말을 하기도 했다.</p>

<p>정확한 기간을 정해놓은 것은 아니지만, 나 역시 비슷한 생각을 가지고 있다.</p>

<p>보통 주니어나 신입에게는 기대치를 낮춘 채, 다양한 기회를 부여하는 경우가 많다. (당사자들이 느끼는 것과는 별개 일 수 있겠지만 말이다)</p>

<hr>

<h2 id="예시">예시</h2>

<p>그렇다면 과연 이 시기를 어떻게 보내야 하는 것 일까?</p>

<ol>
  <li>업무 적응
    <ul>
      <li>업무 적응은 무조건 1순위다.</li>
      <li>업무 프로세스, 관리자가 요구하는 규칙들에 대한 숙지
        <ul>
          <li>예시
            <ul>
              <li>Jira에 모든 작업은 일감 등록하고 진행 한다거나</li>
              <li>모든 수정 사항은 main/develop branch를 거치지 않고 feature 브랜치 등을 만들고 pull request를 이용해야 한다거나</li>
              <li>모든 기능에는 유닛 테스트가 추가 해야 된다거나</li>
            </ul>
          </li>
        </ul>
      </li>
    </ul>
  </li>
  <li>업무 개선
    <ul>
      <li>모든 팀은 비효율을 내제하고 있다.
        <ul>
          <li>이에 대한 작은 개선 부터 시작한다.
            <ul>
              <li>큰 개선은 시간 적인 측면에서도, 완성도 적인 측면에서도 쉽지 않을 것이기 때문</li>
            </ul>
          </li>
        </ul>
      </li>
      <li>예시
        <ul>
          <li>develop/main 브랜치에 대한 직접 커밋이 사이드 이펙트가 자주 발생했다면, github 설정을 통해 protect를 걸자는 제안이 있을 수 있다</li>
          <li>유닛 테스트 추가 규칙을 놓치는 사람이 본인이거나, 팀에서도 자주 놓친다면
            <ul>
              <li>유닛 테스트 추가가 누락된 기능에 대한 정책 코드 분석기 추가하고, 빌드시 검증</li>
              <li>혹은 Reflection 등으로 구현</li>
            </ul>
          </li>
          <li>성능 측정 도구의 불편함을 개선, 리포팅 기능 추가</li>
          <li>로그 수집 작업 추가
            <ul>
              <li>보통 라이브 서버는 되어있는데, 개발 서버는 안된 경우는 종종 있음
                <ul>
                  <li>이에 대한 개선</li>
                  <li>만약 라이브 서버도 안되어있으면 이에 대한 반영을 위한, 선행 작업처럼 해도 좋음</li>
                </ul>
              </li>
            </ul>
          </li>
        </ul>
      </li>
    </ul>
  </li>
  <li>기초 보강
    <ul>
      <li>컴퓨터 과학 기초
        <ul>
          <li>자료구조</li>
          <li>OS</li>
          <li>네트워크</li>
          <li>데이터베이스</li>
        </ul>
      </li>
      <li>업무로 사용하고 있지만 원리가 잘 이해 되지 않은 것
        <ul>
          <li>JPA 원리
            <ul>
              <li>JPA 캐싱 규칙</li>
              <li>쿼리가 생성 되는 규칙</li>
              <li>쿼리 로깅</li>
              <li>트랜잭션 처리 과정</li>
            </ul>
          </li>
          <li>스프링과 같은 웹 프레임워크의 내부적 구조
            <ul>
              <li>컨트롤러 까지 들어오는 과정</li>
              <li>DI가 처리 되는 과정</li>
              <li>Filter, Interceptor의 시점 차이</li>
              <li>기본 예외 처리 규칙
                <ul>
                  <li>Custom 예외 처리 규칙은 어떻게 할지</li>
                </ul>
              </li>
            </ul>
          </li>
        </ul>
      </li>
    </ul>
  </li>
  <li>새로운 시도
    <ul>
      <li>새로운 언어나 프레임워크
        <ul>
          <li>모든 언어와 프레임워크는 서로 영향을 주고 받는다.</li>
          <li>자바/스프링에서 사용되는 수많은 기술은 이미 다른 언어나 프레임워크에서 좋은 반응을 얻고 좋은 결과를 냈던 것을 이식한 경우가 많다
            <ul>
              <li>다른 언어나 프레임워크에 대한 경험이 많으면, 자바/스프링을 사용할 때에도 좀 더 폭넓은 인사이트와 시선을 가질 수 있다고 생각</li>
            </ul>
          </li>
        </ul>
      </li>
      <li>분명 회사 생활을 하며 느껴지는 것만으로도 학생 때와 달리 시야가 넓어졌을 것이다.
        <ul>
          <li>부족하다 느끼는 부분도 좋고, 신기하고 새로워 보이는 것도 좋다.</li>
          <li>개발적 관심사를 가지고, 살펴보다 재미를 느꼈거나, 갈증을 느낀 부분 중 어느 것도 좋다.</li>
        </ul>
      </li>
      <li>토이 프로젝트</li>
    </ul>
  </li>
</ol>

<p>위 설명들은 예시일 뿐이고, 얼마든지 어레인지해서 자신의 팀과 상황에 맞는 적합한 노력을 하는 것이 좋다.</p>

<hr>

<h2 id="끝내며">끝내며</h2>

<p>개발자 우대는, 모든 개발자에게 좋은 대우를 하겠다고 느껴지기 쉽지만, 근본적으로 능력있고 훌륭한 개발자에 대한 우대다.</p>

<p>또한 신입은 포텐셜을 보고 뽑는 것인데, 그 포텐셜을 충족하지 못한다면 천덕꾸러기가 되어, 위에 언급한 위기가 오기 쉽다.</p>

<p>이미 무엇을 해야 할지 감을 잡지 못했다면, 이 글을 참고해서 자신만의 계획을 수립해보는 것은 어떨까?</p>


                <hr>
                
                <hr>

                
                
                
                
                

                
            </div>
</article></div>

Elky Essay

개요
보통 힘든 취업 준비 기간을 지나서, 취업을 하면 모든 걸 이룬 거 같겠지만, 사실 개발자로서의 인생은 취업한 시점이 시작이다.
내가 다녔던 모 회사에서 신입 공채 합격자인 신입 사원은 수습 기간 통과 후 팀 배정 뒤 첫 회식에서, 공채 통과 했으니 열심히 일하고 싶지 않다. 이미 성공했다고 생각하며, 앞으론 열심히 보다는 즐기며 살고 싶다는 말을 한 친구도 있었지만, 대부분 이런 친구들은 여유로운 팀과 회사 문화가 아닌 경우 위기가 온다.
운 좋게도 위기가 안오는 회사로 가거나, 한 회사에서의 재직 기간으로 버티며 위기 없이 살 수도 있겠지만, 경쟁력 없는 경력자가 되어 팀에 민폐가 되거나, 책임 떠넘기기식 관리자가 되는 케이스도 적지 않다.
필요성
하지만 생각보다 위 케이스처럼 무던하게 시간이 흘러가며 시니어까지 가는 것도 그리 쉽지 않으며, 몇년의 신입 기간을 허비 한 뒤 보통 인정 받지 못하는 포지션의 시니어가 되었다가, 그때 가서 발에 불등이 떨어 지는 경우도 꽤 많이 봤다.
그때가서도 남탓만 하거나, 각종 변명과 정치로 연명하고, 위기가 올때마다 팀 옮겨가며 버티는 사람도 많이 봤다.
물론, 버틸 수 없게끔 그 이상의 액션을 취하는 회사도 적지는 않았고 말이다.
모든 것에는 시기가 있는 법
주니어 시기의 성장이 중요한 것은, 위에 언급한 위기가 경력이 쌓일 수록 올 확률이 높아진다는 점이다.
주니어 시기에는 많은 회사가 실수나 역량에 대한 기회를 많이 준다. 내가 다녔던 어떤 회사는 신입 3년간은 무엇이든 실패해도 되는 시간이라는 말을 하기도 했다.
정확한 기간을 정해놓은 것은 아니지만, 나 역시 비슷한 생각을 가지고 있다.
보통 주니어나 신입에게는 기대치를 낮춘 채, 다양한 기회를 부여하는 경우가 많다. (당사자들이 느끼는 것과는 별개 일 수 있겠지만 말이다)
예시
그렇다면 과연 이 시기를 어떻게 보내야 하는 것 일까?
업무 적응
    
업무 적응은 무조건 1순위다.
업무 프로세스, 관리자가 요구하는 규칙들에 대한 숙지
        
예시
            
Jira에 모든 작업은 일감 등록하고 진행 한다거나
모든 수정 사항은 main/develop branch를 거치지 않고 feature 브랜치 등을 만들고 pull request를 이용해야 한다거나
모든 기능에는 유닛 테스트가 추가 해야 된다거나
업무 개선
    
모든 팀은 비효율을 내제하고 있다.
        
이에 대한 작은 개선 부터 시작한다.
            
큰 개선은 시간 적인 측면에서도, 완성도 적인 측면에서도 쉽지 않을 것이기 때문
예시
        
develop/main 브랜치에 대한 직접 커밋이 사이드 이펙트가 자주 발생했다면, github 설정을 통해 protect를 걸자는 제안이 있을 수 있다
유닛 테스트 추가 규칙을 놓치는 사람이 본인이거나, 팀에서도 자주 놓친다면
            
유닛 테스트 추가가 누락된 기능에 대한 정책 코드 분석기 추가하고, 빌드시 검증
혹은 Reflection 등으로 구현
성능 측정 도구의 불편함을 개선, 리포팅 기능 추가
로그 수집 작업 추가
            
보통 라이브 서버는 되어있는데, 개발 서버는 안된 경우는 종종 있음
                
이에 대한 개선
만약 라이브 서버도 안되어있으면 이에 대한 반영을 위한, 선행 작업처럼 해도 좋음
기초 보강
    
컴퓨터 과학 기초
        
자료구조
OS
네트워크
데이터베이스
업무로 사용하고 있지만 원리가 잘 이해 되지 않은 것
        
JPA 원리
            
JPA 캐싱 규칙
쿼리가 생성 되는 규칙
쿼리 로깅
트랜잭션 처리 과정
스프링과 같은 웹 프레임워크의 내부적 구조
            
컨트롤러 까지 들어오는 과정
DI가 처리 되는 과정
Filter, Interceptor의 시점 차이
기본 예외 처리 규칙
                
Custom 예외 처리 규칙은 어떻게 할지
새로운 시도
    
새로운 언어나 프레임워크
        
모든 언어와 프레임워크는 서로 영향을 주고 받는다.
자바/스프링에서 사용되는 수많은 기술은 이미 다른 언어나 프레임워크에서 좋은 반응을 얻고 좋은 결과를 냈던 것을 이식한 경우가 많다
            
다른 언어나 프레임워크에 대한 경험이 많으면, 자바/스프링을 사용할 때에도 좀 더 폭넓은 인사이트와 시선을 가질 수 있다고 생각
분명 회사 생활을 하며 느껴지는 것만으로도 학생 때와 달리 시야가 넓어졌을 것이다.
        
부족하다 느끼는 부분도 좋고, 신기하고 새로워 보이는 것도 좋다.
개발적 관심사를 가지고, 살펴보다 재미를 느꼈거나, 갈증을 느낀 부분 중 어느 것도 좋다.
토이 프로젝트
위 설명들은 예시일 뿐이고, 얼마든지 어레인지해서 자신의 팀과 상황에 맞는 적합한 노력을 하는 것이 좋다.
끝내며
개발자 우대는, 모든 개발자에게 좋은 대우를 하겠다고 느껴지기 쉽지만, 근본적으로 능력있고 훌륭한 개발자에 대한 우대다.
또한 신입은 포텐셜을 보고 뽑는 것인데, 그 포텐셜을 충족하지 못한다면 천덕꾸러기가 되어, 위에 언급한 위기가 오기 쉽다.
이미 무엇을 해야 할지 감을 잡지 못했다면, 이 글을 참고해서 자신만의 계획을 수립해보는 것은 어떨까?

주니어를 위한 성장에 필요한 노력

댓글