1. 변화량 분석 을 중심으로 한저비용 고효율의지속가능한코드퀄리티 관리법부제: “코드는 변화한다”던파개발실송창규

2. 발표자 소개송창규 (남, 31세, 애인없음) 잡캐 프로그래머innover@neople.co.krtwitter @innovariPersonal History 한스타 개발 (1999)넥슨크레이지 아케이드 BnB(2002)디지팡 (2002~2003)빅샷 (2004~2006)버블파이터 (2006~2010)마비노기2 (2010~2011)네오플던전앤파이터(2011~)

3. 발표 아젠다게임 업계는 이미 레드오션신규개발vs. 라이브의 비중 변화패러다임의 변화

4. 발표 아젠다점점 중요해지고 있는그동안 소홀했던 점들에 대해 함께 고민시도사례 / 아이디어 공유돈을 벌고 있는 (그러나 노쇠해져가는)프로젝트를 어떻게 잘 개선/유지 할 것인가그것을 어떻게 지속가능 하게 만들 것인가

5. 발표 구성3부작

6. 코드 퀄리티 관리일반적으로 이야기되는코드 퀄리티 관리깨진 창문을 방치하지 말자:관리되지 않는다는 느낌으로 인식시키면 안됨

7. 코드 퀄리티 관리일단 라이브로 접어들게 되면 코드 퀄리티는깨진 창문 을 넘어서서 슬럼화되기 시작

8. 코드 퀄리티 관리관리되지 않는다는 느낌을 벗어나기가 힘들다규모에 압도당하기 쉽다현명한 포기가 필요“전기가 안들어와서나와봤어요”전선을 좀 손봐얄텐데..Kowloon Walled City in Hong Kong – 대표적인 슬럼 도시

9. 청소 메타포:코드 퀄리티 관리는 청소와 흡사살다보면 어지럽혀진다어지럽힌걸 꼭 청소할 필요는 없다청소하지 않을수록 점점 살기 불편해진다AND..청소되지 않은 집에서는 더 쉽게 어지럽히게 된다( 여럿이 사는 집이라면 더욱 )조금만 어지럽혀진 집은 그때그때 쉽게 정리하면 되지만,대단히 어지럽혀진 집은 맘잡고 대청소를 해야한다( 여럿이 사는 집이라면 동의도 구해야한다 )

10. 청소 메타포:청소와 다른점?코드퀄리티 관리건물 청소프로그래머 증가엔 제한이 있지만코드는 시간에 따라 무한히 증가건물이 커질수록사람 수도 증가SizeCode Size늘어가는 괴리해외 진출라이브 돌입Team SizeTime

11. 장수 프로젝트의 모습D모 프로젝트 소스오픈 6년 후..CPP한개.cpp 파일 2282 개 !.h 파일 2935 개 !클래스 5855 개 !

12. 난관: 규모가 커지면…어디서 창문이 깨지는지조차 알 수 없는다한가지를 정리하는 것도 비용이 너무 크다코드 퀄리티 저하/향상이 체감되지 않는다개선점이 유지되지 않고 곧 다시 망가진다다수 인원의 alignment 가 쉽지 않음<학습된 무기력>에 의해 개선의지 자체가 퇴색

13. 피할수없는 코드 오염인정하자:라이브 서비스 코드 는어차피 망가진다특히라이브로 갈수록“그거 할 시간에 컨텐츠를 더..” “괜히 건드렸다가 터지면..”코드가 방대해질수록학습된 무기력프로그래머가 많아질수록책임분산TD 역할이 흐려질수록일관성 있는 방향 alignment 약화 (퀄리티 ≒ 일관성)

14. 하지만정도의 차이가 있다여러 프로젝트 경험이 있다면 경험해봤을 것더 관리되는 코드와 덜 관리되는 코드의 차이더 잘 망가지는 코드와 덜 망가지는 코드의 차이망가지는 속도의 차이개발 편의성, 안정성과의 연관성분명 중요한데어떻게 퀄리티를 끌어올릴지는 막막..

15. 어떻게 정리할까자동화 하기시간 에 초점을 맞추기

16. 자동화자동화 기법의 기존 관점: (Static Analysis 등..)“소스코드를 데이터 로 보기”데이터

17. 시간을 고려하여 관점 확장자동화 기법의 기존 관점: (Static Analysis 등..)“소스코드를 데이터 로 보기”시간 개념을 도입, 확장한 관점:“소스코드를 변화하는 데이터로 보기”데이터현재데이터과거데이터미래데이터변화변화

