카카오 4년차 백엔드 개발자 이직 회고

 

이 글은 국내 IT 기업 이직에 대한 팁과, 4년 차 개발자로서 개인적인 생각들이 있습니다.

---

1.  이직에 대하여

1) 동기

이직을 하려면 강한 동기가 필요합니다. 에너지가 없으면 준비 자체가 쉽지 않습니다.

스스로 왜 이직하려는지, 그 이유를 확실히 정리하고 천천히 준비해 보는 게 좋습니다.

 

저는 회사 내에서 만족할 만한 평가를 받지 못하고 있다고 느꼈습니다.
'내가 진짜 개발을 못 하는 건가?' 싶은 생각에 자존감이 흔들리기도 했지만, 냉정하게 보면 실력 차이가 그렇게 크다고는 생각하지 않았습니다.

그래서 이직을 통해 다른 회사 면접을 보면서 제 실력을 시험해보고 싶었습니다.

 

2) 서류

이력서는 노션으로 준비했습니다.

간단한 자기소개, 기술 스택, 프로젝트 경험 위주로 정리했습니다.

프로젝트 경험은 디테일한 문제 해결보다는, '이 프로젝트를 통해 어떤 경험을 했고, 어떤 역량을 얻었는지' 에 초점을 맞춰 작성했습니다.
총분량은 약 2페이지 정도였습니다.

보다 구체적인 문제 해결 경험은, 서류 제출 플랫폼에 따로 1000자 내외로 작성할 수 있는 칸을 활용해 적었습니다.

 

요즘은 기술 스택이 조금이라도 안 맞으면 바로 서류 탈락시키는 경우가 많습니다.
그래서 회사가 강조하는 기술 경험을 명확히 어필하는 게 중요한 것 같습니다.

 

또, 같은 계열사 내에서도 동일한 서류가 어떤 곳은 붙고 어떤 곳은 떨어지기도 합니다.
어느 정도 운도 작용하니 너무 부담 갖지 말고 편한 마음으로 지원하는 게 좋다고 생각합니다

 

3) 코테

회사에 따라 리트코드, 프로그래머스, 해커랭크 같은 플랫폼을 통해 코딩 테스트를 진행합니다.

저는 네이버 계열사와 라인 코테 모두 봤는데, 소문과 달리 경력직이라고 해서 테스트가 쉬운 건 아니었습니다.

보통 한 문제 정도는 리트코드 하드 난이도나 백준 플래티넘 하위 수준의 꽤 어려운 문제가 출제됩니다.

체감상 거의 다 풀어야 합격하는 분위기였습니다

 

4) 라이브 코테

네이버웹툰이나 일부 회사는 라이브 코딩 테스트를 봅니다. 특히 외국계 기업에서는 거의 필수라고 합니다.

문제가 쉬울 거라고 생각할 수 있지만, 리트코드 하드 수준의 어려운 문제를 출제하는 경우도 있습니다.

너무 어려워서 한 줄도 못 적는 상황이 생기더라도, 면접관과 문제 해결을 위한 소통 과정이 좋았다면 합격하는 경우도 있었습니다.

 

알고리즘을 많이 연습해서 바로 푸는 것보다는, 문제 조건을 꼼꼼히 확인하고
면접관과 소통하며 힌트를 얻어가며 풀어나가는 방식를 더 중요하게 보는 것 같았습니다.

 

5) 1차 면접

면접관 스타일에 따라 면접 분위기는 정말 다양합니다.
그래도 대체로 아래와 같은 유형으로 나눌 수 있을 것 같습니다.

 

- 프로젝트 질문

어떤 면접이든 무조건 나오는 건 프로젝트 관련 질문입니다.
예를 들어 이런 것들입니다

- 프로젝트에서 가장 어려웠던 점은 무엇인가요?

- 가장 우선순위가 높았던 일은 무엇인가요?

- 만든 아키텍처를 그림으로 간단히 설명해 주세요.

- 이 부분은 왜 그렇게 설계했나요?

