1. 3줄 요약
2025년 6월, 첫 직장에 입사했다.
기술 스택은 C#과 .NETCore 였다.
6개월 동안 코드도 짜고, 사람도 만나고, 전체 작업도 날려봤다.
2. 처음 적응기의 난장판
입사하자마자 제일 먼저 맞닥뜨린 건 개발 환경이었다.
폐쇄망 + VDI 조합이었고, 인터넷도 제대로 못 쓰고,
로컬에서 복사 붙여넣기도 막혀 있고, 프로그램도 거의 못 깔다시피 했다.
세팅만 하는 데 거의 3일이 걸렸다.
그다음은 협업 툴 적응.
메신저, 티켓, 깃 플로우 다 처음이었다.
그 와중에 전체 작업을 날려먹기도 했다.
신입의 생존기1 : 푸시 한 번으로 메인 브랜치를 밀어버린 날
3. 실무에서 배운 진짜 기술들
실무에서 느낀 건,
기술을 “알고 있다”는 감각이랑,
“진짜로 쓸 줄 안다”는 건 전혀 다르다는 것이었다.
예를 들어, API 하나 만들 때도 그 안에서 어떤 값이 빠졌을 때 걔만 안 나오는 게 맞는지,
전체 응답이 실패해야 하는 건지 서비스 단위에서 어디까지 책임질지를 먼저 정해야 했다.
에러 처리는 단순한 기능 구현이 아닌 설계의 일부였고,
프론트랑 협의해서 이건 200인지 400인지
이건 사용자에게 보여주는 메시지인지 로그로만 남기는지
하나하나 다 정하고 나서야 제대로 된 API가 됐다.
그리고 나만 쓰는 코드라도,
“왜 이렇게 짰는지”, “어디서 뭐가 터질 수 있는지” 설명할 수 있어야 했다.
그걸 애매하게 넘기면 결국 나중에 다시 내 손으로 고치게 된다. (더 고통스럽게.)
실무에선 모르는 걸 그냥 둔 채로 넘어가는 게 제일 위험했다.
애매한 건 언젠가 더 크게 돌아오고, 그때는 실수로 안 끝날 수도 있다는 걸 몇 번 겪고 나서 알게 됐다.
4. 내가 생각했던 개발자와 실제 개발자 사이의 간극
입사 전엔, 개발자는 그냥 조용히 자기 자리에서 코드 잘 짜는 사람이면 되는 줄 알았다.
근데 막상 실무에선 코드보다 말이 중요할 때가 많았다.
같이 일해보니, 기술적으로 잘하더라도 소통이 안 되면 같이 일하기 힘들어지는 사람이 있었다.
반대로 기술은 아직 차치 하더라도 정리해서 잘 설명하고, 흐름을 공유하는 사람은
팀 전체의 일 속도를 올리는 사람이었다.
실제로 느낀 건, 소통 없는 코드는 아무도 읽고 싶어하지 않는다.
설명이 없는 작업, 공유되지 않은 흐름은 팀을 계속 헤매게 만든다.
그렇게 내가 뭘 설명하려면 일단 내 머릿속이 먼저 정리가 되어 있어야 했다.
내가 지금 왜 이걸 하고 있는지,
어떤 방식으로 하려는 건지,
누구의 도움이 필요한지,
지금 이게 중요한 일인지 아닌지.
이걸 정리하지 않으면 결국 제대로 말도 못 했다.
또 하나 배운 건,
권한과 책임을 명확히 이해하고 행동해야 한다는 것이었는데,
그냥 “이건 이렇게 해도 되겠지”로 움직였다가
정말 다른 팀에 피해가 갈 수도 있고, 누구도 그걸 커버하지 못할 수도 있다.
일단 “누가 결정할 수 있는 일인지”부터 먼저 물어보는 게 진짜 중요한 전제였다.
결국 지금 내가 생각하는 좋은 개발자는, 코드를 잘 치는 사람이 아니라 같이 일하기 좋은 사람이 되었다.
(함께 일하면서 흐름을 공유하고, 설명하고, 같은 기획을 바라보고 있다는 걸 계속 맞춰갈 수 있는 있는)
'실습일지' 카테고리의 다른 글
| 신입의 생존기1 : 푸시 한 번으로 메인 브랜치를 밀어버린 날 (0) | 2026.01.03 |
|---|