From Student to Developer: Learning the Flow of Server Development, from Building a Lotto to Improving Legacy Code

The 2026 new-hire tech new crews went through three stages—TDD & OOP Implementation, Legacy Code Acceptance Testing, and Legacy Code Refactoring—and learned not just how to build features but how to develop.

The first mission was implementing a Lotto game. While implementing 1 ticket for 1000 won, automatic and manual issuance, and winning statistics calculation, they also had to follow constraints such as indentation depth of 1 level, methods of 10 lines or fewer, wrapping primitive values, and Early Return, and all implementation was carried out using TDD.

Since the random logic had to be testable, they restructured the number generation strategy into an abstracted interface that could be injected. They also learned design criteria for distinguishing object identity from value equality by caching the numbers 1 through 45 for reuse instead of creating them anew each time.

The second mission was acceptance testing on service-level legacy code. They divided what needed to be protected into user behavior, system return results, and externally observable state changes, and applied Strong Assertion and Cucumber-based BDD to create tests that prove things "succeeded correctly."

They also aligned the test environment with production as closely as possible. They switched the H2 database to PostgreSQL, unified the execution environment with Docker, and automated testing with Gradle Task. Data isolation was solved with FK reverse-order deletion, TRUNCATE ... CASCADE, and a common Cleanup utility, ensuring tests always started from the same state.

The final mission was legacy code refactoring. The core principle was separating structural changes from behavioral changes—when cleaning up structure, behavior was not changed, and when modifying behavior, structure was not touched. Through this process, PR reviews became not just simple code checks but training in predicting and controlling change.

AI was also actively used, but they confirmed the limitation that verification becomes difficult when a wide scope is handed off at once. Afterward, they established principles of requesting work in small units, delegating repetitive tasks to AI while humans make the final decisions, and not trusting AI-written code without tests.

After hundreds of PRs and hundreds of reviews, server development was no longer a massive wall but became a process of structurally solving problems. By mastering the sequence of testing, design, refactoring, and verification, what was once vague server development has now become an area that can be handled with questions and standards.