| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | |||||
| 3 | 4 | 5 | 6 | 7 | 8 | 9 |
| 10 | 11 | 12 | 13 | 14 | 15 | 16 |
| 17 | 18 | 19 | 20 | 21 | 22 | 23 |
| 24 | 25 | 26 | 27 | 28 | 29 | 30 |
| 31 |
- 무료 오라클 설치
- 윈도우 Oracle
- ORA-12899
- 오라클 캐릭터셋 변경
- Oracle Express Edition
- oracle 18c
- Oracle 사용자명
- 오라클 캐릭터셋 조회
- Oracle 18c HR
- Oracle 초기 사용자
- 서평단
- Oracle 18c HR schema
- Oracle 사용자명 입력
- ora-01722
- ORA-00922
- 무료 오라클 데이터베이스
- 오라클 캐릭터셋 확인
- Oracle 18c 설치
- Oracle 윈도우 설치
- Oracle 테이블 띄어쓰기
- Orace 18c
- oracle
- Oracle 테이블 대소문자
- 비전공자를 위한 데이터베이스 입문
- Today
- Total
The Nirsa Way
AI 시대, 왜 소프트웨어 기본기가 더 중요해졌는가? 본문
※ 해당 포스팅은 Matt pocock의 발표 영상(https://youtu.be/v4F1gFy-hqg?si=7M0lPIfwYiBs4Yfs)을 정리하고, 저의 생각을 추가한 작성한 글입니다.
AI 시대, 왜 소프트웨어 기본기가 더 중요해졌는가?
최근 AI 코딩 도구가 빠르게 확산 되면서 개발 방식도 크게 달라지고 있습니다. 이제는 개발자가 직접 모든 코드를 작성하지 않아도 AI에게 요구사항을 전달하고 코드를 생성하게 만들 수 있습니다.
하지만 Matt Pocock은 이런 흐름 속에서도 소프트웨어 기본기, 즉 Software Fundamentals가 그 어느때보다 중요해졌다고 강조합니다.
핵심은 단순한데, "AI에게 스펙을 전달하고 코드를 생성하게 하는 방식만으로는 좋은 시스템을 만들기 어렵다" 입니다. 코드베이스 전체의 설계를 고려하지 않은 채 기능 추가와 수정만 반복하면 Software Entropy가 발생하고 시스템은 점점 이해하기 어렵고 변경하기 어려운 구조로 변해 결국 유지보수가 힘든 스파게티 코드가 만들어집니다.
※ Software Fundamentals : 소프트웨어 개발의 기본기
※ Software Entropy : 시간이 지날수록 시스템 점점 무질서해지고, 이해하기 어렵고, 변경하기 어려운 상태로 변해가는 현산
AI는 전술적 프로그래머, 개발자는 전략적 설계자
영상에서는 AI를 뛰어난 전술적 프로그래머로 바라봅니다. AI는 구체적인 코드 작성, 구현 세부 사항 처리, 반복 작업 수행에는 강한 강점을 보이지만 시스템 전체의 방향을 결정하고, 모듈간 관계를 설계하고, 유지보수가 가능한 구조를 만드는 책임은 개발자에 있다라고 합니다.
즉 AI 시대의 개발자는 코드를 더 많이 작성하는 사람이 아니라, AI가 좋은 코드를 작성할 수 있는 환경을 설계하는 사람에 더욱 가까워지고 있습니다.
이 영상에서 말하는 전체적인 워크플로우는 아래와 같은 형태를 가집니다.
요구사항 전달 → AI와 공통 이해 형성 → 용어와 설계 개념 정리 → 작은 단위로 테스트하며 구현(TDD) → 딥 모듈로 복잡성 은닉 → 인터페이스는 개발자가, 구현은 AI에게 위임 → 유지보수 가능한 코드 베이스 확보
1. AI와 먼저 공통된 설계 개념을 맞춰야 한다.
AI와 협업할 때 자주 발생하는 문제는 "AI가 내가 원한 대로 하지 않았다"라는 것 입니다. 이 문제는 단순한 프롬프트 문제가 아니라, 개발자와 AI가 서로 다른 설계 개념을 가지고 있기 때문에 발생합니다.
영상에서는 이를 해결하기 위한 방법으로 Grill Me 기법이 소개되는데, 이 방식은 AI에게 다음과 같은 역할을 부여하는 것 입니다.
"우리가 공유된 이해에 도달할 때까지 이 계획의 모든 측면에 대해 계속 질문하라"
AI가 요구사항, 의존 관계, 설계 의도를 계속 파고들게 만들면 개발자와 AI 사이의 생각 차이를 줄여나갈 수 있습니다.
2. 유비쿼터스 언어로 AI와 같은 단어를 사용한다.
해당 영상에서는 도메인 주도 설계의 유비쿼터스 언어 개념도 중요하게 다루고 있습니다.
기존에는 기획자와 개발자 간의 용어 간극을 메우기 위한 방법이였다면, 이 포스텡어슨ㄴ 현재는 AI와 개발자 간의 간극을 메우기 위한 방법으로써 활용됩니다.
AI와 개발자가 같은 단어를 다른 의미로 사용하면 결과물을 쉽게 어긋나기 때문에, 코드 베이스에서 사용하는 핵심 용어를 마크다운 파일 등으로 정리하고 AI가 계획 수립과 코딩 과정에서 이 용어를 기준으로 생각하게 만드는 것이 필요합니다.
| 구분 | 문제 상황 | 해결 방식 |
| 설계 개념 | 개발자와 AI가 서로 다른 결과를 상상함 | Grill Me 기법으로 질문을 유도하여 공통 이해 형성 |
| 용어 | 같은 단어를 다른 의미로 해석함 | 유비쿼터스 언어를 마크다운 파일로 정리 |
| 구현 방향 | AI가 설계 의도와 다른 코드를 작성함 | 용어집과 설계 개념을 계속 참조하게 함 |
여기서 말하는 용어집은 말 그대로 용어들을 정리하여 개발자와 AI가 용어에 의한 차이를 보이지 않도록 하는 것입니다.
# 용어집 예시
수강생(Student)
- 학원에서 강의를 신청하고 수강하는 사용자
강사(Instructor)
- 강의를 개설하고 수업을 진행하는 사용자
강의(Course)
- 특정 주제와 기간을 가진 수업 단위
수강신청(Enrollment)
- 수강생이 특정 강의에 참여 신청하는 행위
정원(Capacity)
- 하나의 강의에 등록 가능한 최대 수강생 수
3. TDD로 AI의 작업 단위를 작게 유지한다.
현재 AI를 사용하며 개발을 하시는 분들은 "한번에 여러가지의 작업을 요청하지 마라" 라는 말을 들어보셨을겁니다.
AI는 때때로 너무 많은 코드를 한 번에 작성하려 하는데, 이를 '헤드라이트보다 빨리 달리는 상황'으로 설명합니다. 코드가 빠르게 생성되더라도 검증 없이 많은 변경이 쌓이면 개발자는 오히려 결과를 따라가기 힘들어지고, 이는 오히려 개발자가 병목의 원인이 되는 이유로 이어집니다.
영상에서는 이를 제어하기 위한 핵심 방법으로 TDD를 소개하고, 이는 저의 개인적인 AI 이후 개발 방법론과 정확하게 일치합니다.
이전 사람이 TDD를 작성할때는 오히려 테스트 코드를 작성하느라 개발 속도가 느려지고, 테스트 코드가 '주'가 되면서 테스트 코드의 품질에 신경쓰다보니 실제 개발의 코드 품질이 오히려 낮아지며 대부분의 TDD는 실패한 TDD인 상황이 많았습니다.
하지만 AI 시대에서 코드의 작성을 AI에게 위임하게 되면서 코드 생산성이 수십배 빨라진 상황에서, TDD는 오히려 AI와 함께 사용함으로써 더욱 많은 장점을 제공합니다.
TDD를 사용함으로써 AI가 작은 단계로 움직이게 만듭니다. 테스트를 먼저 작성하고, 작은 단위로 구현하고, 다시 리팩터링하는 흐름은 AI의 코드 생성을 사람이 검증 가능한 단위로 제한할 수 있습니다.
영상에서는 피드백 루프의 속도가 개발 속도와 연결된다고 설명합니다. 결국 빠른 개발은 단순히 코드를 많이 생성하는 것이 아니라, 빠르게 검증하고 안정적으로 다음 단계로 넘어가는 구조를 만드는 것 입니다.
4. 딥 모듈로 복잡성을 숨긴다.
영상에서 강조하는 또 하나의 핵심은 딥 모듈(Deep Modules) 입니다.
딥 모듈은 많은 기능과 복잡성을 내부에 숨기고 외부에는 단순한 인터페이스만 노출하는 구조입니다. 이미 좋은 메이저 오픈소스들은 사용자가 내부 구현을 몰라도 사용할 수 있도록 복잡한 구현을 단순한 public interface 뒤에 숨기는 경우가 많습니다. 이는 딥 모듈의 핵심과 일치합니다.
반대로 얕은 모듈(Shallow Modules)은 기능이 너무 작은 조각 단위로 흩어져 있어 AI가 코드의 맥락을 파악하기 어렵게 하며 AI는 수많은 파일과 함수, 의존 관계를 따라가야 하고 코드 베이스의 목적과 경계를 놓칠 수 있습니다.
| 구분 | 얕은 모듈 | 딥 모듈 |
| 구조 | 작은 조각이 많이 흩어져 있음 | 관련 기능을 하나의 모듈로 묶음 |
| 인터페이스 | 외부에서 알아야 할 것이 많음 | 외부 인터페이스가 단순함 |
| 복잡성 | 외부로 노출되기 쉬움 | 내부로 캡슐화됨 |
| AI 협업 | 맥락 추적이 어려움 | 모듈의 목적과 경계를 이해하기 쉬움 |
| 테스트 | 검증 지점이 분산됨 | 입출력 경계 기준으로 테스트 가능 |
딥 모듈을 만드릭 위한 기준은 관련 코드들을 찾아 하나로 묶고, 외부에서는 단순한 인터페이스만 호출하도록 만드는 것 입니다.
이러한 방식의 핵심은 복잡성은 내부에 숨기고 인터페이스는 단순하게 유지하는 것이며 이는 다음 내용과 이어집니다.
5. 인터페이스는 개발자가 설계하고 구현은 AI에게 위임한다.
현재 AI 시대의 개발자들은 모든 구현을 직접 작성할 필요가 없습니다. 인터페이스는 개발자가 직접 설계하고, 구현은 AI에게 위임하는 방식을 제안합니다.
이 접근은 개발자의 인지 부하를 줄여줍니다. 개발자는 모듈의 경계, 입출력, 테스트 가능성, 시스템 전체 방향에 집중하고 AI는 그 안쪽 구현을 담당합니다.
이것이 전략적 프로그래머의 역할입니다.즉, 앞으로는 더욱 더 코드를 잘 작성하는 개발자보다는 아키텍처의 관점에서 코드를 잘 설계하고 AI에게 구현을 위임할 수 있는 개발자가 되어야 합니다.
결론
AI의 압도적인 생산성으로 인해 개발자가 모든 코드를 직접 치던 시대는 점점 끝나가고 있습니다. 그러나 좋은 코드베이스와 좋은 설계가 없다면 AI는 오히려 소프트웨어 엔트로피를 빠르게 증가시킵니다.
AI 시대에 중요한 것은 코드를 얼마나 많이 생성하고 빠르게 기능을 구현하느냐가 아니라, AI가 올바른 코드를 생성할 수 있도록 시스템을 설계하는 능력입니다. 이제 개발자는 코드를 직접 구현하는 포지션이 아니라, 전략적 설계자로써 코드베이스의 품질을 지켜야 합니다.
많은 개발자들은 이러한 AI의 압도적은 생산성으로 인해 소프트웨어 기본기보다는 화려한 기술들을 향해 가고 있지만, 역설적이게도 AI의 압도적인 생산성으로 인해 소프트웨어의 기본기가 점점 더 중요해지고 있습니다.
'이런 저런 이야기' 카테고리의 다른 글
| [이런 저런 이야기] 2025 표준프레임워크 컨트리뷰션 후기 (feat. 굿즈 개봉) (2) | 2025.11.02 |
|---|---|
| [이런 저런 이야기] 내가 AI 플랫폼을 여러 개 사용하는 이유 : AI는 의견을 밀고 나간다 (2) | 2025.08.09 |
| [서평단] 비전공자를 위한 데이터베이스 입문 후기 (0) | 2024.05.28 |
| [YouTube] 유튜브 전체화면 회전 안됨, 터치 기능 안됨 해결 방법 (1) | 2022.09.15 |
| 마이크로소프트 MS 서포터즈 1기 모집 (0) | 2020.11.11 |