AI 코딩 시대, 시스템 설계 없이 '감성코딩'하다 망하는 이유

 

누구나 만들 수 있지만, 아무나 잘 만들진 못하는 시대

요즘 AI 코딩 도구들 정말 대단하지 않나요? 프롬프트 몇 줄만 입력하면 앱이 뚝딱 나오는 시대가 왔어요. 워드프레스가 누구나 블로거로 만들었고, 유튜브가 누구나 크리에이터로 만들었다면, AI 코딩 도구는 이제 누구나 개발자로 만들어주고 있어요.

그런데 여기 함정이 하나 있어요. AI는 '돌아가게' 만드는 건 엄청 잘하는데, '잘 돌아가게' 만드는 건 별로 못한다는 거예요. 특히 진짜 제품을 만들려는 창업가나 PM들에게는 이 차이가 정말 중요하답니다.

AI는 '지금 작동'만 신경 쓴다

AI에게 기능을 만들어달라고 하면, AI는 딱 한 가지만 생각해요. 바로 '지금 당장 돌아가게 하기'죠. 그래서 설정값을 코드에 직접 박아넣거나, 나중 변경은 전혀 고려하지 않은 채 단기적 해결책만 제시하더라구요.

최근 한 사례를 보면, 누군가 러버블이라는 AI 도구로 채용 관리 시스템을 만들었는데요. 처음엔 고용 형태나 근무 위치 같은 필드 옵션들이 코드에 하드코딩되어 있었대요. 나중에 채용 공고를 올리려다 보니 선택지를 바꿀 수가 없더라는 거죠. 결국 관리자 설정 화면을 따로 만들어야 했어요.

물론 AI한테 "이건 하드코딩하지 말고 설정 가능하게 만들어줘"라고 할 수도 있어요. 하지만 그러려면 당신이 먼저 그게 하드코딩되면 안 된다는 걸 알아야 하죠. 이건 감성으로 코딩하다가 얻어지는 지식이 아니라, 경험에서 나오는 거예요.

테스트? 그게 뭐죠?

테스트 얘기를 좀 해볼까요. AI는 기본적으로 테스트 케이스나 테스트 전략 같은 걸 거의 만들지 않아요. 해피패스, 그러니까 모든 게 순조로운 경우만 커버하는 코드를 뚝딱 만들고 넘어가버리죠.

위에서 말한 채용 시스템 사례를 보면, PDF 이력서를 업로드하면 데이터를 자동으로 파싱하는 기능을 만들었대요. 몇 개 올려봤더니 어떤 건 잘 되고 어떤 건 별로더래요. 근데 도대체 뭘 어떻게 파싱하는지 알 수가 없는 거예요. 결국 'PDF 추출 테스트 도구'를 따로 만들어서 체계적으로 테스트할 수 있게 했다고 해요.

2024년 스택오버플로우 개발자 설문조사에 따르면, AI 코딩 도구를 사용하는 개발자의 약 76%가 코드 품질 검증에 여전히 어려움을 느낀다고 답했어요. AI가 만든 코드가 작동은 하는데, 제대로 작동하는지 확신하기 어렵다는 거죠.

작동은 하는데... 진짜 좋은 제품일까?

결과적으로 어떤 일이 벌어지냐면요. 겉보기엔 작동하고, 빠르게 만들어지고, 표면적인 수정도 쉬운 제품들이 쏟아져요. 하지만 테스트하기는 고통스럽고, 변경에 취약하고, 시간이 갈수록 발전시키기 비싸지는 제품들이 되는 거죠.

러버블 같은 도구는 프롬프트로 변경사항을 바로바로 반영하게 해줘요. 한 오후에 수십 번 수정하는 게 마법처럼 느껴지죠. 하지만 끝없는 프롬프트 반복과, 일관된 구조와 의도를 가진 제품을 만드는 건 완전히 다른 얘기예요.

감성코딩은 속도를 최적화하지, 튼튼한 구조를 만들진 않아요. 취미로 하는 소규모 프로젝트엔 괜찮아요. 하지만 새 집을 짓는 기초공사를 이런 식으로 하면 위험하죠.

시스템 설계는 여전히 필요하다

감성코딩이 시스템 설계를 없애주는 건 아니에요. 그냥 뒷전으로 밀어놓을 뿐이죠. 미리 구조를 생각하지 않으면, 여전히 구조는 만들어지는데 우연히, 무의식적으로 만들어지는 거예요. 그게 위험한 거죠.

시스템 설계는 제품이 시간이 지나도 제대로 버티는지에 관한 거예요. 이런 질문들을 던지는 거죠. 핵심 설정값들은 어디에 둘까? 뭘 설정 가능하게 하고 뭘 고정할까? 제품의 각 부분은 서로 어떻게 의존하고 있을까? 6개월 후 뭔가 바뀌면 어떻게 될까? 데이터 모델에 어떤 가정이 깔려 있을까?

이런 결정들은 스크린샷에 안 나타나요. 하지만 당신 제품이 유연할지 깨지기 쉬울지를 결정하죠.

