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

                
                

				<h2 id="시니어-개발자">시니어 개발자</h2>

<ul>
  <li>트렌디한것과, 로우 레벨 깊이와, 경험의 균형을 잡고 합리적인 판단을 해야 한다.</li>
  <li>이 균형을 놓치기 시작하면, 팀원들의 공감을 못얻고, 결국 뒤쳐지는 경우를 많이 봄</li>
  <li>경쟁력을 위해 꾸준히 발전하고, 성장해야 하는 것이 개발자가 평생 공부 해야 된다는 개념</li>
</ul>

<h2 id="어떻게-해야-하나">어떻게 해야 하나?</h2>

<h3 id="철저히-재미">철저히 재미</h3>
<ul>
  <li>누가 안시켜도 지속 가능</li>
  <li>그냥 재밌으니까, 우선 순위가 자연스레 높아짐
    <ul>
      <li>만약 자연스레 안 높아지면, 다른 일이 너무 많아서 시간이 없거나, 그 정도 재밌는건 아닌것
        <h3 id="업무적-역량-개발">업무적 역량 개발</h3>
      </li>
    </ul>
  </li>
  <li>어떠한 업무 방향이 있을 때, 문제를 해결하기 위해서 우리가 떠올릴 수 있는 범주 내에서 결론을 냄
    <ul>
      <li>이 범주를 넓히는 것</li>
    </ul>
  </li>
  <li>내가 업무에서 모든 경험을, 다 할 수 없음
    <ul>
      <li>업무는 분담할 수 밖에 없고, 분담해서 진행한 부분에 대한 이해도는 따라 잡아야 됨
        <ul>
          <li>리뷰도 하고, 사용도 하고, QA 대응도 같이 하게 될 수도 있음</li>
          <li>하지만, 내가 직접 베이스부터 구현한 이해도 만큼은 아님
            <ul>
              <li>결국 나는 시간을 들여서 이해도를 끌어 올리는 프로젝트를 해야 함</li>
            </ul>
          </li>
        </ul>
      </li>
    </ul>
  </li>
  <li>새로운 기술의 도입 혹은 개선 방향
    <ul>
      <li>업무적으로 시간을 배정 받을 수 있으면 나이스 함
        <ul>
          <li>하지만 현실적으로 이러한 리서치에 일정이 주어지는 환경이 내 기준으로 아주 많지 않았음</li>
        </ul>
      </li>
      <li>토이 프로젝트에서 어느정도 결론을 내야, 이 것이 어떤 방향으로 해야 되는지 알 수 있다
        <ul>
          <li>심지어 조금 아쉬운 퀄리티라도, 자신만의 결론을 내야 함</li>
        </ul>
      </li>
    </ul>
  </li>
</ul>

<h2 id="어떻게-이-것들을-업무-시간-이외에-하는가">어떻게 이 것들을 업무 시간 이외에 하는가?</h2>

<ul>
  <li>전제 조건을 깔겠음
    <ul>
      <li>저도 크런치 빈도가 높고, 주말 출근까지 할 때는 못합니다</li>
      <li>적어도 8~10시에는 퇴근하는게 패턴인 시기에 가능함
        <ul>
          <li>주말도 쉬어줘야… 여력도 생기고 컨디션도 괜찮아서 가능했음</li>
        </ul>
      </li>
    </ul>
  </li>
</ul>

<h2 id="어떻게-했냐">어떻게 했냐?</h2>

