안전입찰 2.0 시스템

1. 고객사 소개

• 기관: 조달청
• 대상 시스템: 전자 조달 입찰의 외부통제 영역
• 대상 사용자: 전자 입찰에 참여하는 기업 담당자
• 과제: 입찰 과정의 보안을 유지하면서 처리 속도와 안정성 개선

당사는 차세대 안전입찰 2.0 시스템 구축에 참여했습니다.

2. 도입 배경

공공 조달의 전자 입찰은 정해진 시각에 수많은 기업이 동시에 접속합니다. 마감 직전 몇 분에 트래픽이 몰리고, 그 시간에 시스템이 느려지면 입찰 자체를 못 하는 기업이 생깁니다. 한 번의 지연이 곧 기업의 사업 기회 상실로 이어지는 구조입니다.

동시에 이 시스템은 높은 보안 수준을 요구합니다. 입찰 금액은 공개되기 전까지 보호되어야 하고, 입찰자 본인 확인이 정확해야 하며, 부정한 방법으로 다른 입찰 정보를 얻는 시도를 막아야 합니다. 공정성이 무너지면 조달 제도 자체가 흔들립니다.

보안과 속도가 부딪힌다

문제는 이 두 요구가 서로를 밀어낸다는 점입니다. 보안을 강화하면 확인 절차가 늘어나고, 절차가 늘면 처리가 느려집니다. 입찰자 PC에서 동작하는 보안 모듈은 실행 시간이 길어질수록 마감에 쫓기는 사용자의 부담이 됩니다.

기존 시스템에서는 보안 모듈이 무겁게 동작해 실행이 지연되는 문제가 있었습니다. 입찰 마감이 임박한 시점에 이 지연은 단순한 불편이 아니라 참여 자체를 막는 요인이 됩니다.

다른 프로그램과 충돌한다

또 하나의 문제는 사용자 환경입니다. 입찰 담당자의 PC에는 업무용 프로그램이 여러 개 설치되어 있습니다. 보안 모듈이 시스템 자원을 많이 점유하거나 다른 프로그램과 간섭하면 충돌이 발생합니다.

충돌이 나면 입찰 담당자는 원인을 알 수 없습니다. 어떤 프로그램 때문인지 알 수 없으니 재설치를 반복하게 되고, 그사이 마감 시각은 다가옵니다. 기관 입장에서는 문의가 폭증하고, 대응에 인력이 묶입니다.

개선의 기준을 정하다

안전입찰 2.0은 보안 수준을 낮추지 않으면서 이 두 문제를 푸는 것을 목표로 했습니다. 실행 속도를 높이고, 다른 프로그램과의 충돌을 줄이고, 결제와 관련된 절차의 보안을 강화하는 것이 과제였습니다.

한 줄 요약 보안을 낮추지 않으면서 빠르게 만드는 것이 과제였습니다. 둘 중 하나를 포기하는 선택지는 없었습니다.

공공 시스템의 제약

민간 서비스라면 "권장 환경"을 안내하고 그 밖의 환경은 지원하지 않을 수 있습니다. 공공 조달은 그럴 수 없습니다. 입찰에 참여하려는 기업이 어떤 PC를 쓰든 동작해야 하고, 특정 환경에서만 된다면 그 자체로 참여 기회의 불균형이 됩니다.

이 제약은 개발 방식을 바꿉니다. 최신 환경을 전제로 만들 수 없고, 설치된 다른 프로그램을 통제할 수도 없습니다. 어떤 조건에서도 최소한의 동작을 보장하는 쪽으로 설계해야 합니다.

검증 범위도 넓어집니다. 여러 환경 조합에서 반복 확인해야 하므로, 기능 개발보다 검증에 들어가는 비중이 큽니다. 이것이 공공 과제의 일반적인 특성입니다.

3. 활용 기능

보안 처리 구조를 다시 설계하고, 사용자 환경에서 발생하던 충돌 요인을 제거했습니다.

처리 구조 개선