- 여기서 이런 에러가 나면 어떻게 대응하나요?

- MSA를 도입한 이유는 무엇인가요?

- 많은 트래픽을 감당하기 위해 어떤 부분을 고려했나요?

이런 질문들은 대부분 준비할 수 있습니다.
프로젝트에 대한 이해도가 높다면 어렵지 않지만, 잘 모르겠다면 지금이라도 히스토리를 꼼꼼히 정리하면서 준비하는 게 좋습니다.

 

- 기술 질문(CS)

회사에 따라 조금 다르긴 하나, 경력직도 CS 질문이 많이 나옵니다. 

내가 적은 기술스택 혹은 지원하려는 회사에 우대사항에 적혀있는 기술스택에 관련된 질문이 나옵니다.

예를 들면 프레임워크, 언어, 네트워크, 운영체제, DB 질문입니다.

뻔한 질문도 하지만 응용버전으로 특정 자료(리소스 사용량, 에러 로그, 코드 등)를 제시하고 퀴즈형식으로 답을 말해보라고도 합니다.

 

신입보다 좀 더 깊게 물어본다 생각하시면 됩니다.

이 부분은 평소에 공부를 많이 해두는 게 좋습니다.

 

- 설계 질문

'이런 요구사항을 서비스를 만들 건데 어떻게 설계할래?'와 같은 류의 질문입니다.

주변 대부분 '가상 면접 사례로 배우는 대규모 시스템 설계 기초' 책으로 공부를 합니다.

어느 정도 특정상황에서는 정답 같은 설계 기법들이 존재합니다.

이 기법들을 이해하고 요구사항에 맞게 응용 및 조립하여 대답하면 됩니다.

 

외국계 혹은 시니어 면접에선 중요하게 생각하는 항목입니다. 거의 무조건 나온다고 생각하시면 됩니다.

이것 또한 면접관과의 의사소통을 통해 문제가 없는지 중간중간 확인하고 이해하는 과정이 중요하다고 느꼈습니다.

 

6) 2차 면접

기술면접, 인성면접 둘 중 하나로 진행되거나, 둘 다 진행될 수 있습니다.

회사에 따라 다릅니다.

 

- 기술면접

임원급 혹은 리더급이 나와서 1차와 동일하게 기술면접을 동일하게 진행합니다.

조금 더 딥하게 물어보는 경향이 있습니다.

 

- 인성면접

인성 면접은 대부분 ‘내가 한 말’에 대한 검증입니다.

‘가르치는 걸 좋아한다’고 하면 실제로 가르쳐본 사례를 물어보고,
‘코드 리뷰를 중요하게 생각한다’고 하면 최근 인상 깊었던 리뷰 경험을 말해보라고 할 수 있습니다.

형식적인 답보다, 실제 경험을 바탕으로 솔직하게 말하는 게 중요하다고 생각합니다.

 

7) 연봉협상

2차 면접까지 통과하면 연봉 협상이 진행됩니다.

메일로 오퍼레터가 오고, 거기엔 연봉과 복지 관련 내용이 포함돼 있습니다.

이후 인사 담당자가 배정되어, 그분과 협상을 진행하게 됩니다.

 

연봉이 기대보다 낮게 책정됐다면, 인사 담당자에게 한 번 더 검토를 요청해 보는 걸 추천합니다.
요청했다고 해서 갑자기 탈락하거나 불이익이 생기는 일은 없었습니다.

 

8) 지원했던 회사들

- 라인

처음에 제일 가고 싶었던 회사는 라인이었습니다.

국내에서 손꼽히는 트래픽 규모를 다루고 있고, 외국인과 협업할 기회도 많고,
오픈소스를 적극적으로 운영하는 걸 보면 기술적으로도 수준 높고 신경을 많이 쓰는 회사라는 인상을 받았습니다.

게다가 제가 좋아하는 개발자인 이희승 씨가 라인에서 근무 중이라는 점도 매력적이었습니다.
심지어 자율적인 재택근무까지 가능하다는 점도 마음에 들었습니다.

 

