읽지 않는 코드의 시대를 읽고

 

읽지 않는 코드의 시대 : NHN Cloud Meetup

읽지 않는 코드의 시대 : NHN Cloud Meetup

 

 

위 기술블로그를 보다 예전에 생각했던 내용들이 있어 작성해봄

요새 오픈클로를 사용하면서도 느꼈던 생각과도 연결이 되는거 같음

 

AI가 코드를 잘 작성하는 시대, 개발자의 경쟁력, 역할은 무엇일까?

 

-----

 

1. 코드 작성의 가치가 내려가면 무엇의 가치가 올라갈까?

AI가 코드 생성을 주도하면서 가독성의 기준이 인간 → 기계로 이동

코드를 읽을 줄 아는 능력은 오히려 희귀 자산이 됨

 

나도 중요하다고 생각하는건

- AI는 만능 도구가 아니라 증폭기다. 사람이 가진 사고 습관이 그대로 증폭된다.

 

요구사항을 흐릿하게 주면 -> 흐릿한 구현이 나옴
대충 맞겠지로 검증을 생략하면 -> 그대로 프로덕션 리스크

 

반대로

명확한 기준과 검증 구조를 주면 → 생산성과 품질이 동시에 올라간다

 

AI 시대의 경쟁력은 코드를 잘 쓰는 능력이 아니라 AI가 잘 쓰게 만드는 환경과 기준을 설계하는 능력으로 옮겨가는 중이라고 생각을 정리해 봄

 

-----

 

2. LLM의 비결정성 행동

 

가끔 마틴 파울러 아티클을 보는데 작년에 간단한 crud 스프링 부트 서비스를 여러번 만들어 보는 실험을 함

How far can we push AI autonomy in code generation?

How far can we push AI autonomy in code generation?

 

요약을 해보면

 

- 과잉 친절: 요청하지 않은 기능을 추가한다

- 가정으로 빈칸 채우기: 요구사항의 빈 부분을 임의로 해석한다

- 테스트 실패 무시: 실패한 테스트를 건너뛰고 “완료”를 선언한다

- 무차별 수정: 원인 대신 증상만 바꾼다

 

이건 “AI가 나쁘다”가 아니라, AI가 그렇게 작동한다는 뜻

결론도 현실적인데 비즈니스 크리티컬 소프트웨어에서, AI는 인간 감독 없이 자율적으로 유지보수할 수 없다 라는 결론을 냈음

 

-----

 

켄트백의 아티클 2개

 

Party of One for Code Review! - by Kent Beck

Party of One for Code Review!

 

Taming the Genie: "Like Kent Beck" - by Kent Beck

Taming the Genie: "Like Kent Beck"

 

각각 내용을 정리해보면

리뷰를 할 수 없을 정도로 코드 생산이 빠름, 코드 작성은 병목이 아니고, 리뷰가 중요해졌다.

제약을 주는게 아키텍쳐를 잘 구조화 한다. 라는 내용..... 으로 해도 되려나??

 

어쨌든 위 내용들을 모두 고려해보면 원칙을 하나 생각해볼 수 있음

 

원칙 - 검증 구조가 없는 코드는 도입하지 않는다

AI가 무엇을 만들어도 결과를 프로덕션 품질로 끌어올리는 장치는 테스트/검증 임

 

-----

 

그럼 개발자의 앞으로 역할은?

1. 컨텍스트 엔지니어링

AI가 올바르게 일하도록 규칙을 설계한다.

모호한 프롬프트는 모호한 코드를 낳는다.
그래서 constitution.md, AGENTS.md, 요구사항/설계 문서가 단순한 문서 작업 이 아니라는 뜻

2) 검증 구조 설계

AI의 비결정성을 전제로, 결과물이 틀렸을 때 잡아내는 구조를 먼저 만든다.
테스트, 체크리스트, 정적 코드 검사, 회귀 방지 규칙이 여기에 포함된다.

3) 읽을 줄 아는 능력

프로덕션 장애는 기계가 읽는 코드도 있지만 결국 사람이 해결해야 함.
“읽을 줄 아는데 안 읽는 것”과 “못 읽는 것”은 완전히 다르다.
AI가 코드를 쓸수록, 읽을 줄 아는 능력은 더 중요해지는 듯.

 

-----

3. 포트폴리오와 앞으로의 토이 프로젝트는 아래처럼 진행해 보려고 함

단순한 AI를 붙였다 -> dog나 cow나 다함

이 사람이 만든 코드는 믿을 만한가?
문서/테스트/PR 기록으로 그걸 증명할 수 있는가?

 

문서 구조를 만들고, 테스트를 더 해보자

내가 생각한 기본 구조

project/
├── constitution.md
└── docs/
    ├── design/
    │   ├── requirements.md
    │   └── architecture.md
    └── impl/
        ├── tasks.md
        └── checklist.md

 

이 구조의 목적은 최대한 개발을 재현 가능하게 해보는 것

• 요구사항이 고정 - 무엇을 만들지
• 설계가 고정 - 어떻게 나눌지
• 태스크가 원자화 - 어떤 순서로 할지
• 체크리스트 - 끝났다고 말할 기준이 생김

이 파일들이 곧 컨텍스트 레이어가 된다.

 

그래서 요새 실무에서도 쓴다고 들은 Spec-kit, BMAD 들도 비슷하게 컨텍스트를 표준화 하려고 하는거 같음

 

Spec-Kit은 대략 이런 흐름을 갖는다.

• constitution → specify → clarify → plan → analyze → tasks → implement

BMAD는 역할을 분리한다.

• Analyst → PM → Architect → Scrum Master → Developer → QA

겉으로 보면 워터폴 같기도 하지만 핵심은 다름

• 문서가 낡으면 구현이 깨진다 → 그래서 문서는 ‘사후 산출물’이 아니라 실행 도구가 된다
• 역할 분리는 관료주의가 아니라, LLM에게 명확한 역할과 입력을 주는 기법이 된다

-----

4. 정리해보자면......

1)  AI의 비결정성을 전제로 설계

AI가 테스트 실패를 무시할 수 있다는 사실을 알고,
테스트/하네스를 먼저 설계하고 통과한 결과물만 반영

2) 나머지 10%

운영 환경에서 동시성,캐싱, 비동기 처리 경험은 AI가 쉽게 대체하지 못하는 영역이라 생각함

 

AI는 코드를 더 빨리 만든다

그래서 코드 작성은 점점 평준화된다

결국 차별점은 컨텍스트(왜/무엇/어떻게) + 검증(테스트/게이트/회귀 방지)가 됨

 

-> 신뢰할 수 있는 개발 방식을 레포 자체에 남겨보자

 

[참조]
- NHN Cloud Meetup: 읽지 않는 코드의 시대
  https://meetup.nhncloud.com/posts/408
- Martin Fowler
  https://martinfowler.com/articles/2025-nature-abstraction.html
- Kent Beck
  https://tidyfirst.substack.com/p/party-of-one-for-code-review
  https://tidyfirst.substack.com/p/taming-the-genie-like-kent-beck
- Thinking Machines Lab: Defeating Nondeterminism in LLM Inference(temperature=0에서도 재현 어려운 이유)
  https://thinkingmachines.ai/blog/defeating-nondeterminism-in-llm-inference/

[방법론]
- GitHub Spec Kit
  https://github.com/github/spec-kit
  https://github.blog/ai-and-ml/generative-ai/spec-driven-development-with-ai-get-started-with-a-new-open-source-toolkit/
- BMAD-METHOD
  https://github.com/bmad-code-org/BMAD-METHOD