18. 변동성소프트웨어 퀄리티에서의 화두:“어떻게 나눌 것인가”논리적인 분류와 함께 의존성이 주로 이야기됨변동성의존성과 함께 가장 중요한 고려사항잘 언급되지 않는 경향김학규 님의 글 중,“ 소프트웨어를 잘 만드는 방법 - 변동성”아키텍팅에 관심을 있다면: 강력 추천

19. 변동성변동성이 낮은 것이 변동성이 높은 것에 의존하면, 변동성이 낮은 것의 변동성이 그만큼 높아진다상점기능을 위해 CButton 을 보강(?)했더니상점을 고칠때마다 모든 UI 코드 리빌드게임 엔진이 게임 로직을 참조하면엔진의 변동성이 높아짐UI System 이 UI Logic 을 참조하면UI System 의 변동성이 높아짐…자동차 범퍼의 예를 생각해보면 쉽게 이해가 갈 것이다.차체와 범퍼가 구분되어 있지 않으면, 범퍼의 교체 비용이 차체까지 확산되는 것이다.- from <소프트웨어를 잘 만드는 방법 – 변동성> - 김학규

20. 변동성을 기준으로 나누기“프로젝트 전체의 유지 보수 비용을 낮추기 위해서는 변동성이 높은 부분과 낮은 부분을 올바르게 나누어야 한다”“…보통 자동차는 10장 내외의 철판, 범퍼등의 파트로 나뉘어져 있다. 만약 100 장 이상의 철판으로 잘게 나뉘어진 자동차를 상상해보라.아마 자동차가 아니라 누더기가 되지 않을까?”간단한 접촉사고가 났다고 생각하면..- from <소프트웨어를 잘 만드는 방법 – 변동성> - 김학규

21. “변동성의 분리 사례”.cpp.hC++ compiler헤더 파일 (.h) vs. 소스 파일 (.cpp)인터페이스 vs. 구현알고리즘 vs. 데이터 타입코드 vs. 데이터C++ 소스 vs. 스크립트 소스프레임워크 코드 vs. 로직 코드ImplementationInterfacepimpl, …Data StructureAlgorithmsTemplateDataCodeData-drivenScript SourceC++ CodeScriptingLogicCodeFrameworkCodeFramework / Library- from <소프트웨어를 잘 만드는 방법 – 변동성> - 김학규

22. 현재데이터과거데이터미래데이터변화변동성 측정“변동성 을 정량적으로 측정 가능하지 않을까?”SVN 등 VCS 를 쓴다는 것은 과거의 코드와 코드 변화를 가지고 있다는 것(정성적) 소프트웨어 변동성을(정량적) Repository 변화량으로 측정해보자!변화과거 변화량분석

23. 1부변화량 분석

24. 기대효과:“설계”와 “구현”을 위한 프로파일링공간적 내용만 볼 수 있는 소스코드에시간적 변화량를 가시화하여설계와 구현에 참고하고 활용할 수 있지 않을까?ex)인터페이스가 적절히 잘 나누어졌는가?모듈 재구성 / 리팩토링현 구현에서 패턴화시켜 분리가 가능한가?정적인 부분은 프레임웍화동적인 부분은 스크립트화/데이터화

25. 기대효과:“자주 변하는 곳이중요한 곳이다”최근 변한곳은근미래에 변할 가능성이 높으므로중요도가 높다한동안 변하지 않았다면 크게 신경쓸 필요가 없음함께 늘어놓지 않고 숨겨두면 가독성 향상Caching 에서 늘 얘기되는 Temporal Locality최근 참조된 영역은근미래에 다시 참조될 가능성이 높다

26. 과거 변화량 분석pysvn 을 이용하여 과거 변화량을 분석하는300 줄 남짓의 python script 작성

27. 파일 변화량 시각화알 수 있는게 별로 없다

28. 일주일 단위로 묶어서 조사이제 뭐가 좀 보이는군최근 변경일 및 변경수로 정렬하면..

29. 전체를 보면전부 늘어놓으면:

30. 활용 #1변동성이 높은 파일변동성이 높은 파일은말그대로 “HOT” 한 파일개선시켰을때 효용이 높다신규 프로그래머의 진입장벽/정보과잉 해소

