2025 회고

strongmhk·2026년 1월 25일

회고

목록 보기
2/2
post-thumbnail

2025년의 시작점

2025년을 시작할 때 내가 가장 원했던 것은 단순했다.
좋은 기업에 들어가는 것이었다.
그 당시 내가 생각한 ‘좋은 기업’은 명확한 기준이 있었다.

회사가 해결하려는 문제가 분명하고, 그 문제를 해결하기 위해 기술에 집착하지 않고 도구로 잘 사용하는 회사였다.
지금 돌아보면 꽤 이상적인 기준이었다.

그리고 동시에, 내가 그 기준을 얼마나 추상적으로만 이해하고 있었는지도 드러나는 지점이기도 했다.



취업 이후, 그리고 나의 부족함

취업이라는 목표는 달성했지만, 일을 하면서 느낀 현실은 처음 생각과는 달랐다.
내가 기대했던 것과 달리, 현업에서 마주하는 문제는 항상 명확한 형태로 주어지지 않았다.

고객사가 요청한 요구사항은 종종 추상적이었고, 그 요청이 실제로 무엇을 의미하는지, 어디까지를 해결해야 하는지를 스스로 해석하고 구체화해야 하는 상황이 많았다.

이 경험을 통해, 내가 가지고 있던 기대가 현업의 맥락을 충분히 반영하지 못하고 있었다는 사실을 깨닫게 되었다.

문제가 명확하게 주어지는 환경을 바랐지만, 실제로는 문제를 명확하게 만들어가는 과정 자체가 업무의 중요한 일부였다.

이후로는 환경을 평가하기보다, 주어진 상황 속에서 무엇을 배울 수 있는지에 더 집중하게 되었다.
지금의 자리에서 내가 성장할 수 있는 지점을 차분히 찾아보려 노력하고 있다.



현업에서 배운 것들

레거시 코드를 바라보는 시선

가장 먼저 달라진 것은 코드를 바라보는 시선이었다.

jQuery 기반으로 작성된 코드들을 처음 마주했을 때는 ‘왜 이렇게 작성된 걸까?’라는 의문이 먼저 들었다.

그 질문을 안고 사수분께 코드의 히스토리를 자주 여쭤보았고, 관련 글과 자료도 찾아보며 맥락을 이해하려 노력했다.

레거시 코드와 친해지는 법: 두려움에서 도구로

그 과정에서 깨달은 점은, 레거시 코드는 단순히 정리가 안 된 코드가 아니라 당시의 제약과 요구사항 속에서 내려진 선택들이 쌓인 결과라는 사실이었다.

코드를 평가하기보다, 그 코드가 만들어진 배경을 이해하려는 태도가 필요하다는 것을 배우게 되었다.


나의 의견을 잘 전달하는 방법

또 하나 크게 느낀 점은, ‘좋은 의견’보다 ‘전달되는 의견’이 훨씬 중요하다는 것이었다.

아무리 좋은 생각이라도 상대가 이해하지 못하면 의미가 없다는 것을 여러 번 경험했다.

그 과정에서 플로우 차트나 시퀀스 다이어그램을 그리는 습관, 변수명 하나에도 의미를 담으려는 고민이 자연스럽게 따라왔다.

업무를 대하는 태도도 바뀌었다.

예전에는 코드부터 열어보는 경우가 많았다면, 이제는 먼저 이 기능이 어떤 흐름으로 동작하는지, 왜 이런 구조를 가지게 되었는지를 정리하려고 했다.

*아래의 사진은 사이드 프로젝트에서 그린 다이어그램이다.


도움을 요청하는 방법

또 하나 배운 점은, 업무 중 병목이 생기거나 혼자서 감당하기 어려운 지점이 보일 때 빠르게 상황을 공유하는 것이 전체 효율을 높인다는 것이었다.

모든 문제를 혼자 해결하려 하기보다, 현재 상황을 명확히 정리해 공유하고 함께 논의하는 것이 오히려 더 책임 있는 태도라는 점을 체감했다.



스스로에 대한 피드백

현업을 경험하며 가장 많이 했던 것은, 스스로에게 불편한 질문을 던지는 일이었다.

나는 기본기를 갖추었는가?

첫 번째는 ‘나는 개발자로서 기본기를 갖추었는가?’ 라는 질문이다.

내가 생각하는 개발자의 기본기란, 특정 기술을 많이 아는 상태라기보다 문제를 마주했을 때 그 원인을 논리적으로 추적하고, 설명할 수 있는 힘에 가깝다.

동작하는 코드를 작성하는 것에서 그치지 않고, 왜 그렇게 동작하는지, 어떤 전제 위에서 성립하는지를 이해하고 있는 상태라고 생각한다.

업무를 하다 보면 단편적인 기술이나 도구를 아는 것과, 그 배경이 되는 원리를 이해하고 있는 것 사이에는 분명한 차이가 있다는 것을 체감하게 된다.

