답이 많은데 진도가 안 나가는 회의
회의를 하다 보면 종종 이런 일이 있다. 안건은 분명히 있고, 사람들도 의견을 낸다. 그런데 한참을 떠들어도 결론이 안 난다.
답이 부족해서가 아니다. 답은 충분히 나왔다. 문제는 사람들이 각자 다른 질문에 답하고 있다는 거다. 누군가는 "어떻게 빨리 만들지"에 대해 말하고, 누군가는 "이걸 만드는 게 맞는지"에 대해 말한다. 같은 회의실에서 다른 회의를 하고 있는 셈이다.
이럴 때 결국 정리해주는 사람이 있다. 보통 더 좋은 답을 들고 온 사람이 아니다. "잠깐, 지금 우리가 풀려는 게 정확히 뭐였죠?"라고 다시 묻는 사람이다.
좋은 답보다 좋은 질문이 귀하다는 말, 격언처럼 들리지만 사실 회의실에서 자주 확인되는 경험칙이다.
코딩이라고 별다르지 않다
코딩도 마찬가지다. 오히려 코딩은 답이 너무 많은 쪽이다. 같은 문제를 푸는 방법이 수십 가지고, 라이브러리도 많고, 의견도 분분하다. 자료가 없어서 막히는 경우는 거의 없다.
막힐 때는 늘 다른 데서다. "이걸 진짜 만들어야 하나", "지금 만들어야 하나", "이렇게 만드는 게 맞나" 같은 질문 앞이다.
원래도 그랬다. 다만 요즘 이게 더 도드라진다. AI 때문이다. 코드 짜는 비용이 워낙 싸지니까, 어떤 코드를 짤지 정하는 일의 비중이 상대적으로 커진다.
"시니어"라는 말이 실제로 가리키던 것
지금까지 "시니어"라고 하면 보통 어떤 사람을 떠올렸는지 생각해보자. 표면적으론 "경험 많은 사람"이지만, 구체적으론 좀 더 좁다.
코드 빠르고 정확하게 짜는 사람. 처음 보는 버그도 어떤 패턴인지 알아보는 사람. 새 기술이 나와도 "아 이거 그거랑 비슷하네" 하고 빠르게 흡수하는 사람. 함정 같은 거 미리 피하는 사람. 결국 이런 능력들이 시니어라는 단어의 실제 내용이었다.
이 정의가 오래 통한 이유는 단순하다. 코드 짜는 일이 개발자 직업의 가장 큰 부분이었기 때문이다. 그 일을 잘하는 사람이 곧 잘하는 개발자였다.
그 정의가 흔들린다
지금은 좀 다르다. 정의 자체가 사라지진 않았지만, 그 안의 비중이 달라진다.
코드 잘 짜는 일이 가치 없어진 건 아니다. 다만 거기에 사람 시간이 얼마나 필요한지가 바뀌었다. 익숙한 패턴은 AI가 빠르게 만들어준다. 알려진 함정도 도구가 같이 본다. 일정 수준까지는 그냥 싸졌다.
그러니까 옛날에 시니어를 알아보던 신호들이 점점 흐려진다. "코드 빨리 짠다"는 건 도구의 도움을 받으면 누구나 보낼 수 있는 신호다. "라이브러리 잘 안다"도 마찬가지다. 검색하면 나오는 능력은 더 이상 식별 기준이 못 된다.
이게 시니어가 필요 없어졌다는 얘긴 아니다. 시니어라는 말이 가리키는 내용이 재배열되고 있다는 얘기다.
그럼 뭐가 새로 올라오나
내가 보기엔 문제 정의 능력이다. 모호한 상황을 풀 수 있는 형태의 문제로 바꿔내는 일.
이 말은 추상적으로 들리기 쉬워서, 좀 더 쪼개봐야 한다.
첫째, 모호한 요구를 명확하게 만드는 일.
누가 "이거 좀 빠르게 해주세요"라고 했을 때, 그 말 뒤에 있는 진짜 요구는 사람마다 다르다. 어떤 화면이 느린 건지, 어떤 사용자가 어떤 흐름에서 답답함을 느낀 건지, 다시 물어보지 않으면 모른다. 그냥 표면의 말만 받아서 코드를 짜기 시작하면, 결과물이 잘못된 질문에 대한 답이 된다. 빠르게 만들어졌지만 쓸모는 별로 없는.
둘째, 무엇을 만들지 정하는 일.
가능한 선택지는 늘 많다. 예전엔 한 방향을 코드로 옮기는 데도 시간이 오래 걸렸으니까, "뭘 만들지 정한다"가 상대적으로 작은 일처럼 보였다. 어차피 시간이 부족했으니 한두 개 골라서 만들면 끝이었다.
지금은 다르다. 만드는 시간이 짧아지니까, 어떤 방향을 골랐느냐에 따라 결과 차이가 크게 벌어진다. 같은 일주일에 다섯 개를 만들 수 있다면, 어느 다섯 개를 만드는지가 그 일주일의 가치를 거의 다 결정한다.
셋째, 무엇을 만들지 않을지 정하는 일.
두 번째랑 비슷해 보이지만 결이 다르다. 만들 걸 정하는 게 가능성을 보는 일이라면, 만들지 않을 걸 정하는 건 비용을 보는 일이다.
코드가 싸지면 일단 만들고 보자는 결정도 가벼워진다. 그래서 오히려 "이건 안 만든다"는 결정의 값어치가 올라간다. 안 만들기로 한 결정이 이미 만든 것들의 수명을 늘리는 경우가 의외로 많다.
AI는 왜 이걸 못 가져가나
여기서 이런 의문이 나올 수 있다. 문제 정의도 결국 잘 정리해서 시키면 AI가 하는 거 아니냐고. 일부는 맞다. 잘 정리된 문제라면 AI가 사람보다 잘 푼다. 근데 AI가 약한 부분은 문제를 푸는 게 아니라 문제를 알아채는 쪽이다.
문제를 알아챈다는 게 결국 맥락을 읽는 일이다. 지금 우리 조직이 어디 있는지, 이 제품을 누가 쓰는지, 이번 결정이 6개월 뒤에 어떻게 돌아올지. 이런 정보는 코드 안에 안 들어 있다. 회의록에도 다 없다. 사람들 표정, 지난 분기에 실패한 시도, 다음 분기 예산 같은 데 흩어져 있다.
AI는 문제가 잘 정리되어 있을 때 그 안에서 잘 푼다. 정리되지 않은 상황을 정리된 문제로 바꾸는 일, 그건 아직 사람이 한다.
정의가 바뀌면 따라 바뀌는 것들
시니어의 정의가 바뀌면 주변도 같이 움직인다.
성장 경로가 달라진다. 옛날엔 "오래 짜면 시니어 된다"가 어느 정도 통했다. 지금은 잘 모르겠다. 오래 짜는 거랑 잘 묻는 거는 다른 능력이다. 코드 많이 짜본 사람이 좋은 질문 던지는 사람으로 자라려면, 의식적으로 다른 훈련을 해야 한다.
평가도 달라져야 한다. PR 개수, 작성한 코드량, 처리한 티켓 수. 이런 지표들이 시니어를 가리키는 데 쓰여왔는데, 새 정의에선 잘 안 잡히는 영역이 더 무겁다. 만들지 않기로 한 기능, 다시 정의한 요구사항, 회의에서 정리한 우선순위. 다 지표화가 어렵다. 근데 결과 차이는 거기서 더 크게 난다.
주니어한테 주는 피드백도 바뀌어야 한다. "이 코드 더 잘 짤 수 있겠는데"만 묻는 피드백은 점점 가벼워진다. "근데 이걸 진짜 만들어야 했나, 만든다면 이 방식이 맞나"를 같이 묻는 피드백이 더 무거워진다.
답에서 질문으로
코드는 답이다. 답을 만드는 일은 점점 싸지고 있다. 그러면 그 답이 무엇에 대한 답인지 정하는 일, 그러니까 질문을 다듬는 일이 비싸진다. 시니어라고 부를 만한 사람이 누구냐는 질문에 대한 답도 그쪽으로 옮겨가는 중이다.
좋은 질문이 좋은 답보다 귀하다는 말, 이제 격언이라기보단 직업에서 실제로 통하는 경험칙에 가깝다.