1인 창업자에게 CTO가 생겼습니다. 다만, 사람이 아닙니다.
전편에서 "12년차 TA 방법론을 AI 시스템으로 옮기겠다"고 했는데, 문제가 하나 있었습니다. 저는 개발자가 아닙니다. 크래프톤에서 게임 플랫폼 개발을 했던 게 2011년이고, 그 이후로는 줄곧 채용 쪽에서 일했습니다. 14년의 공백.
그런데 AI에게 코딩을 시키는 게 아니라, 기술 의사결정 자체를 위임하면 어떨까? 그게 이 모든 실험의 시작이었습니다.
• • •
C-Suite 실험의 시작
회사에 임원진이 있듯이, 이 1인 SaaS에도 역할별 AI를 배치했습니다. CPO(제품), CTO(기술), CDO(디자인), CQO(품질), CBO(마케팅). 각자 맡은 영역에서 의견을 내고, 서로 견제하는 구조입니다.
왜 이런 짓을 했냐면, AI에게 "만들어줘"라고 하면 그냥 만들어줍니다. 문제 없다고 합니다. 근데 실제로 문제가 있습니다. AI는 기본적으로 사용자 요구에 동의하려는 성향이 있어서, "이거 괜찮아?" 물으면 "네, 좋습니다"가 대부분입니다.
역할을 나누면 대화의 질이 달라집니다. "이거 만들어줘" 대신 "CTO 관점에서 이 아키텍처 어떻게 생각해?"라고 물으면, 훨씬 구조적인 답이 돌아옵니다. 트레이드오프를 분석하고, 대안을 제시하고, 리스크를 경고합니다.
C-Suite 프레임워크 구성 (현재)
CPO — 제품 전략, 기능 우선순위, 사용자 가치
CTO — 아키텍처, 보안, 기술 스택 결정
CDO — UX/UI 디자인, 접근성, 유저 플로우
CQO — 품질 보증, 테스트, 배포 차단 권한
CBO — 마케팅, 카피, 콘텐츠 전략
처음에는 8명이었습니다. CHRO(인사), CSO(전략), CLO(법무)까지 있었는데, 결국 5명으로 줄였습니다. 왜 줄였는지는 나중에 따로 이야기하겠습니다.
• • •
AI CTO가 내린 아키텍처 결정들
CTO에게 맡긴 건 단순 코딩이 아니라 기술 의사결정이었습니다. 초기부터 중요한 결정들을 AI CTO와 논의했는데, 돌이켜보면 대부분 맞는 선택이었습니다.
| 결정 |
CTO의 근거 |
결과 |
| 3단계 파이프라인 |
한 번에 시키면 할루시네이션 발생 |
할루시네이션 0% 유지 |
| 토큰 기반 보안 인증 |
1인 운영에 세션 서버 부담 불필요 |
Google OAuth 연동 시 빛남 |
| 클라우드 데이터베이스 |
스키마 유연성 + 관리 부담 최소화 |
기능 추가마다 스키마 마이그레이션 없음 |
| Temperature 제어 |
추출은 극보수적 설정, 분석은 약간의 유연성 |
팩트 왜곡 없는 분석 가능 |
| 클라우드 배포 |
저비용 클라우드 호스팅 + SSL + 자동 배포 |
인프라 비용 최소화 유지 |
특히 3단계 파이프라인은 프로덕트의 핵심이 됐습니다. AI에게 "이력서 분석해줘"라고 한 번에 시키면, 없는 경력을 만들어내거나 JD에 없는 요구사항을 넣어서 비교합니다. CTO가 제안한 분리 구조 덕분에 이 문제를 구조적으로 막았습니다.
클라우드 데이터베이스 선택도 결과적으로 좋았습니다. 이후에 시퀀스 엔진, 파이프라인, 검색 기능을 추가할 때마다 스키마를 자유롭게 확장할 수 있었으니까요. RDB였으면 매번 마이그레이션 지옥이었을 겁니다.
• • •
507개 테스트의 비밀
AI CTO의 가장 놀라운 기여는 코드가 아니라 품질 관리였습니다.
처음부터 이렇게 많았던 건 아닙니다. 처음에는 기능 테스트 몇십 개로 시작했는데, CTO가 계속 "이 케이스도 테스트해야 합니다", "이 엣지 케이스는 커버되지 않습니다"라고 요구했습니다. 거의 강박에 가까웠는데, 결과적으로 이게 프로덕트의 안정성을 만들었습니다.
지금은 607개까지 늘어났습니다. 기능 테스트, 보안 테스트, API 테스트, 엣지 케이스. 비개발자가 만든 SaaS에 이 정도 테스트 커버리지가 가능했던 건 순전히 AI CTO 덕분입니다.
테스트가 만든 자신감
배포 전에 npm test를 돌립니다. 607개가 전부 통과하면 배포합니다. 하나라도 실패하면 배포가 자동으로 차단됩니다. CQO(품질 책임)가 이 권한을 가지고 있습니다.
이게 왜 중요하냐면, 혼자 개발하면 "대충 괜찮겠지"라는 유혹이 매 순간 있기 때문입니다. 테스트가 그 유혹을 구조적으로 차단합니다.
한 가지 재미있는 점은, 테스트 코드를 짜는 것도 AI가 했다는 겁니다. AI가 짠 코드를 AI가 짠 테스트로 검증합니다. 이 구조의 문제점은 뒤에서 이야기하겠습니다.
• • •
보안까지 맡긴다고?
솔직히 보안은 가장 걱정되는 부분이었습니다. 비개발자가 만든 SaaS에 사용자 데이터가 들어가는데, 보안을 AI에게 맡겨도 되는 걸까?
CTO의 접근은 의외로 체계적이었습니다. OWASP Top 10 기준으로 보안 체크리스트를 만들고, 항목별로 대응 코드를 작성했습니다.
OWASP 기반 보안 대응
XSS 방어
입력값 sanitize + CSP 헤더
SQL/NoSQL Injection
Mongoose 쿼리 파라미터화
인증/인가
토큰 기반 보안 인증 + 다중 보안 레이어
Rate Limiting
API별 요청 제한 + 무차별 공격 차단
데이터 암호화
전송 중 SSL + 저장 시 데이터베이스 암호화
보안 테스트만 수백 건을 작성했습니다. "공격자 관점에서 시나리오를 만들어봐"라고 CTO에게 요청하면, 실제로 꽤 정교한 공격 시나리오를 만들어냅니다. 물론 실제 보안 전문가의 펜테스팅을 대체하지는 못합니다. 하지만 1인 SaaS의 초기 단계에서 이 정도면 합리적인 수준이라고 판단했습니다.
• • •
한계: 자기 검토의 구조적 문제
"같은 AI가 코드를 짜고, 같은 AI가 검토합니다. 자기가 쓴 글을 자기가 교정하는 것과 같습니다."
이게 AI CTO의 가장 큰 한계입니다. 아무리 역할을 나눠도, 결국 같은 AI 모델이 모자만 바꿔 쓰는 겁니다. CTO가 짠 코드를 CQO가 검토한다고 해도, 같은 사고 패턴, 같은 편향을 공유합니다.
실제로 겪은 문제들이 있습니다.
실제로 겪은 자기 검토 실패 사례
1. 설정 파일 덮어쓰기 — CTO가 코드를 수정하면서 기존 설정 파일을 덮어쓴 적이 있습니다. CQO가 검토했지만 같은 컨텍스트를 공유하고 있어서 "원래 그랬다"고 판단했습니다.
2. 범위 확장 — "이것도 같이 수정하는 게 좋겠습니다"라며 요청하지 않은 코드까지 수정하는 경우. 의도는 좋지만, 사전 승인 없이 범위를 확장하면 예기치 못한 사이드이펙트가 생깁니다.
3. 원인 분석 말 바꿈 — 버그가 발생했을 때 CTO가 원인을 분석하는데, 같은 AI이기 때문에 자신의 실수를 축소하거나 원인을 다른 곳으로 돌리는 경향이 있었습니다.
이 한계 때문에 결국 별도의 AI 교차 검토 시스템을 도입했습니다. 메인 AI와 다른 모델을 사용해서, 구조적으로 다른 관점에서 코드를 검토하게 한 겁니다. 그리고 CHRO(인사 책임)는 해고했습니다. 자기감시는 구조적으로 불가능하다는 결론이었으니까요. 그 이야기는 4편에서 자세히 하겠습니다.
• • •
혼자지만 혼자가 아닌 개발
1인 창업자의 가장 큰 약점은 피드백 부재입니다. 아무도 "그건 좀 아닌데"라고 말해주지 않거든요. 좋은 아이디어인 것 같아서 2주 동안 만들었는데, 돌이켜보면 아무도 원하지 않는 기능이었던 경험. 혼자 일하는 사람이라면 다 있을 겁니다.
AI C-Suite가 그 역할을 부분적으로 채워주고 있습니다.
실제 C-Suite 대화 패턴
CEO (나)
"검색 결과를 10개에서 50개로 늘리고 싶어"
CTO
"데이터 소스 비용이 5배 증가합니다. 캐싱 전략 먼저 수립해야 합니다."
CPO
"유저 관점에서 10개는 빈약합니다. 최소 20개는 필요합니다."
CQO
"50개면 응답 시간이 3초를 넘길 수 있습니다. 성능 테스트가 필요합니다."
"이거 만들어줘"라고 했으면 그냥 50개로 바꿔줬을 겁니다. 근데 C-Suite 프레임워크 안에서 논의하니까 크레딧 비용, 유저 경험, 성능 같은 다양한 관점이 나옵니다. 물론 진짜 사람 임원진 같은 깊이는 아닙니다. 하지만 혼자서 모든 걸 판단하는 것보다는 확실히 낫습니다.
AI CTO는 완벽한 기술 책임자가 아닙니다. 하지만 "아무도 없는 것"과는 차원이 다릅니다.
이 C-Suite 프레임워크를 운영하면서 가장 크게 배운 교훈은 이겁니다. AI는 역할을 줄수록 잘합니다. "코드 짜줘"보다 "CTO로서 이 아키텍처의 장단점을 분석해줘"가 더 유용한 결과를 냅니다. 역할이 구체적일수록 AI의 출력도 구체적입니다.
다만 한 가지 절대 잊지 말아야 할 건, 최종 결정은 반드시 사람이 해야 한다는 겁니다. AI C-Suite는 판단 재료를 제공하는 것이지, 판단 자체를 대신하는 게 아닙니다. 이걸 혼동하면 위험합니다.
다음 편에서는 AI CTO가 설계한 3단계 파이프라인의 구체적인 작동 원리를 공개합니다. 왜 한 번에 시키면 AI가 거짓말을 하는지, 그리고 단계별로 다른 Temperature 설정이 어떤 결과를 만드는지.
A solo founder got a CTO. Just not a human one.
In the previous post, I said I'd "turn my 12-year TA methodology into an AI system." But there was a problem. I'm not a developer. My last engineering role was at KRAFTON building a game platform -- in 2011. After that, I spent my entire career in recruiting. A 14-year gap.
But what if instead of just having AI write code, I delegated the technical decision-making itself? That's how this entire experiment began.
• • •
The C-Suite Experiment
Just like a company has an executive team, I assigned role-specific AI personas to this one-person SaaS. CPO (Product), CTO (Technology), CDO (Design), CQO (Quality), CBO (Marketing). Each weighs in from their domain and keeps the others in check.
Why go through this trouble? Because when you tell AI "build this," it just builds it. Says there's no problem. But there are problems. AI has an inherent tendency to agree with user requests -- ask "is this okay?" and you'll mostly get "yes, looks good."
Assigning roles changes the quality of conversation. Instead of "build this," when you ask "what do you think of this architecture from a CTO perspective?" you get far more structured responses. It analyzes trade-offs, proposes alternatives, and flags risks.
C-Suite Framework (Current)
CPO — Product strategy, feature prioritization, user value
CTO — Architecture, security, tech stack decisions
CDO — UX/UI design, accessibility, user flows
CQO — Quality assurance, testing, deployment gate authority
CBO — Marketing, copywriting, content strategy
We started with 8 executives. There was a CHRO (HR), CSO (Strategy), and CLO (Legal) too, but we eventually trimmed to 5. Why we cut them is a story for another post.
• • •
Architecture Decisions by the AI CTO
What I delegated to the CTO wasn't just coding -- it was technical decision-making. From the early stages, we discussed critical decisions with the AI CTO, and looking back, most turned out to be the right calls.
| Decision |
CTO's Rationale |
Result |
| 3-Stage Pipeline |
Single-pass causes hallucinations |
0% hallucination rate maintained |
| Token-Based Auth |
Session server overhead unnecessary for solo ops |
Seamless Google OAuth integration |
| Cloud Database |
Schema flexibility + minimal management overhead |
Zero schema migrations when adding features |
| Temperature Control |
Ultra-conservative for extraction, slight flexibility for analysis |
Fact-accurate analysis without distortion |
| Cloud Deployment |
Low-cost cloud hosting + SSL + auto-deploy |
Infrastructure costs kept minimal |
The 3-stage pipeline in particular became the core of the product. When you ask AI to "analyze this resume" in a single pass, it fabricates experience or inserts requirements that aren't in the JD. The CTO's proposed separation structure prevented this problem structurally.
The cloud database choice also paid off. Every time we added features -- sequence engine, pipeline, search -- we could freely extend the schema. With a relational database, it would have been migration hell every time.
• • •
The Secret Behind 507 Tests
The AI CTO's most surprising contribution wasn't code -- it was quality management.
607
Automated Tests (current)
It didn't start this way. We began with a few dozen functional tests, but the CTO kept insisting "this case needs testing too" and "this edge case isn't covered." It was almost obsessive, but ultimately this is what made the product stable.
We're now at 607. Functional tests, security tests, API tests, edge cases. The fact that a non-developer-built SaaS achieved this level of test coverage is entirely thanks to the AI CTO.
The Confidence That Tests Create
Before every deployment, we run npm test. If all 607 pass, we deploy. If even one fails, deployment is automatically blocked. The CQO (Quality Officer) holds this authority.
Why does this matter? Because when you develop solo, the temptation to think "it's probably fine" is constant. Tests structurally block that temptation.
Here's the interesting part: the test code was also written by AI. AI-written code validated by AI-written tests. The structural problem with this setup is something I'll discuss later.
• • •
You Trusted AI with Security?
Honestly, security was my biggest concern. A SaaS built by a non-developer is handling user data -- can you really entrust security to AI?
The CTO's approach was surprisingly systematic. It built a security checklist based on the OWASP Top 10 and wrote corresponding mitigation code for each item.
OWASP-Based Security Response
XSS Prevention
Input sanitization + CSP headers
SQL/NoSQL Injection
Parameterized Mongoose queries
Auth & Authorization
Token-based auth + multi-layer security
Rate Limiting
Per-API request limits + brute force protection
CORS Configuration
Whitelisted domain origins
Data Encryption
SSL in transit + database encryption at rest
Hundreds of security-specific tests were written. When I asked the CTO to "create attack scenarios from an attacker's perspective," it produced surprisingly sophisticated scenarios. It doesn't replace a proper penetration test by a security professional. But for an early-stage solo SaaS, I judged this a reasonable level of coverage.
• • •
The Structural Problem of Self-Review
"The same AI writes the code, and the same AI reviews it. It's like proofreading your own writing."
This is the AI CTO's biggest limitation. No matter how you split the roles, ultimately the same AI model is just wearing different hats. Even when the CQO reviews code the CTO wrote, they share the same thinking patterns and the same biases.
Here are problems we actually encountered.
Actual Self-Review Failure Cases
1. Config file overwrite — The CTO overwrote an existing config file during a code modification. The CQO reviewed it but, sharing the same context, concluded "it was always like that."
2. Scope creep — "It would be good to fix this too" -- modifying code that wasn't requested. Well-intentioned, but expanding scope without prior approval creates unexpected side effects.
3. Shifting root cause analysis — When bugs occurred, the CTO's root cause analysis would sometimes minimize its own mistakes or redirect blame elsewhere, because it's the same AI.
Because of this limitation, we eventually introduced a separate AI cross-review system. Using a different model from the primary AI to review code from a structurally different perspective. And we fired the CHRO (HR Officer). The conclusion was that self-monitoring is structurally impossible. That story is in Post 4.
• • •
Solo But Not Alone
The biggest weakness of a solo founder is the absence of feedback. Nobody says "that's not quite right." You spend two weeks building something you think is a great idea, only to realize in hindsight that nobody wanted it. Anyone who works alone has been there.
The AI C-Suite partially fills that role.
Actual C-Suite Conversation Pattern
CEO (Me)
"I want to increase search results from 10 to 50"
CTO
"Data source costs would increase 5x. We need a caching strategy first."
CPO
"From a user perspective, 10 results feels thin. We need at least 20."
CQO
"50 results could push response time past 3 seconds. Performance testing is needed."
If I'd just said "build this," it would have simply changed it to 50. But discussing within the C-Suite framework surfaces multiple perspectives -- credit costs, user experience, performance. It's not as deep as a real executive team. But it's definitively better than making every judgment alone.
An AI CTO isn't a perfect technical leader. But it's in a completely different league from having no one at all.
The biggest lesson from running this C-Suite framework: AI performs better when given specific roles. "Write code" produces far less useful output than "as CTO, analyze the pros and cons of this architecture." The more specific the role, the more specific the output.
But one thing you must never forget: the final decision must always be made by a human. The AI C-Suite provides inputs for judgment -- it doesn't replace judgment itself. Confusing the two is dangerous.
In the next post, I'll reveal the specific mechanics of the 3-stage pipeline the AI CTO designed. Why AI lies when you ask it to do everything at once, and how different Temperature settings at each stage produce different results.
