<div id="readability-page-1" class="page"><cite>시뻘건볼때기</cite>
 2024. 2. 15. 09:40
 <div>
 
<h2 data-ke-size="size26">Who</h2>
&nbsp; 나는 이번 해에 6년차를 맞이하는 백엔드 엔지니어다. 지금까지는 회사에서 시키는 것 외에 "뭘 더 알아갈 것이 없나?"하고 이것 저것 시도해보고 장애도 많이 내보면서 "경험"에 포커스를 맞추어 경력을 쌓았다. 6년을 맞이하는 지금, "이제 주니어를 벗어나야하지 않을까?"라는 물음표를 내게 던져보았다. 후배들 앞에서 떳떳하게, 당당하게 창피하지 않은 개발자가 되고싶다.

<h2 data-ke-size="size26">Why</h2>
&nbsp; 6년동안 내가 생각한 "시니어"라 함은 후배가 업무를 어려워하고 있을 때, 적절한 힌트를 줄 수 있고, 여러 이슈에 대한 해결방안을 제안할 수 있으며 자신이 맡은 메인 업무에 대한 히스토리와 개발 방향 그리고 앞으로의 계획을 설명할 수 있어야한다.
&nbsp; 큰 사이즈의 프로젝트가 들어와도 "어디부터 어디까지 손을 대고 어떤 것들을 고려해야하며 어떤 사이드이펙이 있을 수 있기 때문에 n일 소요된다!"라고 확신에 찬 목소리를 낼 수 있는 그런 사람이라고 생각한다.
&nbsp; 그 동안 많은 시니어와 많은 동료들을 만나고 함께 업무를 진행했다. 모든 동료들로부터 배울 점들이 분명히 있었고 그 면들을 내 것으로 만들 수 없었지만 내면에 차곡차곡 쌓아두면서 "그 분이라면 이 이슈를 어떻게 해결해나갈까?"라는 생각으로 접근을 해보기도 한다.
&nbsp; 그렇기에 나는 부끄럽지 않은 시니어가 되고싶다. 누군가 날 롤모델로 삼기를 바라며... 이 얼마나 영광스러운 일일까?

<h2 data-ke-size="size26">How</h2>
&nbsp; 최근 GPT의 핫이슈를 통해 각 기업에서 많은 변화가 있었을 것이라고 생각한다. 그 중에서도 주니어 개발자에 대한 변화가 가장 컸을 것으로 예상으된다. 내가 생각하는 큰 변화는 "GPT에 대한 의존도"이다. GPT가 세상에 나오기 전까지 우리는 stackoverflow 혹은 공식 document, googling 등을 통해서 이슈의 원인을 찾고 해결하면서 내 것으로 만드는 과정을 거쳤을 것이다. 그러나 GPT는 이 것을 단 번에 해결해준다. 물론 100% 정확한 것은 아니지만 대부분 제안까지 해주기 때문에 왜 해결 되었는지에 대한 과정을 본인도 모르게 넘기는 경우를 종종 본 적이 있다.
&nbsp; 나는 GPT 4.x를 사용하지 않는다. 내가 의존하는 순간 내 커리어는 거기까지 일 것이라는 두려움에 겁이난다. 그래서 나는 3.5를 사용하는 대신, 참고용으로 사용하며 보통 googling을 통해 먼저 펙트체크를 먼저 진행한다.
&nbsp; 내 자신의 단점을 항상 보완하려고하자. 이건 대학생 때부터 길들인 버릇이다. 내 자신의 단점을 눈치채거나 누군가 알려준다면 그 부분에 대한 고려를 하고 관리를한다. 예를들어 "비즈니스 개발은 잘 하는데 인프라에 대한 지식이 없어!"라고 한다면 회사 인프라를 직접 그려본다. 방화벽은 어디에서 어떻게 열려있고 보안 장비는 어떻게 동작하며 private 존과 public 존이 어떻게 연결되어있는지, 로드밸런서와 게이트웨이 등을 그림으로 표현해보면 더 복잡해보일 수 있겠지만 머릿속으로 상상만 하는 것보다는 훨신 더 좋은 효과를 낸다. 분명 비즈니스 개발을 하면서 타 서버와 통신을 하는 통신부 혹은 통신 모듈을 개발할 수도 있다. 그렇다면 client를 어떻게 설정해야하고 암/복호화는 어떻게 하며 예외처리는 어떤 것들을 해야하는지 쉽게 알 수 있다.
&nbsp; 최근에 api 호출을 했는데 간헐적으로 readtimeout이 발생되는 경우가 생겼다. 보통은 1번과 같이 A서버에서 B서버의 GET /my/payment-history api를 호출한다는 생각을 하겠지만, 실제로 인프라를 살펴보면 로드밸런서 혹은 게이트웨이를 두어 통신할 수 있다. 만약 이 인프라 그림이 없다면, B서버의 응답시간만 보고 "어? 1초도 안걸렸는데?"라고 생각할 수 있다. 여기까지가 내가 생각하는 주니어 개발자의 모습이지만, 시니어라면 로드밸런서와 게이트웨이를 파악하고 이슈 원인을 분석하여 해결할 수 있어야한다.
<blockquote data-ke-style="style3">1. A server -- GET /my/payment-history --&gt; B server 2. A server --&gt; A' Load Balancer --&gt; --&gt; B server 3. A server --&gt; A' gateway --&gt; --&gt; B server 4. A server --&gt; A' Load Balancer --&gt; A' gateway --&gt; --&gt; B server</blockquote>


