Lead Programmer, Chief Architect , Chief Technology Officer

It's been a while since I posted. I've worked on various projects recently. The development went well but market success was limited.

Looking back at my programmer career, I've completed many projects and gained much experience. I rarely make mistakes now and can make timely decisions.

I used to admire the Chief Architect role. Now I understand what it entails, as it describes my current work.

After 33 years of coding and 25 years professionally, once a Lead Programmer develops skills evaluating practices, architectural insights, and thoughtful choices over hard work, they near the Architect role.

The difference from CTO is being more hands-on. CTO is harder - you must influence business decisions with technical expertise. Both political equity and tech credit are crucial.

I'm still learning and gaining new perspectives. Open source creativity impresses me. I want to share good practices so developers create quality software without struggle.

I aim to explain good practices simply, give back inspiration received, and attract more talented developers to our company and team. With that spirit, I'm starting to blog again.

The image could show the progression from a junior coder to lead programmer to architect/CTO, with increasing skills and wisdom gained over time. The senior architect is sharing knowledge back with younger coders, completing the cycle.

간만에 포스팅이다.

그간 여러 프로젝트를 했었다.

개발은 성공했다고 보지만, 시장에서의 성과는 별로였다.

프로그래머로 살아온 그간의 세월들에서 완성한 프로젝트들을 세어보니 정말 많았다.

많이 겪었다.

이제는 거의 실수를 안 한다.

시간에 맞는 선택도 할 줄 안다.

Chief Architect가 멋있어 보이기만 하던 시절이 있었다. 막연히 간지나는 역할을 해보고 싶다는 생각도 했었다.

이제는 그 역할이 뭔지 알 것 같다.

요즘 내가 하는 일이 그것인 것 같다.

코딩을 시작한지는 33년만이고, 소프트웨어 개발로 돈을 벌기 시작한지 25년만이다.

Lead Programmer가 경험을 쌓고, 좋은 프랙티스와 나쁜 프랙티스를 평가할 수 있고, 프로그램의 구조를 통찰할 수 있는 능력이 쌓이고, 각성하면, 열심히 하는 것보다 좋은 선택이 뭔지 보이게 되었다면, Architect에 가까와 진 것이다.

Chief Technology Officer 과 다른 점은 실무에 더 가깝다고 생각한다.

사실 CTO가 더 어렵다. 왜냐하면, 경영의 의사결정에 기술적 의사결정을 반영시킬 수 있어야 CTO라고 생각한다. 회사에서의 정치적인 지분과 기술적인 의사결정에 대한 크레딧이 필수적이다.

아직도 배우고 익히면서 새로운 통찰력을 얻는다.
오픈소스의 크리에이티브에 감탄한다.

좋은 프랙티스는 소개하고 공유하고 싶다.

개발자들이 고생하지 않으면서 좋은 품질의 소프트웨어를 개발하게 되길 원한다.

쉬운 말로 좋은 프랙티스를 공유하고 싶고, 내가 받은 영감을 되돌려 주고 싶다.

우리 회사와 우리 팀에 좋은 개발자들이 더 많이 모였으면 좋겠다.

그런 마음으로 다시 블로깅을 시작해보려고 한다.

Responsibility #1: Help the Project Director having in mind that I am just a Technical Director.

CTO(Chief Technology Officer)의 역할은 무엇인가?



CTO는 회사내의 최고 기술 책임자이다.



Project Director(또는 Project Producer)나 CSO(Chief Service Officer)와의 팀워크가 좋아

발전적인 시너지가 날 수 있다면 좋겠지만,

많은 경우 오래된 팀워크가 아니면 그렇게 되기는 쉽지 않고,

잘 되는 경우는 이 글이 다룰 문제가 아니다.



그런데, 이 말을 한번 생각해보라.

"CTO때문에 성공하는 프로젝트는 없어도, CTO가 잘못해서 망하는 프로젝트는 많다."

