개발 철학란을 따로 분류를 했다.
2000년 전까지는 주로 완성품을 만드는 개발을 했다면, 2000년 이후부터는 남들이 완성품을 만들 수 있게 하기 위한 API를
만드는 일을 주로 했다.
API를 만들고 구현하는 일은
application을 만드는 일과는 사뭇 다르다. Use case에 따른 API 사용법을 디자인하는 것부터 시작해서, 사용자로 하여금 어떤
식의 프로그래밍을 유도할 것인지도 생각해야 하고, API 이름을 짓는 것부터도 어떤 형태의 일관성을
제공해야 한다. 그렇게 API 스펙과 구조 설계가 나오게
되면 API 구현에 대한 상서 설계가 나오게 되고, 그것을
기반으로 해서 기능 구현, 예외 보장, 속도 최적화와 같은
일을 하게 된다.
이런 일을 함에 있어서 필요한 것이 철학이다. 모든 철학은 그에
맞는 의미가 있기 때문에 서로의 우위를 가리기는 어렵다. (특히 높이 올라 갈수록 더 그렇다) 여기서 중요한 것은 그런 철학의 더 좋고 나쁘고를 따지는 것이 아니라 자신에게 철학이라고 말할 만한
것이 존재하는가 그렇지 않은가 하는 것이다. 나의 경우에는 신입 사원들을 개발 능력을 평가할 때, ‘철학’의 유무를 가장 먼저 파악한다. 요새는 인터넷으로 쉽게 좋은
글들을 발견할 수 있기 때문에 좋은 개방 방법론을 접하는 것이 쉬워졌다. 하지만 그런 방법론을 제대로
자기 것으로 만들지 못하면 결국은 흉내만 내는 것이며 머리 속에 정리된 자신만의 철학은 만들지 못한 것이다.
시대가 변하면서 나의 개발 철학도 조금씩 변해갔다. 점점 다듬어져
가는 것인지, 아니면 외골수로 가는 것인지는 알 수 없다. 내가
필요한 것은 나의 철학을 이야기 하면서 여러 사람들과 의견을 교환하는 것이다. 비난이 아닌 비평이 필요한
것이다.
Posted by 안영기
