MVP (Minimum Viable Product)와 기술 부채에 대처하는 자세

기존에 잘 돌아가는 코드를 수정해야 하는 경우가 생겼습니다.

가급적 기존 코드를 수정 만큼은… 특히 구조나 아키텍처까지 건드려야 하는 상황은 정말로 피해야 하는게 당연한데도 다른 사람은 몰라도 개인적으로는 충분히 문제가 예상되기 때문입니다.

오픈 소스를 Github에 올리기로 마음 먹었을 때 제일 걱정인 부분이 이거 였다는 것을 다시 상기하게 됩니다.

소스 코드를 외부에 공개하지 않아도 되는 경우 개발자 만드는 프로그래밍 소스에 대해 자유도나 팀원들 또는 담당자들과 합의 할 여지가 많습니다. 이것은 기업내 프로젝트든 SI든, SaaS든 어떠한 분야에서든 마찬가지 입니다.

간단한 예를 들면 프로그램 실행시 상용 라이센스 정보나 데이터베이스 연결문자열 등 키 정보를 수급하기 위한 정보 관리를 내부 소스 제어 관리를 이용하거나 비밀 키를 관리하는 시스템을 통해서 가져오도록 하는 부분을 모두가 동일하게 공유 해야 하는 공개 소스로 만드려면 어떻게 해야 할까요?

이러한 딜레마는 정말 일부에 불과합니다

  • 업계에 널리 알려진 범용적인 아이디와 패스워드로 변경하여 공개한다
  • 상용 라이센스 키를 마스킹하여 공개한다
  • 키를 수급하기 위한 프로그램을 추가로 만들어 공개한다
  • 민감한 부분은 아예 공개를 안하고 기술 문서로 남겨둔다
  • 공개되더라도 내부 시스템에 적용되지 않으면 문제되지 않으니 그냥 공개한다

물론 정답은 없으며 적정선에서 타협은 봐야겠지만 기본적으로 프로젝트의 성과는 돈을 더 많이 벌게 하거나 (1순위), 일을 편하게 하거나 (2순위), 제품의 가치를 올릴 수 있을때 (3순위) 나타납니다. 즉 지속적인 비즈니스를 운영 해야 하는 관점에서 성과의 기준을 벗어나는 기술 부채에 고민이 드는 것은 어쩔수 없습니다. 사실 누가 알아주는 경우도 많지 않거든요.

품질은 양심인데 하며 손을 대는 상황에 일이 해결되는 것이 아니라 문제가 점점 커지거나 답이 안나오는 경우에 따라 이런 심리가 반복적으로 생기는 것 같습니다.

  • 어차피 기능적인 결과는 동일한 것을 내가 무슨 영달을 얻으려고 잘 돌아가는 코드를 수정하고 있는지… 번아웃도 가끔 옵니다
  • 구조나 아키텍처까지 건드리면 예상 되어지거나 예상 못했던 사이드 이펙트에 시간이 지연되고 계획해 두었던 일정이 깨지는 스트레스가 옵니다

그럼에도 불구하고 기술 부채들에 대해서 현실적인 고민을 하고 손을 대어 보는 건 충분한 가치가 있습니다.

  • 프로그램 소스 코드에 대한 품질이 높아집니다. 라면 한두개 끓이는 경험과 백개, 천개, 만개를 끓이는 경험은 레시피를 만들때 수준과 깊이가 달라지니까요.
  • 적정선에서 만족스러운 결과를 만들어 냈을때의 성취감은 어제보다 나은 오늘의 나를 만들었다는 자부심을 만듭니다.
  • 어느 순간 나와 비슷한 고민을 해봤던 사람들을 만나게 될때 좀 더 상대방의 겪었던 고충과 이면을 이해하게 되는 시야가 생깁니다.

이번 주에 HandStack 내에서 태넌트 기능을 처리하기 위한 부분을 개선하기 위해 문득 들었던 생각입니다. 읽어 주셔서 감사합니다.

한 주간의 여정 (2024-01-08 ~ 2024-01-12)

  • 회원가입 및 로그인시 UserWorkID, TenantAppRequestPath 사용자 정보 추가하기
  • contract, view 화면을 빌드 디렉토리로 복사하는 스크립트 추가
  • applicationID 를 전달하는 /handsup/api/tenant-app 요청을 수행하는 클라이언트에 UserWorkID를 전달하도록 변경
  • 파일 업로드/다운로드시 설정 파일 위치에 따라 호스트, 태넌트 파일 경로를 구분하도록 개선
  • 프로젝트 참조 패키지 버전 업데이트
  • 파일 업로드시 절대 링크 경로 버그 수정
  • 참조 프로젝트 목록에서 내가 만든 프로젝트가 아닌 경우만 조회되도록 개선
  • 빈 경로에 대한 디렉토리 생성 기능 추가
  • syn.js measureSize(text, fontSize) 기능 개선
  • 태넌트 앱 요청을 수행하는 서버리스 함수(featureMeta.json, featureMain.cs)에 UserWorkID를 하도록 대응 개발
  • handsup 확장 모듈 메뉴 표시, 순서 정리
  • 태넌트 앱 UI Assets 디렉토리 조회 기능 개선
  • UI Assets 관리 화면 파일 관리 기능 개선

HandStack 확인하기

7개의 좋아요

연속해서 같은 제품에 대한 홍보글을 올리셔서 부득이하게 모든 글을 숨김처리하였습니다. 닷넷데브 행동강령 (온라인 커뮤니티 행동 규범) 중 다음의 사항을 위반한 것으로 간주하여 취한 조치임을 말씀드립니다.

  • 인내심을 가져주세요. 포럼, 메일링 리스트, 코드 기여 (즉, 비동기적 형태의 커뮤니케이션)에 대부분 적용되는 것이 인내입니다. 커뮤니티는 참여자든 조직자든 자발적인 참여로 이루어지는 경우가 많습니다. 여러분의 질문이나 코드 기여 또는 제안에 대해 즉각적인 응답을 얻지 못할 수도 있습니다. 인내를 가지고 커뮤니티의 일반적인 기준을 고려해 주세요. 답변을 구하는 요청을 한 번 정도 보내는 것은 좋습니다. 하지만 답변을 줄 것을 반복적으로 재촉하는 것은 무례한 행동이 될 수 있습니다. 또한, 여러 스레드에서 같은 질문을 게시하는 것은 눈살을 찌푸리게 하므로 삼가해 주시기 바랍니다.

제품의 가치는 무리한 홍보 행위에서 오는 것이 아니라, 제품 개발과 개선에 더 많은 시간을 투자로부터 오는 것이라고 생각합니다. 연속 포스팅은 지양해주시고, 커뮤니티 회원들과 소통하는 것에 집중해주시기를 부탁드립니다.

만약 같은 상황이 반복될 경우 로그인 차단 등의 좀 더 엄격하고 강력한 제약이 가해질 수 있으니 유의 부탁드립니다.

참고로 숨김 처리한 글들은 다음과 같습니다.

1개의 좋아요