[심층분석] "우리 망했다"는 외침, AI 시대 개발자의 진짜 속내는 무엇일까

들어가며: "We're cooked"라는 탄식의 정체

요즘 영어권 개발자 커뮤니티, 특히 레딧이나 트위터를 돌아다니다 보면 자주 보이는 밈 같은 표현이 하나 있어요. 바로 "We're cooked"라는 말인데요. 직역하면 "우리 익혀졌다" 정도가 되겠지만, 실제로는 "우린 망했다", "끝났다", "이제 어쩌지?" 같은 자조적인 탄식을 담은 슬랭이에요. 한국어로 치면 "아, 망했네" 정도의 뉘앙스죠.

이 표현이 특히 ChatGPT 관련 커뮤니티에서 자주 튀어나오는 건 우연이 아니에요. 2022년 말 ChatGPT가 세상에 나온 이후로 3년 반이 흘렀는데요, 그 사이에 AI가 보여준 변화는 정말 어마어마했거든요. 단순히 챗봇이 대화를 잘하는 수준을 넘어서, 이제는 코드를 짜고, 디자인을 하고, 영상을 만들고, 심지어는 긴 호흡의 추론까지 해내는 시대가 됐어요.

그래서 개발자들 사이에서 "우리 망했다"는 말은 단순한 농담이 아니라, AI가 내 일을 대체할지도 모른다는 실존적 불안을 유머로 포장한 것이라고 봐야 해요. 오늘은 이 짧은 한마디 뒤에 숨어있는 개발자 커뮤니티의 진짜 심리와, 우리가 어떤 태도로 이 시대를 살아가야 할지 함께 이야기해볼게요.

왜 하필 지금, 이 탄식이 나오는 걸까

AI 발전 속도의 체감 변화

개발자들이 느끼는 불안의 근원을 이해하려면, 최근 몇 년간 AI가 얼마나 빨리 발전했는지 먼저 짚어볼 필요가 있어요.

• 2022년 11월: ChatGPT(GPT-3.5) 공개. 대화는 잘하지만 코드는 자주 틀림.
• 2023년: GPT-4 등장. 간단한 함수 정도는 꽤 정확하게 작성.
• 2024년: Claude 3.5, GPT-4o 등장. 중간 규모의 리팩터링도 가능해짐.
• 2025년: Claude Sonnet 4, Opus 4 시리즈, GPT-5 등장. 에이전트(Agent) 형태로 여러 파일을 동시에 수정하고 테스트까지 돌림.
• 2026년 현재: 코드 작성뿐 아니라 긴 호흡의 작업(몇 시간짜리 PR 작성, 릴리스 노트 작성, 디버깅)까지 자동화되는 흐름.

여기서 에이전트라는 말이 나왔는데요, 이게 뭐냐면 쉽게 말해 AI가 스스로 계획을 세우고, 도구를 써가며 목표를 달성하는 방식이에요. 예전에는 "이 함수 고쳐줘" 하면 AI가 그 함수만 고쳐줬다면, 지금은 "로그인 버그 고쳐줘" 하면 AI가 알아서 관련 파일을 찾아 읽고, 테스트를 돌려보고, 수정하고, 다시 검증하는 수준까지 온 거예요.

주니어 개발자 입장에서 보면 이런 생각이 들 수 있어요. "내가 지금 배우는 걸 AI가 이미 다 하고 있는데, 나는 뭘 해야 하지?" 이게 바로 "We're cooked"의 본질이에요.

밈으로 소비되는 불안

재미있는 건, 이런 불안이 진지한 논문이나 칼럼보다는 짧은 밈과 스크린샷으로 소비된다는 점이에요. 레딧 r/ChatGPT 같은 커뮤니티에 올라오는 글들을 보면, 대부분 이런 패턴이에요.

1. AI가 엄청나게 잘한 결과물 스크린샷을 올림
2. 제목은 "We're cooked" 혹은 "It's over" 같은 한 줄 탄식
3. 댓글창에서는 진지한 토론과 농담이 뒤섞임

왜 이런 형태로 소비될까요? 제 생각엔, 불안을 진지하게 이야기하기엔 너무 무겁고, 그렇다고 무시하기엔 너무 크기 때문인 것 같아요. 유머로 감싸서 공유하면 혼자 느끼던 감정이 "다들 그렇구나" 하는 연대감으로 바뀌거든요.

