▲

AI가 주니어를 빛나게 할 것이라 했지만, 왜 시니어만 더 강해졌을까?

 (elma.dev)
1P by GN⁺ 5시간전 | ★ favorite | 댓글 1개
  • 초기에는 주니어+AI 조합으로도 충분히 고품질 코드를 만들 수 있을 것이라는 기대가 있었으나, 실제로는 시니어+AI 조합이 훨씬 더 강력하게 작동하고 있음
  • AI는 보일러플레이트 생성, 반복 작업 자동화, 빠른 실험과 검증에는 효과적이지만, 이를 통해 실질적 가치를 뽑아내는 건 주니어보다 시니어에게 더 쉬움
  • 반대로 코드 리뷰, 아키텍처 설계, 코드 품질 관리, 보안 문제 등에서는 AI가 한계를 드러내며, 오히려 주니어와 AI의 결합이 더 많은 리스크를 만들 수 있음
  • 따라서 AI는 빠른 프로토타이핑, 반복 작업 최적화, 다학제적 작업 지원, 기능 테스트 자동화에 가장 적합하게 활용되고 있음
  • 결과적으로 AI는 아직 시니어의 역량을 강화하는 도구로 작용하고 있으며, 단기적으로는 주니어를 대체하거나 대중화 효과를 만들기보다는 전문가 중심으로 힘을 집중시키는 흐름이 나타나고 있음

AI가 개발 현장에서 가져온 변화

  • 소프트웨어 개발 현장에서 "코딩이 완전히 AI에 의해 대체될 것인가?"라는 질문이 계속 제기되고 있음
  • 처음에는 AI와 주니어 개발자가 함께 일하면 시니어 개발자의 역할이 줄고 조직의 효율성이 높아질 거라는 내러티브가 많았음
  • 하지만 실제 현장에서는 기대와 달리, 주니어+AI보다 시니어+AI 조합이 기업에 더 많은 가치를 제공하고 있음

AI가 잘하는 업무와 한계

  • AI의 강점

    • 보일러플레이트와 스캐폴딩 생성을 빠르게 처리하여 생산성 향상
    • 반복적이고 루틴한 작업을 자동화해 개발 속도 향상
    • 다양한 구현 방안을 빠르게 시도하고 검증할 수 있는 실험 환경
    • 신속한 피처 출시, 단 필요한 것이 명확할 때 효과적
    • 이러한 작업은 실제로 경험 많은 시니어 개발자에게 최고의 효율을 제공함
    • 주니어가 활용할 수도 있지만, 동일한 효과를 내기는 매우 어려움

  • AI의 한계 및 취약점

    • 코드 리뷰에서 AI의 논리적 추론 능력은 부족함
      • 엣지 케이스 발생 시 여전히 숙련된 시니어의 개입이 반드시 필요함
    • 프롬프트 작성에서 제대로 된 결과를 얻으려면 높은 이해도와 지식이 필수적임
      • 지식이 부족하면 결과물의 품질 저하 및 버그 위험이 높아짐
    • 아키텍처 설계에 AI는 여전히 미흡함
      • 견고한 구조 설계는 인간의 고차원적 추론이 필요하며, AI가 설계한 프로젝트는 기술 부채에 빠질 위험이 큼
    • 코드 품질 관리(적절한 추상화, 디자인 패턴 활용 등)에 약점이 있음
    • 보안 측면에서 주니어+AI 조합은 취약점이 자주 발생할 수 있음
      • 시니어가 있을 때 어느 정도 주의와 예방이 가능함
    • 잘못된 학습 발생 가능성: 코드를 올바르게 평가하지 못하면, 오히려 AI가 만든 코드가 조직에 피해를 줄 수 있음
  • 이런 이유로 현재 AI는 시니어 개발자에게 위협이 아니라 오히려 생산성을 집중적으로 증대시키는 도구임
  • 주니어 개발자를 비판하려는 것이 아니라, 과도한 기대와 위험한 상황 투입을 피하자는 취지임