여러 현직자분들과 커피챗을 하며 공통적으로 들었던 이야기 역시 비슷했다.

기술 트렌드는 빠르게 변하지만, 그 기반이 되는 지식은 쉽게 변하지 않는다는 것이었다. 이 말이 이전보다 훨씬 현실적으로 다가왔다.

그렇다고 해서 새로운 도구를 외면해야 한다는 뜻은 아니었다.

AI를 비롯한 다양한 도구를 직접 사용해보며 생산성을 높이려는 시도도 했고, 동시에 그 과정에서 도구에 의존하면 오히려 사고가 얕아질 수 있다는 점도 체감했다.


좋은 개발자란 무엇인가?

두 번째 질문은 ‘어떻게 하면 잘하는 개발자처럼 보일까’에 대한 고민에 너무 많은 에너지를 쓰고 있지는 않았는가였다.

퍼포먼스를 잘 드러내는 것도 중요하지만, 그 이전에 근본적으로 좋은 개발자가 되기 위한 준비가 충분했는지를 돌아보게 되었다.

그 과정에서 실제 사용자가 있는 서비스를 운영해보는 경험이 필요하다고 느꼈고, 위치 인증 기반 알람 앱의 v1을 개발해 잠시 운영했다.
올해는 이를 개선해 v2로 다시 선보일 계획이다.


내 삶을 잘 챙기고 있는가?

마지막 질문은 스트레스를 어떻게 관리할 것인가였다.
번아웃을 겪으면서 일에만 몰두하면 성과도, 삶의 만족도도 떨어진다는 것을 배웠다.

그래서 애견 카페를 찾아가거나 야구 경기를 직관하며 몸과 마음을 쉬게 했다. 걷기 명상처럼 간단한 취미를 통해 생각을 정리하는 시간이 업무 집중도에 오히려 도움이 되었다.




삶과 개발에 대한 생각의 변화

돌아보면, 나는 오랫동안 ‘시간을 많이 투자하면 언젠가는 원하는 결과가 나올 것’이라고 막연히 믿고 있었고 많은 시간을 투자하기만 했다.
하지만 노력의 양과 결과는 항상 정비례하지 않았고, 그 간극에서 번아웃이 반복되었다.

왜 잘 안 풀렸을까를 생각해보니, 방향과 전략 없이 달리고 있었던 것은 아닐까라는 결론에 닿았다.
또한 내가 정말로 원하는 것이 무엇인지에 대한 고민 없이, 그저 남들이 가는 길을 따라가고 있었던 것 같다는 생각도 들었다.

여러 현직자들과의 대화는 이 고민을 더 구체화시켜주었다.
컴퓨터 사이언스와 같은 근본적인 지식의 중요성, 그리고 동시에 업무 생산성을 높이기 위한 도구를 적극적으로 사용하는 태도 역시 개발자에게 필요하다는 점을 다시 한 번 인식하게 되었다.



개발자의 본질에 대한 고민

회사에 들어가지 않고 자신의 서비스를 만들고 있는 지인과의 대화도 인상 깊었다.
그 대화를 통해 다시 한 번 정리된 생각은, 개발은 결국 문제 해결을 위한 도구라는 점이었다.

기술 자체를 쌓는 것도 중요하지만, 그보다 먼저 우리 삶에서 어떤 문제가 존재하는지, 그 문제를 겪고 있는 사람들은 어떤 불편을 느끼고 있는지에 대한 고민이 선행되어야 한다는 생각이 들었다.

그리고 그 문제를 제대로 이해하기 위해서는, 해당 도메인의 전문가와 직접 이야기하고 지식을 쌓는 과정이 반드시 필요하다는 것도 느꼈다.

앞으로의 방향

여러 고민 끝에 내린 결론은 단순하다.
나는 세상에서 일어나는 문제를 해결함으로써, 누군가에게 실제로 도움이 되는 사람이 되고 싶다.
아직은 매우 추상적인 목표지만, 그 일환으로 사이드 프로젝트로 작년부터 개발해온 위치 인증 기반 알람 앱을 계속 고도화해볼 생각이다.
동시에 개발자로서의 기술 역량을 쌓는 노력도 게을리하지 않아야겠다는 생각도 했다.

2025년은 내게 명확한 답을 준 해라기보다는, 어떤 질문을 붙잡고 살아가야 할지를 알려준 한 해였다.
아마 이 질문들은 2026년에도 계속 이어질 것 같다.

한 해를 돌아보며, 부족한 부분과 배운 점을 솔직하게 기록하는 것은 쉽지 않다. 하지만 이런 회고 덕분에 다시 목표를 정비하고, 다음 발걸음을 준비할 수 있음을 느꼈다.

profile
저 커서 개발자가 될래요!

0개의 댓글