2024년 개발자 회고: 무엇을 배우고 성장했을까?

2024년은 개발자에게 있어 다사다난한 해였습니다. 경기 악화에 따른 개발자 채용 감소는 물론, ChatGPT와 Gemini를 포함한 AI 서비스들이 출시 시점과는 비교할 수 없을 정도로 발전했죠. 이에 개발자를 준비하던 분들, 현직 개발자들도 미래에 대한 걱정의 소리를 내기 시작했습니다.

저 또한 개발자로서 더욱 성장하기 위해 지난 1년 동안 많이 고민했습니다. 그래서 올해를 되돌아보며 개발자가 키워야 할 역량과 방향성에 대해 정리하고, 더욱 실력 있는 개발자가 될 수 있는 2025년을 준비해 보고자 2024년 개발자 회고를 작성해 봤습니다. 회고를 준비하는 분들에게 도움이 되길 바랍니다. (회고에서 다루는 예시들은 실제 진행한 개인 사이드 프로젝트의 내용임을 밝힙니다.)

한 해 동안 느낀 점

큰 규모의 프로젝트를 진행하며

저는 현재 구글에서 일하고 있고, 구글은 매우 큰 회사입니다. 그리고 구글이 가진 많은 제품 중 제가 속한 서치(search) 또한 굉장히 큰 규모를 가지고 있는 서비스입니다. 이렇게 큰 서비스에서는 더 이상 어떤 점을 개선해야 할지, 지금 가지고 있는 문제가 무엇인지 찾기가 쉽지 않습니다. 실제로 구글 서치에서 일하고 있다고 소개하면, 구글 검색에서 더 할만한 게 있냐는 질문도 많이 받습니다.

스스로 그렇지 않다고 생각했지만, 저 또한 지금까지는 팀 리드분들이 발견한 문제에 대해서만 고민하고, 서비스가 어떻게 발전할 수 있을지 먼저 찾으려는 노력은 부족했다는 것을 깨달았습니다. 그동안 너무 수동적으로 일하고 있었던 거죠. 얼핏 작아 보이는 기능 하나도 많은 팀이 얽혀있고, 접근성과 개인 정보 보호 등 신경 써야 할 것들이 많았습니다. 이러한 이유로 저의 시야는 당장 눈앞에 주어진 일들만 바라보고 있었죠. 당장 그 일을 처리하기도 벅차고, 그 외적인 일은 다른 팀원들이나 매니저가 해줄 것이라 생각했습니다.

프로젝트 규모가 크다 보니, 주변 동료들의 실력 또한 높았습니다. 마치 높은 나무로 구성된 숲에 들어와, 제 눈앞의 시야는 가려진 듯했습니다. 회사에 들어오기 전, 진행한 사이드 프로젝트들은 직접 작은 문제들을 발견하고, 해결할 수 있었는데 더 이상 그러고 있지 않다는 것을 알게 되었죠. 가령 프로젝트에서 ‘시간 범위를 선택하는 기능’을 구현해야 하는 상황에서, 지금까지는 그 기능을 구현하는 데만 집중했습니다. “시간 범위를 선택한다”라는 것에 초점을 맞춰, 이 프로젝트에서 어떤 상황에 이러한 기능이 필요한지에 대한 이해가 부족했죠. 그저 주어진 작업만 제대로 처리하려고 한 것입니다.

이렇게 일을 하다 보니 종종 프로젝트의 방향성과 맞지 않는 구현을 하는 일이 잦았습니다. 만약 예약 프로그램을 만든다면, 예약 가능한 시간대에서 선택할 수 있는 기능이어야 하고, 하루 일과 시간표 프로그램을 만든다면, 24시 내에서 선택할 수 있어야 합니다. 이처럼 프로젝트에 대한 이해가 부족한 상태에서 진행하게 되면, 필요한 기능과 어긋나 있는 상황이 발생합니다. 이를 방지하기 위해 재사용성과 일반성을 높이려다 보면 오버 엔지니어링이 되어버리죠.

저 스스로 프로젝트에 대한 이해와 맡은 일의 필요성에 대해 잘 몰랐기 때문에, 지금까지는 누군가 알려주는 대로 눈앞의 수풀만 헤치며 나아갔던 것 같습니다. 그러다 보니 다른 숲에 들어가거나, 길을 알려주는 누군가가 없다면 아무것도 할 수 없는 상황에 놓이게 되었죠. 이제는 직접 높은 시야를 가지고 숲을 내려다보며 길을 찾아야 할 필요성을 느끼게 됐습니다.

AI로 인해 바뀐 것은 없다

