Cursor가 저를 더 빠르게 만들지만, 개발자로서의 역량을 떨어뜨리고 있을까요?
요약
AI 코딩 도구인 Cursor를 사용하며 얻는 생산성 향상과 그 과정에서 발생할 수 있는 개발 역량 저하 사이의 고민을 다룹니다. AI가 실행(execution)을 대신해 주는 시대에 개발자가 유지해야 할 핵심적인 판단력(judgment)의 중요성을 강조합니다.
핵심 포인트
- Cursor는 반복 작업과 보일러플레이트 제거를 통해 생산성을 극적으로 높임
- AI에 의존할 경우 엔지니어링 판단력을 쌓을 기회를 상실할 위험이 있음
- AI는 실행(execution)에 능숙하지만, 아키텍처와 보안 등 판단력(judgment)은 인간의 영역임
- 의도적인 사용을 위해 문제와 제약 조건을 먼저 정리하고 변경 원인을 파악해야 함
AI 코딩 도구가 없던 시절에는 소프트웨어를 구축하는 것이 종종 몇 시간을 디버깅하고, 문서를 읽고, 가정을 테스트하며, 첫 번째 접근 방식이 틀렸다는 것을 발견하는 데 드는 시간이었다.
느리고 좌절스러웠다.
하지만 그것이 제가 배우는 방법이기도 했다.
지금 저는 Cursor를 사용하고 있고, 제 개발 시간이 극적으로 줄었습니다. 이 도구는 코드를 생성하고, 프로젝트의 생소한 부분을 설명하며, 오류를 추적하고, 테스트를 작성하며, 백엔드(backend), 프론트엔드(frontend), 데이터베이스(database), 배포 작업 사이를 이동하는 것을 도와줍니다.
솔로 개발자에게는 이것이 엄청나게 가치 있습니다.
하지만 최근 저는 스스로에게 질문하기 시작했습니다:
제가 더 나은 개발자가 되고 있는 걸까요, 아니면 단지 더 좋은 도구를 가진 더 빠른 개발자가 되고 있는 걸까요?
생산성 향상은 현실적이다
Cursor는 불필요한 많은 작업을 제거합니다:
- 보일러플레이트(Boilerplate)
- 반복적인 코드
- 생소한 구문(Syntax)
- 기본 테스트(Basic tests)
- 설정(Configuration)
- 문서 초안(Documentation drafts)
- 많은 파일을 검색하는 것
저는 이 모든 것을 수동으로 다시 하고 싶지 않습니다.
문제는 AI가 과거에 엔지니어링 판단력(engineering judgment)을 쌓게 해 주었던 종류의 어려움까지 제거할 수 있다는 것입니다.
AI 이전에는 어려운 버그를 발견했을 때, 가설을 세우고, 코드를 검사하고, 가정을 테스트하며, 시스템이 예상과 다르게 작동하는 이유를 이해해야 했습니다.
이제 과정은 다음과 같아질 수 있습니다:
describe the problem
→ Receive a suggested fix
→ Apply it
...
제품은 전진하지만, 저는 무슨 일이 일어났는지 깊이 이해하지 못한 채 끝날 수도 있습니다.
모든 어려움이 가치 있는 것은 아니다
저는 개발자들이 단순히 어려움을 위해 난관을 유지할 필요는 없다고 생각합니다.
동일한 보일러플레이트를 반복해서 작성하거나 하나의 설정 옵션을 찾는 데 몇 시간을 보내는 것에는 교육적 가치가 거의 없습니다.
더 유용한 구분은 **실행(execution)**과 판단력(judgment) 사이일 수 있습니다.
AI는 실행에 매우 능숙합니다:
- 스캐폴딩(Scaffolding)
- 구문(Syntax)
- 반복적인 변환(Repetitive transformations)
- 일상적인 테스트(Routine tests)
- 문서 초안(Documentation drafts)
하지만 저는 여전히 판단력은 스스로 가져가야 합니다:
– 실제 요구사항 이해하기
– 아키텍처 선택하기
– 데이터 모델 설계하기
– 보안 위험 식별하기
– 실패 모드 생각하기
– 생성된 솔루션이 적절한지 판단하기
– 실제로 정확한지 검증하기
위험은 제가 실행(execution)만 위임한다고 믿으면서 판단력(judgment)까지 위임할 때 시작됩니다.
Cursor를 다르게 사용하려고 노력하는 방법
저는 Cursor 사용을 멈추지 않을 것입니다. 생산성 향상이 너무 크기 때문입니다.
대신, 저는 더 의도적으로 사용하려고 합니다.
중요한 기능을 구현해 달라고 요청하기 전에, 문제점(problem), 제약 조건(constraints), 데이터 흐름(data flow), 그리고 위험 요소(risks)를 글로 적어둡니다.
디버깅할 때는 때때로 수정 방법(fix)을 요청하기 전에 가능한 원인들을 먼저 물어봅니다.
의미 있는 변경 사항에 대해서는 하나의 규칙을 따르려고 노력합니다:
저는 무엇이 바뀌었는지, 왜 작동하는지, 그리고 여전히 무엇이 실패할 수 있는지 설명할 수 있어야 합니다.
또한 인증(authentication), 보안(security), 영속성(persistence), 배포(deployment)와 같은 중요한 세부 사항들을 공식 문서와 대조하여 검증합니다.
어려운 버그의 경우, AI에게 요청하기 전에 제한된 시간 동안 수동으로 조사해 봅니다. 이는 수동 디버깅이 도덕적으로 더 낫기 때문이 아니라, 여전히 가설을 세우고 테스트하는 연습을 하고 싶기 때문입니다.
경험이란 지금 무엇을 의미할까요?
AI 이전에는 경험의 일부가 우리가 개인적으로 어려움을 겪었던 문제들로부터 쌓였습니다.
AI 시대에는 더 많은 제품을 만들고 더 많은 시스템에 접하게 될 수는 있지만, 각 구현(implementation)에 깊이 관여하는 정도는 줄어들 수 있습니다.
이는 숙련된 개발자가 된다는 것이 무엇을 의미하는지 바꿀 수도 있습니다.
아마도 경험은 우리가 개인적으로 코드를 얼마나 많이 타이핑했는지보다는 다음 요소들에 더 의존하게 될 것입니다:
– 문제를 얼마나 잘 정의하는가
– 출력을 얼마나 신중하게 검증하는가
– 나쁜 솔루션을 얼마나 정확하게 인식하는가
– 기술적인 결정을 얼마나 책임감 있게 내리는가
Cursor는 저를 훨씬 빠른 개발자로 만들었습니다.
하지만 이것이 저를 더 좋은 개발자로 만들고 있는지는 아직 결정 중입니다.
지금으로서는, 그 답이 엔지니어링의 어떤 부분을 위임하지 않기로 선택하느냐에 달려 있다고 생각합니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기