안녕하세요! 프론트엔드 개발자 오소현입니다 :)

오랜만에 이렇게 글을 쓰게 되었는데요! 최근에 기록을 잠시 멈췄는데, 어느 순간 다시 나는 어떤 개발자가 되고 싶을까?생각이 들었습니다.

이번 글은 지난 2년간 제가 일을 하며 겪은 변화와 고민을 담은 짧은 회고입니다.
신입으로 시작해 주니어로 성장해 오면서, “좋은 개발자란 무엇일까”를 스스로에게 계속 묻고 그런 개발자가 되기 위해 열심히 연습하며 답해온 기록입니다.

시작하며

2년 차, 나는 어떤 개발자가 되고 싶을까

2024년 1월에 첫 회사에 입사했을 때는 좋은 개발자가 어떤 사람인지 명확히 알지 못했다. 단순히 맡은 일을 성실히 하면 된다고 생각했다. 그러나 일을 경험할수록 그 생각은 조금씩 달라졌다. 인턴 시절에는함께 일하고 싶은 개발자 가 되고 싶었고, 1년 차 즈음에는 모든 예외 상황을 꼼꼼히 고려하는 개발자가 되고 싶었다. 2년 차가 되어가는 지금은 불편함을 찾아 개선하는 개발자가 되고 싶다. 시기에 따라 좋은 개발자의 기준은 바뀌었지만, 그 변화 속에서 일하는 태도와 사고방식이 성장했다고 느낀다.

---

인턴, "함께 일하고 싶은 개발자"를 꿈꾸다

신뢰를 쌓는 일의 시작

대학교 마지막 학기에 스타트업에서 프론트엔드 인턴으로 근무했다. 입사 전에는 주로 프론트엔드 개발을 위주로 빠르게 결과물을 내는 데 익숙했지만, 회사에서는 백엔드, 인프라 영역까지 포함된 풀스택을 경험했다. 이 과정에서 개발이 프론트엔드 영역만으로 완성되지 않으며, 시스템 전반의 구조를 이해하는 것이 중요하다는 사실을 배웠다. 이때 AWS 기본 자격증을 취득하며 인프라의 전반적으로 공부하며, 서비스가 돌아가는 전체 구조를 이해하려고 계속 노력해왔다.

이 시기때는 동료들에게 내 신뢰가 가장 중요했다. 코드를 작성할 때마다 단순히 기능을 구현하는 것에 그치지 않고, 그 선택의 이유를 설명하려고 노력했다.

PR에 리뷰어가 빠르게비즈니스 맥락을 파악할 수 있도록 이 작업의 목표, 관련된 비즈니스 문서를 추가하고, 리뷰어가 빠르게 코드 맥락을 파악할 수 있도록 시각 자료(개발 화면, 테스트 결과 등)를 첨부해맥락을 알고 코드 리뷰를 할 수 있게 끔 노력을 많이했던 것 같다. 코멘트로 판단의 이유를 해당 코드에 달아두기도 했다.

협업에서 신뢰를 쌓기위해 자주 공유하고, 이해하기 쉬운 전달이 더 큰 가치를 갖는다는 것을 느꼈다.

업무가 본격화된 이후에는 내가 맡은 기능의 릴리스 이후까지 오너십을 가지고 모니터링하고자 노력했다. 사용자 이벤트 데이터를 사내 모니터링 도구를 통해 직접 확인하며 개선점을 정리해보았다. 서비스를 단순히 개발 대상으로 보지 않고, 직접 사용하는 사용자 입장에서 관찰하려고 했다.

인턴 기간 동안 팀이 내 작업을 신뢰할 수 있도록 만드는 일에 집중했고, 그 결과 협업 과정이 훨씬 원활해졌다고 느낀다. 이때의 경험은 이후 어떤 프로젝트에서도 일관된 협업 방식을 유지하는 기반이 되었다.

---

1년 차, "예외사항을 잘 고려하는 개발자"를 연습하다.

문제를 예방하는 설계와 작업 흐름

서비스를 계속 개발해 나갈 수록 “문제가 생긴 다음에 대응하는 개발자”가 아니라, 문제를 미리 방지하는 개발자가 되고 싶었다. 같은 유형의 오류가 다른 서비스들 사이 간에서 반복되는 상황에서, 근본적인 개선 방법이 필요하다는 생각이 들었다. 릴리스가 끝날 때마다 발생한 이슈를 유형별로 정리하고, 각각 에러 문서를 작성해두었다.

이 문서에는 왜 발생했고, 어떤 것을 고려하지 못했는지, 어떻게 문제의 원인을 파악했는지, 해결 방안은 어떻게 대처했는지를 위주로 작성했다. 사내에 장애 발생 시 시스템이 있어서 해당 문서를 참고하면서 기준을 정했다. 각각 문서가 쌓일 수록 주로 무엇을 고려하지 못하는지도 파악할 수 있게 되었고, 다양한 에러 케이스를 많이 쌓아둘 수 있어 다양한 시나리오를 많이 생각할 수 있게 되었다.

그리고 이 문서를 바탕으로 짧게 체크리스트를 만들어 다음 기능 개발 전 검토하는 과정을 습관화했다.
나만의 체크리스트를 만들고, 안전하게 릴리즈 되는 것을 목표로 최선을 다해보고자했다. 그래서 예상 가능한 범위의 에러를 많이 줄이려고 노력했다.