<ul>
  <li>나는 최소 마지노선이 1시간이고, 원하는 목표를 달성하면 빨리 끝내고, 재밌으면 더 길게함</li>
  <li>이 Dev Toy알림이 항상 저에게 노이즈로써 작용해야 하고 Snooze 할 수 없어야 했음
    <ul>
      <li>이 Dev Toy하지 않는 것이 저에게 만큼 프로답지 못한, 시니어 개발자 답지 못한 자세라고 규정지었음
        <ul>
          <li>사실 Dev Toy 안 하는 시니어가 아주 많음</li>
          <li>남들도 안하니까 나도 안해도 괜찮다고 생각하지 않는 것이 중요함</li>
          <li>사실 여기까지 오기 전에 즐거움을 많이 느껴야 함
            <ul>
              <li>즐거운 힘, 그리고 자율적인 압박이 꾸준함으로 치환될 수 있음</li>
            </ul>
          </li>
        </ul>
      </li>
    </ul>
  </li>
  <li>출퇴근 시간에 Dev Toy의 방향성을 정리하는 것을 계속 함
    <ul>
      <li>뭘 할 것인가?</li>
      <li>어떻게 할 것인가?</li>
      <li>출퇴근 시간에는 자료 읽기는 꾸준히 함</li>
      <li>출퇴근 시간에 코딩을 한 적도 있으나, 버스가 너무 불편하고 옆자리에 영향을 줘서 생각을 정리하고, 리서치 하는 것 위주로만 하고 있음</li>
    </ul>
  </li>
  <li>너무 먼 프로젝트는 절대 하지 않았음
    <ul>
      <li>한 시간 단위로 결과를 낼 수 있는 단위로 일을 쪼갤 수 없으면 진행하지 않음</li>
      <li>각이 안잡히는 방향성은 1시간 이상은 쓰지 않음</li>
    </ul>
  </li>
  <li>예를 들어 기술 학습
    <ul>
      <li>철저히 Best Practice를 따라 갔고, 허들이 생길만한 수준은, 이 것을 경험하고, 이해도가 높아지고 나서 경험하게 유도함</li>
      <li>새로운 언어 배울 땐 환경 구성 같은 것이 좀 시간이 걸림
        <ul>
          <li>시간이 걸리는 데드라인을 정하고 이를 넘어서면 학습 대상에서 빠르게 배제</li>
        </ul>
      </li>
      <li>어떠한 학습에 허들이 많이 오는 경험은 Dev Toy를 부담스럽게 만든다고 규정함
        <ul>
          <li>허들이 많이 걸릴 수록 뒤로 (사실은 거의 반 이상 폐기) 미룸
            <ul>
              <li>내 이해도 때문 일 수도, 해당 기술이나, 패키지가 성숙하지 못해서일 수도 있음
                <ul>
                  <li>어떤 경우던 허들이 많이 느껴지면 바로 폐기</li>
                </ul>
              </li>
            </ul>
          </li>
        </ul>
      </li>
      <li>무언가 구현을 할 때, 어떻게 해야 될지 감이 안잡히면 절대 하지 않았음
        <ul>
          <li>이러한 고민은 업무나, 일부 도전 주제에 가까운 큰 맘먹고 해야 되는 일부 주제 한정임</li>
          <li>기본적으로 내가 어떻게 구현해보고, 어떤 경험을 해보고, 어떠한 이해도를 높일 것인지가 추상적이면, 내가 그것을 결론내기 전까지는 TO DO 상태로만 유지함
            <ul>
              <li>TO DO 상태에 오래 남은 주제는 archive로 보냄</li>
            </ul>
          </li>
        </ul>
      </li>
    </ul>
  </li>
</ul>

<h2 id="그래도-잘-안되는-시기가-있음">그래도 잘 안되는 시기가 있음</h2>