기술적으로 정말 개발자가 "익혀지고" 있을까

자, 이제 감정의 영역을 벗어나서 냉정하게 들여다볼 차례예요. AI가 진짜로 개발자를 대체하고 있는 걸까요?

AI가 잘하는 것 vs 아직 못하는 것

현재 시점(2026년 4월)에서 AI 코딩 도구들이 실제로 잘하는 영역과 그렇지 않은 영역을 나눠보면 이래요.

잘하는 것

• 잘 정의된 함수 단위 코드 작성 (예: "이 JSON 파싱하는 함수 짜줘")
• 보일러플레이트 코드 (예: CRUD API, 폼 검증)
• 기존 패턴을 따라가는 리팩터링
• 테스트 코드 생성
• 에러 메시지 해석과 디버깅 힌트
• 문서화와 주석 작성

아직 어려워하는 것

• 도메인 이해가 필요한 의사결정 (예: "이 기능을 이렇게 만들면 사용자가 혼란스러워할까?")
• 이해관계자들 사이의 요구사항 조율
• 시스템 전체의 장기적인 아키텍처 설계
• 레거시 코드의 "왜 이렇게 짰는지" 맥락 파악
• 성능이 극단적으로 중요한 코드의 최적화
• 보안·규제·윤리적 판단

여기서 핵심은, AI가 "코드 작성"이라는 좁은 작업은 잘하지만, "소프트웨어 엔지니어링"이라는 넓은 일은 아직 전부 대체하지 못한다는 거예요. 둘은 다른 개념이에요. 코드 작성은 요리로 치면 "양파 썰기" 정도의 작업이고, 소프트웨어 엔지니어링은 "어떤 메뉴를 낼지, 재료는 어디서 살지, 손님에게 어떻게 낼지"까지 포함한 전체 식당 운영이거든요.

주니어 포지션이 줄어든다는 진짜 문제

다만 완전히 안심할 수는 없어요. 업계에서 실제로 관찰되는 변화 중 하나는, 시니어는 여전히 필요한데 주니어 채용이 줄어든다는 거예요.

왜 그럴까요? 예전에는 주니어가 맡던 일이 "간단한 버그 수정", "유닛 테스트 작성", "문서 정리" 같은 것들이었거든요. 그런데 이런 일을 이제 AI가 꽤 잘해요. 그러니까 회사 입장에서는 "굳이 신입을 뽑아서 가르칠 필요가 있나? 시니어 한 명이 AI 도구 써서 더 많이 처리하는 게 낫지 않나?" 하는 계산이 서는 거죠.

이게 바로 주니어 사다리의 위기라고 불리는 현상이에요. 시니어는 원래부터 있던 사람들이니까 괜찮은데, 이제 막 시장에 들어오려는 사람들이 디딜 첫 계단이 점점 얇아지고 있는 거예요.

그럼 우리는 어떻게 해야 할까

"AI를 쓰는 사람"이 되는 것

가장 자주 나오는 조언이지만, 여전히 유효한 말이 있어요. "AI가 당신을 대체하는 게 아니라, AI를 잘 쓰는 사람이 당신을 대체한다". 뻔한 말 같지만, 구체적으로 들어가면 의미가 달라져요.

AI를 "잘 쓴다"는 건 단순히 프롬프트를 영리하게 짜는 게 아니에요. 더 중요한 건 이런 것들이에요.

1. AI가 틀린 것을 알아채는 능력: AI는 자신있게 틀린 코드를 내놓을 때가 많아요. 이걸 바로 잡아내려면 본인이 기본기가 탄탄해야 해요.
2. AI에게 맡길 것과 직접 할 것을 나누는 판단력: 중요한 비즈니스 로직을 AI에게 통째로 맡기는 건 위험해요. 반면 테스트 코드 뼈대는 AI에게 맡겨도 되죠.
3. 컨텍스트를 제공하는 능력: AI는 우리 팀의 코드 컨벤션, 과거 결정의 이유, 현재 조직의 상황을 몰라요. 이걸 잘 전달해주는 게 실력이에요.

주니어 개발자를 위한 구체적 조언

이제 막 시작한 분들에게는 이런 조언을 드리고 싶어요.

