나는 AI가 아니라 인간이다

AI를 어떻게 사용하고 있나요?

돌아보면 그동안 AI가 작성해준 코드를 제대로 이해하지 못한 채 조합하며 개발했던 순간들이 많았습니다. 기능은 동작했지만 왜 이렇게 작성됐는지, 어떤 구조가 더 좋은지 고민조차 해보지 않았습니다. 

하지만 최근에 기본부터 다시 공부하며 의식적으로 코드를 작성하고 있는데요, 

그러다보니 자연스럽게 AI를 어떻게 활용해야 하는지에 대한 고민이 생기게 되었습니다. 

---

AI로 작업 속도가 빨라지다 보니 자연스럽게 이런 생각이 들었습니다. 

이제 개발이 빨라지면 더 일찍 끝나겠지?

 

실제로 계산해보면 좀 다른데요, AI로 코딩 생산성이 100% 향상됐다고 해도, 서비스 개발에서 코딩이 차지하는 비중은 생각보다 훨씬 낮습니다. 기획, 설계, 테스트, 커뮤니케이션, 코드 리뷰까지 다 포함하면 코딩 비중이 50%도 안 되는 경우가 많습니다. 그 50%에서 생산성이 두 배가 돼도 전체 일정에서 줄어드는 시간은 고작 25%인 거죠.

오히려 개발이 빨라지면 더 많은 코드를 만들고, 더 많은 리뷰를 요청하고, 커뮤니케이션도 더 늘어나게됩니다. AI 도입 이후 이전보다 훨씬 바빠졌다는 말이 나오는 이유가 이거죠.

AI는 시간을 단축시켜주는 도구가 아니라, 더 중요한 일에 집중할 시간을 만들어주는 도구인 거죠. 

그래서 저는 내가 특정 변수를 저장하는 로직을 어디에 두었는지와 같이 중요하지 않은 일을 AI를 사용하곤 합니다. 

 

스펙코딩

저는 처음 AI를 쓸 때 별 생각 없이 물어보고 시키는 방식으로 시작했습니다. 이게 바이브 코딩인데, 느낌 가는 대로 프롬프트를 던지고 나온 결과를 붙여넣는 식이에요.

이 방식에는 한계가 있습니다. 대규모 트래픽을 감당하는 아키텍처를 설계하거나 복잡한 시스템을 개발하는 건 프롬프트 하나로 해결이 안 돼요. AI가 내놓는 여러 답변 중 뭐가 최선인지 판단하려면, 그 도메인에 대한 이해가 먼저 있어야 하거든요.

더 좋은 방식은 스펙 코딩입니다. 요구사항 스펙을 먼저 정의하고, 그걸 기반으로 AI와 협업합니다. 요구사항 정의서, 도메인 엔티티, 비즈니스 규칙까지 설계 문서가 먼저 잡혀있으면 AI와의 대화가 훨씬 정확하고 깊어지게됩니다. 결과에 대한 피드백보다, 과정에 대한 피드백을 통해 더 좋은 프롬프트를 만들어가는 게 핵심인 거죠.

 

AI를 잘 쓰는 사람들은?

역할을 명확하게 나눕니다. 

분석: AI + 사람
판단: 사람
실행: AI의 도움을 받은 사람

 

 

AI가 정리해준 분석 결과를 그대로 실행하지 않고 분석을 바탕으로 뭘 먼저 해야 하는지, 어디가 리스크인지 판단한 다음에 명확한 의도를 담아 AI에게 요청합니다. 

그걸 어케함... 

→ 코드 분석할 때 이런 질문을 던져보세요! 

 

• 이 코드는 어떤 역할을 담당하는가
• 어떤 비즈니스 흐름의 일부인가
• 변경 시 영향 범위는 어디까지인가
• 외부 시스템과의 접점은 무엇인가

 

 

누가 내 코드에 대해서 물어봤을 때 답할 수 있으려면 어떤 기준으로 분석했는지 계속 생각하는 습관을 들여야하는 것 같습니다. 

 

흐름을 이해하자 

 

시작 지점: 요청 또는 이벤트는 어디서 시작되는가
종료 지점: 처리 흐름은 어디에서 끝나는가
Flow 시퀀스: 그 사이에서 어떤 순서와 조건으로 흐르는가

 

이 세 가지를 기준으로 시스템을 시퀀스 형태로 정리하면, 코드를 그냥 읽는 게 아니라 전체 흐름을 한 번에 이해할 수 있습니다. 특히 기존 시스템을 수정해야 할 때 어디를 바꿔야 하고, 어디는 그대로 두어야 하는지 판단할 때 도움이 되는 거죠.

 

