일을 잘한다와 개발을 잘한다의 정의

최근 들어 데이터 집계 및 추출에 대한 과업을 많이 맡아서 진행했다. (월결산 데이터 집계와 같은)

배치 애플리케이션이 존재하는 것들은 간단하게 돌리면 알아서 집계정산 로직이 돌고 파일로 저장까지 되니 그저 버킷에 업로드된 결과를 경관에게 보고할 수 있도록 옮기는 작업만 하면 된다.

그 이후 쿼리로 진행해야할 집계들은 (예를들면 이번달에 나간 대출건들중에 OOO 이라는 카테고리의 대출) 직접 쿼리하여 엑셀시트에 올려 전달해야한다.

보통이라면 이런 집계 데이터들은 상위에 보고 혹은 외부 감사 기관 (금융감독원 등)과 같은 곳에서 요청하는 경우다. 보통의 집계 로직을 단순 db쿼리로 커버할 수 있으니 그때그때 달마다 돌릴 수도 있겠지만 한달뒤에 또 어떻게 집계를 했더라 하고 쿼리를 짜거나 할것이다.

여기서 조금 센스있는 사람들은 해당 쿼리의 형식을 기록해두고 다음달이 되었을 때, 재사용하거나 배치 애플리케이션을 작성하거나 할 건데, 문제는 쿼리 저장까지는 당연히 하면 좋다고 말할수있지만 배치 애플리케이션과 같은 코어 서버에 변경이 가해지는 작업들은 무조건 작성해놓는게 좋을까에 대한 의문이다.

물론 개발을 잘한다는것은 이런 애플리케이션들을 언제나 문제없이 만들어낼 수 있는것이지만, 그때그때 sql 쿼리로 집계해서 세번정도만 클릭하면 커버할 수 있는 작업을 꼭 소프트웨어로 풀어나가야할까?

충분히 수기로도, 딸깍으로도 커버해나갈 수 있는 작업들은 번거롭긴하지만, 번거럽다고 느끼지도 못할세 빨리 끝나는 작업들이다. 그런 사소한 작업들을 위해서 나의 리소스를 소모할 수 있을까? 또 새로운 애플리케이션을 개발했다면 보통의 개발조직에서 리뷰의 과정을 거칠것이고 테스트의 과정을 거칠것이다.

그리고 혹여나 집계로직의 전제상황이나 필요 데이터의 구조가 바뀌게된다면? 참조하고있는 테이블의 컬럼이 바뀌게 되는 의사결정을 통해 해당 배치 애플리케이션의 사이드 이펙트까지 고려해야하게 된다면?

개발을 잘 한다는 것은 문제상황(여기서 문제에 대한 정의는 불편함의 존재여부만을 바라본다. 규모를 보지않는다.)을 해결하기 위해 소프트웨어를 구현해내는 역량이 뛰어나다고 정의해보겠다.

일을 잘한다는 것은, 할 수 있으나 할 필요가 있을지 질문을 먼저 해보고 우선순위 과업을 먼저 처리해나가며 상대방이 당장 원하는것이 무엇이고 어디까지 내가 제공해줄 수 있는지를 고민해보고 한 발 더 앞서나가는 센스라고 생각한다.

센스 #

예를 들어보겠다. 엑셀 시트에 월 결산 대출액을 집계하고자 집계는 안해줘도 되니 raw_data(id값과 대출액) 정도만 추출해서 전달해달라는 요청을 받았다.

여기서 기본적인 센스는 데이터를 id별로 정렬하거나 시간별로 정렬하거나 혹은 규칙있고 보기쉽게 or 엑셀함수를 사용하기 쉬운 형식으로 전달해주는 것이다.

여기서 조금 더 하이레벨의 센스가 발휘된다면 직접 집계까지 시트에 적용해서 (vlookup, sum, count 등과 같은) 전달해줄수도 있겠다.

물론 바로위의 내용은 개발자가 할 일은 아니다 이런일은 PM 팀원에게 인수인계를 해주거나 자료요청을준 팀원에게 전달해주면 무방하지만, 그럼에도 이 점을 미리 쓱싹 해주게 된다면 요청준 상대방은 단순 데이터 체크만 진행하게 되며, 당신의 인사평가가 극도로 올라가게 될 것이다.

물론 필수는 아니다. 해당 과업은 센스의 영역이며 개발자로서 가장 중요한 업무는 역시나 개발이며 그 개발에서 실수가 발생하지 않도록 더욱 신경쓰는게 중요하다.

반복 파악과 자동화 시점 #

모든것을 자동화 하라는 devops 원칙을 어디선가 들은것같지만, 난 살짝 반대다. 모든것을 자동화하라는 것이 배포 시스템만을 말씀해주신건지는 모르겠지만,

어느정도 인간의 개입은 당연하게 필수다. 내가 과거 개발하면서 가장 후회하는점중 하나가 모든것을 자동화하려는 습관이였다.

그렇기에 단순안 이슈로도 자동화 시스템의 시작부터 끝점까지 디버깅해보거나 고쳐나가야했다 (물론 그때당시의 결합도높은 자동화 시스템을 만든 나의 문제도 있었겠지만)

위에 집계상황을 예로 들어봤을때도 이 집계를 자동화 해야할까, 대출이라는 도메인은 많은곳과 결합되어있다. 코어뱅킹 시스템이기때문이다. 안그래도 사이드 이팩트가 많은 곳에 또 넣을 필요가 있을까?

역으로 생각해서 이미 코어뱅킹 시스템으로서 매우 변경 가능성이 불변에 가까운 도메인이니 추가해도 별 상관없지 않을까? 이 배치 애플리케이션을 개발할 수 있는 여유가 있을까?

보통 내가 추천하는건 이런 과업들을 깰때 우선도를 파악하고 타임 리미트를 걸고 해보자. 이건 30분정도를 잡고 그 이상나오면 일단 후순위로 미루고 수기로 대응하자. 그 시간에 다른것을 해보자.

그리고 그런 타임 리미트를 결정할때 필요한게 현재 상황과 상대방의 니즈, 혹은 반복패턴들을 분석하는 것이다.

월결산 집계 데이터를 요청했다는 것은 왜 그런것이지? 요즘 금융사고가 많이 일어나서 땡떙땡 기관에서 감사를 많이 다닌다고들 하는데 우리도 그럼 앞으로 달마다 감사를 받지 않을까? 간헐적으로 일어나는 것 같지는 않군. 일단 이번달까지 더 봐볼까? 데이터의 구조가 자주 바뀌고 형식이 자주 바뀌네 일단 애플리케이션으로 개발하긴 더 지켜봐야겠군

등과 같은 지금 닥친 상황과 규칙을 파악하고 이에 알맞는 의사결정을 할 수 있는 능력, 더욱 나아가서 상대방이 어떤 추가요청을 할지, 어떤것을 원하고 있는지 어느 부분에서 불편함을 느끼고있는지도 우선적으로 파악해보자. 질문을 던질수록 답은 많이 나온다. 답을 많이 낼수록 해야할 것들이 보인다.

해야할것들을 클리어하다보면 당신은 일을 잘하게 될 것이다.