<ul>
  <li>이럴 때는 기존에 만들었던 Toy 프로젝트를 폴리싱하거나</li>
  <li>진짜 재밌는 내가 만드는 소품 프로젝트 같은 것만 함</li>
  <li>내가 써먹는 제품을 만드는 게 제일 좋음
    <ul>
      <li>기존 제품이 어떤 이유에서건 부족함이 있어서, 내가 개선 해야 되는데, 해당 제품 만든사람만 개선할 수 있는 상황일 때가 좋았음</li>
    </ul>
  </li>
  <li>성취감을 느껴야 함
    <ul>
      <li>이 행위가 재미, 카타르시스를 못 일으키면 지속성있기가 어려움</li>
      <li>적어도 자신은 만족 시켜야 함</li>
      <li>그래서, 나는 백엔드 개발자지만, 시각적 자극을 줄 수 있는 수단을 보조 하는 것을 좋아함
        <ul>
          <li>프론트 or 슬랙 웹 훅, 디스코드 연동, 기존에 내가 다른 툴과 연동 이런식으로 시각적으로 볼 수 있게 제품을 만들어 내는 것을 좋아함</li>
        </ul>
      </li>
      <li>기존에 만든 Dev Toy와의 연계를 통해 시너지를 체감하고 이를 즐거움으로 느낄 수 있게 유도함</li>
    </ul>
  </li>
  <li><strong>나의 성장, 사용처, 시너지를 계속 떠올려야 성취감을 느끼고, 즐거움을 느껴서 지속할 수 있다</strong></li>
</ul>


                <hr>
                <ul>
                    
                    <li>
                        <a href="/2025/01/01/retrospect/" data-toggle="tooltip" data-placement="top" title="2024 한해 회고">
                        Previous<br>
                        <span>2024 한해 회고</span>
                        </a>
                    </li>
                    
                    
                </ul>
                <hr>

                
                
                
                
                

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

Elky Essay

시니어 개발자
트렌디한것과, 로우 레벨 깊이와, 경험의 균형을 잡고 합리적인 판단을 해야 한다.
이 균형을 놓치기 시작하면, 팀원들의 공감을 못얻고, 결국 뒤쳐지는 경우를 많이 봄
경쟁력을 위해 꾸준히 발전하고, 성장해야 하는 것이 개발자가 평생 공부 해야 된다는 개념
어떻게 해야 하나?
철저히 재미
누가 안시켜도 지속 가능
그냥 재밌으니까, 우선 순위가 자연스레 높아짐
    
만약 자연스레 안 높아지면, 다른 일이 너무 많아서 시간이 없거나, 그 정도 재밌는건 아닌것
        
업무적 역량 개발
어떠한 업무 방향이 있을 때, 문제를 해결하기 위해서 우리가 떠올릴 수 있는 범주 내에서 결론을 냄
    
이 범주를 넓히는 것
내가 업무에서 모든 경험을, 다 할 수 없음
    
업무는 분담할 수 밖에 없고, 분담해서 진행한 부분에 대한 이해도는 따라 잡아야 됨
        
리뷰도 하고, 사용도 하고, QA 대응도 같이 하게 될 수도 있음
하지만, 내가 직접 베이스부터 구현한 이해도 만큼은 아님
            
결국 나는 시간을 들여서 이해도를 끌어 올리는 프로젝트를 해야 함
새로운 기술의 도입 혹은 개선 방향
    
업무적으로 시간을 배정 받을 수 있으면 나이스 함
        
하지만 현실적으로 이러한 리서치에 일정이 주어지는 환경이 내 기준으로 아주 많지 않았음
토이 프로젝트에서 어느정도 결론을 내야, 이 것이 어떤 방향으로 해야 되는지 알 수 있다
        
심지어 조금 아쉬운 퀄리티라도, 자신만의 결론을 내야 함
어떻게 이 것들을 업무 시간 이외에 하는가?
전제 조건을 깔겠음
    
저도 크런치 빈도가 높고, 주말 출근까지 할 때는 못합니다
적어도 8~10시에는 퇴근하는게 패턴인 시기에 가능함
        
주말도 쉬어줘야… 여력도 생기고 컨디션도 괜찮아서 가능했음
어떻게 했냐?
나는 최소 마지노선이 1시간이고, 원하는 목표를 달성하면 빨리 끝내고, 재밌으면 더 길게함
이 Dev Toy알림이 항상 저에게 노이즈로써 작용해야 하고 Snooze 할 수 없어야 했음
    