AI는 이런 질문에 답하지 않고도 기능을 만들어줘요. 작동하게 만들고, 당신이 연결하라는 점들을 연결해줘요. 하지만 "이건 전역 설정으로 빼는 게 낫겠는데요?"나 "이 스키마는 나중에 마이그레이션하기 고통스러울 거예요"라고 먼저 얘기해주진 않아요. 그런 판단은 시스템을 이해하는 데서 나오는 거예요.

기능 만들기 전 꼭 물어봐야 할 5가지

이게 사람들이 가장 많이 건너뛰는 실용적인 부분이에요. AI한테 뭔가 만들어달라고 하기 전에, 잠깐 멈춰서 이 다섯 가지 질문에 답해보세요. 코드로도 프롬프트로도 아니고, 그냥 평범한 말로요.

첫째, 나중에 바뀔 가능성이 있는 건 뭘까요? 바뀔 수 있다면, 하드코딩하면 안 돼요.

둘째, 이게 한 번만 있어야 할까, 아니면 여러 곳에 있어야 할까요? 같은 값, 규칙, 개념이 여러 곳에 나타난다면 시스템이 그걸 처리할 수 있게 설계해야 해요. 한 번 만들어서 어디든 적용하는 거죠.

셋째, 진실의 원천은 뭘까요? 이게 설정에서 오는 건지, 데이터베이스인지, 사용자 입력인지, 아니면 로직 어딘가에 숨어있는 가정인지 따져봐야 해요.

넷째, 이걸 바꾸면 뭐가 깨질까요? 이 질문에 답 못 하면, 시스템은 이미 취약한 거예요.

다섯째, 이걸 어떻게 테스트할까요? 테스트가 어색하거나 수동으로만 가능하면, 시스템 설계에 문제가 있는 거예요.

완벽한 답이 필요한 건 아니에요. 질문만 던져보면 돼요. 이 다섯 가지 체크만으로도 감성코딩이 무작위 움직임에서 의도적인 진전으로 바뀐답니다.

엣지 케이스와 에러 처리, 여기서 진짜가 갈린다

감성코딩은 조용히 두 군데서 모서리를 깎아내요. 바로 엣지 케이스와 에러 처리예요.

엣지 케이스와 에러를 다루는 건 화려하지도 않고 지루한 일이에요. 자주 일어나지 않길 바라지만, 이걸 처리하는 게 프로토타입을 신뢰할 수 있는 제품으로 만드는 거죠.

감성코딩할 때는 거의 항상 해피패스만 만들게 돼요. 입력값이 깔끔하고, 가정이 맞아떨어지고, 사용자가 예상대로 행동하는 경우만요. AI는 이건 정말 잘해요.

하지만 AI는 이런 것엔 별로 관심이 없어요. 데이터가 없을 때, 입력이 잘못됐을 때, 시스템끼리 충돌할 때, 사용자가 예상 밖 행동을 할 때, 모델이 확신이 없을 때 어떻게 할지요.

간단한 예시 하나 볼까요. 존 스미스라는 사람이 시니어 디자이너 지원서를 냈는데, PDF에서 링크드인 URL을 파싱했더니 "https://"가 앞에 없어서 에러가 났대요. 짜증나는 일이죠. 이력서에 URL을 '제대로' 쓴다는 보장이 없으니까요.

더 복잡한 예시는 AI 이력서 채점 기능이에요. 좋은 이력서로만 테스트하면 좋은 점수 나오고 기분 좋죠. 하지만 정말 중요한 건 나쁜 이력서를 걸러내는 거잖아요. 그래서 엉터리 이력서로 테스트를 해봤더니, 거의 빈 이력서가 더 나은 이력서보다 높은 점수를 받더래요. 왜냐면 AI가 지역을 과도하게 중요하게 봤거든요.

가트너의 2024년 보고서에 따르면, 생성 AI로 만든 애플리케이션의 약 65%가 프로덕션 배포 후 6개월 이내에 주요 버그나 예외 처리 문제로 핫픽스를 해야 했다고 해요. 엣지 케이스를 제대로 안 다루면 이렇게 되는 거죠.

점진적으로 쌓다 보면 나쁜 구조가 드러난다

대부분의 진짜 제품은 한 방에 만들어지지 않아요. 점진적으로 만들어지죠. 뭔가 간단한 걸로 시작해요. 기본 버전의 기능, 핵심 문제를 가장 직접적으로 해결하는 MVP요.

그다음에 더 추가해요. 더 많은 기능, 옵션, 로직, 사용자, 규칙 등등. 이게 정상이에요. 제품이 실제로 진화하는 방식이죠.

그런데 감성코딩을 통한 점진적 개발에는 사람들이 과소평가하는 날카로운 모서리가 있어요. 기저의 시스템 설계를 생각하지 않았다면, 새로운 레이어를 추가할 때마다 뭔가 깨질 확률이 올라가는데, 항상 명확하게 드러나진 않아요.