보안 확인 절차를 단계별로 나누고, 반드시 순서대로 해야 하는 작업과 병행할 수 있는 작업을 구분했습니다. 모든 절차를 직렬로 처리하면 각 단계의 시간이 그대로 합산되지만, 독립적인 확인을 함께 진행하면 전체 소요 시간이 줄어듭니다.

불필요하게 반복되던 확인도 정리했습니다. 같은 세션 안에서 이미 확인된 항목을 다시 검사하지 않도록 하고, 결과를 재사용할 수 있는 구간을 찾아 중복을 없앴습니다.

자원 점유 축소

보안 모듈이 사용자 PC에서 차지하는 자원을 줄였습니다. 상주하며 계속 동작하던 부분을 필요한 시점에만 동작하도록 바꾸고, 메모리에 올려 두던 데이터를 정리했습니다.

자원 점유가 줄면 다른 프로그램과 부딪힐 가능성도 함께 줄어듭니다. 충돌 문제의 상당 부분이 자원 경합에서 비롯되기 때문입니다.

충돌 요인 제거

다른 업무 프로그램과 간섭이 발생하던 지점을 찾아 처리 방식을 바꿨습니다. 시스템 전역에 영향을 주던 동작을 프로그램 내부로 한정하고, 외부 환경에 대한 가정을 줄였습니다.

사용자 PC의 환경은 통제할 수 없습니다. 어떤 프로그램이 설치되어 있을지 알 수 없으므로, 보안 모듈이 환경에 덜 의존하도록 만드는 것이 유일한 해법이었습니다.

결제 절차 보안

입찰과 연결된 결제 과정의 보안을 강화했습니다. 금전이 오가는 구간은 다른 구간보다 요구되는 수준이 높고, 처리 결과가 명확히 기록되어야 합니다.

주요 기능

보안 확인 절차 수행

입찰 참여 시 필요한 확인 절차를 수행합니다. 절차를 단계로 나누고 순서 의존성이 없는 작업은 함께 처리해 소요 시간을 줄였습니다.

중복 검사 제거

같은 세션에서 이미 확인된 항목을 다시 검사하지 않습니다. 반복 확인이 실행 시간의 상당 부분을 차지하고 있었습니다.

자원 사용 최적화

상시 동작하던 처리를 필요 시점으로 옮기고, 메모리 사용을 줄였습니다. 프로그램 용량도 함께 축소했습니다.

환경 의존 축소

사용자 PC의 다른 프로그램과 간섭하던 동작을 프로그램 내부로 한정했습니다. 설치 환경이 제각각인 조건에서 안정성을 확보하기 위한 조치입니다.

결제 프로세스 보안화

입찰과 연계된 결제 절차의 보안을 강화하고, 처리 결과를 기록으로 남깁니다.

오류 상황 안내

문제가 발생했을 때 원인을 구분해 안내합니다. 사용자가 무엇 때문에 멈췄는지 알 수 없으면 재설치를 반복하게 되고, 마감이 임박한 상황에서 이는 치명적입니다.

처리 이력 기록

수행한 확인 절차와 결과를 기록합니다. 문제 발생 시 어느 단계에서 멈췄는지 확인할 근거가 됩니다.

호환 환경 검증

여러 환경 조합에서 동작을 확인했습니다. 공공 시스템은 사용자가 쓰는 환경을 지정할 수 없으므로, 폭넓은 조건에서 검증이 필요합니다.

속도를 개선한 방법

실행 시간을 줄이는 방법은 크게 세 가지입니다. 할 일을 줄이거나, 순서를 바꾸거나, 같은 일을 더 빠르게 하는 것입니다.

보안 시스템에서 첫 번째 선택지는 쓸 수 없습니다. 확인 항목을 줄이면 검증 수준이 내려가고, 그것은 제도의 신뢰와 직결됩니다. 그래서 두 번째와 세 번째에 집중했습니다.