<h2 data-ke-size="size26">Plan</h2>
&nbsp; 지식을 습득하고 더 많은 경험을 통해 얻어가는 것이 많아야한다는 내 고집으로 인해 배울 것이 많고 얻을 수 있는 기술력을 가진 회사로 입사하였다. 이 시점에서 만약 내가 이직을 한다면 포커스를 다르게 두고싶다. 그 동안 쌓아올린 나의 경험과 지식을 바탕으로 회사에 기여할 수 있고 성과를 내어 나의 회사를 성장시킬 수 있는 포지션, 그리고 함께 성장할 수 있는 회사로 나아가고싶다.
 
 
 </div></div>

시뻘건 개발 도전기

Who
  나는 이번 해에 6년차를 맞이하는 백엔드 엔지니어다. 지금까지는 회사에서 시키는 것 외에 "뭘 더 알아갈 것이 없나?"하고 이것 저것 시도해보고 장애도 많이 내보면서 "경험"에 포커스를 맞추어 경력을 쌓았다. 6년을 맞이하는 지금, "이제 주니어를 벗어나야하지 않을까?"라는 물음표를 내게 던져보았다. 후배들 앞에서 떳떳하게, 당당하게 창피하지 않은 개발자가 되고싶다.
 
Why
  6년동안 내가 생각한 "시니어"라 함은 후배가 업무를 어려워하고 있을 때, 적절한 힌트를 줄 수 있고, 여러 이슈에 대한 해결방안을 제안할 수 있으며 자신이 맡은 메인 업무에 대한 히스토리와 개발 방향 그리고 앞으로의 계획을 설명할 수 있어야한다.
  큰 사이즈의 프로젝트가 들어와도 "어디부터 어디까지 손을 대고 어떤 것들을 고려해야하며 어떤 사이드이펙이 있을 수 있기 때문에 n일 소요된다!"라고 확신에 찬 목소리를 낼 수 있는 그런 사람이라고 생각한다.
  그 동안 많은 시니어와 많은 동료들을 만나고 함께 업무를 진행했다. 모든 동료들로부터 배울 점들이 분명히 있었고 그 면들을 내 것으로 만들 수 없었지만 내면에 차곡차곡 쌓아두면서 "그 분이라면 이 이슈를 어떻게 해결해나갈까?"라는 생각으로 접근을 해보기도 한다.
  그렇기에 나는 부끄럽지 않은 시니어가 되고싶다. 누군가 날 롤모델로 삼기를 바라며... 이 얼마나 영광스러운 일일까?
 