상시 모집 중인 부서가 많아 자연스럽게 지원하게 됐습니다.
다른 회사에 비해 코딩 테스트 및 면접의 난이도가 많이 높았습니다.

 

- 네이버 본사 + 계열사(웹툰, 페이 등)

네이버는 여러 계열사에 동시에 지원했는데, 동시 지원에 문제가 있진 않았고 실제로 동시에 진행됐습니다.

앞서 말한 것처럼, 이번 이직의 가장 큰 동기 중 하나는 내가 연차에 맞는 레벨을 가진 개발자인지 확인해보고 싶다는 것이었습니다.
신입으로 카카오에 입사하긴 했지만, 카카오 4년 차 개발자로서 얼마나 성장했는지를 확인하기엔 네이버 면접이 좋은 기준이 될 것 같았습니다.

1차, 2차 모두 기술 중심의 면접이었고,
1차 기술 면접을 두 번 통과하고 최종 합격까지 하며, 나도 경쟁력이 있다는 걸 느낄 수 있었습니다.

 

다만, 채용 프로세스가 매우 느린 편이었습니다.
서류 제출부터 최종 결과까지 약 4개월 정도가 걸렸습니다.

 

- 토스

처음부터 토스에 꼭 가야겠다는 생각은 없었습니다.
하지만 마침 채용 공고가 열려 있길래, 경험 삼아 한 번 넣어봤습니다

 

공고에 적힌 대로, 1차는 직무 인터뷰(기술), 2차는 문화적 합성 인터뷰(인성)으로 진행됐습니다.
1차 2차 모두 면접관 분들이 친절해서 전체적인 면접 경험도 좋았습니다.

면접을 준비하며 토스의 열정적인 문화가 저와 잘 맞는다는 느낌도 들었습니다.

 

무엇보다 좋았던 점은 채용 프로세스가 매우 빠르다는 것이었습니다.
결과도 빠르게 나오고, 지체 없이 진행됐습니다.

 

9) 이직 소감

이직을 준비하는 것은 힘들고 피곤한 일입니다.

그래도 기회가 있다면 가끔씩 봐보는 것을 추천드립니다.

 

면접을 보다 보면 여러 가지를 느끼게 됩니다.

'내가 경쟁력이 있는가?' '내가 개발자로서 잘 성장하고 있는가?' 에 대해 시장으로부터 직접 피드백을 받는 기회라는 생각이 들었습니다.

면접이 어렵게 느껴졌다면, 내 연차 수준에 요구되는 역량이 이런 것이구나 하고 감을 잡을 수도 있습니다

그런 면에서 면접은 단순한 평가가 아니라, 배움의 계기가 될 수도 있는 것 같습니다.

 

면접 탈락의 이유는 여러 가지가 있습니다.

저 역시 답변을 잘했다고 느꼈던 면접에서 떨어진 적이 있습니다.

회고해 보니, 답하는 것만으로는 부족하고, 그 답을 잘하는게 더 중요했던 것 같습니다.

 

대답을 잘한다는 게 어떤 의미일까요?

어느 정도의 지식을 가지고 있는지 보여줄 수 있는 대답을 하는 게 중요합니다.

면접 시간이 한정되어 있는 만큼 자신을 보여줄 수 있는 시간이 적습니다.

쉬울 수 있는 질문에도 적당히 대답하지 말고 자신을 어필할 수 있도록, 혹은 좋은 질문으로 이어지도록 대답을 하는 걸 추천합니다.

이 파인만의 질문대답 영상을 보면서 예시를 들어보겠습니다.

위 영상은 면접 관련 영상은 아닙니다. 다만 질문에 관계없이 파인만의 답변에서 엄청난 수준의 지식이 있음은 누구라도 알 수 있습니다.

결론적으로 면접관에게 '나는 관련 지식을 매우 잘 알고 있다'를 어필하는 것이 중요한 것 같습니다.

 

추가로 면접관들은 항상 여러분보다 뛰어난 개발자는 아닙니다.

