소프트웨어 기본기가 그 어느 때보다 중요합니다 (한국어 더빙)

생각 덩어리

자기 기술이 더는 가치 없다고 느끼는 분들께

어떤 분들께는 조금이나마 위로가 되었으면 하는 말입니다. 이 새로운 시대에 자기 기술이 더는 같이 없다고 느끼는 분들께 저는 소프트웨어 기본기가 지금이야말로 중요하다고 말씀드리고 싶습니다. 그 어느 때보다 더 중요해졌습니다.

스펙스 2 코드 — 컴파일러를 다시 돌리면 더 나쁜 코드만 남는다

스펙스 2 코드 흐름은 앱이 어떻게 동작해야 하는지 명세서를 먼저 쓰고 그다음 AI를 쓰면 된다고 말합니다. 그걸 코드로 바꾸는 방식입니다. 앱에 문제가 생기면 다시 명세서로 돌아가면 됩니다. 코드를 구제볼 필요는 없고 명세서만 바꾸면 됩니다. 컴파일러를 다시 돌리면 코드가 더 나옵니다.

처음엔 코드가 나오고 그다음 실행하면 더 나쁜 코드가 나오고 다시 하면 또 더 나쁜 코드가 나왔다는 겁니다. 결국 쓰레기만 남더군요.

코드는 그냥 무시하고 알아서 관리되게 두면 된다는 생각은 결국 이름만 다른 바이브 코딩일 뿐입니다.

나쁜 코드 = 바꾸기 어려운 코드 — 존 오스트하우트의 정의

복잡성은 소프트웨어 시스템의 구조와 관련돼서 그 시스템을 이해하고 수정하기 어렵게 만드는 모든 걸 말합니다.

그러니까 나쁜 코드 베이스는 바꾸기 어려운 코드베이스입니다. 버블을 만들지 않고 코드 베이스를 바꿀 수 없다면 그건 나쁜 코드베이스입니다. 좋은 코드 베이스는 쉽게 바꿀 수 있습니다.

소프트웨어 엔트로피 — 변경 하나만 보면 점점 무너진다

엔트로피는 사물들이 점점 재난 쪽으로 가고 서로 흩어지고 무너지는 경향을 말합니다. 대부분의 소프트웨어 시스템도 정확히 그렇게 움직입니다. 코드 베이스를 바꿀 때마다 그 변경 하나만 생각하면 문제가 생깁니다. 전체 시스템 설계를 생각하지 않으면 코드 베이스는 점점 더 나빠집니다.

코드는 싸지 않다 — 나쁜 코드가 그 어느 때보다 비싸다

저는 그 말이 맞지 않다고 생각합니다. 코드는 싸지 않아요. 사실 나쁜 코드는 그 어느 때보다 비용이 큽니다.

바꾸기 어려운 코드 베이스를 갖고 있으면 AI가 줄 수 있는 수많은 이점을 다 가져갈 수 없습니다. 좋은 코드 베이스에서는 AI가 정말 정말 잘 작동하거든요.

그래서 좋은 코드 베이스는 그 어느 때보다 중요하고 결국 소프트웨어 기본기도 그 어느 때보다 중요해집니다. 이게 이 강연의 핵심입니다.

디자인 콘셉트 — 마크다운에 못 담는 보이지 않는 이론

더 프레그메틱 프로그래머에서는 아무도 정확히 자기가 뭘 원하는지 모른다고 말합니다. 여러분과 AI 사이에는 소통 장벽이 있습니다.

디자인 콘셉트라는 개념을 이야기합니다. 그 말은 여러 사람이 함께 뭔가를 설계할 때 그 사이에 아직 형태가 잡히지 않은 아이디어가 떠다닌다는 뜻입니다. ... 그건 자산이 아니고 마크다운 파일에 넣어 둘 수 있는 것도 아니에요. 우리가 만들고 있는 것에 대한 보이지 않는 이론 같은 거죠.

Grill Me 스킬 — 합의된 이해에 도달할 때까지 집요하게 인터뷰

계획의 모든 부분을 끝까지 집유하게 물어보면서 서로 같은 이해에 도달할 때까지 계속 인터뷰해 주세요. 프레더릭 P브룹스가 말한 또 다른 개념인 디자인 트리의 각 관래를 하나씩 따라가세요. 각 결정 사이에 의존성을 하나씩 풀어 나가는 거예요.

AI가 포제로게 예순계 질문을 막 던져요. 어떤 사람들에게는 서로 이해가 됐다고 판단할 때까지 100개 질문을 하기도 했습니다.

클로드 코드의 기본 플랜 모드보다 이게 더 낫다고 생각합니다. 플랜 모드는 뭔가 결과물을 만들고 싶어 한 달이 나 있습니다. 그냥 계획을 만들려고 하죠. 그리고 바로 작업을 시작하려고 합니다. 반면 저는 먼저 디자인 콘셉트를 공유하는게 훨씬 좋다고 생각합니다.

AI가 너무 장황하다 — 도메인 전문가 비유

개발자로 오래 일하다 보면 예를 들어 도메인 전문가와 함께 일할 때가 있잖아요. ... 도메인 전문가가 마이크로칩 관련 뭔가를 만들어 달라고 할 수도 있어요. 그런데 나는 마이크로칩이 뭔지도 모르죠. 공통 언어를 먼저 만들어야 해요.