따라서, CTO는 성공에 커다란 공헌을 하는 것이다.



물론, CTO가 직접 프로젝트를 지휘하는 경우는 일부 회사에서 일어나는 일이다.

그러나, 현실은 One Project Company(프로젝트 하나에 의존하는 소규모의 회사)가 많다.

One Project Company에서는 특히 CTO 가 그 Project의 TD(Technical Director) 역할을 해야 한다.

그러므로, CTO의 역할을 알아보기 위해서는 TD의 역할을 먼저 알아야 한다.



TD는 그 Project에 있어서 Technical Issue(기술 이슈)에 대한 최고 결정권자이다.

Project Director(PD)는 Project 의사결정의 최고 결정권자이다. 

간단히 결론부터 말하면, 협력하는 의사결정 구조가 중요한 것이다.



PD는 기술 이슈뿐 아니라, 비즈니스 이슈, 서비스 디자인 이슈들에 대한 큰 책임을 지기 때문에, 기술 이슈까지 신경쓸 수 없기 때문에 TD에 의존해야 하고, 신뢰하여야 한다.



그런데, TD가 알아야 할 것이 있다.

반대로 TD는 비즈니스 이슈,서비스 이슈에 관심이 없진 않겠지만, 결국 PD가 책임지는 이슈에 대해서 의존해야 한다. 따라서, PD의 결정을 존중해야 하고, 특히 PD가 필요한 요구사항에 대해서 관심을 갖고 '실현'되도록 해야하는데 집중해야 한다.



그러나, 그 '실현'이 미래를 망쳐서는 안된다. TD의 존재이유 중에서 아주 중요한 면이다.

고객의 요구에 맞춰서 잘 왔더라도, 문제들이 문제를 만들어 점점 감당할 수 없는 상황이 된다면, 변화하는 고객의 요구를 결국에는 대응하지 못할 것이기 때문이다.



고객의 요구사항은 끊임없이 변화하고 진화하기 때문에, 그것들을 실현하려면 항상 시간이 촉박하다.



유한한 자원과 TD가 바라보는 미래와의 밸런스를 유지하고 있어야 하는 것이다.

Rapid Development도 필요하지만, Stable Development에 대해서도 관심을 갖지 않을 수 없다.



또한, '실현'을 위해서 '실행능력'과 '요구사항의 핵심'의 밸런스에 견주어 PD에게 '실현'방안을 제시할 수 있어야 한다.

그러려면, 탄탄한 아키텍쳐링 능력과 다양한 경험, 현재 개발팀의 역량에 기초한 바른 판단력이 필요한 것이다.

그 판단력에는 할 수 있다는 자신감과 집요하게 문제를 해결하려는 문제해결 능력이 필요할 것이다.





그렇지만, 그 밸런스와 PD의 요구사항 중에서 어떤 것이 더 중요한가?

PD의 요구사항이 중요하다.

왜냐하면, PD가 고객의 요구사항중에 어떤 것이 중요한 가를 결정하는데,

그 결정 사항중에서 시도도 못해서, 잘 될 수 있는 서비스가 고객을 실망시킬 수 있지 않겠는가?

만약에 시도해서 성공한다면, TD에게는 시간과 자원을 얻을 수 있는 기회를 얻을 수 있게 되고, 그것이 선순환을 일으킬 수 있다.

실패한다면, 그러한 기회를 얻지못하고, 유한한 자원에 쫓겨 더 나쁜 선택을 해야 할 수 밖에 없을 것이고, 그것은 악순환으로 이어지는 것이다.





정리하면, 우선순위는

1) PD의 요구사항에 맞추는 실행력

2) TD 개인의 전문적인 역량(지식과 경험)과 개발팀의 역량에 따른 촌철살인적인 판단력

3) 개발팀의 역량과 프로젝트의 미래를 보는 균형감각

순으로 될 것이다.



CTO로 다시 돌아가면, CTO는 이러한 TD들을 돌봐야 한다.