순서를 바꾸는 작업은 절차 사이의 의존 관계를 확인하는 것에서 시작합니다. A가 끝나야 B를 할 수 있는지, 아니면 독립적으로 수행 가능한지 하나씩 따져야 합니다. 관행적으로 순서대로 처리하던 것 중 상당수가 병행 가능했습니다.

같은 일을 빠르게 하는 작업은 중복 제거였습니다. 한 세션 안에서 같은 항목을 여러 번 확인하던 부분을 찾아 결과를 재사용하도록 바꿨습니다.

충돌을 줄인 방법

충돌은 대개 두 프로그램이 같은 자원을 두고 부딪힐 때 생깁니다. 자원 점유를 줄이면 부딪힐 일 자체가 줄어듭니다.

상주하며 계속 동작하던 처리를 필요한 시점에만 동작하도록 바꾸고, 메모리에 올려 두던 데이터를 정리했습니다. 프로그램 용량이 줄면서 설치와 실행 과정의 부담도 함께 줄었습니다.

시스템 전역에 영향을 주던 동작을 프로그램 내부로 한정한 것도 효과가 컸습니다. 외부 환경에 개입하는 범위가 줄수록 예상치 못한 간섭이 줄어듭니다.

실행 상태 표시

처리가 진행 중인지 멈춘 것인지 구분해 보여 줍니다. 마감이 임박한 상황에서 화면이 멈춘 것처럼 보이면 사용자는 강제 종료를 시도하고, 그것이 다시 문제가 됩니다.

설치 절차 간소화

설치 과정의 단계를 줄였습니다. 입찰 직전에 설치하는 사용자가 적지 않으므로, 설치 자체가 빨라야 합니다.

검증에 들어간 시간

이 과제에서 개발보다 비중이 컸던 것은 검증입니다. 공공 시스템은 사용자 환경을 지정할 수 없기 때문입니다.

한 가지 환경에서 동작하는 것을 확인하는 데는 오래 걸리지 않습니다. 문제는 조합입니다. 운영체제 버전, 설치된 다른 보안 프로그램, 네트워크 조건이 각각 몇 가지씩만 되어도 확인해야 할 경우의 수가 빠르게 늘어납니다.

모든 조합을 다 확인할 수는 없으므로, 실제 사용자 환경에서 자주 나타나는 조합을 우선순위로 정리해 검증했습니다. 기존 시스템에서 접수된 문의 유형이 이 우선순위를 정하는 근거가 되었습니다. 어떤 환경에서 어떤 문제가 실제로 발생했는지가 가장 정확한 정보이기 때문입니다.

수치를 확인한 방식

속도 64.3%와 충돌 86.4%라는 수치는 개선 전후를 같은 조건에서 비교한 결과입니다. 환경이 다르면 비교 자체가 의미가 없으므로, 동일한 환경에서 동일한 절차를 반복 실행해 측정했습니다.

충돌 감소는 발생 빈도를 기준으로 했습니다. 충돌은 특정 조건에서만 나타나므로 한 번의 실행으로는 확인할 수 없고, 반복 실행에서 몇 번 발생하는지를 비교해야 합니다.

문의가 줄면 생기는 여유

충돌이 줄면 바로 나타나는 변화는 문의 감소입니다.

입찰 마감 시각에 문의가 몰리면 대응 인력이 전부 묶입니다. 전화를 받는 동안에도 다른 사용자의 문의가 쌓이고, 정작 급한 사안을 먼저 처리하기 어려워집니다. 마감 시각은 정해져 있으므로 대응이 늦으면 그 사용자는 입찰을 놓칩니다.

문의가 줄면 남은 문의에 제대로 대응할 여유가 생깁니다. 건수가 줄어드는 것보다 이 차이가 실질적입니다. 오류 원인을 구분해 안내하도록 한 것도 같은 맥락입니다. 사용자가 화면에서 원인을 확인할 수 있으면 문의 자체가 발생하지 않습니다.

재시도 처리

