공기업 전산직인데 프로젝트 제안서 기술검토를 처음으로 맡았음
우리 사내에 여러가지 시스템이 있고 이번에 구축하려는 시스템이 다른 시스템 3개랑 연계가 되어야 함.
한 업체 제안서 내용인데
시스템 간 연계를 api로 하는게 아니라 걍 DB 링크를 서로 오픈해서 다이렉트로 데이터 공유하는 식으로 연계하겠다고 써놓음.
근데 이걸 무슨 간편하고 직관적인 방식이라고 장점으로 써놨는데 이게 맞음?
옛날 아키텍처에서 쓰던 방식 아닌가 저거?
공기업 전산직인데 프로젝트 제안서 기술검토를 처음으로 맡았음
우리 사내에 여러가지 시스템이 있고 이번에 구축하려는 시스템이 다른 시스템 3개랑 연계가 되어야 함.
한 업체 제안서 내용인데
시스템 간 연계를 api로 하는게 아니라 걍 DB 링크를 서로 오픈해서 다이렉트로 데이터 공유하는 식으로 연계하겠다고 써놓음.
근데 이걸 무슨 간편하고 직관적인 방식이라고 장점으로 써놨는데 이게 맞음?
옛날 아키텍처에서 쓰던 방식 아닌가 저거?
그거 하지말라고 나온게 API 방식임
그니깐 저걸 특장점으로 써놔서 어이가 없는데 검토의견을 써야하니까 제대로 확인해볼려고 ㅅㅂ
업체 종속성을 이용해 향후, 계속 유지보수에 붙겠단거잖아
그럼 이렇게 써놓지 그래 직접 DB 방식은 단기적 구현이 편하나, 보안, 유지보수, 시스템 유연성 측면에서 공공 시스템 아키텍쳐 표준과 배치됩니다. 특히 DB 접근제어 및 로깅 미비가 심각한 문제로 이어질 수 있으며, 차후 유지 보수 업체 변경시 종속성 우려도 존재합니다. 따라서 API 기반 연계방식으로 전환하여야합니다.
그거 하면 장점) 구현이 존나게 빠름. 간단하고 빠르게 돌아감 단점) 이후에 유지보수가 그 업체에 종속될 확률이 농후함(복잡도 관리를 짠 사람만 알기 때문)
이런 방법이 있었네
아키텍쳐만 판단하기는 정보가 부족함. 경우에 따라 더 효율적일 수도 있으니까.
기간이 일주일 정도로 개짧으면 모를까. 그냥 하지말란 방식임 저건
저 방식이 효율적인 경우 딱 하나 뿐임 래핑된 API 호출 자체가 오버헤드 비용이 문제될정도로 많은 데이터를 받아야한다 이 시나리오 외에는 무조건 지양해야함
데이터 싱크가 중요할 경우(주문 <-> 재고)에는 많이 사용됨 그런 경우도 primary, secondary, 보안, 성능, 로그, 알림 물론 다 고려해서 판단함
그렇군 현업인 너가 더 정확하겠지 그럼
rfp 확인은 해본거야? 니 조직 누군가가 시키거나 써놓은 rfp에 부합하는 제안서 아냐?
공기업에서 많이 하는 방식임. 보안 상 안전할 확률도 높고. 어짜피 인터페이스용 테이블들은 따로 생기게될거라, 복잡도도 문제없음. 위에 저 현업에서 일 한 번 안해본 커뮤 망령 말 들을 필요 없음.