이 Dev Toy하지 않는 것이 저에게 만큼 프로답지 못한, 시니어 개발자 답지 못한 자세라고 규정지었음
        
사실 Dev Toy 안 하는 시니어가 아주 많음
남들도 안하니까 나도 안해도 괜찮다고 생각하지 않는 것이 중요함
사실 여기까지 오기 전에 즐거움을 많이 느껴야 함
            
즐거운 힘, 그리고 자율적인 압박이 꾸준함으로 치환될 수 있음
출퇴근 시간에 Dev Toy의 방향성을 정리하는 것을 계속 함
    
뭘 할 것인가?
어떻게 할 것인가?
출퇴근 시간에는 자료 읽기는 꾸준히 함
출퇴근 시간에 코딩을 한 적도 있으나, 버스가 너무 불편하고 옆자리에 영향을 줘서 생각을 정리하고, 리서치 하는 것 위주로만 하고 있음
너무 먼 프로젝트는 절대 하지 않았음
    
한 시간 단위로 결과를 낼 수 있는 단위로 일을 쪼갤 수 없으면 진행하지 않음
각이 안잡히는 방향성은 1시간 이상은 쓰지 않음
예를 들어 기술 학습
    
철저히 Best Practice를 따라 갔고, 허들이 생길만한 수준은, 이 것을 경험하고, 이해도가 높아지고 나서 경험하게 유도함
새로운 언어 배울 땐 환경 구성 같은 것이 좀 시간이 걸림
        
시간이 걸리는 데드라인을 정하고 이를 넘어서면 학습 대상에서 빠르게 배제
어떠한 학습에 허들이 많이 오는 경험은 Dev Toy를 부담스럽게 만든다고 규정함
        
허들이 많이 걸릴 수록 뒤로 (사실은 거의 반 이상 폐기) 미룸
            
내 이해도 때문 일 수도, 해당 기술이나, 패키지가 성숙하지 못해서일 수도 있음
                
어떤 경우던 허들이 많이 느껴지면 바로 폐기
무언가 구현을 할 때, 어떻게 해야 될지 감이 안잡히면 절대 하지 않았음
        
이러한 고민은 업무나, 일부 도전 주제에 가까운 큰 맘먹고 해야 되는 일부 주제 한정임
기본적으로 내가 어떻게 구현해보고, 어떤 경험을 해보고, 어떠한 이해도를 높일 것인지가 추상적이면, 내가 그것을 결론내기 전까지는 TO DO 상태로만 유지함
            
TO DO 상태에 오래 남은 주제는 archive로 보냄
그래도 잘 안되는 시기가 있음
이럴 때는 기존에 만들었던 Toy 프로젝트를 폴리싱하거나
진짜 재밌는 내가 만드는 소품 프로젝트 같은 것만 함
내가 써먹는 제품을 만드는 게 제일 좋음
    
기존 제품이 어떤 이유에서건 부족함이 있어서, 내가 개선 해야 되는데, 해당 제품 만든사람만 개선할 수 있는 상황일 때가 좋았음
성취감을 느껴야 함
    
이 행위가 재미, 카타르시스를 못 일으키면 지속성있기가 어려움
적어도 자신은 만족 시켜야 함
그래서, 나는 백엔드 개발자지만, 시각적 자극을 줄 수 있는 수단을 보조 하는 것을 좋아함
        
프론트 or 슬랙 웹 훅, 디스코드 연동, 기존에 내가 다른 툴과 연동 이런식으로 시각적으로 볼 수 있게 제품을 만들어 내는 것을 좋아함
기존에 만든 Dev Toy와의 연계를 통해 시너지를 체감하고 이를 즐거움으로 느낄 수 있게 유도함
나의 성장, 사용처, 시너지를 계속 떠올려야 성취감을 느끼고, 즐거움을 느껴서 지속할 수 있다

Dev Toy를 지속하는 이유

댓글