품질과 네트워크 마케팅을 생각하며 tdd고찰

최근에 친척분이 네트워크 마케팅을 하신다... A사라는 미국의 글로벌 기업이다... 불쑥 찾아와서 당황했지만...
여러가지 생각을 해본다..
해당 제품은 품질을 내세우지만 가격이 비싸다..

품질이 불량하면 사실 네트워크 마케팅이 불가능하다..
가격이 비싼거는 가치가 있다면 어떻게든 커버가 가능하지만
품질이 아주 불량하다면 이런 사업구조 자체가 불가능할 것이다..
 
그리고 또하나 있다. 품질만 가지고 되는게 아니고
네트워크 마케팅을 하려면 무언가 감정적인 교류가 있어야 한다.
 
아무리 좋은 물건이라도 싫은 사람이 팔면
안팔릴 것이다.
 
보통 기업에서 이미지 좋은 연예인을 내세워서 마케팅을 하는것이
다 그런 이유일 것이다.
 
자 여기서 내가 생각해보는 것은 품질이다.
 
분야는 다르지만 나는 개발자이니
프로덕트를 만든다...
 
그러나 사실 지금 곰곰히 생각해보면
나는 참 열악한 환경에서만 개발했구나 하는 생각이든다
 
연차가 쌓여감에따라 지식이 늘어서
대충 어떤 것이 좋은것이고
어떤 것이 안좋은지 감을 잡아간다.
 
그러나 이번에 생각해보면tdd라는게 원래 품질을 높이기 위한 것이 주목적이다.
 
실패하는 케이스를 먼저 생각한다는것은 품질을 높이고 보다 견고한 코드를 짜는 것이다.
 
그 다음에 클린코드와 리팩토링.. .책임분리 이런 것들이 간다면금상청화겠지만
 
빚좋은 개살구가 되지 않을라면
tdd통과가 더 우선이다.
 
내가 맨 처음 개발 했을때는 그냥
구글의 콘솔에서 찍어보고...
에러로그 보고 되었다 싶으면
통과하고... (junit 도구없이.. 그냥... 경우의 수 테스트..)
 
사실상의 단위테스트는... 
QA에게 넘어갔었다...
 
그리고 유지보수에서는 팀장이 봐주었다...
 
생각해보니까... tdd라는 개념 자체를..
왜 그 누구도.. 말하지 않았을까...
장인정신이 없는걸까?
 
tdd를 남겨 놓으면 QA의 감수와 별개로
고려하지 않아도 되는 경우의 수가 나온다...
 
SI에서는 보통 기간내에 만드는게 급급해서 tdd를 QA에게 맡기고 
SM에서는 팀장급들이 잘못되었을 경우 봐주는... 그런 케이스였다..
내가 만든게 문제가 있었던 적은 없었고...
css같은것을 잘 못 고쳐서 난감했던적이 있었다.(프론트 웹과 모바일...)
 
그것이 이커머스 시스템이었다...
상당히 낙후된 시스템같으나 그래도 자바11에 롬복을 사용하고 있던 녀석이었다.
빌더 패턴까지 써서 만들었으니 나름 잘 만들었는데...
 
그러다보니 사실 DB같은 거나 풀스택을 했지만..
프론트는 번거롭고... 백엔드는 조금 물어보면 거의 다 해결되고...
복잡한 프로시저에서 이리저리... 조금 힘든 기억이 있다.
 
어쨌건 처음으로 돌아와서...
그 이커머스 시스템은 결국 또 차세대로 넘어갔다..
그만큼 기술이 급별하는것이다
 
이커머스 개발로 갈 기회가 있었는데...
때마침 아이가 태어났고...
대기업 전사 4개 사이트와 동시에 스트레스를 받으면서...
신입녀석을 도와주면서...
조금씩 번아웃이 왔다...
그래서 개발을 하고 싶었으나 부담스러웠다.
 
그리고 무엇보다도..
 
코로나 기간 동안 체력이 너무 약해진 것이다.
 
그 뒤에 중소기업진흥공단에 가서 
약해진 체력을 이끌고 그냥 짬으로 일하다가...
진단 시스템을 만든 사수가 있어서
탄소중립 진단 고도화만 하면 되었기에...
업무적인거 물어보면 거의 다 답이 나왔고..
비즈니스 로직은 체계적으로 해보면 다 답이 나왔고...
단위테스트는 사실상... 나의 테스트(?)로 끝나고...
사수가 보고 지적하거나... 간간히 QA팀이 알려줬다...
그러나 그도 그럴것이 요구사항 변경이 제일 까다라웠다.
 
요구사항이 바뀌어서 내려오면...
김이 빠지기 때문에... 
무언가를 그냥 다시 만든다...
SI의 이런 산업구조는 tdd에 대한 동기부여 자체가 없었던 것이다.
 
요구사항변경...
그건 유지보수에서 개발중에도 수없이 많이 있었다..
 
지금 데이터모델링 설계를 보고 나서 드는 생각은
자신들도 무엇을 원하는지 모르는 상태에서
 
야생형으로 개발하는 애자일 문화가 있어서
프로토타입 이후의 삽질을 통해서 
계속해서 산출물을 변경해가는 애자일 개발방식이었다.
 
프로토타입의 삽질 애자일 방식은 참 많이 힘들었다.
 
그 사이트만 전담했으면 상관이 없지만
여러 사이트를 맡고 있기에 아무래도... 
집중도가 떨어지고는 했는데...
 
이클립스가... 전자정부도 junit가 되기는 하지만...
프론트는... junit 같은게 없어서...
풀스택SI는 사실상 어느정도.. QA를 요구하게 되어 있다... QA들도 요구사항변경에 성격버려간다는 혼자말이 기억난다
 
그렇게 안하려면 시간을 갈아 넣어야 하는데...
외주가 안좋다고 생각하는 점은
장인정신을 가지고 해봐야... 본전이기 때문이다.
장신정신은 우선순위에 밀리고 속도가 앞서게 되어 있다.
 
그래서... 자체 솔루션을 가지고 있는 곳이 그나마 조금더 
책임감과 전문성을 가지고 할 수 있는 것 같다.

어쨌건 tdd는 장인정신과 함께한다는 한 마디 말을 하기 위해서...
이 긴 글을 쓴다.