우리는 더 이상 문제를 해결하지 않는다

발행: (2026년 4월 22일 AM 08:22 GMT+9)
14 분 소요
원문: Dev.to

Source: Dev.to

(번역할 텍스트가 제공되지 않았습니다. 번역이 필요한 본문을 알려주시면 도와드리겠습니다.)

개발자로서의 여정

나는 20년 동안 개발을 해왔습니다: 웹 관련 작업, 애플리케이션, 게임, 스크립트, 플러그인… 호기심이 이끄는 대로 무엇이든. 항상 나를 움직이게 했던 것은 창조였습니다 – “아무것도 없는” 상태를 내가 사용할 수 있는 무언가로 바꾸는 것.

나는 퍼즐도 좋아합니다 (대부분의 개발자들이 그렇듯). 코드를 어떻게 설계할까? 어떻게 조합할까? Y가 발생했을 때 X를 어떻게 할까? 이런 것들을 우리는 (예전엔?) 매일 했습니다.

개발에서 내가 가장 좋았던 점은 문제를 스스로 해결해 나가는 것이었습니다. 최근 들어 그 부분이 사라지고 있는 느낌이 듭니다.

내 작업 방식

나는 코드를 한 줄 쓰기 전에 어떻게 것들이 함께 작동할지를 생각하는 편이다. 경력 초기에, 계획을 세우는 것이 노트북 페이지와 형편없는 UML 다이어그램의 미로에 빠지게 만들곤 했다.

이 사고방식은 또한 나를 계속 배우게 만들었다: 새로운 기술, 새로운 언어, 현재 진행 중인 일들을 최신 상태로 유지하는 것.

  • 두 앱 사이에 메시지를 보내야 하나요? 어떤 무작위 사람이 만든 RabbitMQ 클론을 확인해 보세요 – 훌륭합니다.
  • 복잡한 좌표 거리 계산이 필요하나요? 아직 해킹당하지 않은 NPM 패키지를 약속합니다… 아직은요.
  • 한 페이지짜리 웹사이트가 필요하나요? Rust를 사용하세요: 메모리 누수가 없습니다.

나는 장난스럽게 말하는 것이지만, 배우고 흐름에 머무르는 것이 업무의 큰 부분입니다.

좋은 환경

저는 기능을 구현하기 전에 기술 사양서를 작성하도록 장려하고, 코드를 건드리기 전에 검증을 하는 회사에서 일하게 된 것이 행운이었습니다.

그 덕분에 다음을 할 수 있었습니다:

  • 생각을 정리할 수 있었습니다.
  • 동료와 설계에 대해 논의했습니다.
  • 함께 프로젝트를 개선했습니다.

또한 과도하게 작업하지 말아야 함을 배웠습니다. 고객에게는 예산이 있고, 어느 순간에는 제품을 출시해야 합니다.

요즘은 빠른 반복이 표준이 되었습니다. 항상 그랬던 것은 아니었습니다.

현재 역할

제가 더 시니어가 되면서 코드 리뷰에 많은 시간을 할애했습니다. 몇 달 전만 해도 이는 내 업무량의 3분의 1이었습니다. 또한 최신 정보를 유지하고 배운 것을 내부 뉴스레터를 통해 공유할 시간이 주어집니다 (다른 사람들이 즐기거나 메일을 버릴 수 있도록).

AI: 도구, 대체가 아니다

바로 말하자면: 나는 AI에 반대하지 않는다.

AI는 훌륭한 도구이며, 암호화 컨소시엄이 AI 브로 로비로 변신한 집단이 그것을 본래가 아닌 형태로 만들려 해도 마찬가지다.

  • 다른 사람들처럼, 나는 구글링하기 귀찮은 질문들을 ChatGPT에 묻는다.
  • 친구와 가족 사진에 구글리 아이를 달아달라고 요청하기도 했는데(구글도 할 수 있는 일이라 아쉬움이 있다), 그 과정에서 환경 비용에 약간 죄책감을 느꼈다.

시스템 구축을 즐기는 사람으로서, AI는 이미 수십 번 해결한 코드를 작성하는 데 훌륭하다. 나는 CRUD, 날짜 처리, 이메일 검증 같은 것에 신경 쓰지 않는다. 심지어 API 경로를 찾기 위해 Swagger 파일을 열고 싶지도 않다. AI가 그 일을 할 수 있다.

내가 관심 있는 것은 구성 요소들이 어떻게 맞물리는가이다.

한동안 나는 AI를 고무오리처럼 사용했다: 아이디어를 반복하고 시스템을 명확히 파악한 뒤, 에이전트를 이용해 코드를 단계별로 생성했다. 이런 설정에서는 AI가 도구일 뿐이다. 여전히 그것을 사용하는 사람은 나다.

새로운 “Agentic AI” 워크플로우

최근 우리 회사는 전체 에이전트형 AI 워크플로우를 도입했습니다. 비즈니스 분석부터 코드 리뷰까지 모든 것이 내부 도구인 AI 에이전트, 스킬, 명령 등을 통해 처리됩니다.

목표

  1. 클라이언트 요구를 받아 상세 사용 사례로 분할한다.
  2. 사용 사례를 기술 사양으로 변환한다.
  3. 사양을 구현 단계로 변환한다.
  4. 해당 단계들을 실행한다.
  5. 생성된 코드를 검토한다.

개발자에게 기대되는 역할