일시적인 문제로 중단된 경우 처음부터 다시 하지 않고 이어서 진행합니다. 마감 직전에 전 과정을 반복하는 것은 사용자에게 큰 부담입니다.

환경 사전 점검

실행 전에 필요한 조건이 갖춰졌는지 확인합니다. 진행 도중에 실패하는 것보다 시작 전에 알려 주는 편이 사용자가 대응할 시간을 남깁니다.

4. 성과

실행 속도 64.3% 향상. 보안 확인 절차를 재구성하고 중복 검사를 제거하면서 처리 시간이 줄었습니다. 마감 직전에 몰리는 입찰 특성상, 이 차이는 참여 가능 여부를 가릅니다.

프로그램 충돌 86.4% 감소. 자원 점유를 줄이고 환경 의존을 낮춘 결과입니다. 충돌이 줄면 사용자 문의가 줄고, 기관의 대응 부담도 함께 줄어듭니다.

결제 프로세스 보안 강화. 입찰과 연계된 결제 구간의 보안 수준을 높이고 처리 결과를 기록하도록 했습니다.

보안을 낮추지 않고 속도를 개선했다는 점이 이 과제의 핵심입니다. 확인 항목을 줄이는 방식이었다면 속도는 쉽게 올랐겠지만 제도의 근간이 흔들립니다. 절차의 순서와 중복을 정리하는 방식으로 접근했기 때문에, 검증 수준을 유지하면서 시간을 줄일 수 있었습니다.

핵심 설계 확인을 줄여 빨라진 것이 아니라, 같은 확인을 더 효율적인 순서로 수행하도록 바꿨습니다.

마감 시각이 있는 시스템의 특성

일반적인 서비스는 트래픽이 하루에 걸쳐 분산됩니다. 전자 입찰은 그렇지 않습니다. 마감 시각이 정해져 있고, 참여자 대부분이 그 직전에 몰립니다.

이 구조에서는 평균값이 큰 의미가 없습니다. 평소에 빠르게 동작하더라도 마감 직전에 느려지면 그 시스템은 실패한 것입니다. 반대로 평균이 다소 느려도 마감 시점에 안정적이면 문제가 없습니다.

그래서 개선의 기준을 평균이 아니라 최악의 경우에 맞췄습니다. 가장 느린 경우를 줄이는 것, 특정 환경에서만 실패하는 상황을 없애는 것이 목표였습니다. 평균을 줄이는 방법과 최악을 줄이는 방법은 다릅니다. 전자는 자주 쓰이는 경로를 빠르게 만드는 것이고, 후자는 드물게 발생하는 지연 요인을 찾아 제거하는 것입니다.

사용자가 기다리는 시간

체감 속도는 실제 처리 시간과 다릅니다. 같은 3초라도 화면에 아무 변화가 없으면 길게 느껴지고, 진행 상태가 보이면 짧게 느껴집니다.

마감에 쫓기는 사용자에게는 이 차이가 큽니다. 멈춘 것처럼 보이면 강제 종료를 시도하고, 그러면 처음부터 다시 해야 합니다. 실행 상태를 표시하도록 한 것은 성능 개선과 별개로 필요한 조치였습니다.

개선 이후의 운영

성능 개선은 한 번의 작업으로 끝나지 않습니다. 시간이 지나면 기능이 추가되고, 사용자 환경도 바뀝니다.

그래서 처리 이력을 남기도록 한 것이 중요합니다. 어느 단계에서 얼마나 걸렸는지 기록이 있으면, 나중에 느려졌을 때 어디가 원인인지 좁힐 수 있습니다. 기록이 없으면 전체를 다시 측정해야 하고, 그 과정에서 재현되지 않는 문제를 쫓게 됩니다.

사용자 환경 변화도 마찬가지입니다. 새로운 보안 프로그램이 널리 쓰이기 시작하면 이전에 없던 충돌이 나타날 수 있습니다. 어떤 조건에서 문제가 생겼는지 확인할 데이터가 있어야 대응이 가능합니다.