31. 활용 #2변동성이 낮은 파일변동성이 낮은 파일은별도 프로젝트나 DLL 로 분리를 고려개발환경의 복잡도를 낮출 수 있다빌드 시간을 줄일 수 있다WTL80DNFSplinetinyxmlEquipmentImagePack…뭔가 라이브러리화해야할것 같은 놈들

32. 활용 #3변동성이 높으면서 파급력도 높은 파일변동성이 높은 파일이파급력도 높다면 명백하게 좋지 않은 상황

33. 활용 #4변동성이 높으면서 파급력도 높은 파일시간에 따른파급력 조사irdmonster.h 의 변경으로 인해재컴파일 된 파일 수:1주일 평균 약 3178개 !

34. commit 내용 중 바뀐 부분의함수명을 추적해서함수별 변화량 분석활용 #5함수별 변화량 분석Profiler::DumpProfiler::ResetNode

35. 활용 #5함수별 변화량 분석

36. 활용 #5함수별 변화량 분석 (던파)Packet Handler 와 함께setState 가 빈번하게 변화State Machine 관련해서데이터드리븐 고려 가능

37. 다른 프로젝트들은 어떨까?국내 대표 장수 프로젝트들 총출동!던전앤파이터크아 BnB메이플스토리

38. 활용 #5함수별 변화량 분석 (CA BnB)이벤트 핸들링을 스크립트로 분리?UsingContents: Data-Driven 여지?PacketName: 공정 자동화 여지?

39. 활용 #5함수별 변화량 분석 (MapleStory)공격관련 함수 쪼개기 고려?

40. 활용 #6로그 메시지를 고려한 변화량 추적“로그 메시지를 고려해서정량적 추적이 가능하지 않을까?”

41. 활용 #6로그 메시지를 고려한 변화량 추적 (던파)bugfix 로그 고려 변화량 추적: 나름 그럴싸CNATFighter::setSTATE******onChangeSkillEffectonBeforeAttack / onAfterAttackState Machine 관련해서시스템 마련/교육/체크리스트 고려가능

42. 활용 #6로그 메시지를 고려한 변화량 추적 (던파)revert 로그 고려 변화량 추적:의의가 크지 않음1. 대상 자체가 적다2. 같은 기간에 작업된것이 함께 revert 되는 경우들

43. 활용 #6로그 메시지를 고려한 변화량 추적 (CA BnB)주로 보상치 계산에서 높은 빈번한 등장 (밸런싱 문제?)서버에서 스크립트를 통한 계산등을고려할 수 있지 않을까?잘은 모르지만...

44. 활용 #6로그 메시지를 고려한 변화량 추적 (MapleStory)스킬 관련된 함수들이 많다타이밍에 따라 퍼져있는 스킬관련Asynchronous 로직을 모으거나 시스템으로 정리?잘은 모르지만...

45. 아예 소스 라인별로 변화량을 추적하면 더 구체적인 것들을 알 수 있지 않을까?소스 내 상수 또는 파라메터라던가..자꾸 변하는 if 내 조건문 이라던가..함수내 변동성이 두드러지는 부분의 분리를 위해서라던가..BUT..파일과 함수는 indexing 할 key 가 있지만라인별 바뀐 부분은 어떻게 추적 하지?활용 #6소스 라인별 변화량 추적

46. LCS(Longest Common Subsequence)알고리즘을 이용공통 부분과 아닌 부분의 변화를 추적(diff-like)활용 #6소스 라인별 변화량 추적po다이내믹프로그래밍wer

47. 소스를 라인단위로 hashing 한 후 LCS 응용1 공통부분 sequence 의 변화량는 보존 이동2 다른부분 sequence 의 변화량은 정규화 후 증가활용 #6소스 라인별 변화량 추적

48. 소스를 라인단위로 hashing 한 후 LCS 응용1 공통부분 sequence 의 변화량는 보존 이동2 다른부분 sequence 의 변화량은 정규화 후 증가활용 #6소스 라인별 변화량 추적

49. 활용 #6소스 라인별 변화량 추적두드러지는 부분에서데이터로 뽑아내야 할 부분이많이 발견되긴 했지만..

50. 활용 #6소스 라인별 변화량 추적입력 자체가 너무 적어서대부분의 소스에서유의미한 결과가 나오지 않음FAIL

51. 활용 #5UnityBuild*추천자료*변동성이 낮은 파일을 기준으로 묶은 후Unity Build 를 적용하여 빌드시간 단축