RoleExpected Tasks
Lead dev• 300줄짜리 사용 사례 마크다운 파일을 읽는다.
• 재프롬프트하고 커피를 마시며 AFK 상태가 된다(검증될 때까지).
Lead dev• 500줄짜리 사양을 읽는다.
• 다시 재프롬프트하고 AFK 상태가 된다(검증될 때까지).
Dev• AI에게 사양을 작업으로 나누도록 요청한다. AFK.
• AI에게 각 작업을 코딩하도록 요청한다. “next”를 입력해 완료될 때까지 반복한다. AFK.
• AI에게 리뷰하고, 수정하고, 푸시하도록 요청한다. AFK.

아내: “오늘 뭐 했어?”
나: “튜링 테스트를 통과한 LLM과의 대화에서 ‘next’만 쓰며 하루를 보냈어.”

무엇이 빠졌나요?

There is no figuring things out. No puzzle solving. One could even say there is not much thinking involved at all—just babysitting the AI.

Sure, you might step in if something looks wrong. In the first weeks of using only this workflow you will course‑correct (adjust prompts, fix output). But you don’t really engage with the problem anymore.

결과

  • 코드와의 연결이 끊깁니다.
  • 뇌가 게을러져서 문제를 놓치기 시작합니다(예: 클라이언트가 선택한 임의의 색상이 잊혀짐).
  • 코드를 적게 건드리면서 빠르게 배포하면 팀 전체가 시스템을 진정으로 이해하지 못한 채 코드를 추가하게 됩니다.
  • 한 번도 작업해보지 않은 프로젝트에 합류하면 사양은 읽지만 시스템이 전체적으로 어떻게 동작하는지는 알지 못합니다.
  • 시간이 지나면서 AI의 말을 지나치게 신뢰하게 됩니다.

Even if you have great prompting skills, you can’t fit everything into a prompt or a context window. That feature mentioned casually by the client in a meeting that will come with v2? AI wasn’t there. You were. You’re the one who can shape the system so future changes don’t break everything—at least, you used to.

The Nail in the Coffin

“우리는 더 이상 문제를 해결하지 않고, 단지 출력만 검증하고 있습니다.”

“이렇게 계속하면 우리 자신의 코드에 대해 비판적으로 생각할 능력을 잃게 될 것입니다.”

마무리 생각

AI는 놀라운 조수이지만, 우리를 개발에 빠져들게 만든 핵심 활동인 문제 해결의 즐거움을 대체해서는 안 됩니다.

우리는 균형을 찾아야 합니다—AI를 우리의 작업을 보강하는 데 사용하고, 우리를 날카롭게 만드는 퍼즐을 지우는 데 사용하지 말아야 합니다.

요약

매니저의 최근 발언 때문에 좌절감을 느끼고 있습니다:

  1. “프론트엔드 프레임워크를 배울 필요 없어; AI가 코드를 작성해줄 거야.”
  2. “인간 코드 리뷰는 구시대적이야; AI가 자동 병합할 수 있어.”

두 주장 모두 근본적으로 틀리지만, 그들이 제안하는 전반적인 워크플로우가 전혀 가치가 없는 것은 아닙니다.

왜 학습이 여전히 중요한가

  • 기술 성장: 학습은 문제 해결 능력을 날카롭게 합니다.
  • 품질 관리: 코드를 이해하면 AI가 생성한 출력물의 문제점을 발견할 수 있습니다.
  • 리뷰를 통한 학습: 코드 리뷰는 향상되는 가장 좋은 방법 중 하나입니다.

비즈니스 관점

기업의 주요 목표는 매출입니다. 더 빨리 배포되는 도구—버그가 발생하더라도—는 그 버그를 수동으로 모든 작업을 하는 것보다 빠르게 수정할 수 있는 한 매력적일 수 있습니다. 이것이 매니저의 입장이 비즈니스 관점에서 이해되는 이유입니다.

미래에 대한 질문

  • 우리가 배포하는 코드를 여전히 읽게 될까?
  • 대규모 AI 생성 코드베이스는 유지 보수가 가능할까?
  • 기능 추가가 원활할까, 아니면 끊임없는 싸움이 될까?
  • 계속 배워야 할까? 예.
  • 나는 여전히 가치를 제공하고 있는가?

개인적인 성찰

  • 에너지 상승: 새로운 워크플로우 덕분에 하루 종일 코드를 생각하지 않아도 되어 개인 프로젝트에 더 많은 에너지를 쏟을 수 있습니다.
  • 불확실성: 이것이 궁극적으로 유익한지 확신이 서지 않습니다.

요약

  • 계속 배우세요. AI 오류를 발견하고 개인 성장에 필수적입니다.
  • 효율성과 품질의 균형을 맞추세요. 빠른 출시가 가치 있지만, 유지보수성 및 지속적인 학습도 동일하게 중요합니다.
0 조회
Back to Blog

관련 글

더 보기 »

라이트, 카메라, 오픈소스!

그들은 open-source 프로젝트와 이를 유지하는 사람들이 청중에게 왜 그렇게 흥미로운 이야기가 되는지, 외부인으로서의 입장이 어떻게 이 이야기를 전달하는 데 도움이 되었는지 탐구한다.

사물에 대하여

비용 비교 다음 해에 물건을 만드는 것이 오늘 만드는 것보다 더 저렴합니다. 다음 해에 물건을 유지보수하는 것이 오늘 유지보수하는 것보다 더 저렴합니다.