표준 1C 구성 아키텍처의 치명적인 구조적 결함
표준 1C 구성에서는 비즈니스 로직이 폼(Form)에 직접 주입되는 경우가 많아, 실행 환경이 클라이언트로 제한됩니다. 폼 및 객체 모듈 내 프로시저는 대부분 내보내기(Export)로 설정되지 않아 확장 기능 없이 직접 호출하기 어렵습니다. 함수 간 결합도가 높고 폼 컨텍스트에 강하게 의존하여 격리 원칙을 위배합니다.
이러한 강한 결합의 대표적인 예는 다음과 같습니다.
- 은행 거래 내역서 로딩은 목록 폼이나 문서 폼에서만 가능합니다.
- TIN(사업자등록번호)을 통한 조직 또는 거래처 정보 채우기가 UI 요소에 묶여 있어, 프로그래밍 방식으로 객체를 생성할 때 개발자가 코드를 중복 작성해야 합니다.
이러한 아키텍처 방식은 모듈 재사용과 테스트를 심각하게 저해합니다.
비효율적인 서버 호출 활용
1C 개발자들은 _ServerCall_ 접미사가 붙은 모듈에 과도하게 의존하여 동일한 프로시저 호출을 중복하는 경우가 많습니다. 공용 모듈의 함수는 '서버 호출' 플래그 없이 서버에서 직접 실행되지만, 플래그가 활성화된 프록시 모듈을 통해 다시 호출되기도 합니다. 이는 코드베이스를 불필요하게 부풀립니다.
표준 구성에 수십 개의 이러한 모듈이 존재하면 개발자가 혼란에 빠집니다. 더 깔끔한 방법은 Export 키워드를 사용해 서버 측 프로시저를 직접 내보내어 불필요한 래퍼를 제거하는 것입니다.
가독성을 해치는 방대한 쿼리
데이터 추출은 객체 메서드로 충분함에도 불구하고 주로 쿼리로 처리됩니다. 문서 관리자 모듈에서는 쿼리가 인쇄 데이터를 생성하지만, 레지스터 이동을 계산할 때는 조인(JOIN)과 조건 분기가 난무하는 난해한 구조로 변질됩니다.
이는 선언적 스타일을 고수하느라 가독성을 희생하여 디버깅과 향후 수정을 어렵게 만듭니다. 더 나은 대안은 쿼리와 프로시저 내 명령형 로직을 결합하는 것입니다.
모호한 데이터 구조
인쇄 양식을 생성할 때 여러 표 문서를 단일 문서로 병합하고, 적절한 컬렉션을 전달하는 대신 영역(_Document1_, _Document2_)으로 구분하는 경우가 많습니다. 이러한 컬렉션 구조는 객체를 모방하지만 필드 구성이 비논리적이라 커스터마이징 시 수동 매핑이 필요합니다.
혼란스러운 비동기 호출 체인
1C의 비동기 호출 체인은 문서화가 부실합니다. 프로시저 이름에 설명적 맥락이 부족하고 주석이 없습니다. 현금 영수증 처리 디버깅이 대표적인 예로, 명확한 진입점 없이 긴 호출 시퀀스가 이어집니다.
최적의 해결책은 현재 상태 매개변수를 기반으로 호출을 분배하는 상태 기계(State Machine)를 도입하는 것입니다.
상태 기계 의사코드 예시:
Procedure ExecuteAction(CurrentStatus) Export
If CurrentStatus = "Initialization" Then
InitializeReceipt();
TransitionToStatus("Forming");
Else If CurrentStatus = "Forming" Then
GenerateReceipt();
TransitionToStatus("Printing");
// And so on
EndIf;
EndProcedure안전한 디버깅 환경 부재
현금 등록기 연동과 같은 핵심 작업은 응답 에뮬레이션을 지원하지 않습니다. 코드는 실제 하드웨어 피드백을 기대하므로 가상 테스트가 불가능합니다. 이는 개발 및 통합 단계에서 위험을 크게 증가시킵니다.
불안정한 명명 규칙 및 리팩토링
애플리케이션 객체, 모듈, 필드 이름이 빈번히 변경되며 때로는 _Delete_ 접두어가 붙습니다. 구성에서 _Delete_를 검색하면 수백 개의 결과가 나옵니다. '파트너/거래처/구매자'와 같은 용어는 일관성이 없으며, 엔티티(예: 매입 계약)는 지속적으로 병합되거나 분리됩니다.
이러한 접근 방식은 충동적인 아키텍처 결정을 반영하며, 개발자가 참조 마이그레이션에 시간을 낭비하게 만듭니다.
일관성 없는 인터페이스
UI 요소의 명명 규칙이 매우 제각각입니다. 표 부분의 추가 버튼이 _InventoryAdd 또는 단순히 _Add로 명명될 수 있습니다. 문서의 오른쪽 열은 _RightColumn 또는 _HeaderRight로 불립니다. 이러한 불일치는 자동화 및 확장 기능 개발을 저해합니다.
비효율적인 알고리즘
성능을 강조함에도 불구하고 코드베이스에는 상당한 중복과 부하가 존재합니다. 청구서 인쇄 시 필요한 템플릿은 소수임에도 불구하고 모든 템플릿을 사전에 로드합니다. 온디맨드 캐싱을 도입하면 99%의 경우 오버헤드를 줄일 수 있습니다.
중복된 HTTP 기능
각 팀이 직접 뱅킹, 웹사이트 동기화 등을 위해 HTTP 요청을 고립적으로 구현하며, 통합된 인터셉션 지점이 부재합니다. 중앙 집중식 구성을 위한 표준화된 프록시가 없습니다.
기능적 결함
표준 솔루션은 시스템 설계자의 과도하게 단순화된 가정으로 인해 실제 비즈니스 환경에서 자주 실패합니다.
원가 계산 문제
월말 마감으로 전환하면 대규모 제조업에는 적합하지만, 소매 및 중견 기업에는 병목 현상을 초래합니다. 기간 말 마이너스 잔액이 원가 계산 자체를 완전히 차단합니다.
하드웨어 제한
단일 워크스테이션에서 두 대의 현금 등록기 사용을 금지하는 것은 비즈니스 친화적인 최적화를 차단하는 대표적인 사례입니다.
잘못된 포인트(보너스) 회계
만료되는 보너스는 배치 수준 추적이 필요하지만, 1C는 기본값으로 평균화 방법을 사용하여 계산 오류를 유발합니다. 버전 2.5는 이 문제를 악화시켜 완전한 재작성 없이는 기능을 사용할 수 없게 만듭니다.
구식 접근 권한 모델
역할(Role)은 정적 체크박스에 의존하여 동적 코드 실행을 무시합니다. 전체 접근 권한에 관리 권한이 우연히 포함되어 있어 일반 사용자가 계정 생성이나 전체 데이터베이스 다운로드가 가능합니다.
핵심 요약
- 아키텍처의 경직성: 폼 및 컨텍스트에 대한 강한 결합이 재사용성을 심각하게 제한합니다.
- 코드 중복:
_ServerCall_모듈이 로직을 불필요하게 증식시킵니다. - 가독성 저하 쿼리: 방대한 단일 쿼리가 깔끔한 객체 메서드를 대체합니다.
- 에뮬레이션 지원 부재: 현금 영수증 작업의 격리 테스트가 불가능합니다.
- 불안정한 명명 규칙: 수백 개의
_Delete_요소가 장기 유지보수를 복잡하게 만듭니다.
— Editorial Team
아직 댓글이 없습니다.