시니어 개발자는 어떻게 문제를 바라보는가

시니어에게 문제 해결은 단지 답을 빠르게 찾는 것만이 아닙니다. 유일한 정답이 있는 시험과 달리, 현실에서는 답이 하나가 아닐 때가 많습니다. 현실에서의 문제 해결은 눈앞에 보이는 현상에 속지 않고 그 이면에 감춰진 진짜 ‘문제’를 찾아내고, ‘최적해(Optimal Solution, 가장 최고(최적)의 결과를 내는 답)’를 설계하는 과정에 가깝습니다. 그 과정은 복잡한 맥락과 조건 속에서 가장 설득력 있고 효과적인 선택을 내려야 하는 ‘판단의 과정’이라고도 할 수 있습니다.

2월 COMMIT에서는 각기 다른 도메인에서 내공을 쌓아온 세 명의 패널이 마주했던 ‘판단의 여정’을 따라가 봅니다.  

서로 다른 맥락, 다른 책임, 다른 선택. 세 명의 에피소드는 다르지만 결국 하나의 질문에 이르게 됩니다. “문제를 푼다는 것은 무엇인가? 또 문제를 어떻게 바라봐야 하는가?”

이번 COMMIT은 성공담이나 해답을 제시하지 않습니다. 대신, 시니어 개발자가 되어가며 마주했던 세 개의 결정의 순간을 통해 각자의 기준을 돌아보고, 같은 문제를 보되 전혀 다른 시야로 문제를 바라보고 질문하고 답하는 과정 속에서 문제를 바라보는 올바른 시야와 판단의 기준을 다시 한번 생각해 봅니다.

➡ 참가 신청하기 
 

의사결정의 기준

“며칠 밤을 새운 성능 개선 브랜치를 삭제하며” – 하조은

기술적으로는 훌륭한 개선이었지만, 냉정하게 돌아봤을 때 비즈니스 임팩트는 낮았던 프로젝트들이 있었습니다. 결국 공들여 짠 코드를 메인 브랜치에 합치지 못하고 삭제해야만 했습니다.

지금은 ‘비즈니스 임팩트’를 가장 먼저 생각합니다. 100점짜리 기술적 정답이 비즈니스에는 0점일 수 있다는 사실을 받아들인 것이죠. “이 일이 팀과 제품에 기대만큼의 임팩트를 주는가?”라는 질문이 저의 의사결정 기준이 되었습니다.

문제 정의의 힘

“엘리베이터 관제 시스템에서 배운 문제 정의의 힘” – 이민석

엘리베이터 관제 시스템을 만들 때, 한 대는 완벽했지만 여러 대를 돌리자 데이터가 엉망이 되었습니다. ‘동기화’라는 문제의 본질을 몰랐기 때문입니다. 문제 자체를 잘못 정의하니 해결책이 나올 리 없었죠.

AI 시대가 와도 마찬가지입니다. 요구사항을 명확히 정의하지 않으면 AI도 쓰레기를 내놓습니다. “무엇을 풀어야 하는가”를 정의하는 능력이 여전히 중요합니다.

시야의 확장

“암묵지에 이름을 붙이고 지도를 그리는 일” – 박상권

어느 날 문득 깨달았습니다. 뒤로가기 버튼과 X 버튼의 동작 기준이 화면마다 다르다는 것을요. 누구도 의도하지 않았지만, 기준이 없어 생긴 ‘암묵지’였습니다. 그 뒤로 이런 사소한 것들에 질문을 던지는 습관이 생겼습니다.

팀이 커질수록 ‘누구나 알지만 아무도 정하지 않은 것’들은 필연적으로 생겨납니다. 시니어의 시야는 내 코드 한 줄을 넘어 팀 전체의 병목 구간을 향해야 합니다.