2024년에는 인공지능 경쟁이 더욱 심화되면서 발전 속도 또한 매우 빨라졌습니다. 이에 많은 사람들이 AI가 개발자를 대체하게 될 시기가 얼마 남지 않았다는 불안감을 가졌습니다. 아마 2025년에는 이러한 현상이 더욱 심화되겠죠. 인공지능의 성능은 더욱 뛰어나질 것이고, 현재 LLM의 문제점인 빌드가 안 되는 코드를 작성한다거나, 사용자가 원하는 바를 정확하게 파악하지 못하는 점들이 많이 개선될 것입니다.

그렇다면 개발자가 살아남기 위해서는 어떻게 해야 할까요? AI가 절대 따라올 수 없는 뛰어난 코딩 실력을 과연 갖출 수 있을까요? AI의 성장 속도가 이렇게 빠른데 나의 코딩 역량은 금방 따라잡힐 것 같습니다. 어쩌면 지금이라도 AI 개발자로 전향하거나 다른 직종을 알아봐야 하는 것이 아닐까요?

저 또한 1년 내내 이러한 질문을 매우 많이 받았고, 스스로 생각도 많이 해봤습니다. 그리고 내린 결론은 “바뀐 것은 없다”라는 것이었습니다.

제가 개발자라는 직업을 선택했을 때를 떠올려보면, 내가 코드를 작성하는 대로 프로그램이 만들어지고, 만들고 싶은 걸 직접 만들어 낼 수 있는 등 내 생각을 실현시킬 수 있다는 것에  매력을 느꼈습니다. 아마 이 글을 읽는 여러분도 크게 다르지 않을 것 같습니다.

그러나 직접 프로그래밍을 공부하면서 접한 코딩의 벽은 생각보다 높았죠. 생각할 틈도 없이 주어진 업무와 과제를 해나가야 합니다. 이것이 반복되다 보면 어느 순간 내 생각을 실현하기보단, 눈앞에 놓인 것만 해결하기에 급급하고 당장 작성할 코드만 생각하는 코더가 되어 있습니다. 그리고 코드 생성을 위해 AI를 사용했는데, 생각하기 어려웠던 코드를 너무 쉽게 짜는 모습을 보며 절망하기도 하고, AI에 대한 의존성이 커지기도 하고요.

저 또한 사이드 프로젝트를 할 때 제미나이를 이용해 많은 코드를 생성합니다. AI는 화면을 그리는 코드를 생성하고, API를 호출하고, 접해본 적 없는 라이브러리를 활용하면서 제가 원하는 기능을 척척 구현해 줍니다. 그러나 제미나이가 저보다 나은 개발자라고 생각하지는 않습니다. 원하는 것을 코드로 옮기는 능력은 앞설지 몰라도, “원하는 것”을 찾고 정확히 정의하기 위한 역량은 AI가 학습할 수 없는 추상적인 내용이기 때문입니다.

AI와 비교해 우리가 가지고 있는 힘은 ‘코드를 작성하는 능력’이 아닙니다. 바로 문제를 파악하고, 해결 방안을 설계하는 힘이죠. 우리는 더욱 넓은 시야를 가지고, 프로젝트의 요구 사항과 목표를 정확히 인식한 채, 프로젝트 상황에 알맞는 코드를 작성할 수 있는 개발자가 되어야 합니다. 이것은 실력 있는 개발자가 되기 위해 AI가 등장하기 전에도 지향해야 할 목표였고, AI가 등장했다고 해서 달라지지도 않았습니다. AI는 그저 코드 작성을 조금씩 거들어주면서, 우리가 이전보다 더 넓은 시야를 가질 수 있게 도와주는 도구로 활용될 뿐입니다.

2025년에 키우고 싶은 역량

2024년을 돌아보니, 당장 눈앞의 문제에만 집중하는 제 자신을 발견했습니다. 여러 사이드 프로젝트를 하면서 넓은 시야를 가졌다고 생각해 왔지만, 정작 회사에서 진행하는 프로젝트는 규모에 겁을 먹고 당장 닥친 것만 해결하기 바빴던 것 같습니다.

그래서 더욱 실력 있는 개발자가 되기 위해 2025년에 집중할 세 가지 역량을 다음과 같이 정리해 보았습니다.

1. 유저 생각하기

개발자들이 흔히 저지르는 실수는 서비스를 개발자의 시각으로 생각하는 것입니다. 서비스를 실제로 구현하며 기술적 측면에 대해 생각하다 보면, 기술적으로 말이 되는 방향으로 프로젝트가 빠져버리기 쉽습니다. 이렇게 되면 열심히 만든 서비스가 막상 사용하려고 보니 불편하기만 하고, 본래 목적으로 활용하기 힘들어질 수 있습니다.