개인 로드맵으로 하고 있던 E2E 테스트 환경에서도 변화를 시도했다. 사용자 흐름을 기준으로 핵심 경로를 자동화해 테스트했고, 사내 로그인 인증 과정을 E2E 테스트로 구현했다. Playwright를 사용하며 내부 동작 방식을 분석했고, 필요에 따라 오픈소스에 기능을 직접 기여했다.

이 시기에는 개발 속도보다는 안정적인 배포 주기를 만드는 데 집중했다. 대규모 릴리스 대신 작은 단위로 자주 배포해 검증과 개선을 반복했다. 작은 배포는 QA와 리뷰 부담을 줄이고, 롤백 리스크도 낮췄다. 사내 디자인 시스템을 만들고 안정적으로 도입하면서 부터는 컴포넌트에 에러 처리, 로딩 상태를 내장시켜 재사용 과정에서 발생할 수 있는 실수를 예방했다. 예외를 완벽히 제거할 수는 없지만, 발생 가능성을 줄이는 구조를 설계하는 것이 더 효율적이라는 점을 깨달았다.

---

지금, "불편한 개발자"가 되고 싶다

문제를 감지하고 개선으로 연결하는 태도

업무를 하다 보면 동료들이 “이게 너무 불편해서 이렇게 바꿔봤어요”, “이건 지금 불편하니까 앞으로는 이렇게 바꿔야 해요”라고 말할 때가 있다. 이런 말이 나오는 순간은 언제나 팀이 성장하고 있다는 신호라고 생각한다. 개발자는 문제를 해결하는 사람이고, 문제의 시작은 대부분 불편함에서 출발하기 때문이다. 불편함을 느끼지 못한다면 개선의 방향을 잡을 수도 없다. 그래서 나는 요즘 좋은 개발자는 불편함을 인식할 줄 아는 사람이라고 생각한다.

하지만 나는 보통 그 반대편에 있었다. 불편함을 느껴도 금세 이해하고 넘어가는 쪽에 가까웠다. “이건 왜 이렇게 되어 있지?”라고 생각하다가도 비즈니스 배경이나 일정, 당시의 리소스를 확인하면 금방 납득해버렸다. ‘아, 그럴 수밖에 없었겠구나’ 하고 공감한 뒤, 결국 아무 변화 없이 그대로 유지보수만 이어갔다. 이런 태도는 그 당시에는 합리적으로 보였지만, 지금 돌이켜보면 개선의 기회를 스스로 차단한 셈이었다. 레거시 코드에 적응하고, 그 위에 새 코드를 쌓는 일에 익숙해지면서 문제의식이 점점 흐려져갔던 것 같다.

이 관점을 바꾸게 된 계기가 있었다. 김맥스(김종혁)님의 블로그 글에서 레거시를 미워하지 말자에 대한 글을 읽었는데, 단순히 코드를 바꾸는 차원이 아니라 “왜 이런 구조가 되었는지 이해하면서도, 그 위에서 어떻게 더 나은 선택을 할 수 있을까”를 고민하는 관점이 인상 깊었다. 그 글을 계기로 나는 기존 코드를 분석할 때 단순히 배경을 이해하는 데서 멈추지 않고, 개선 가능성을 함께 검토하는 습관을 들였다.

요즘의 나는 엇 왜이러지? 혹은 불편함 느꼈을 때 실제로 개선할 수 있을지를 판단하고, 어떻게 개선할 수 있을지 고민해본다. 바로 실행 가능한 수준부터 적용해 본다. 반복되는 설정 작업을 스크립트로 정리하거나, 문서화가 부족한 부분을 보완하는 식으로 작게 시작한다. 큰 구조를 바꾸지 않아도 효율이 좋아지는 지점을 찾는 것이 목표다.

불편한 개발자는 불평이 많은 개발자가 아니라,문제를 잘 인식하고 바꿀 방법을 찾는 사람이이라고 생각한다. 이전에는 ‘이해’로 끝났던 나의 사고가 이제는 ‘개선’으로 이어지고 있다. 그 변화가 지금의 내가 되고 싶은 개발자로 노력하는 것을 가장 잘 설명하는 문장이다.

---

마무리

인턴 시절에는 협업을 원활하게 이끌어가는 개발자가 되고 싶었다. 신뢰는 복잡한 기술보다 명확한 의사소통과 꾸준한 실행에서 생긴다는 것을 배웠다. 1년 차에는 오류를 줄이고 문제를 예방하는 개발자가 되고자 했다. 위험을 줄이는 구조적 접근이 결국 팀 전체의 효율로 이어진다는 점을 확인했다. 지금은 불편함을 찾아 개선하는 개발자가 되고 싶다. 현 상태에 안주하지 않고, 작은 문제라도 개선으로 연결하려는 태도를 유지하려 한다.

세 단계의 경험은 모두 연결되어 있다. 신뢰가 기반이 되어야 안정적인 설계가 가능했고, 안정적인 설계가 쌓여야 개선이 의미를 갖는다. 앞으로도 좋은 개발자의 정의는 계속 바뀔 것이다. 하지만 한 가지는 변하지 않을 것이다. 팀이 일하기 편한 환경을 만들고, 제품이 더 나은 방향으로 발전하도록 기여하는 개발자가 되고 싶다.