클린 코드 원칙

단일 책임 원칙(SRP):

- 함수는 한 가지 책임만 가지기

- 레이어 분리, 추상화, 의존성 관리 같은 설계 원칙

 

추상화의 내려가기 규칙(Stepdown rule)

- n 단계의 추상적인 함수는 n-1 단계의 함수로 구성

- 함수 이름은 내려갈수록 구체적으로, 변수 이름은 내려갈수록 추상적으로

 

주석

사실 저는 주석을 최대한 자세하게 다는 게 좋다고 생각했었는데요, 코드 리뷰를 하다 보니 주석 하나 없어도 흐름이 바로 읽히는 코드를 보면서 아.. 주석은 정말정말 필요할 때만 달자 생각했습니다. 물론 이해 안 되는 코드보다는 주석이 많은 코드가 낫긴 하지만, 진짜 좋은 코드는 코드 자체가 스스로를 설명할 수 있어야 하는 것 같습니다. 주석은 TODO, 외적인 맥락, 제한사항처럼 코드로 표현할 수 없는 부분에만 최소한으로 씁시다!

 

 

간단히 정리해볼까요? 

버릴 것과 가져갈 것 

버릴 것

 

• 모든 로직을 명시적으로 작성해야 한다는 강박
• 모든 예외 상황을 미리 정의하려는 시도 (반복적이거나 정형화된 작업은 AI의 도움을 받기) 
• AI를 그저 똑똑한 자동완성 정도로만 보는 시각 (코드 분석, 구조 제안, 리팩토링 방향 제시까지 함께 고민)

 

 

가져갈 것

 

• 레이어 분리, 단일 책임 원칙, 추상화 (구조가 명확할수록 정확하게 분석 가능)
• 의존성 관리, 인터페이스 설계
• 테스트 가능성, 디버깅 전략
• 코드 리뷰, 점진적 개선

결국 기본기가 있는 사람이 AI를 잘 쓰는 것 같습니다. AI에게 다 맡기는 것이 아니라, 내가 완전히 컨트롤할 수 있는 범위 내에서 문제를 쪼개 질문하고 활용해야 합니다.

아래 두 가지 역량을 가집시다!

기술 도메인 전문성: 문제의 본질을 꿰뚫는 날카로운 질문과 비판적 사고. 

AI 협업 마인드: AI에만 의지하거나 AI를 무조건 배척하지 않고, AI의 능력과 한계를 명확히 이해하며 지속적인 피드백으로 시너지 만들기

 

 

너무 대체한다고만 생각하지 말고(그럼 우울하니까...) 제대로 잘 쓰자! 

 

 

---

참고

https://velog.io/@tnalxmsk/AI-%EC%8B%9C%EB%8C%80-%ED%94%84%EB%A1%A0%ED%8A%B8%EC%97%94%EB%93%9C-%EA%B0%9C%EB%B0%9C%EC%9E%90

AI 시대 프론트엔드 개발자

https://boostcamp.connect.or.kr/insight/expert/ai-dev

AI 시대 개발자에게 필요한 것 — 경험, 훈련, 그리고 함께 바뀌는 조직 | boostcamp

https://techblog.musinsa.com/%EA%B0%9C%EB%B0%9C%EC%9E%90%EB%8A%94-%EB%8D%94-%EC%9D%B4%EC%83%81-%EC%BD%94%EB%93%9C%EB%A5%BC-%EC%A7%9C%EB%8A%94-%EC%82%AC%EB%9E%8C%EC%9D%B4-%EC%95%84%EB%8B%99%EB%8B%88%EB%8B%A4-7bbca700a8d7

개발자는 더 이상 코드를 짜는 사람이 아닙니다

https://tech.kakao.com/posts/735

AI 시대를 살아갈 개발자들에게 - tech.kakao.com

https://medium.com/naver-cloud-platform/%EB%84%A4%EC%9D%B4%EB%B2%84%ED%81%B4%EB%9D%BC%EC%9A%B0%EB%93%9C-%EA%B0%9C%EB%B0%9C%EC%9E%90-%EC%8A%A4%ED%86%A0%EB%A6%AC-%EC%A2%8B%EC%9D%80-%EC%BD%94%EB%93%9C%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%BC%EA%B9%8C-%ED%81%B4%EB%A6%B0%EC%BD%94%EB%93%9C-%EC%9D%B4%EC%95%BC%EA%B8%B0-c7811f73a46b

[네이버클라우드 개발자 스토리] 좋은 코드란 무엇일까?🤔 #클린코드 이야기