How
  최근 GPT의 핫이슈를 통해 각 기업에서 많은 변화가 있었을 것이라고 생각한다. 그 중에서도 주니어 개발자에 대한 변화가 가장 컸을 것으로 예상으된다. 내가 생각하는 큰 변화는 "GPT에 대한 의존도"이다. GPT가 세상에 나오기 전까지 우리는 stackoverflow 혹은 공식 document, googling 등을 통해서 이슈의 원인을 찾고 해결하면서 내 것으로 만드는 과정을 거쳤을 것이다. 그러나 GPT는 이 것을 단 번에 해결해준다. 물론 100% 정확한 것은 아니지만 대부분 제안까지 해주기 때문에 왜 해결 되었는지에 대한 과정을 본인도 모르게 넘기는 경우를 종종 본 적이 있다.
  나는 GPT 4.x를 사용하지 않는다. 내가 의존하는 순간 내 커리어는 거기까지 일 것이라는 두려움에 겁이난다. 그래서 나는 3.5를 사용하는 대신, 참고용으로 사용하며 보통 googling을 통해 먼저 펙트체크를 먼저 진행한다.
  내 자신의 단점을 항상 보완하려고하자. 이건 대학생 때부터 길들인 버릇이다. 내 자신의 단점을 눈치채거나 누군가 알려준다면 그 부분에 대한 고려를 하고 관리를한다. 예를들어 "비즈니스 개발은 잘 하는데 인프라에 대한 지식이 없어!"라고 한다면 회사 인프라를 직접 그려본다. 방화벽은 어디에서 어떻게 열려있고 보안 장비는 어떻게 동작하며 private 존과 public 존이 어떻게 연결되어있는지, 로드밸런서와 게이트웨이 등을 그림으로 표현해보면 더 복잡해보일 수 있겠지만 머릿속으로 상상만 하는 것보다는 훨신 더 좋은 효과를 낸다. 분명 비즈니스 개발을 하면서 타 서버와 통신을 하는 통신부 혹은 통신 모듈을 개발할 수도 있다. 그렇다면 client를 어떻게 설정해야하고 암/복호화는 어떻게 하며 예외처리는 어떤 것들을 해야하는지 쉽게 알 수 있다.
  최근에 api 호출을 했는데 간헐적으로 readtimeout이 발생되는 경우가 생겼다. 보통은 1번과 같이 A서버에서 B서버의 GET /my/payment-history api를 호출한다는 생각을 하겠지만, 실제로 인프라를 살펴보면 로드밸런서 혹은 게이트웨이를 두어 통신할 수 있다. 만약 이 인프라 그림이 없다면, B서버의 응답시간만 보고 "어? 1초도 안걸렸는데?"라고 생각할 수 있다. 여기까지가 내가 생각하는 주니어 개발자의 모습이지만, 시니어라면 로드밸런서와 게이트웨이를 파악하고 이슈 원인을 분석하여 해결할 수 있어야한다.
1. A server -- GET /my/payment-history --> B server
2. A server --> A' Load Balancer --> --> B server
3. A server --> A' gateway --> --> B server
4. A server --> A' Load Balancer --> A' gateway --> --> B server
 
 
Plan
  지식을 습득하고 더 많은 경험을 통해 얻어가는 것이 많아야한다는 내 고집으로 인해 배울 것이 많고 얻을 수 있는 기술력을 가진 회사로 입사하였다. 이 시점에서 만약 내가 이직을 한다면 포커스를 다르게 두고싶다. 그 동안 쌓아올린 나의 경험과 지식을 바탕으로 회사에 기여할 수 있고 성과를 내어 나의 회사를 성장시킬 수 있는 포지션, 그리고 함께 성장할 수 있는 회사로 나아가고싶다.

시니어 개발자가 되려고 하는 과정

댓글