예를 들어 채용 시스템에 맞춤형 질문 기능을 추가했다고 해봐요. 채용 공고마다 특정 질문을 만들 수 있는 거죠. 쉽게 만들어졌는데, 한 가지 깜빡한 게 있었어요. 이 질문들이 AI 이력서 채점에 어떻게 영향을 줄지요.

맞춤 질문을 추가할 정도면 중요한 거잖아요. 당연히 답변이 점수에 영향을 줘야 하죠. 하지만 질문 형태가 예/아니오일 수도, 객관식일 수도, 주관식일 수도 있어요. 어떤 건 필수고 어떤 건 선택이에요. 특정 질문 타입이 점수에 더 큰 영향을 줄까요?

작은 기능이나 반복 작업이 큰 영향을 미칠 때가 있어요. 미친 듯이 복잡해질 수 있죠. AI 코딩 도구는 당신이 요청하는 대로 기꺼이 해줘요. 결국 이 모든 게 제대로 된 시스템 설계, 하기 전에 생각하기, 감성코딩 전에 계획하기로 귀결돼요.

학습 곡선은 더 가파르다

여기 제가 가장 흥미롭게 보는 도전과제가 있어요.

AI 덕분에 뭔가를 만들기 시작하는 게 그 어느 때보다 쉬워졌어요. 하지만 잘 만드는 게 쉬워진 건 아니에요. 오히려 그 반대죠.

누구나 만들 수 있다면, 누구나 제품 결정을 내리는 거예요. 그런데 필요한 핵심 스킬 없이 제품 결정을 내린다면? 나쁜 제품이 많이 나오겠죠.

게다가 감성코딩할 때는 실제로 더 넓은 스킬셋이 필요해요. 제품 결정이 곧 시스템 결정이고 코드 결정이니까요. 감성코딩은 나중에 엉망이 되고 싶지 않다면 더 일찍 올바르게 해야 하고, 더 적은 사람에게 책임을 옮기는 거예요.

맥킨지의 2024년 연구에 따르면, AI 지원 개발 도구를 사용하는 팀의 생산성은 평균 35~45% 향상됐지만, 기술 부채는 오히려 28% 증가했다고 해요. 빨리 만들 수 있게 됐지만, 제대로 만드는 건 여전히 어렵다는 증거죠.

우리는 그 어느 때보다 강한 제품 판단력이 필요해요. 더 강하고 숙련된 PM들이 필요하죠. PM들은 빌더여야 해요. 단순 프로젝트 매니저가 아니라요. 그리고 이제 거의 무한대의 파워툴을 쓸 수 있어요.

모서리 안 깎고 감성코딩하는 법

하면 좋은 것들부터 말씀드릴게요.

프롬프트 하기 전에 시스템을 설계하세요. 대충이라도 시스템 스케치가 있는 게 AI가 아키텍처를 발명하게 두는 것보다 낫습니다. 바뀔 수 있는 건 다 밖으로 빼세요. "나중에 고칠 것 같은데"라는 생각이 든다면 하드코딩하지 마세요.

기능은 진화한다고 가정하세요. MVP는 끝이 아니라 시작점이에요. 확장을 염두에 두고 설계하세요. 불행한 경로를 테스트하세요. 엣지 케이스, 잘못된 입력, 애매함, 실패 모드가 진짜 제품이 깨지는 곳이에요. 시스템이 뭘 하는지 이해하는 도구를 만드세요. 왜 그런 일이 일어났는지 설명 못 하면, 통제하지 못하는 거예요.

반대로 하면 안 되는 것들도 있어요.

해피패스를 믿지 마세요. "한 번 됐다"는 "된다"와 다릅니다. AI가 기본값을 정하게 두지 마세요. AI는 자신 있게 빈칸을 채우지, 정확하게 채우진 않아요. 빠르다고 로직을 중복시키지 마세요. 오늘의 반복은 내일의 취약성이에요.

반복을 아키텍처로 착각하지 마세요. 프롬프트를 더 많이 한다고 더 나은 구조가 되진 않아요. 하위 호환성을 무시하지 마세요. 어제 데이터를 깨뜨리는 게 오늘 기능을 싫어하게 되는 가장 빠른 방법이에요.

AI 코딩 도구가 누구나 개발자로 만들어주는 시대가 왔지만, 잘 만드는 건 여전히 어려워요. 감성코딩은 빠르지만 시스템 설계 없이는 위험해요. 진짜 제품을 만들려면 엣지 케이스를 생각하고, 테스트 가능하게 설계하고, 변경을 염두에 두고, 점진적 개발에 대비해야 해요. AI는 강력한 도구지만, 판단과 설계는 여전히 사람의 몫이랍니다. AI가 훨씬 더 많은 사람을 제품 빌더로 만들어주는 건 대단한 일이에요. 하지만 장기적으로 성공하는 빌더는 AI와 기본적이면서도 핵심적인 제품 관리 규율을 함께 활용하는 사람들일 거예요. AI는 파워툴이에요. 파워툴은 장인정신을 없애주지 않아요. 장인정신의 부재를 처벌할 뿐이죠.