예를 들어 내가 한 프로젝트 설명을 쉽게 안 하면, 면접관들은 이해조차 못 합니다.

즉 개떡같이 설명하면 개떡같이 이해합니다. 추가질문이 나올 수 없을 수 있습니다

말할 때 상대방이 이해하게끔 잘 정리해서 설명하는 연습은 필요합니다.

면접은 나보다 월등히 뛰어난 해당 분야 교수님한테 평가받는 자리가 아니라고 생각합니다.

내가 선생님이 된 것처럼 어려운 것을 쉽게 잘 설명해 준다는 생각을 하는 게 좋은 것 같습니다.

 

---

2.  커리어에 대하여

여기부터는 면접에 대한 내용은 전혀 없습니다.

4년 차 백엔드 개발자로 살아오면서 정리된 개인적인 생각들입니다.

 

1) 천재 개발자에 대한 망상. 잘하는 개발자란?

네이버 웹툰 중 'AI 닥터'라는 만화가 있습니다.

주인공은 저연차 의사임에도 자기 혼자 AI의 힘을 빌어 교수들 사이에서 천재소리를 듣는 의사가 되는 스토리입니다.

개인적으로 만화를 보면서 내과의사가 진단명을 찾는 과정은 개발자가 문제의 원인을 찾아가는 방식과 비슷하다고 느꼈습니다.

 

여기서 상상을 하나 하게 됩니다.

만화적 허용으로 누구나 인정할만한 '회사에서 천재 소리를 듣는 개발자'를 만든다면 어떻게 그려낼 수 있을까요?

전 세계 보안망을 뚫는 슈퍼 해커나 리누스 토르발스, 빌 게이츠처럼 전설적인 인물이 아니라,
현실에서 실제로 존재할 법한 사람을 떠올려보려 했는데,
사실 잘 떠오르지 않았습니다. 주변에서도 그런 사람은 본 적이 없습니다.

 

그렇다면 다른 질문으로, 여러분이 지금 가지고 있는 지식으로 나이만 어려져 신입 재입사한다고 가정해 보세요.

천재소리 듣는 신입이 될 수 있으신가요?

저는 어려울 것 같습니다.

신입치고는 일을 잘한다는 평가는 받을 수 있겠지만, 그 정도일 것 같습니다.

 

저는 웹툰을 보며 개발자에 대입해 어느 정도 생각을 정리했습니다.

웹툰의 주인공을 한 줄로 정리하면 '경력에 비해 문제해결력이 말도 안 되게 좋다'입니다.

무슨 말이냐면 무슨 병인지 진단명을 찾기 위해 환자의 여러 가지 기기 검사 결과, 환자의 현재 지표, 과거 병력 히스토리 등의 '힌트'를 통해 문제의 원인. 즉 진단명을 찾아냅니다.

근데 그게 아주 진단하기 힘든 희귀한 병일지라도 주인공은 수십 년 치 많은 자료가 머릿속에 있으니, 신입인데도 근거를 통해 진단명을 정확하게 찾아내며 천재소릴 들을 수 있게 됩니다.

 

진단 능력을 개발자에 대입하면 어떨까요?

개발자는 일하며 여러 가지 문제를 만나게 됩니다.

애플리케이션이 특정상황에서 동시성 이슈가 발생한다던지, 빌드가 안된다던지, 의도한 로직대로 동작하지 않는다던지, 트래픽이 몰렸을 때 터진다던지, 메모리 릭이 있다던지, 처리속도가 너무 느리다던지. 아주 많습니다.

마찬가지로 여러 힌트들이 주어집니다. 각종 모니터링 지표들이 있고, 로그들이 있으며, 힙덤프, 소스코드 등이 있습니다.

단순히 코드를 잘 못 짠 거라면 누구나 바로 분석이 가능하죠.

하지만 도저히 모르겠을 때가 있습니다. 그것은 로우레벨 동작에서 문제가 생겼을 때가 많죠.

근데 연차가 낮은 개발자가 복잡한 장애 상황에서 원인을 빠르게 찾아내고 해결책까지 제시한다면 어떨까요?

