1년 반 회고

개발자로 직장에서 일할 수 있게 된 것이 햇수로는 3년에 접어들었다.

"실제 직장에서는 어떻게 개발을 할까? 내가 하는 게 맞는 걸까?"라는 고민을 대학 시절에 많이 했던 것 같다.

그래선지 처음 직장에 와서 지금까지 겪던 하나하나의 일들이, 좋은 답이 되었던 나쁜 답이 되었던 학창 시절 궁금했던 질문의 답이 되었고 궁금증이 풀리는 시간이기도 했던 것 같다.

그런 의미에서 내가 경험한 직장은 어떤 곳이었는지 회고를 남기고 싶다.

목차

1. 입사
2. 첫번째 프로젝트
3. 두 번째 프로젝트
4. 햇수로 3년 차가 되며

 

입사

처음 입사하고 굉장히 행복했다.

첫 주에 어느날은 출근을 해서 직장 선배를 보고 인사를 하는데, 직장에서 선배와 인사를 한다는 게 낯도 간지럽고 사회인이 되었구나라는 실감이 들어서 입꼬리가 잘 내려오지를 않았다.

입사과정이 길었던 탓이었는지 무슨 업무를 맡게 되던 일을 하게 되었다는 게 너무 좋았다.

지금 생각해보면, 흔히들 허니문 기간이라고 하는 기간이었던 것 같다.

무엇보다.. 돈을 안 줘도 나는 코드를 짜는데, 돈을 주고 코드를 짜라니 믿기지 않을 정도로 좋았다.

 

첫 프로젝트

온보딩 기간이랄 것도 없이 바로 첫 프로젝트에 투입되어서 백엔드 개발자로 개발을 시작하게 되었다.

나는 신입이고 실력이 검증되지 않은 사람이었지만, 입사 준비 기간에 봐왔던 내 모습을 좋게 봐주신 덕에 프로젝트의 중요한 모듈 하나를 혼자 맡아 개발할 수 있게 되었다.

입사해서 처음 맡게된 업무에서 "무언가 보여주겠다!" 내지는 "절대 못하는 사람으로 보이고 싶지 않다"라는 마음이 정말 강했다.

따라서 업무시간이 아닐 때도 계속 맡은 업무를 어떻게 개선할 수 있을까 고민했고, 실제로 출근/퇴근의 구분이 내게는 크게 느껴지지 않았던 것 같다.

개발적으로 첫 프로젝트에서 정말 크고 작은 문제들을 겪었다.

별생각 없이 했던 설계가 이후에 발목을 잡았고, 잘 모르고 사용한 개념이 문제를 만들었다.

또한 절대 멈추지 않고 끊임없이 바뀌는 요구사항은 OCP와 같이 변경에 열려있는 설계를 중요하게 이야기하는 이유를 몸소 느낄 수 있게 만들었다.

이 문제들을 해결하며 프로젝트를 완성해 가는 과정에서 하나 느낀 것은 "회사는 정말 가르쳐주는 사람이 없구나"라는 것이었다.

정말 모든게 내가 직접 곡괭이를 들고 땅을 파는 느낌이었다.

내 성향상 시켜서 공부하는 사람도 아니고 혼자 공부하는 것을 좋아하기에, 다행히 이 점은 내게 잘 맞았다.

하지만 내가 처한 문제상황과 그 문제에 대한 고민과 결론에 대해 나누고 평가하며 지적해 줄 사람이 없었다는 것은 아쉬운 점이었다.

당시에는 문제상황을 혼자 어떻게든 해결해내며, 내가 짧은 시간 안에 성장했다고 느꼈다.

하지만 시간이 지난 뒤 돌아봤을 때, 그렇게 성장하는 것이 좋은 것이 아닌 것 같다.

시간도 없고 답은 모르겠고 눈앞의 문제는 급하다보니 고민을 해서 나온 결과의 퀄리티가 너무 낮고, 그 퀄리티가 낮다는 사실을 본인은 인지하지 못한다는 문제가 있기 때문이다.

사람은 이미 가본 길을 다시갈 때 매우 빨리 갈 수 있다고 생각한다.

다만 처음 그 길을 가볼 때는 충분한 고민과 리뷰가 필요하다. 그래야 그 길을 제대로 가본 경험을 얻을 수 있지 않을까.

비유하자면 들길에서 가지치기 없이 자란 나무가 어떻게든 햇빛 쪽으로 몸을 틀어서 억지로 자란 형태로 성장해 버리고 첫 번째 프로젝트를 마무리했다.

 

두 번째 프로젝트