Ubiquitous Language — AI와 공유하는 용어 목록

유비쿼터스 언어를 쓰면 개발자들끼리 하는 대화나 코드의 표현 그리고 도메인 전문가와의 대화가 모두 같은 도메인 모델에서 나와요. 쉽게 말해 여러분과 AI가 공유하는 용어 목록이 담긴 마크다운 파일 같은 거예요.

AI 싱크킹 트레이스를 읽어보면서 제가 알게 된 건 ... 계획을 더 잘하게 해 줄뿐 아니라 AI가 덜 장황하게 생각하게 만들고 실제 구현도 우리가 계획한 것과 더 잘 맞게 해 줘요.

피드백 속도가 곧 속도 제한 — 헤드라이트보다 빨리 달리지 마라

경험 많은 개발자처럼 피드백 루프를 최대한 잘 쓰지는 못합니다. 대신 한 번에 너무 많은 걸 하려는 경향이 있습니다. 엄청난 양의 코드를 만든 뒤에야 이건 타입 체크를 해야겠다. 테스트도 한번 돌려 봐야겠다. 이런 생각을 하게 됩니다.

실령주의 프로그래머들은 이걸 헤드라이트보다 더 빨리 달린다고 표현하는데 결국 피드백 속도가 곧 속도 제한이라는 뜻입니다.

TDD가 LLM을 작은 단계로 강제한다

그래서 세 번째 스킬은 TDD입니다. TDD 즉 테스트 주도 개발을 써야 합니다. LM이 정말 작은 단계로 움직이게 만들어 주기 때문입니다. 먼저 테스트를 통과시키고 그다음 코드를 더 보기 좋게 리팩토링하면서 설계를 다듬습니다.

좋은 코드 베이스 = 테스트하기 쉬운 코드 베이스

우리가 발견한 건 좋은 코드 베이스일수록 테스트하기도 쉽다는 점입니다. 여기서 다시 코드가 중요하다는 생각으로 돌아오게 됩니다. 코드 베이스가 좋을수록 피드백 루프도 좋아집니다. LM에 더 좋은 피드백을 줄수록 더 좋은 코드를 만들어 냅니다.

딥 모듈 vs 셸로 모듈 — 단순한 인터페이스 뒤에 복잡함을 숨겨라

그는 코드 베이스에 깊은 모듈이 있어야 한다고 말합니다. 얕은 모듈이 아니라 많은 함수를 노출하는 모듈이 잔뜩 있는 구조가 아닙니다. 비교적 적은 수에 크고 깊은 모듈이 있어야 합니다. 간단한 인터페이스입니다.

딥모은 단순한 인터페이스 뒤에 많은 기능과 복잡함을 숨깁니다. 원하면 딥 모듈 안을 들여다볼 수는 있지만 그럴 필요는 없습니다.

셸로 모듈 코드베이스 — AI가 이해 못 한다

코드 베이스에서 셀로 모듈은 이런 식입니다. AI가 지나가야 할 아주 작은 덩어리들이 엄청나게 많은 거죠. 사실 이런 구조는 AI가 탐색하기 정말 어렵습니다. ... AI는 이런 코드 베이스를 정말 잘 만들어 내지만 결국 AI가 코드가 뭘 하는지 이해하지 못하는 상황이 생깁니다.

인터페이스를 설계하고 구현은 위임하라

인터페이스만 설계하고 구연은 너무 걱정하지 않겠다고요? 물론 앱에서 덜 중요한 부분이라면 구현을 너무 자세히 리뷰하지 않아도 됩니다. 금융처럼 중요한 영역에는 이렇게 하면 안 됩니다. 하지만 앱의 많은 모듈에서는 구현을 깊게 생각하지 않아도 됩니다.

큰 덩어리 안쪽은에게 맡기고 저는 바깥에서 테스트하고 검증하겠습니다. 그래서 다섯 번째 팁은 이것입니다. 인터페이스를 설계하고 구현은 위임하세요.

매일 시스템 설계에 투자하라 — 켄트 백

그 지도를 아주 잘 알아야 합니다. 그것이 우리 팀의 공통 언어가 되어야 하고 계획을 세우는 능력 안에도 들어가야 합니다.

이 생각은 캔트백에게서 온 것입니다. 매일 시스템 설계에 투자하세요. 핵심은 바로 이것입니다. 스펙이 코드를 만들게만 두면 우리는 시스템 설계에 투자하는 것이 아니라 오히려 빼앗고 있는 겁니다. 그걸 놓아 버리는 셈입니다.

코드는 싸지 않다 — 전술가 위에 전략가가 필요하다

그래서 코드는 싸지 않습니다. 이것만은 꼭 기억해 주세요. 코드는 중요합니다.

AI를 현장에서 아주 뛰어난 프로그래머, 즉 코드를 직접 바꾸는 전술 담당자로 본다면 그 위에 누군가가 필요합니다. 전략적으로 생각하는 사람이 필요합니다. 그 사람이 바로 여러분입니다. 그리고 거기에는 우리가 20년 넘게 써온 소프트웨어 기본기가 필요합니다.