저는 굉장히 잘한다고 생각할 것 같습니다.

게다가 직접 사용하는 오픈소스의 중요한 문제를 찾아내 기여하거나,
아예 더 나은 오픈소스를 만들어 운영하는 사람이라면
회사 안에서 충분히 ‘천재 같다’는 말을 들을 수 있을지도 모르겠습니다

 

저든 위에 설명한 진단능력을 포함하여 뛰어난 개발자의 능력을 크게 2개로 정리 하였습니다.

 

1. 연차를 뛰어넘는 문제해결력을 가지고 있다.

2. 코드, 설계를 잘 짠다.

 

-  문제해결력

트러블슈팅을 잘하려면 사용하는 프레임워크나 라이브러리의 내부 동작에 대한 이해가 필요합니다.
또한 운영체제, 네트워크, DB, Kafka, JVM 같은 핵심 기술 스택의 구조와 동작 원리를 알고 있어야
복잡한 문제를 해결할 수 있는 경우도 많습니다.

이 분야들은 양도 방대하고 깊이도 있어서, 단기간에 공부로만 습득하기는 어렵다고 생각합니다.
이런 로우레벨 기본기는 경험이 누적되며 서서히 쌓이는 경향이 있는 것 같습니다
그래서 저는 이 부분을 연차가 쌓일수록 점진적으로 키워가야 할 경쟁력이라고 보고 있습니다.

 

- 코드, 설계

개발자는 기본적으로 코드를 잘 짤 수 있어야 합니다.

코드를 잘 짠다는 것은 결국 가독성이 좋고, 변화에 유연하게 짜는 것을 의미합니다.
이걸 위해선 정말 여러 가지 공부해야 할 게 많습니다.

특정 언어의 베스트 프랙티스나 안티패턴, 함수형/객체지향 프로그래밍, 클린코드, 리팩토링, 아키텍처 설계 같은 책들도
이런 역량을 키우는 데 중요한 자료라고 생각합니다. (참고로 저는 코드레벨의 설계가 확장되면 아키텍처 설계로 이어진다고 생각하는 편이라, 두 분야를 같은 흐름 안에 있다고 보고 있습니다)

이 분야는 하다 보면 어느 정도 레벨에는 도달할 수 있지만, 정말 잘한다고 평가받기까지는 쉽지 않은 영역이라고 느끼고 있습니다.

 

여기까지가 제가 생각한 정리입니다.
앞서 말한 두 가지 역량을 잘하기 위해 지금도 계속 노력 중입니다.

‘잘하는 개발자란 무엇인가’, ‘나는 무엇을 공부해야 하는가’를 고민하던 시기에 정리했던 내용이라
공감이 되지 않는 분도 있을 수 있다고 생각합니다.

사람마다 생각이 다를 수 있으니, 그냥 이렇게 생각하는 사람도 있구나 정도로 봐주시면 감사하겠습니다.

 

2) 회사 일을 잘하는 개발자

위에서 제가 생각하는 잘하는 개발자에 대해 생각은 했으나, 그게 일을 잘하는 개발자는 아니라고 생각합니다.

'구글 엔지니어는 이렇게 일한다'라는 책에는에서도 이런 말이 있습니다.

2.2 천재 신화
구글에서의 업무 거의 대부분이 천재 수준의 지능을 요구하지 않는 반면, 모든 업무가 최소한의 사회성을 요구합니다. 그래서 우리의 경력을 미래로 이어주는 핵심은 다른 사람과 얼마나 잘 협력하느냐입니다.

 

회사에서 개발자로 일하다 보면 모든 일이 고차원적인 기술력을 요하지는 않는다는 걸 자주 느끼게 됩니다.
분명 까다로운 업무도 있지만, 누구나 감당 가능한 종류의 일이 대부분이고,
그 일들을 어떻게 풀어가느냐가 더 중요하게 작용하는 경우가 많습니다.

 

