Necessity of Certification
29.2.1. Risks of Non-Certification
Projects that do not apply TQS certification are exposed to the following risks. Each risk may occur independently, but in most cases they act in combination, severely compromising the project's quality and stability.
29.2.1.1. Technical Debt Accumulation
When development proceeds without standardized criteria, technical debt accumulates rapidly.
Scenario: Team A of Project A develops without coding conventions. When the initial 3 members were working, code style was maintained through verbal agreements alone. However, as the team grew to 8 members, each individual's coding style became mixed. Variable naming, package structures, and error handling approaches vary from file to file, and after 6 months, more time is spent understanding existing code than adding new features.
The specific manifestations of technical debt accumulation are as follows.
| Domain | Technical Debt Manifestation | Result |
|---|---|---|
| Code Style | Formatter not applied, differing coding styles per individual | Reduced code readability, increased review time |
| Testing | Tests not written or written perfunctorily | Inability to detect side effects during changes, deployment instability |
| Dependencies | Insufficient version management, neglected vulnerable libraries | Security vulnerability exposure, compatibility issues |
| Documentation | API documentation not written, absence of architecture descriptions | Surging handover costs, delayed onboarding of new personnel |
29.2.1.2. Security Vulnerability Exposure
Without systematic security criteria, the probability of security vulnerabilities remaining in the code increases.
Scenario: Project B is deployed to production without security verification. Because the developer did not validate user input, SQL Injection vulnerabilities exist, and among the dependency libraries, a version containing critical vulnerabilities with CVSS 9.0 or above is in use. Such vulnerabilities may lead to data breach incidents through external attacks.
The main pathways for security vulnerability exposure are as follows.
- Missing input validation: XSS and SQL Injection vulnerabilities due to non-application of Bean Validation
- Encryption not applied: Plaintext storage of sensitive data, unencrypted communication (HTTP)
- Insufficient access control: Non-application of RBAC (Role-Based Access Control), possibility of authentication bypass
- Dependency vulnerabilities: Known vulnerabilities left unaddressed due to lack of security scanning
- Hardcoded secrets: API keys and passwords written directly in source code
29.2.1.3. High Handover Costs
Non-standardized projects incur massive costs during handover.
Scenario: The key developer of Project C resigns. The successor must understand the project's technology stack, code structure, and deployment method from scratch. Since the project's unique patterns and conventions are not documented, the successor must read the code line by line to understand its behavior. Complete handover takes 3 months, during which feature development for the project effectively ceases.
The causes of increased handover costs are as follows.
- Learning costs due to differing technology stacks per project
- Increased difficulty of code comprehension due to non-standard code structures
- Difficulty understanding service functionality due to lack of API documentation
- Inability to trace change history due to insufficient configuration management
29.2.1.4. Increased Service Outage Frequency
Inadequate testing and CI/CD automation lead to increased service outage frequency.
Scenario: Project D has only 20% test coverage. After adding new features, whether existing features function normally must be verified manually, making it easy to miss key scenarios. After production deployment, unexpected side effects occur, and emergency rollbacks are performed 2-3 times per month.
The cascading effects of increased outage frequency are as follows.
- Increased customer complaints and declining service trust
- Developer burnout due to emergency response
- Disruption to planned development schedules
- Increased incident response costs (labor costs, opportunity costs)
29.2.2. Industry Trends
The adoption of internal technical quality certification systems is an approach already proven by global technology companies. TQS has been designed to suit TIENIPIA's technical environment while referencing these industry trends.
29.2.2.1. Global Company Case Studies
Major global technology companies operate systems that systematically manage code quality and technical competence internally.
| Company | System | Core Concept | Similarities with TQS |
|---|---|---|---|
| Readability | Language-specific code quality certification, code review qualification | Code-level quality verification | |
| Amazon | Bar Raiser | Independent quality criteria applied to hiring/technical decisions | Independent audit committee system |
| Meta | Code Quality Standards | Automated code quality measurement, deployment blocked when standards not met | CI-based automated verification |
| Netflix | Paved Road | Standardized technology stacks and patterns, best practice enforcement | Technology stack standardization |
These case studies demonstrate the industry-wide consensus that systematic management of technical quality becomes essential as organizations scale.
29.2.2.2. Domestic Industry Trends
Domestic companies are also strengthening their internal technology standardization and quality management systems.
- Large IT companies are standardizing and distributing internal development guidelines.
- In the fintech/financial sector, code security verification is trending toward mandatory adoption.
- With the transition to cloud-native architectures, quality management requirements for Infrastructure as Code (IaC) are increasing.
29.2.2.3. TQS Differentiation
TQS learns from existing industry case studies while differentiating itself in the following ways.
- Integrated certification system: Software, hardware, and infrastructure are unified under a single certification framework.
- Code-level verification: Actual implementation artifacts (code, configurations, builds) are directly verified rather than processes.
- Grade system: Rather than a single pass/fail result, a three-tier grade system encourages progressive quality improvement.
- Formal specification: Managed as a structured specification document rather than verbal communication or wiki-level documentation.
29.2.3. Quantification of Adoption Benefits
The expected benefits from TQS certification adoption are presented quantitatively. The figures below represent TIENIPIA's internal target benchmarks and will be continuously updated based on actual measured data after certification adoption.
29.2.3.1. Defect-Related Metrics
| Metric | Without Certification (Estimated) | With Certification (Target) | Improvement |
|---|---|---|---|
| Production defect rate (cases/month) | 8-12 cases | 3-5 cases | 50-60% reduction |
| Average defect resolution time | 4 hours | 1.5 hours | 60% reduction |
| Post-deployment emergency rollback frequency (times/month) | 2-3 times | 0-1 times | 60-70% reduction |
| Remaining security vulnerabilities | 5-10 cases | 0-2 cases | 70-80% reduction |
29.2.3.2. Productivity-Related Metrics
| Metric | Without Certification (Estimated) | With Certification (Target) | Improvement |
|---|---|---|---|
| Code review time (per PR) | 60 minutes | 30 minutes | 50% reduction |
| Code review rejection rate | 40% | 15% | 60% reduction |
| New hire onboarding period | 3 months | 1 month | 65% reduction |
| Handover duration | 4-6 weeks | 1-2 weeks | 60-70% reduction |
29.2.3.3. Stability-Related Metrics
| Metric | Without Certification (Estimated) | With Certification (Target) | Improvement |
|---|---|---|---|
| Build success rate | 80-85% | 95% or above | 10-15%p improvement |
| Test coverage (line) | 30-50% | 80% or above | 30-50%p improvement |
| Test coverage (branch) | 20-40% | 70% or above | 30-50%p improvement |
| Mean Time To Recovery (MTTR) | 2 hours | 30 minutes | 75% reduction |
29.2.3.4. Measurement and Update Plan
The above figures are internal targets, and actual benefits will be measured and updated on the following schedule after certification adoption.
- 6 months after adoption: First benefit measurement and achievement rate analysis against targets
- 12 months after adoption: Second benefit measurement, target figure readjustment
- Annually thereafter: Periodic measurement and target updates
Measurement results are reported to the TQS Committee and used as supporting data for standard revisions. For items where the achievement rate falls significantly below targets, the effectiveness of the standard is reviewed.