SI는 프로젝트의 연속이다.

프로젝트 초기인지 중기인지 후기인지만 있을 뿐..

나는 곧이어 바로 두 번째 프로젝트를 경험했다.

이번에 맡은 프로젝트는 첫 번째 프로젝트와는 다르게 훨씬 분업이 되고 큰 프로젝트라고 개인적으로 느꼈다.

이번에도 나는 핵심 기능을 담당하여 개발하게 되었고, 이는 상황이 잘 안 풀릴 시 나를 프로젝트에 갈아 넣어야 한다는 의미가 된다는 것을 알았다.

지금은 프로젝트를 마무리했지만.. 정말 힘든 프로젝트였고 솔직히 지금도 벅차다.

이 프로젝트를 진행하며 느낀 건 정말 수도 없이 많다.

그중 가장 뼈저리게 느낀 건 시스템의 중요성이다.

업무는 커지면 개인이 처리할 수 없다.

그렇다면 업무는 결국 집단이 처리해야 하는데, 집단은 무조건 시스템으로 굴러간다.

그렇기에 어떤 문제가 생기던 그 문제를 개인의 문제로 바라보아서는 안되고 시스템의 결함으로 바라보아야 한다.

예시 상황을 들면 다음과 같다.

• 기능의 변경이 필요하여 기획팀의 A 씨와 개발팀의 B 씨가 논의하였다.
• 이 기능이 변경된 것을 A씨와 B씨 말고는 아무도 인지하지 못하고 있다.

이런 상황은 A와 B가 자기들만 이야기하고 변경을 팀과 공유하지 않은 게 문제인 것일까?

나는 아니라고 본다.

정말 문제는 "왜 둘만 아는 변경이 일어나는 상황이 발생할 수 있는가?", "왜 말을 안 해주면 변경 사항을 모를 수밖에 없는가?"가 아닐까?

이건 시스템적으로 막지 않으면 재발할 문제이다.

정보는 중앙으로 모여야 하고, 기능변경 또한 구두로 발생하는 것이 아니라 체계적인 프로세스를 잡아야 한다.

이러한 점을 사전에 내가 알지 못했고, 대안을 만들어 에스컬레이션 하지 못한 게 아쉽게 느껴진다.

아쉽더라도 어쩌겠는가 그렇게 한 해가 끝나버렸다.

 

햇수로 3년 차가 되며

돈을 받고 일한 지 햇수로는 3년차가 되었다.

실제 기간으로는 1년 반이 안 되는 기간이었다.

짧은 시간이었지만 정말 머리가 아프게 많은 걸 느끼고 고민도 해보고 많은 문제를 직면해 본 것 같다.

무언가 배웠던 점 중 아쉬웠던 점을 위주로 기록하였지만 배운 점이 훨씬 더 많다. 아쉬운 것도 그만큼 배웠기 때문에 아쉬운 것 같다.

사실 따지고 보면 나 개인이 부족한 점이 내가 느낀 아쉬운 점보다 몇 배는 더 많다.

난 항상 집중하는 게 단순히 눈앞의 문제를 해결하는 것이다 보니, 나와는 다르게 더 멀리 보고 더 깊게 파고들고 생각할 줄 아는 동료들과 선배들을 보면 늘 부끄럽고 배우게 된다.

특히, 내가 생각 없이 짜놓은.. 당장의 상황을 면피하기 위해 작성한 코드를 선배 개발자가 리뷰해 줄 때는 정말 얼굴이 실시간으로 뜨거워지며 부족함을 느낀다.

 

햇수로 3년이라는 것은.. 뭔가 애매하다.

하지만 신입으로 누군가에게 기대기를 바라는 시점은 지나가고 있는 것 같다.

내가 느끼기에 나라는 사람은 아직 골조 공사도 제대로 안되었는데 위에서는 시멘트를 붓고 있다.

그래서 하루하루 부족한 점을 채워가기에 부단히 노력해야 함을 느낀다.

 

오랜만에 회고를 적었는데, 보통 회고라 하면 1년 주기로 적는데 나는 귀찮아서 거의 1년 반 주기로 적는 것 같다.

너무 일 이야기만 했는데, 이제는 일만큼 내 삶도 돌보아야 한다고 느낀다.

2026년도는 내 삶과 일의 균형을 잡는 것이 회사에서의 목표 중 하나이다.

다음 회고는 내년이나 내후년 즈음에나 적을 것 같다. 그때는 더 행복해져 있고 생각도 많이 바뀌어있고 더 성숙해져 있기를 기대해 본다.