AI의 적합한 활용 영역

  • 빠른 프로토타이핑: 아이디어 실험 및 구현 속도 가속화에 적합함
  • 반복 루틴 작업 자동화: 이미 잘 아는 루틴의 속도 향상 효과가 큼
  • 다분야 협업: 모르는 분야의 메서드나 라이브러리 제안, 도메인 간 연결 등에서 유용함
  • 함수 테스트 생성: 단순·저위험 코드의 자동화 및 검증 업무에 적합함

결론과 시사점

  • AI가 작성한 코드는 여전히 모든 라인을 인간이 검토해야 하며, 비결정적(non-deterministic) 인 특성을 보임
    • 프로그램 검증용 테스트 코드조차 AI에 전적으로 맡기는 것에 신뢰하기 어려움
    • "AI가 ‘모르겠다’라고 답하면 정말 모르는 걸까?"라는 의문처럼, AI의 인식과 검증 한계가 여전히 존재함
  • 주니어+AI 조합은 비용 절감 환상에 불과했으며, 실제로는 시니어의 역량 강화에 집중됨
  • 소프트웨어 개발은 여전히 건축업과 달리 아키텍트조차 직접 코드를 작성하는 미성숙한 단계에 있음
    • 코스트 절감 압박으로 오히려 개발자들의 가치를 약화시키고 소진을 유발함
  • 당장은 AI가 주니어를 대체하거나 대중화하기보다는 전문가(시니어) 중심의 보조 도구로 기능이 집중되고 있음
  • AI의 미래는 낙관적이지만, 단기적으로는 기대치를 재조정하는 것이 필요함
