《개발 너머의 일》신입 개발자 시절, 몰랐던 것들

지금으로부터 20여 년 전, 신입 개발자로 처음 사회에 발을 내딛었을 때, 저의 모든 관심은 오로지 코드에만 집중되어 있었습니다. 밤을 새우며 완벽한 코드 한 줄을 짜기 위해 매달렸고, 그것이 좋은 개발자가 되는 유일한 길이라고 확신했습니다. 그러나 기대와는 달리 프로젝트가 끝나고 나면 돌아오는 건 칭찬이 아닌 따가운 피드백과 혼란스러운 평가들이었습니다.

저는 항상 스스로에게 질문했습니다. “분명 내 코드는 문제가 없는데, 왜 사람들은 만족하지 않을까? 왜 완벽한 코드가 늘 완벽한 결과로 이어지지 않을까?” 돌이켜보면 그 시절 저는 기술을 절대적인 가치로 생각하며 다른 중요한 것들을 미처 보지 못했습니다.

기술보다 중요한 건 무엇일까?

코딩을 배우면서, 기술이 곧 모든 문제를 해결할 수 있는 만능 도구라고 생각했습니다. 하지만 실무에 들어서자 상황은 달랐습니다. 실무 프로젝트에서는 단지 기술적 문제 해결만이 아니라, 프로젝트 일정, 고객과의 원활한 소통, 팀 내 협력과 같은 요소들이 더 큰 비중을 차지하고 있었습니다. 결국 프로젝트의 성공 여부는 코드의 완벽성보다는 이런 요소들이 잘 어우러져야만 가능한 것이었습니다.

어느 날 팀장님이 제게 해주신 이야기가 있었습니다.

기술은 누구나 배우면 할 수 있지만,
상황을 정확하게 이해하고 대응할 수 있는 능력은 특별한 것이다.

이 한마디가 제 사고방식을 바꾸기 시작했습니다. 그때부터 저는 코드를 넘어서 주변의 상황과 사람들의 관계에 더 관심을 기울이기 시작했습니다.

SI 환경에서 배우는 리스크 관리

제가 처음 경험한 SI 환경은 늘 예측 불가능한 변수와 빠듯한 일정이 존재하는 곳이었습니다. 꼼꼼히 짜 놓은 일정이 고객의 단 한 마디로 순식간에 바뀌는 일이 비일비재했고, 완벽히 마쳤다고 생각한 작업이 다음날 전혀 다른 방향으로 뒤바뀌기도 했습니다. 처음에는 이런 상황이 매우 혼란스럽고 좌절스러웠습니다.

실제 프로젝트에서 있었던 일입니다. 밤새도록 고민하며 어렵게 완성한 기능을 고객사 미팅에서 자신 있게 시연했습니다. 그런데 돌아온 대답은 황당했습니다.

우리가 원한 건 이 기능이 아닌데요. 전혀 다른 기능입니다.

고객은 처음 요구사항을 전달할 때 애매한 표현을 사용했고, 저는 제 나름대로의 해석으로 개발을 진행했던 것입니다. 그때 처음으로 명확한 소통과 리스크 관리의 중요성을 몸소 깨닫게 되었습니다.

이런 경험들이 쌓이면서 저는 점차 깨닫게 되었습니다. 중요한 것은 일이 계획대로 되는 것이 아니라, 일이 계획대로 되지 않을 때 어떻게 대응하는가라는 사실을 말입니다. 리스크를 미리 예측하고, 이에 대비할 수 있는 유연한 사고와 상황 판단력이 SI 프로젝트에서는 필수였습니다. 이 과정에서 저는 문제를 미리 예측하고 관리하는 방법을 자연스럽게 익히게 되었습니다.

코드는 완벽한데 왜 욕을 먹을까?

한번은 고객에게 강력한 질책을 받은 적이 있었습니다. 기능적으로 전혀 문제없는 완벽한 코드였지만, 고객의 입장에서는 그 코드가 현실적인 문제를 해결해 주지 못한 것입니다.

이 기능은 사용자가 원하는 방식과 전혀 달라요.

이 경험을 통해 저는 다시 한번 깊이 깨달았습니다. 좋은 코드는 단지 오류가 없는 코드가 아니라, 사용자의 실제 문제를 정확히 해결할 수 있는 코드라는 것을 말입니다. 이후로는 코딩을 시작하기 전에 사용자와 고객이 진정으로 원하는 것이 무엇인지 먼저 고민하는 습관을 가지게 되었습니다.

신입 개발자 시절을 돌아보면, 이런 혼란과 시행착오들이 오히려 저를 더 성장시켰던 것 같습니다. 코드 너머의 세상을 보게 된 순간이었고, 개발자로서의 진짜 여정이 시작된 순간이었습니다.

다음 편에서는 제가 개발자로서 기획자의 입장을 이해하게 된 결정적인 순간들을 이야기하겠습니다.