따라서 서비스는 유저가 사용하는 것임을 항상 기억해야 합니다. 프로젝트의 방향성을 세우기 위해서는 유저가 서비스를 어떻게 사용하는지를 파악하고, 그 위주로 접근해야 합니다. 프로젝트 개발에 몰두하다 보면 유저들이 프로젝트를 사용하는 방법인 유즈 케이스에 대해 잊기 쉬운데요. 유즈 케이스를 생각하지 않으면, 프로젝트는 방향성을 잃게 됩니다.

한때는 유즈 케이스를 파악하고, 프로젝트의 방향성을 생각하는 것은 기획자의 역량이라고 생각했는데요. 기획자뿐만 아니라, 개발자에게도 매우 중요한 역량임을 깨닫게 됐습니다. 주변에서 프로젝트 방향성을 잘 이끄는 동료들이 프로젝트의 기간을 훨씬 단축시키고, 획기적으로 성공률을 높이는 것을 봤기 때문입니다.

유저를 먼저 생각하는 동료들은 기능을 구현할 때도 유저의 입장에서 생각합니다. 기획 단계에서 모든 걸 완벽하게 결정할 수 없기 때문에, 정해지지 않은 세부적인 것들은 유저가 어떻게 받아들일지를 고려해 디자인하고, 구현이 힘든 것들도 유즈 케이스를 고려해 대안을 제시합니다. 서비스를 사용하는 다양한 유즈 케이스를 떠올리면, 서비스의 강점과 약점을 파악할 수 있습니다. 강점은 서비스의 차별점으로, 약점은 서비스의 개선점으로 인식하고 서비스를 발전시키는 것에 집중하여, 2025년에는 더욱 능동적으로 참여할 수 있는 개발자가 되고자 합니다.

2. 문서화하기

지난 1년간 회사에서 여러 프로젝트를 하는 동시에, 개인적인 사이드 프로젝트도 여러 번 진행했는데요. 일 벌이기 좋아하는 저의 성향상 평소에는 두 개, 많게는 네 개 이상까지의 프로젝트도 동시에 하는 경우가 많았습니다. 그러다 보니 한 프로젝트에 대해 생각하다가 다른 프로젝트로 생각을 전환해야 하는 경우, 즉 생각의 컨텍스트 스위칭이 자주 일어나야 했습니다. 프로젝트가 많아지고 컨텍스트 스위칭을 더욱 자주 해야 할수록 프로젝트 하나하나에 깊이 생각하기 힘들어졌고, 놓치는 부분이 생겨 실수도 잦아졌습니다.

실수가 잦아지는 이유는 프로젝트에 대해 고민하다가, 다른 프로젝트로 스위칭을 한 이후 다시 돌아왔을 때 ‘이전에 어디까지 고민했는지 떠올리는 데 많은 시간이 걸렸기 때문’이라고 생각했습니다. 실제로 컨텍스트 스위칭 이후, 한참 고민해서 내린 결론이 이전에 한 고민이나 결론과 같았던 때도 여러 번 있었죠.

이를 해결하기 위해 최근 문서를 작성하기 시작했습니다. 이전까지는 공유해야 할 중요한 사안이나 규모가 있는 내용들 위주로 문서를 작성했다면, 이제는 스스로를 위해 간단한 내용이라도 문서를 작성하기 시작한 겁니다. 문서를 작성하면 컨텍스트 스위칭 이전에 내가 어떤 고민을 했고, 어디서부터 이어 나가야 할지에 대한 기억을 단기간에 떠올릴 수 있습니다. 이에 따라 프로젝트에 대해 더욱 깊은 고민을 해나갈 수 있게 되며, 이를 팀에 공유하면서 조율된 의사 결정을 유지하는 데도 도움이 됩니다.

그리고 문서는 짧은 내용이어도 읽는 사람들을 최대한 설득할 수 있게 유지하려고 합니다. 이를 위해 하나의 문서는 1. 문제 제시와 2. 문제 해결의 내용을 담고 있습니다. 여기서 문제는 단순히 프로젝트에서 발견된 버그나 구현해야 할 기능만을 말하는 것이 아닙니다. 무언가를 조사해야 할 때는 해당 주제가 프로젝트와 어떻게 연관되는지를 문제라고 할 수 있을 것이고, 주장을 내세우고 싶을 때는 그 주장 자체가 해결해야 하는 문제가 됩니다.

이 두 내용에서는 다음과 같이 더욱 상세한 항목을 다룰 수 있습니다.

• 문제 제시
  • 문제가 발견된 배경을 서술합니다.
  • 유즈 케이스를 고려하여 발생한 문제의 영향을 서술합니다.
• 문제 해결
  • 문제가 발생한 원인을 파악합니다.
  • 문제를 해결할 수 있는 여러 방법을 제시합니다.
  • 각 방법이 문제를 해결할 수 있는 근거를 제시합니다.
  • 시간, 비용, 확장성 등을 고려하여 현재 상황에서 가장 좋은 해결 방안을 선택합니다.

