구조

한 발 떨어져서 바라보기

컴퓨터를 전공하고 삼전에서 개발자로 사회생활을 시작했다. 어쩌다 IBM에서 컴퓨터로 만들어 내는 서비스를 세일즈 하기도 했다. 사물 중에 컴퓨터를 가장 좋아하고 가장 오래 가지고 논다. 컴퓨터로 먹고살고 있지는 않지만 한참 머리가 잘 돌아갈 때 컴퓨터를 배운건 인생의 큰 선물 중에 하나다. 컴퓨터가 어떻게 돌아가는지, 컴퓨터가 무엇을 할 수 있는지, 컴퓨터에게 어떻게 이야기를 해줘야 시키는 대로 하는지를 배우기 위해 꽤 많은 밤을 새웠다. 개발자로 살 때는 전혀 생각 못했는데 먹고사는 일이 컴퓨터와 좀 멀어지고 나서 컴퓨터와 커뮤니케이션할 수 있는 능력을 잘 활용하면 인생에 꽤 쓸모가 있겠다는 생각이 들었다. 사물이나 현상을 이해하고 문제를 해결할 때 컴퓨터를 배운 걸 적용하면 꽤 유용하기 때문이다. 그걸 컴퓨팅 사고라고 한다나 뭐라나.

나는 짧고 아름다운 코드를 만들어 내는 프로그래밍 천재는 절대 아니었고 어떻게든 문제를 집요하게 물고 늘어져서 결국은 풀어내는 스타일이었다. 알고리즘 수업 때 꽤 어려운 과제가 있었다. 일주일 밤낮을 개고생 하며 결국 풀어냈다. 100명 중에 10명도 과제를 풀지 못해서 나름 우쭐했다. 하지만 우쭐함도 잠시, 코딩을 제일 잘하는 친구의 코드를 보고 좌절했다. 그의 코드의 길이는 나의 코드보다 딱 10배 짧았다. 그리고 아름다웠다. 내 코드는 예외가 덕지덕지 붙어있어서 이해하기 힘든 누더기였다. 왜 같은 걸 배웠는데 이렇게 다른 코드가 나왔을까? 그 친구는 문제를 구조적으로 접근했고 나는 그냥 덤벼들었던 것이다. 구조를 먼저 생각하고 구조를 잘 짜는 것은 처음에 좀 힘들고 골치 아플지 모르겠지만 뒤가 쉬워지는 방법이다. 뭐 나무를 베는데 한 시간이 주어지면 도끼 날을 가는데 40분인가 50분을 쓴다는 말이랑 비슷한 맥락이다.

지난번 글에 식당에서 주방을 없애야겠다고 했다. 식당을 한 발 떨어져서 '구조적'으로 바라보고 생각한 결과다. 구조적으로 주방이 있으면 비효율이 날 수밖에 없는 게 식당이다. 식당이라는 프로그램을 만들면서 주방 함수를 직접 짜면 프로그램의 완성도가 떨어질 수밖에 없다. 내가 프로그래밍의 천재가 아니기 때문에 내가 짠 코드는 에러와 비효율이 있을 수밖에 없다. 처음에는 일단 돌아가는 게 우선이니 무작정 돌리다 보면 하나 둘 나타나는 에러에 땜빵, 땜빵, 땜빵하며 누더기 프로그램을 만들게 된다. 누더기 프로그램은 확장성, 안정성이 떨어지기 때문에 성능이 떨어지고 리스크를 가지고 있다. 쪽팔려서 남에게 팔 수도 없다. 구조적으로 생각해서 주방 함수를 직접 짜지 말고 음식을 가져다주는 API를 호출하자는 거다. 쉽고, 빠르고, 유연해진다.

뭘 하던 구조는 너무너무 중요하다. 무인양품 회장님도 그랬다. 무인양품의 90%는 구조라고.