개인적으로 ‘회사에서 일을 잘하는 개발자’는 아래와 같은 특징을 갖고 있다고 생각합니다.
개발 그 자체보다는 협업과 태도에 가까운 요소들입니다.

 

- 커뮤니케이션

상대방을 존중하고 배려하는 커뮤니케이션은 모든 협업의 기본입니다.
모든 요청을 다 들어주는 것도, 모두 거절하는 것도 옳지 않습니다.
거절이 필요할 때도 예의와 설명이 동반되어야 합니다.

커뮤니케이션이 틀어지면 상대방이 협조적이지 않게 되고,
이로 인해 프로젝트 전체가 흔들릴 수 있습니다.
그 상황에서 타 팀 탓만 하거나 감정적으로 대응하는 건 바람직하지 않다고 생각합니다.

결국 어려운 사람과도 좋은 커뮤니케이션을 통해 일을 잘 완수할 수 있도록 하는 것도 역량 중 하나라고 봅니다.

 

- 꼼꼼함

작은 업무라도 빈틈없이 처리하는 태도는 팀 내 사람들의 신뢰로 이어집니다.
요구사항을 정확히 파악하고, 사이드 이펙트를 미리 점검하며,
배포 이후의 모니터링도 놓치지 않습니다.
코드 리뷰에서도 세심하게 확인하며, 대충 하지 않는 자세를 유지합니다.

또한 여러 이슈를 처리하더라도 일정을 놓치지 않습니다.

꼼꼼함은 실무에서 매우 중요한 경쟁력이라고 생각합니다.

 

3) 개발자는 전문가인가?

사전적인 의미로는 전문가와 전문직은 아래와 같은 의미를 가집니다.

전문가 : 어떤 분야를 연구하거나 그 일에 종사하여 그 분야에 상당한 지식과 경험을 가진 사람

전문직 : 전문적인 지식이나 기술이 필요한 직업

 

전문가라는 소리를 들으려면 많은 시간과 노력을 쏟아부어야 합니다.

만약 어떤 직업을 아무나 할 수 있고, 신입과 시니어의 경계가 없다면 전문직이라고 볼 수 없을 것 같습니다.

예를 들어 1년 차 개발자가 10년 차 개발자보다 문제를 더 잘 해결하고 더 나은 설계를 한다면, 개발은 1년만 투자하면 마스터할 수 있는 일처럼 보일 수 있겠죠. 그럼 개발자는 전문직이라고 보기 어렵다고 생각합니다.

 

그럼 개발자가가 전문직이면 모든 개발자가 전문가일까요?

그렇진 않다고 생각합니다.

개발자의 진입장벽은 낮은 편입니다.
의사나 변호사처럼 시작부터 막대한 시간과 노력을 요구하지도 않죠.
누구나 개발을 배울 수 있고, 빠르게 실무를 경험할 수 있는 구조입니다.

 

그렇다면 오랜 경력을 쌓은 개발자는 전문가일까요?

그렇진 않다고 생각합니다.

개발자로서 회사를 다니는 것은 시간과 노력을 투자해 전문성을 쌓았다고 보긴 어렵습니다.

회사에서의 업무는 실무 감각을 익히는 데엔 도움이 되지만, 깊이 있는 원리나 구조까지 탐구하기엔 한계가 있습니다.
물론 회사 업무를 통해 전문성을 키울 수 있는 환경도 존재하겠지만, 제 경험상 그러한 경우는 드뭅니다.
오히려 시간이 쌓이며 생기는 건 ‘전문성’이라기보다는 ‘익숙함’ 일 때도 많습니다.

 

결론적으로, 개발이 ‘전문직’이 될 수 있느냐는 질문에 대한 제 답은 이렇습니다.
누군가에게는 전문직일 수 있고, 누군가에게는 아닐 수도 있습니다.
전문직이라 불리려면 단순히 오랜 경력을 쌓는 것만으로는 부족합니다.
개인의 시간과 노력을 지속적으로 투자하며, 깊이 있는 지식과 경험을 축적해 온 사람만이 진정한 의미의 전문가라고 생각합니다.

 