5. 기술 구성

적용 영역: 전자 입찰의 외부통제 영역에서 동작하는 보안 모듈입니다. 사용자 PC에서 실행되며 입찰 시스템과 연동합니다.

처리 구조: 확인 절차를 단계로 분리하고 순서 의존 관계를 정리했습니다. 독립적인 작업을 병행하도록 바꾼 것이 속도 개선의 주된 요인입니다.

자원 관리: 상주 처리를 최소화하고 메모리 사용과 프로그램 용량을 줄였습니다. 사용자 환경에 주는 부담을 낮추는 것이 안정성으로 이어집니다.

검증: 다양한 환경 조합에서 동작을 확인했습니다. 공공 시스템은 사용자 환경을 지정할 수 없어, 검증 범위가 넓어야 합니다.

설계 기준: 이 시스템에서 가장 중요한 것은 정해진 시각에 모두가 참여할 수 있어야 한다는 점입니다. 평균 처리 시간보다 최악의 경우가 중요하고, 특정 환경에서만 실패하는 상황을 없애는 것이 우선이었습니다.

구현하면서 다룬 문제

• 보안과 속도의 균형: 확인 항목을 줄이는 선택지는 처음부터 제외했습니다. 절차의 순서와 중복을 정리하는 방식으로만 시간을 줄여야 했습니다.
• 통제할 수 없는 사용자 환경: 어떤 프로그램이 설치되어 있을지 알 수 없습니다. 환경에 대한 가정을 줄이고 외부 영향을 받는 동작을 내부로 한정했습니다.
• 마감 시각의 압박: 입찰은 정해진 시각에 끝납니다. 오류가 나면 사용자는 원인을 파악할 시간이 없습니다. 오류를 구분해 안내하는 것이 기능만큼 중요했습니다.
• 공공 시스템의 검증 범위: 특정 환경에서만 되는 프로그램은 쓸 수 없습니다. 검증에 들어가는 비중이 일반 프로젝트보다 큽니다.

공공 시스템 개선 과제의 특성

민간 서비스 개선과 다른 점을 정리하면 세 가지입니다.

사용자 환경을 선택할 수 없습니다. 권장 사양을 안내할 수는 있어도 강제할 수 없습니다. 입찰 참여는 기업의 권리이므로, 환경 때문에 참여하지 못하는 상황이 생겨서는 안 됩니다. 이 제약이 설계와 검증 범위를 모두 넓힙니다.

기능을 줄이는 선택지가 제한적입니다. 민간 서비스라면 쓰이지 않는 기능을 없애 성능을 확보할 수 있습니다. 공공 시스템에서는 제도상 필요한 절차를 임의로 뺄 수 없습니다. 같은 일을 더 효율적으로 하는 방법을 찾아야 합니다.

실패의 영향이 개별 사용자에게 직접 갑니다. 서비스가 잠시 느려지는 것과 입찰에 참여하지 못하는 것은 무게가 다릅니다. 한 번의 장애가 기업의 사업 기회를 없앨 수 있으므로, 안정성의 기준이 높습니다.

정리하면

안전입찰 2.0은 보안 수준을 유지하면서 실행 속도와 안정성을 개선하는 과제였습니다.

확인 항목을 줄이는 방식은 처음부터 제외했습니다. 절차의 순서를 다시 정리하고 중복 검사를 제거하는 방식으로 실행 속도를 64.3% 높였고, 자원 점유와 환경 의존을 줄여 프로그램 충돌을 86.4% 감소시켰습니다.

공공 조달 시스템은 사용자 환경을 지정할 수 없고 마감 시각이 정해져 있습니다. 평균 처리 시간보다 최악의 경우를 줄이는 것, 특정 환경에서만 실패하는 상황을 없애는 것을 기준으로 삼은 이유입니다.

6. 프로젝트 정보

항목	내용
사업명	안전입찰 2.0 시스템 구축 (전자 조달 외부통제)
담당 범위	보안 모듈 개선 및 최적화