52. 변동성이 큰 파일은 묶지 않으므로기존 UnityBuild 의 단점 해소 가능#include 누락 오류가 숨겨지는 문제파일 제거시 UnityBuild 재구축 필요작은 cpp 만 바꾸어도 큰 파일로 컴파일됨활용 #5UnityBuild

53. UnityBuild 적용60일이내 바뀌지 않았고변경이 많지 않았던 파일들을묶어서 UnityBuild 적용

54. 활용 #5UnityBuild 적용53% 감소(x2.1 향상)BeforeAfter반절만 적용하고도 2배 이상 속도향상

55. 정리 1부 변화량 추적변동성이 높은 낮은 파일은 별도로 분리개발환경의 복잡도 저하, 빌드 시간 단축변동성을 기준으로 UnityBuild 적용빌드 시간이 단축되면서 기존 UnityBuild 기법의 단점 보완변동성이 낮으면서 파급력이 높은 파일설계나 의존방식을 재점검함수별변동성 (+로그 고려)그럴싸해보이는 결과변동성이 높은 부분의 분리나 공정 효율 리서치버그수정이 잦은 부분에 대해 시스템이나 프로세스 점검

56. 왜 commitor 를 분석하지 않는가?“숫자의 함정” 에 빠질 수 있다“프로그래머별 커밋 당 버그 비율”따위를 측정하게됨이런 수치가 존재한다는것만으로디펜시브해지고, 커밋을 오래 끌게된다릴리즈 전 빠른 버그 발생과 수정은 오히려 권장사항대표적인 숫자의 함정“버그 발생 수”프로그래머 KPITDD 도입에 “테스트 실패율” 표시“단기 매출”중심의 기획 평가…

57. 2부지속 가능한코드 퀄리티 관리를 위한 방법들

58. 청소 메타포:청소하는 요령청소한곳과 안한곳을 구분짓는다청소한곳은 다시 어지럽히지 않는다

59. 영역으로 구분지어 점진적으로 정리하라한번에 모든 것을 정리하는 것은 때론 비용이 크고효율적이지 않다중요한 곳과 중요하지 않은 곳을 구분하여 정리한다현명한 포기가 필요정리된 곳과 정리되지 않은 곳을 구분하여 점진적으로 정리한다

60. 직관의 함정우리 머릿속의 코드 정리

61. 현실대상에 대한 우리의 직관은현재에 머무르기 쉽다미래의 변량을 고려해서 관리해야

62. 다시 어지럽히지 말라지속가능한 코드 퀄리티 관리의핵심

63. 어느경우 쓰레기를 쉽게 버릴것 같은가?청소 전청소 후“더럽네” vs. “깨끗하네” 로 인지됨청소한 후에는 사람들이 쓰레기를 쉽게 버리지 않음다시 어지럽히지 않기

64. 어느경우 쓰레기를 쉽게 버릴것 같은가?청소 전청소 후청소해도보람이 없다!양쪽다 “더럽네” 라고 인지여전히 사람들은 쉽게 쓰레기를 버린다다시 어지럽히지 않기

65. 다시 어지럽히지 않기지켜지지 않음All or None: 전부 치우기 전에는 효과를 보기 힘든것이 많다보람이 없다 -“뭐 나아지는거 있어?”관심없으면 잊혀진다인간은 망각의 동물알아도 습관은 고치기 힘들다프로그래머가 많을수록 난이도 급상승청소의 메타포만으로는 한계가 있다보이는대로 일일히 체크하고, 잔소리하고, 고치는것은 구시대적

66. 공정을 개선하라시스템화,프로세스 구축 필요잔소리를 할 필요도 들을 필요도 없다힘들게 습관을 고칠 필요가 없다실수를 걱정하지 않아도 된다지속 가능하다

67. 정리 2부 지속적인 코드 퀄리티 관리영역으로 구분지어 점진적으로 정리하라다시 어지럽히지 말라공정을 개선하라

68. 3부공정 개선을 위한 팁

69. 기존의 도구 / 시스템들AssertionASSERT(..)Lock OrderingNeeds_LockCheck Caller ThreadSystemScoped LockSmart Pointerformat stringNullable Type / Non-nullable Type 분리ValidatorStatic AnalysisSyntax CheckingUnit TestsCompiler Warning코드퀄리티 저하를 예방하는

70. 코드퀄리티 저하를 예방하는Assertion특히 멀티쓰레딩 관련 Assertion 들은 매우 유용:같은 로직흐름에서 재현이 되지 않는 부분을 smoke test 만으로 감지할 수 있게 해줌없을때와 천지차이Lock Ordering데드락 방지Needs_Lock락 없는 접근 방지Check Caller Thread부르지 말아야 할 쓰레드에서 부르는 것을 방지