최근 블로그에 작성한 ‘개발자와 글쓰기’라는 글도 짧지만, 이러한 구성을 갖고 있습니다. “개발자와 글쓰기에는 어떠한 연관성이 있나?”가 이 글이 해결하고자 하는 주제가 될 것이고, 이를 뒷받침하기 위한 이유 세 가지가 문제 해결을 위한 근거가 됩니다.

이렇게 문서를 제대로 작성하기 시작한 지 약 한 달 정도가 지났는데, 그 효과는 톡톡히 체감하고 있습니다. 놓치는 부분이 줄어들고, 오히려 팀원들이 생각하지 못했던 문제점과 계획을 세울 때도 있었습니다. 2025년에도 계속 문서를 작성하여 실수를 줄이고, 생각의 깊이를 더해보려고 합니다.

3. 장기 플랜 세우기

2025년에는 시야를 넓히기 위해 프로젝트의 장기 플랜을 세워 보려고 합니다. 지금까지는 이미 세워진 플랜을 따라가며 각 단계에만 집중했습니다. 왜 이런 플랜이 세워졌는지, 전체 목표는 무엇이며, 각 단계의 목표는 어떤 것인지에 깊이 생각하지 않았죠.

저는 주어진 여러 일들의 우선순위를 파악하는 것에 약합니다. 우선순위가 정해져 있지 않으면 더 마음이 가는 것, 재미있어 보이는 일을 먼저 작업하곤 했습니다. 그러나 이제부터는 직접 프로젝트의 목적에 대해 고민하고, 이를 활용해 장기 플랜에 적용하는 것을시도해 보려고 합니다. 장기 플랜을 위해 다음의 세부 단계를 정해 보았습니다.

• 프로젝트 방향성 생각하기

장기 플랜을 세우기 위해서는 프로젝트의 목적이 명확해야 합니다. 장기 플랜은 실천 시작부터 완료되기까지 오랜 시간이 걸립니다. 명확한 프로젝트 방향성이 정해지지 않은 상태로는 중간에 목적을 상실하고, 원래의 계획과는 다른 길로 빠지기 쉽습니다.

• 사용자 경험 생각하기

사용자 경험을 생각해서 프로젝트의 방향성 내에서 가장 사용자에게 와닿는 부분이 무엇인지를 파악합니다. 프로젝트가 갖는 여러 기능들 중 사용자들이 좋아할 만한 것은 무엇인지, 구현을 쉽게 빠르게 할 수 있는 것은 무엇인지를 따져보며 우선순위를 책정할 수 있습니다.

• 목적 세분화하기

프로젝트의 상황, 사용자 경험, 인력 등을 고려하여, 프로젝트의 최종 목표를 향하는 세부적인 중간 목표를 세웁니다. 한 번에 하나의 중간 목표에 집중하며, 최대한 효율적으로 성취감을 느끼며 프로젝트를 완성해 나갑니다.

이렇게 프로젝트의 가치와 우선순위를 고려해 플랜을 세우면, 팀원들이나 리드를 설득하기도 쉬워질 것이라 생각합니다. 논리적인 플랜을 세운다면 그 과정에서 충분한 근거와 데이터가 기반이 될 것이기 때문입니다. 이렇듯 장기 플랜을 세움으로써 프로젝트의 성공을 위해 어떤 것들을 준비해야 하는지, 논리적인 사고 또한 한 층 성장하기를 기대합니다.

마치며

2024년은 저에게 실력 있는 개발자란 무엇인가를 생각해 보고, 추구하는 개발자의 방향성을 정의하기 위해 고민할 수 있었던 한 해였습니다. “좋은 코드가 좋은 제품을 만든다”라는 저의 좌우명은 아직 변하지 않았습니다. 개발자는 여전히 이해하기 쉽고 잘 설계된 좋은 코드를 작성해야 합니다. 그리고 지금까지는 “좋은 코드”를 작성하기 위해 노력해 왔고요.

그러나 이제 2025년부터는 그 이상을 바라보려고 합니다. 단순히 코딩에만 집중하는 것을 넘어, 시야를 넓혀 프로젝트 전체와 사용자를 고려하는 개발자가 되려고 합니다. 제가 참여하는 프로젝트의 성공을 위해 적극적으로 기여하고 싶습니다. 또한 프로젝트의 발전 방향을 제시하고, 문제 해결 능력뿐 아니라 문제 파악 능력과 리더십까지 갖춘 개발자로 성장하는 것을 희망합니다. 여러분은 2025년을 어떻게 그려나가고 싶으신가요? 이번 글을 통해 한번 더 생각해 보는 계기가 되었으면 합니다.

요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.