가치 레버리지의 변화이다.

처음 프로그래밍 시작할때 내 생산성은 내가 직접 작성하는 코드의 양과 질에 비례한다

하지만 이제 AI 프로그래밍과 또 B2B 앱을 수주 받아 판매하는 입장서는 나는 설계와 AI에게 지시내린다.

이제부터는 설계의 결정이 AI의 토큰과 개발시간을 줄이고, 미래에 발생할 유지보수 비용을 줄이는 것이다.

일단 외주를 받으면 첫번째로 가장 먼저 할 일은

고객의 요구를 국지적 모듈화로 만들어 격리 하는 것이다.

1. 예약할때 캘린더에 동그라미 칠 수 있으면 좋겠어요

2. 이 신호처리를 하고나서 결과를 받았으면 좋겠어요

여기서 이제 1번 동작은 캘린더, 그리고 예약하는 동작, 동그라미 그리고 고객의 요구에는 없지만 X 표시 또한 존재해야하며 취소할 수도 있어야한다.

2번 동작은 FFT로 도메인 값을 변화하는 로직도 존재해야한다.. 고객은 자기가 익숙한 차원에서 계산을 좋아하기때문이다.

따라서 표면의 요구만 보는 것이 아니라, 결국 내면의 요구를 봐야한다. 2번의 경우는 간단해보이지만, 사실 시간->주파수로 변화하는 로직도 포함해야했고, 입력에 따른 결과를 지연없이 받는다는 실시간성 내포가 존재했다. 

결국 이는 자연스레 사용자에게 어떤 경험을 줄 것인가에 대한 고찰로 이루어지고, 이것이 설계의 근간 베이스가 된다.

하지만 우선 일처리를 할때 작은 부분부터 하면 백퍼센트 사고가 터지고, 모든 코딩은 내 컴퓨터에서는 되지만 고객 컴퓨터에서는 돌아가지 않을 문제가 있다는데서 시작하기때문에

일단은 설계과정과 에러가 날 부분들을 생각한다. 가령 아두이노 외주를 해보면 고객의 MCU(보드)가 공식적으로 자주쓰는 메이저 키트가 아니라, 마이너 키트라서 핀이 달라서 매핑이 안되서 설계한 코드가 작동하지 않아 다시 핀을 스캔 후 재매핑하는 경우도 있었고, 대부분 파이썬을 쓸 줄 안다는 고객도, 파이썬의 버전과 가상환경 차이로 인해서 실제로 특정 라이브러리가 되지 않았던 경우가 있었다.

어쨌건 그 이전에 내 문제를 아키텍쳐의 결정으로 넘긴다.

그럼 이제 내가 작성할 앱의 API 계약 관계, 모듈 경계를 만들어야한다. 그 모듈 경계와 API를 어떻게 설정하느냐에 따라서, 구현부는 반복 자동화가 낮아지고, AI가 실수하지 않는다.

중요한 것은 '한 줄 바꿔서 디버깅' 하는 것을 얼마나 줄이느냐다

결국 설계의 결정은 전반적으로 나의 최종적인 시간을 절약한다. 즉 디버깅 시간이 설계로 인해 줄어든다.

그리고 이후 모듈화에 대한 격리 테스트를 시작 한 후, 각 모듈에 대해서 모킹 테스트를 실시한다.

이는 각 모듈의 동작성을 보장한다. 함수와 메서드에 대한 유닛 테스트는 외주하는 입장서 사치기때문에

최대한 모듈 단위로 진행한다.

예전에는 코드를 얼마나 빠르게 많이 작성하느냐이지만

지금 코드 방법론은 대부분

'나는 얼마나 반복적인 디버깅을 덜하게 할 것인가'에

집중하고 있다