• 기본기를 포기하지 마세요. AI가 코드를 대신 짜준다고 해서 자료구조나 알고리즘, 네트워크 기본을 공부할 필요가 없어지는 게 아니에요. 오히려 AI 결과를 검증하려면 이런 기본기가 더 중요해졌어요.
• "왜"를 자주 물어보세요. AI에게 "이렇게 짜줘"가 아니라 "왜 이렇게 짜는 게 좋은지 설명해줘"를 섞으세요. AI는 훌륭한 튜터거든요.
• 작은 프로젝트를 끝까지 만들어보세요. AI 도움을 받든 안 받든, 기획부터 배포까지 해본 경험이 곧 당신의 포트폴리오이자 판단력이 돼요.
• 커뮤니케이션 능력을 키우세요. 앞으로 개발자의 가치는 "코드를 잘 짜는 것"에서 "문제를 잘 정의하고 해결 방향을 잘 설명하는 것"으로 점점 옮겨갈 거예요.

시니어 개발자를 위한 조언

시니어 분들에게는 조금 다른 조언이 필요해요.

• 팀의 AI 활용 문화를 설계하세요. 혼자 AI를 잘 쓰는 것보다, 팀 전체가 안전하고 생산적으로 AI를 쓰도록 가이드라인을 만드는 게 훨씬 임팩트가 커요.
• 주니어 양성 방식을 다시 고민하세요. 예전처럼 "일단 간단한 티켓 주면서 배우게 한다"가 안 통해요. 그 일은 AI가 하니까요. 대신 설계 리뷰, 페어 프로그래밍, 의사결정 맥락 공유 같은 것들이 더 중요해졌어요.

한국 개발 시장에서 이 흐름이 주는 의미

한국 시장은 영어권과는 또 다른 결이 있어요. 영어 기반으로 훈련된 AI는 한국어 도메인(법률, 금융, 공공 데이터)에서 여전히 실수가 많거든요. 그래서 한국어·한국 도메인 컨텍스트를 잘 이해하고 AI와 연결하는 사람이 당분간 중요한 포지션이 될 거예요.

또 하나, 국내 기업들이 AI 도입을 검토하면서 보안, 컴플라이언스, 온프레미스 배포 같은 이슈가 동시에 떠오르고 있어요. 이런 영역을 잘 아는 개발자는 오히려 기회가 늘어날 수 있어요. 구체적으로는 이런 스킬이 각광받을 거예요.

• 오픈소스 LLM(예: Llama, Qwen 등)의 파인튜닝과 호스팅
• 사내 데이터를 안전하게 연결하는 RAG(Retrieval-Augmented Generation, 쉽게 말해 "AI가 우리 회사 문서를 참고해서 답하게 하는 것") 파이프라인
• AI 에이전트가 사내 시스템을 조작할 때의 권한 관리와 감사 로그

마무리: 익혀지는 건 우리가 아니라 옛날 방식일지도

"We're cooked"라는 말을 다시 한번 곱씹어볼게요. 저는 이 말이 결국 "예전 방식대로 일하던 우리는 망했다"는 의미라고 생각해요. 개발자라는 직업 자체가 사라지는 게 아니라, 개발자가 하던 일의 구성비가 바뀌는 거예요.

타이핑은 줄고, 판단은 늘어날 거예요. 혼자 파고드는 시간은 줄고, 다른 사람·다른 에이전트와 협업하는 시간이 늘어날 거예요. 문법을 외우는 건 의미가 없어지고, 문제를 정의하고 해법을 평가하는 감각이 핵심이 될 거예요.

지금 불안한 건 당연해요. 하지만 그 불안을 밈으로 소비하고 끝내기보단, 한 번쯤 진지하게 "나는 어떤 부분을 더 키울까?"를 생각해보는 계기로 삼으면 좋겠어요.

여러분께 드리는 질문

• 최근 일주일 동안 AI 도구가 당신의 작업 중 어떤 부분을 대신해줬나요? 그 시간에 당신은 무엇을 하셨나요?
• 만약 지금 주니어로 다시 시작한다면, 어떤 순서로 공부하시겠어요?
• 팀 안에서 AI 활용에 대한 가이드라인이 있나요? 없다면 누가 먼저 만들어야 할까요?