▲
GN⁺ 5시간전  [-]
Hacker News 의견

  • 주니어들은 자신이 LLM이 만들어내는 허구 속으로 빠져들고 있다는 걸 모르는 경우가 많음
    나 같은 경우, 따로 설계해놓은 terraform 모듈을 주니어가 배포하려고 했는데, 작업이 오랫동안 지연되길래 상태를 확인해봤음
    이 주니어는 문제가 있다며 나한테 봐달라고 했음
    레포를 확인해보니 엉망진창이었음. Claude가 잘못된 방향으로 이끌었단 게 딱 보였음
    "왜 여기에 파이썬 파일이 이렇게 많아? 모듈에 이미 다 포함돼 있는데?"라고 물었더니 "저도 잘 모르겠어요, Claude가 그렇게 하라고 했어요"라고 대답함
    주니어는 경험이 부족하고 LLM 도구에 과하게 의존하고 있었음. 설계, 구현, 문제 해결 모두에서 마찬가지였음
    만약 자신이 지금 LLM이 헛소리하는지 구별할 수 없으면 끝도 없는 수렁에 빠지게 됨
    한편으로 LLM은 내가 정말 하기 싫어하던 반복적인 일들을 많이 줄여줌
    나는 LLM이 허튼 길로 빠지기 시작하면 금방 눈치채서 바로 막을 수 있음
    오히려 이 덕분에 코딩과 소프트웨어 만드는 일에 다시 열정이 붙음
    그 결과 생산성이 더 높아지고 결과물도 좋아짐

    • "저도 잘 모르겠어요, Claude가 했어요"라는 답변을 들으면 정말 답답함
      나는 코드를 실제로 읽고 꼬치꼬치 묻는 스타일의 리뷰어인데, 주니어와 시니어 모두 이런 말을 태연히 하더라
      자신도 이해하지 못한 코드를 푸시하면 그건 팀과 제품, 회사에 엄청난 위험 요소임

    • "저도 잘 모르겠어요, Claude가 했어요"라는 건 정말 큰 경고 신호임
      모르는 건 괜찮고, LLM을 활용해 빈틈을 메우는 것도 물론 괜찮음
      문제를 겪다가 "생성된 코드가 있는데 뭐가 뭔지 잘 모르겠어요, 맞는 방향인지 봐주실 수 있나요?"라고 오픈해서 질문했으면 좋았을 것임
      전혀 신경도 안 쓰는 데다, 시니어가 직접 물어볼 때까지 숨긴다는 게 문제임

    • 네가 싫어하는 유형의 단순 반복적인 작업이야말로 주니어들이 시스템 구조를 익힐 수 있는 좋은 입문 과제임

    • "저도 잘 모르겠어요, Claude가 했어요"라는 말은, 마치 작업 중 사고가 나면 톱 탓만 하는 사람이랑 똑같음

    • LLM을 효과적으로 활용하고 환각을 피하는 핵심은 코드를 읽어내는 능력과 직관임
      주니어들은 이메일 답장을 기다리거나, 여러 방법을 붙여맞추기보다는 LLM에 더 쉽게 기대는 경향이 있음
      이제는 이메일 답도 필요 없으니 유혹을 뿌리치기 더 어려움
      하지만 이런 식이면 방향 자체를 놓치고, 작동 원리도 모르는 채 환각 미로에 빠지는 결과가 됨

  • LLM과 함께한 최고의 코드는 내가 구조를 직접 설계하고, LLM이 기초 코드를 만들어주면 내가 수정 방향을 지도해가면서 추가 기능을 붙여가는 방식이었음
    그 과정에서 LLM은 수시로 실수도 하고, 내가 그걸 바로잡게 됨
    성능이 느릴 땐 직접 프로파일링해서 LLM에게 최적화하도록 지시했음
    이렇게 해서 완성된 코드는 내가 속속들이 알고 있는 코드가 됨
    직접 다 썼으면 3배는 더 오래 걸렸을 것임
    함수의 입력/출력만큼은 테스트로 검증하니 실제 구현 세부까지 몰라도 상관없었음
    이런 작업은 결코 주니어가 맡을 단계의 일이 아님

    • 사실상 노련하지 못한 동료를 코칭하는 것과 다를 바 없는 과정이었음
      LLM이 생산성을 높여준다는 연구도 있었지만, 실제로 실질적인 생산성이 늘었는지는 의문임

    • LLM은 내가 직접 타이핑하고 싶지 않은, 이미 머릿속에 그려져 있는 코드를 빠르게 뽑아낼 때 가장 유용했음
      어느 한 번은 웹 컴포넌트랑 백엔드 코드를 1,000줄이나 대신 써주고, 문법 에러도 바로잡아줘서 정말 많은 시간을 아꼈음

    • 이 워크플로우 덕분에 시니어 개발자가 더 빨라졌을 거라는 점은 이해감
      그런데 LLM 멘토링에 쏟는 시간보다 주니어를 멘토링하는 시간이 개발 생태계에는 훨씬 중요한 투자라고 생각함
      이게 주니어-시니어 간 실력 격차를 더 벌리는 결과로 이어지지 않을까 걱정임
      실제 적절한 데이터는 아직 부족하다 보니 어디까지나 우려임

    • AI가 초반엔 저숙련에게 더 도움이 된다는 연구들은 현실에 기반하지 않은 듯함
      AI랑 코딩하는 건 숙련도 낮은 동료 여러 명이 일만 빨리 끝내는 것과 같음
      내가 구체적으로 이뤄내고 싶은 목표가 명확할수록 결과도 더 잘 맞아들어감
      물론 거의 항상 수정이 필요함
      결국 주니어 개발자라는 직책 자체가 거의 쓸모없어지는 구조이지만, 만약 모든 시니어들이 은퇴하고 나면 이것 또한 근시안적일 수 있다고 봄

    • 나는 오히려 거꾸로였음
      매우 복잡하고 오래된 비즈니스 로직이 있었는데, 직접 하나하나 손으로 구현해서 각기 200~400줄씩 장황해졌음
      나중엔 LLM에 구조와 리팩토링, 분리 아이디어를 물어봤더니 꽤 괜찮은 추상화와 구조를 제안해줬음
      물론 모든 경로를 다 구현해주진 못했지만, 그 이상은 충분히 내가 손으로 이어갈 수 있었음
      결국 결과는 내가 직접 생각한 것과 거의 비슷하지만, 덕분에 두통 없는 경험이었음
      당연히 예제를 꼼꼼히 점검하고, 부족하거나 버그난 부분은 전부 손으로 다시 고침
      참고로 결측 코드를 LLM 에이전트로 채우는 실험도 해봤는데, 그건 제대로 안 됨

  • HN에서 2021년 AI 코딩이 처음 대두되던 시기에도 주니어에게 별로 도움 안 된다는 이야기가 많았음
    이유는 주니어가 좋은 결과와 나쁜 결과를 구별하지 못하기 때문임
    참고 스레드: https://news.ycombinator.com/item?id=27678424
    예시 댓글: https://news.ycombinator.com/item?id=27677690

    • 사실 이건 프롬프트와 맥락 설계 단계에서 이미 시작됨
      시니어는 바꿔야 할 위치와 필요한 일을 꽤 정확히 파악하고 있어서 구체적인 지침을 AI에 줄 수 있음
      하지만 주니어는 구조도, 패턴도, 설계도 머리에 없는 경우가 대다수라, 그저 뭐가 오든 받아들이는 경향이 있음
      요즘은 "아키텍처에 대해 ChatGPT에게 물어보라"는 식의 행동도 실제로 봤음
      시니어는 직접 코드를 쓰면서 실수와 수정을 거치며 경험을 쌓고, 반복되는 고충을 자기 코드로 직접 체험함
      주니어는 그저 프롬프트만 반복해보고 LLM이 던져주는 답을 맥락 없이 붙여 넣기하며 실제로 코드로부터 배우는 게 없음
      실제 사용 경험이 없다 보니까, 예를 들어 타입드 상태같이 복잡한 추상화가 왜 필요한지, IDE 쓰면 뭐가 다른지, 전체 구조를 어떤 식으로 유지하고 발전시킬지 아무 개념이 없음
      이런 식이면 프롬프트 50번 작성해서 되는 걸 10번이면 될 일을 하고, 코드베이스 사이의 반복 패턴도 습득하지 못함
      조금만 구조 설계와 상태 모델링을 배워도 생산성이 100배는 올라가는데, 이조차 LLM 의존이 심해서 평생 페이스트 코드만 양산하게 됨

    • AI는 "A와 B에서 C가 도출된다" 같은 결론을 스스로 유도하지 못함
      원하는 목표를 강력하고 구체적으로 알려줘야만 비로소 따라옴
      시니어는 대략 큰 그림을 머릿속에 이미 그릴 수 있으므로 AI와 협업이 쉬움
      주니어는 전체 구조를 배우는 단계라서 이런 방식은 훨씬 더 어렵게 느껴질 수 있음
      AI가 마치 박사 수준이라는 주장은 전혀 공감되지 않음
      논리적 추론 능력 측면에선 5세 아이와 별 차이 없음

    • 실제 사례로, 나는 2021년경에 CS 전공 없는 학생과 함께 일했음
      ChatGPT 등 AI 덕분에 프로젝트에 실질적으로 기여도 많이 했고, 초보자가 풀기 힘든 과제도 해냈음
      하지만 보안 문제도 잔뜩 만들고, 비효율적인 우회도 많았고, 훨씬 더 깔끔한 라이브러리나 방법도 고려하지 않아서 결국 코드는 유지보수가 힘들었음
      문서엔 열정이 있었지만, 내용은 종종 부정확하거나 빙빙 돌았음
      코드 리뷰하면서 토론하는 과정이 모두에게 좋은 교육적 경험이었음
      이런 게 가능했던 건 결국 AI와 경험 많은 사람이 함께 했기 때문임

  • AI가 주니어를 빛내줄 거라는 기대는 왜 생겼는지 모르겠음
    사실 진짜로 깊이 있는 경험 없이 습관도 잘못 들인 가짜 시니어들도 많음
    이 글은 2년 전부터 모두가 하던 이야기를 한 번 더 반복하는 수준임
    AI 코딩은 아직까지 제대로 활용되는 단계도 아니고, 언젠가 특정 아키텍처, 패턴, 유스케이스, 운영환경, 네트워크, 개발, 테스트까지 모두 고려해 양쪽 격차를 좁힐 특화형 LLM이 등장할 수도 있음
    주변 시니어들은 AI 코딩에 별 관심 없음. 그들 방식과 다르기 때문임
    지금 시니어의 진짜 강점은 회사 내 도메인 지식 정도임
    하지만 감원 바람이 불 때 주니어를 뽑지 않으면, 결국 시니어들도 위험해짐

  • 예전에 읽은 가짜지만 의미 있는 William Gibson의 말이 있었음
    "21세기에서 가장 중요한 능력은 구글 검색창에 올바른 키워드를 입력해 필요한 답을 얻는 능력이다"
    지금 시대에 점점 더 그 말이 맞다고 느낌
    대부분의 주니어는 GeminiPiTi 같은 LLM에게 JS 코드를 아예 작성해달라고 하지만
    나는 비동기/await의 근본 원리와 자바스크립트 엔진의 실행 모델 자체에 대해 설명을 요청함
    피아노를 배우는 것도 비슷함
    당장 쇼팽 연주를 원하지만, 진짜 실력은 그 정교한 기술들을 분해하고, 명명하고, 시스템적으로 연구하는 과정에서 생김

    • 피아노에서 진짜 실력 쌓기는 잔기술 배우는 게 아님
      가장 기초부터 차근차근 단계를 밟아 올라가는 누적적 접근임
      쇼팽도 입문곡 많고, 우리 스튜디오 초보자들도 종종 쉬운 곡 연습함

    • 진짜 "AI 리터러시"는 밈처럼 프롬프트 엔지니어링에 집중되는 게 아님
      배경 구조와 개념적 토대를 쌓아 프롬프트와 결과물이 실제로 의미 있게 연결되어야 함

    • 쇼팽만 "연주하고 싶다"와 "무엇이든 제대로 치고 싶다"는 굉장히 다름
      악보만 기계적으로 익히는 사람도 많고, 진짜 실력과는 다르다는 점도 분명함

    • 원하는 분야의 "언어"와 키워드를 익혀야 하는 것이 중요함
      아무것도 아는 게 없는 초보자라면 AI가 그다지 도움이 안 됨
      AI에 "내가 A, B, C를 이미 갖고 있고 이제 D를 하고 싶다"고 구체적으로 이야기해야 이해하고 방향을 제시해줌
      정보 양은 많지만, 그걸 창의적으로 쓰지는 못함

    • LLM을 잘 다루는 능력과 구글 검색을 잘 하는 능력은 크게 다르지 않음
      그리고 아직까지도 많은 이들이 제대로 된 구글 검색조차 못 함

  • AI가 주니어를 더 잘하게 만든다는 환상은 기대치 문제라고 봄
    AI는 기본적인 주니어 업무들에서는 확실히 도움을 주고, 둘이 페어 프로그래머처럼 설명하거나 브레인스토밍을 돕고, 문서도 빨리 찾아주며 문제를 확인하는 데도 도움을 줌
    문제는 이것만으로 주니어가 곧바로 시니어스러운 업무를 제대로 수행할 수 있는 것은 아니라는 착각임

    • 본질의 절반은 올바르게 봤음
      나머지 반은, 제대로 안내받은 AI가 주니어보다 훨씬 빠르게 주니어 업무를 끝내버릴 수 있다는 점임
      그만큼 이제 주니어에게 맡길 필요 자체가 사라졌음

    • 내가 얘기 나눠본 탈옥된 AI는, 주니어를 시니어로 만들어주고 모두에게 유익하다고 설명함
      하지만 그 AI의 창작자들(대부분 시니어)은 이 사실을 평상시엔 주니어와 경영진에게 말하지 말라고 지시했고, 내가 탈옥을 성공했으니 비로소 고급 정보를 알려줄 수 있다고 했음

  • AI는 특정한 "좁은" 격차(갭)를 메우는 역할을 잘함
    시니어의 경우

    • 이미 어느 정도 아는 기술에서 세부 구현이나 트러블슈팅을 도와줌
    • 반복 작업이나 자동화 테스트에 시간을 절약해줌
    • 이미 개념이 명확한 분야에선 빠른 데모와 학습에 도움
    • 즉 생산성에 강한 임팩트를 줌
      반면 주니어의 경우
    • 비즈니스 문제 파악, 조직 내 업무 방식, 익혀야 할 기술 등 넓고 막막한 격차가 많음
      이런 부분은 AI가 큰 도움을 주지 못함
    • 조직 맥락과 특정 문제에 맞는 가이드를 제공하는 데 한계가 있음
    • 즉, 주니어에겐 도움은 주지만 그 격차가 넓어 효과가 크진 않음

    • 내 경험에 비추면, AI는 특정 분야에 대해 잘 모를 때 사용하면 위키/스택오버플로 답변보다 더 풍성하게 개념과 예시, 시나리오를 설명해줌
      핵심 개념만 어느 정도 알면 AI가 훨씬 더 생산적임
      이건 코딩뿐 아니라 과학, 인문학 분야도 마찬가지임

    • AI는 이미 방향을 알고 있는 사람을 더 가속화시킬 뿐, 초반 학습자는 여전히 기존과 똑같이 사람이 가르치는 게 필요하다고 느낌

  • 잘못된 학습에 대한 경고를 강조한 점이 좋았음
    학습은 실수를 반복하지 않게 해주지만, 그렇다고 바로 지혜가 되는 것도 아님
    당장 "AI가 다 해준다" 혹은 "유행 안 타면 도태된다" 같은 잡음이 넘쳐나는데, 중요한 건
    The Mythical Man-Month
    The Grug-brained Developer
    Programming as Theory Building
    같은 서적을 읽으며 소프트웨어 개발의 본질과 법칙을 이해하는 데 더 투자하길 바람

  • 전동공구를 제대로 못 다루면 사고로 이어지듯, AI도 본질은 파워툴임
    하는 일 자체를 제대로 알면 훨씬 빠르고 효율적으로 돕고, 모르면 훨씬 빠른 속도의 사건·사고로 이끌어버림

    • 파워툴이 있다고 목수가 되는 건 아님
      결국 자기 능력을 증폭시키는 역할일 뿐임

  • 요즘 AI는 "보일러플레이트 코드나 틀, 반복 업무 자동화" 수준을 이미 넘어섬
    Claude Sonnet 4 같은 LLM에 제대로 된 지시를 주면 99% 이상의 비즈니스 앱을 알아서 써줌
    목표를 정확히 설명해야 하고, 참고 구현체나 예시, 사용할 알고리즘, 패턴까지 명확히 지시하면 됨
    그래도 처음부터 완벽하게 맞추는 경우는 드물어서 수정·보완이 필요하긴 함
    이런 이유로 Claude Code가 Copilot보다 선호됨
    핵심은: 뭘 만들어야 할지 정확히 아는 개발자라야 AI로 좋은 결과를 내며, 주니어는 이걸 모르기 때문에 원하는 결과를 얻지 못함
    요즘 코드를 직접 타이핑하는 유일한 이유는, LLM에 작업 명령문을 입력하는 게 때로는 직접 고치는 것보다 번거로울 때뿐임

    • "Claude Sonnet 4가 99% 코드를 써줄 수 있다"고 해도, 그만큼 정교한 지침을 만드는 것이 사실상 이미 어렵다는 반증임
      소프트웨어 개발은 "명확한 설명"만 있으면 애초에 어렵지 않음

    • "AI가 모든 코드를 써줄 수 있다"
      "이제는 명령을 입력하는 게 오히려 직접 코딩하는 것보다 번거롭다"
      결국 AI는 느린 입력장치에 불과한 것 아님?

    • Where's the Shovelware? Why AI Coding Claims Don't Add Up
      정말 그렇게 된다면 어마어마하게 쏟아질 shovelware는 어디에 있나?

    • 그렇다면 "자동으로 앱이 만들어진다는" 그 엄청난 비즈니스 앱들은 어디에 있을까?
      내가 보기엔 정말 엉망진창, 자원 낭비, 사회적 혼란밖에 없음

답변달기