제가 좋아하는(?) 윤석찬님께서 좋은 블로그를 올려주셔서 공유해봅니다. (석찬님 트위터에도 있는 내용) 제가 운영하고 있는 데보션 사이트에도 기술 부채가 좀 많아보이는 코드를 가지고 있는데 시간이 지나면서 기록하지 않아서 코드만 봐서는 도저히 왜 이렇게 했었지? 하는 생각이 많이 들때가 가끔 있거든요. 이 블로그에서 소프트웨어 공학적으로는 아래와 같은 프로세스를 만들 것을 권장하고 있네요. 1. 기술 의사 결정 과정을 기록하세요. ‘아키텍처 결정 기록 (Architecture Decision Records, ADR)’은 소프트웨어 아키텍처에 필요한 구성 요소에 대한 의사 결정, 동기 및 맥락 및 그리고 결과에 대해 설명하는 간단한 문서입니다. 2. 해결하려는 문제를 정확히 파악하세요. 문제에 대해 정의를 내리고, 도입하려는 기술에 대한 동기와 맥락을 정확히 알아야만 올바른 의사 결정을 할 수 있습니다. 맥락을 파악하려면, 만든 사람에게 물어보거나 그 사람이 쓴 책이나 강연, 혹은 논문을 찾아서 읽어 보는 것을 권장합니다. 3. 문제 해결 기술 후보를 선정하고 테스트 하세요. 요즘에는 클라우드 컴퓨팅 활용이 보편화 되면서, 요구 사항에 맞는 솔루션들이 모듈화되어 나오는 경향이 있습니다. 손쉽게 사용해 볼 수 있는 클라우드 서비스가 늘어나면서 테스트해 볼 수 있는 기술 선택의 폭도 넓어졌습니다. 마지막으로… 가끔 오버엔지니어링이 필요할 때도 있습니다. 예를 들어, 시스템 보안이나 개인 정보 보호 같은 영역은 법적인 규정 준수 문제들이 있기 때문에 더 많은 고려가 필요합니다. 팀 내 여유가 있고 일정에 영향이 없을 때 다양한 기술에 대한 실험적인 프로토 타이핑을 하는 것도 좋습니다. 참 저도 소프트웨어공학 전공자이다보니 이런 글이나 SRE 관련 글들을 볼때면 관심 갖고 보게 되고, 공유하고 싶어지는 거 같습니다!