71. 리빙포인트:ASSERT 를 구분하면 좋다DomainSystem / Performance-critical vs. Not criticalCompileCompile / Do not compileActionIgnore / MsgBox / Log / SendPacketMsgBoxIgnore this / Ignore this type / Ignore all

72. 코드퀄리티 저하를 예방하는SystemScoped LockSmart Pointer여러분들 다 아시는 그것format stringboost::formatC#-style formatNullable Type / Non-nullable Type 분리NULL check 는 가장 흔하면서 치명적인 실수모조리 NULL check 를 넣는것이 좋지만은 않다

73. 코드퀄리티 저하를 예방하는ValidatorStatic Analysisex) LINTSyntax Checkingex) php -l /path/to/your/file.phpUnit TestCompiler Warning역시나 다 아시는 그것

74. Validator: 문제지속가능하지 않다(일반적으로)계속 운용되지 않는다강제성이 없다 / 행동을 유발하지 않는다자주 볼수 있는 현상:1. 한번 돌려보고 정리한 후 망각2. 혹은 돌려보고 “이런게 있네”망각3. 정기적으로 돌려보려 하지만 잘될리 없다

75. 지속 가능한 Code Validation과거~현재는 영역으로 분리하고,미래는 시간으로 분리하라현재데이터과거데이터미래데이터변화빌드시스템에서 validation 수행지속적으로 수행 가능하다관리된 상태를 위해 과거를 모두 정리할 필요가 없다과거를 신경쓰지 않을 수 있다커밋될 때 validation 을 수행+ 강제성을 부여할 수 있다default 로 validation check 하되, 과거 데이터는 <ignore> tagging_CRT_SECURE_NO_DEPRECATE, #pragma warning(disable:####)Validator 에 파일마다 태깅하고 선택적으로 무시할 수 있는 기능을 넣어라주의: 미래에 추가되지 않도록 유의할것. 가능하다면 추가되는것도 시스템으로 막는다변화미래 변화관리

76. SVN pre-commit hook

77. Code Validation 활용활용 제안:단순 Coding Style 관리금지된 API 관리주석 관리중복 관리스크립트 소스오타 관리Format String 관리초기화관리삭제 관리

78. 단순 Coding Style 관리단순 coding style 관리금지된 API 관리주석 관리중복 관리스크립트 소스오타 관리format string 관리초기화 관리삭제 관리naming convention, white space, 금지된 API 호출, …ex)별도의 Timer System 이 있기 때문에 GetTickCount, timeGetTime 이용 금지파일 입출력시 전용 프레임웍 이용: CreateFile, fopen 이용 금지쓰레드 생성시 CreateThread 이용 금지, _beginthread / _beginthreadex 만 사용할것로직에서는 scoped lock 만 사용할것. EnterCriticalSection 직접 사용 금지

79. 주석 관리사용하지 않는 주석처리된 코드미리 약속한 주석 컨벤션 (doxygen/함수 파라메터 주석 등)코드양에 비해 부족한 주석단순 coding style 관리금지된 API 관리주석 관리중복 관리스크립트 소스오타 관리format string 관리초기화 관리삭제 관리

80. 중복 관리중복코드 퀄리티 관리에서 가장 치명적인것중복을 감시해보자추가된 코드의 diff 부분을 column 으로전체 소스를 row 로 잡아일정 이상의 연속끊김 등을 처리한LCS 응용으로 중복정도를 검사가능whitespace는 무시하고라인단위보다 구문분석단위면 좋겠지시간복잡도 O(NM),공간복잡도 O(2N) 만으로 OKbacktrack 하려면 좀더 들지만..단순 coding style 관리금지된 API 관리주석 관리중복 관리스크립트 소스오타 관리format string 관리초기화 관리삭제 관리

81. 스크립트 오타 관리스크립트는 편리하지만 오타에 의한 실수가 많음실행이 되어야만 확인가능Symbol 만 뽑아낸 후통계적으로 오타를 예방한다면?다른 Symbol 과 문자열 유사도 높으면서단 한두건밖에 존재하지 않는다면 경고 처리단순 coding style 관리금지된 API 관리주석 관리중복 관리스크립트 소스오타 관리format string 관리초기화 관리삭제 관리

