Introduce Me & Here¶

소프트웨어 아키텍처의 결정적 순간에서 잘못된 판단이 조직에 막대한 비용을 초래합니다. Software Architect로서 저는 이러한 리스크를 사전에 제거하고, 의사결정의 재현성(Decision Reproducibility)을 조직에 이식하는 전문가입니다.

If I have seen further it is by standing on the shoulders of Giants. - Sir Isaac Newton
내가 멀리 볼 수 있었던 것은 거인의 어깨 위에 있었기 때문이다. - 아이작 뉴턴

다음과 같은 경우에 이 사이트의 콘텐츠와 상담을 권합니다.

아키텍처 방향 결정으로 고민이 있는 CTO / 기술 리더
확장성과 유지보수 비용 리스크를 줄이고 싶은 팀
아키텍처 의사결정에 객관적 분석이 필요한 경우
IT 기술적 선택의 파급력을 알고 싶은 CEO
직감(Intuition)에 의존한 개발에서, 논리와 근거 기반의 엔지니어링으로 전환하고 싶은 조직

왜 기록하나?¶

Architect 및 Architecture에 대한 대중적 이해 부족 개선
Software Architect로서 지식/경험을 체계적으로 정리하여 자산화
커뮤니티에 긍정적 영향력 확산
개인 회고를 위한 기록
후배 개발자 및 동료와의 지식 공유

이 문서들은 개인적인 기록이면서 동시에, 제가 실제 프로젝트에서 반복적으로 마주했던 아키텍처 판단 오류와 구조적 문제를 정리한 결과입니다.
일반적인 질문이나 개인 프로젝트 수준의 고민은 이 문서들만으로도 충분한 판단 근거를 얻을 수 있도록 작성되었습니다.

블로그가 아닌 이유¶

지식과 정보는 단독으로 존재하는 것이 아니라, 유사 개념이나 동일 사건에 대한 다른 관점에서의 서술 등 다양한 연관성을 가지고 있습니다.

정확히는 그런 연관성을 통해 지식을 활용할 수 있어야 올바른 사용이며, 그렇지 않다면 그것은 암기에 불과합니다. 따라서 회고록을 단순히 기록하는 것이 아니라 상호 관계에 따라 지식의 연결망을 만들어야 하지만, 일반적인 블로그에서 현실적으로 많은 수정 비용이 발생합니다. 그나마 위키 시스템이 그와 유사하나, 개인 목적으로 작업하기에는 위키 시스템의 생산성이 높지 않습니다. 따라서 mkdocs를 이용한 정적 사이트를 구성하였습니다.

현재 이 사이트의 모든 문서 작업은 VS Code에서 Markdown으로 작성하며, 문서 간 관계에 따라 수시로 갱신됩니다

혹시 글에 대한 질문 or 의견이 있다면?¶

GitHub Issues (https://github.com/js-seth-h/website/issues)에 질문을 남겨주세요.

다만 답변은 개별 질문 글에 답하는 형태보다 별도의 문서를 작성하는 형태를 우선 고려중입니다. 이 방법이 기록이라는 사이트의 목적에 부합하기 때문이니, 양해 바랍니다.

문의 및 상담 안내¶

저 또는 문서의 내용에 관한 질문이 있거나, 프로젝트에 대해서 고민이 있다면 아래 문서를 확인해주세요.