저의 2021년도 회고를 보면 개발자 시작한 이유가 시간이 지날수록 전문성을 쌓을 수 있는 직업이라 선택했음을 알 수 있습니다.

저는 제 직업에 있어서 계속 성장해서 누구나 인정할만한 높은 전문성을 가진 전문가가 되고 싶고, 어떤 방식으로든 주변에 좋은 영향력을 끼치고 싶습니다.

그래서 저는, 개발자로서 전문가가 되기 위해 오늘도 꾸준히 공부하고 있습니다.

4) AI 시대의 개발자

AI 코딩 시대가 왔고, 개발자의 자리가 사라질 거라는 이야기들도 많습니다.
하지만 저는 그렇게 생각하지 않습니다.
개발자의 수가 다소 줄어들 수는 있어도, 개발자라는 직업 자체가 사라지진 않을 것 같습니다.

 

물론, 만약 AI가 백엔드 개발자의 일을 완전히 대체할 수 있다면 어떤 모습일지 상상해 볼 수는 있습니다.

AI가 하드웨어 수준에서 시스템콜을 직접 설계하고, 운영체제를 완전히 이해합니다.
기존 언어보다 성능이 뛰어난 자체 언어를 만들어 그걸로 코딩하고 빌드까지 진행합니다.
스스로 최적의 아키텍처를 구성하고, 배포하며, 문제가 생기면 자동으로 디버깅하고 수정까지 마무리합니다.

개발자는 그 내부 동작을 전혀 알 수 없고, 외부에서 단지 "해줘"라고만 말할 수 있는 상황이라면
저 같은 백엔드 개발자는 끼어들 틈이 전혀 없겠죠.

 

하지만 저는, 기술적으로 그게 가능하더라도 실제로 그런 방식으로 개발이 이뤄지지는 않을 것이라고 생각합니다.

예를 들어, 운영 중인 서비스에 치명적인 문제가 발생했을 때,
서비스 오너가 단순히 “AI야, 무한 에러 디버깅을 통해 고쳐줘”라고 말하고 손을 놓을 수 있을까요?

만약 AI가 해결하지 못한다면?
AI를 교체하는 것 말고는 방법이 없는 구조라면?
이런 리스크를 감수하는 기업은 없을 겁니다.

그래서 AI는 결국 사람이 개입할 수 있도록 사람이 이해할 수 있는 코드를 짜야합니다.

결국 이는 개발자의 필요성을 의미합니다.

 

물론, AI 시대에는 개발자가 집중해야 할 분야나 일의 방식이 이전과 달라질 수 있습니다.
AI는 결국 사용하는 사람의 수준 이상으로 활용되기 어렵습니다.

예를 들어 아무리 뛰어난 AI 모델이라 하더라도, 초등학생과 교수가 사용할 때 그 결과물에는 분명한 차이가 생깁니다.

 

그래서 저는 AI 시대를 준비하는 개발자는 자신의 전문성, 즉 기본기를 탄탄히 다지는 것이 가장 중요합니다.
기본기가 튼튼할수록, AI라는 도구를 더 효과적으로 활용할 수 있기 때문입니다.

 

3. 마치며

2021년 신입으로 카카오에 입사한 이후, 아직까지는 성장에 대한 욕구가 큽니다.

이 직업에 많은 애정을 가지고 있고, 더 잘하고 싶다는 마음도 분명합니다.
회사에서는 팀에 기여하며 개발자로서 성취를 느끼고 싶고,
회사 밖에서는 제 경험과 생각이 누군가에게 좋은 영향을 줄 수 있기를 바랍니다.

 

앞으로 개발자로서 어떤 방향으로 성장할지, 언제까지 이 열정이 이어질지는 저도 잘 모르겠습니다.
하지만 제게 주어진 시간과 노력을 다해, 제 몫의 무언가를 이뤄내고 싶습니다.

 

이 글이 누군가에게 작은 도움이 될 수 있다면 기쁘겠습니다.
긴 글 읽어주셔서 감사합니다.