82. Format String사소하면서 치명적인..NULL pointer 와 함께사소하면서 치명적 문제를 발생시킨다boost::format 를 쓸 경우..C++ 식 해결법이지만, 많은 사람에게 익숙하지 않음 (오히려 망가지기 쉽다)별도 format string 을 사용하는 프로젝트엔 꼭 구코드가 함께한다일관성이 흐트러지기 쉬움단순 coding style 관리금지된 API 관리주석 관리중복 관리스크립트 소스오타 관리format string 관리초기화 관리삭제 관리

83. Format String“커밋시 자동보정하도록 하는건 어떨까?”Type Checking 은 컴파일러에게 맡긴다별도의 Static Analysis 를 위해선 C++ 컴파일러를 만들어야함Validator 는 Type Checker 가 없을 경우 삽입하고인자 개수와 Type Checker 만을 확인아주 간단한 텍스트 프로세싱으로 가능단순 coding style 관리금지된 API 관리주석 관리중복 관리스크립트 소스오타 관리format string 관리초기화 관리삭제 관리

84. 자동보정Pre-commit Hook 에서 커밋 내용을 바꿀 수 있나?바꿀 수 있다 BUT 바꾸면 안됨SVN 클라이언트가 캐시로 인해 오동작서버에서 별도로 변경 및 커밋을 Trigger귀찮긴 하지만 생각해볼 수 있는 방법단순 coding style 관리금지된 API 관리주석 관리중복 관리스크립트 소스오타 관리format string 관리초기화 관리삭제 관리

85. 초기화관리또다른 사소하면서 치명적인..NULL pointer 관리와 함께사소하면서 치명적 문제를 발생시킨다당연하지만 누락이 빈번int, float, pointer type 등의 primitive type 은 반드시 생성자에서 초기화하도록 강제성능상 문제있는곳은 따로 ignore flag tagging

86. 삭제 관리사람들은 삭제를 하지 않는다프로그래머만 국한된 얘기가 아님만드는건 당장 필요하지만제거하는건 당장 필요하지 않다보이지 않지만 중요한..문제가 되었을때는 이미 늦어있다 – Resource Leak나중에 가면 대처하는것도 일이다생몰 쌍 맞추기생성자 / 파괴자 안의 생성/파괴 쌍을 규격화시키고 맞춰주기delete 누락 방지기본적으로 new 만 있고 delete 가 없을 경우 경고소유권 이전시 별도 표시하도록 (ignore flag)

87. 리빙포인트:Validator의 Action Level 을 구분하면 좋다커밋 거부자동 보정본인 통지프로그래밍 팀 통지프로그래밍 팀장 통지Lazy Action코드 주석, 중복 등은 빡빡하게 관리하면 더 불편해질 수도 있다ex)코드 주석은 1주일 후 자동 제거3회 이상 중복 코드는 1주일마다 지속적 통지시간에 따라 통지 수준을 높이기

88. 정리3부 공정 개선을 위한 팁기존 도구 / 시스템들AssertionSystemValidator지속 가능한 Code ValidationCode Validation 활용단순 Coding Style 관리금지된 API 관리주석 관리중복 관리스크립트 소스 오타 관리Format String 관리Initialization 관리

89. 추후 시도/개선사항인터페이스의 변화를 추적서비스 적용 여부와 함께 추적서비스 적용 전 버그 수정 커밋은 미덕서비스 적용 후 버그 수정 커밋은 악덕좀더 밀도있는 변화 추적커밋 할때마다 컴파일 할때마다Symbol 별 변화 추적실제 변동성 진단에 기반한 효율적 개선 사례다양한 지속가능한 Validator 시도

90. 저비용 고효율자동화현명한 포기점진적 정리분리사람이 일일히 하기에 큰 규모1. 분석 자동화2. 운용 자동화변동성이 많은 것이 중요한 것이다중요한 것 위주로 신경쓴다 중요하지 않는것은 신경을 끈다 (현명한 포기) 중요하지 않는것은 신경이 쓰이지 않도록 한다“청소하는 요령”한번에 모두 정리하려면 힘빠진다. 점진적으로 정리해나간다청소한곳과 안한곳을 구분짓는다 (공간적 분리)청소한곳은 다시 어지럽히지 않는다 (시간적 분리)

91. 현명한 포기란..포기하는 방법이 아니라,학습된 좌절로부터 벗어나포기하지 않는 방법

92. END감사합니다송창규innover@neople.co.krtwitter @innovari