개인 프로젝트에서 AI 사용 vs 기업 코드베이스

Source: Dev.to

원래는 johnvw.dev에 게시되었습니다.

Source: …

AI 사용 방식의 변화

시니어 소프트웨어 엔지니어로서 나는 대규모 엔터프라이즈 소프트웨어 작업에서 AI를 광범위하게 활용해 왔습니다. 그럼에도 불구하고 개인 프로젝트에서는 거의 사용하지 않았습니다. 도구들이 아직 비교적 새로웠을 때 거의 1년 전쯤 조금 실험해 보긴 했지만, 그 이후로는 대부분 직업적인 환경에서만 사용했습니다.

하지만 최근 상황이 달라졌습니다.

나는 개인 사이트(아마도 지금 이 글을 읽고 있는 곳)를 GPT 5.2만을 사용해 완전히 구축했습니다. 이 경험은 매우 깨우침을 주었으며, 작은 개인 프로젝트에 AI를 적용할 때와 대규모 엔터프라이즈 시스템에 동일한 도구를 사용할 때의 중요한 차이점을 부각시켰습니다.

다음은 그 대비를 통해 얻은 몇 가지 교훈입니다.

AI가 거의 마법처럼 느껴질 때

개인 프로젝트로, 간단한 정적 블로그를 만들었습니다. 먼저 자리 표시자 랜딩 페이지를 올렸습니다. 내가 원하는 것을 간략히 설명했더니, AI가 내가 생각한 90 % 정도에 해당하는 간단한 페이지를 만들어 주었습니다. 몇 차례 더 대화를 나눈 뒤, 첫 번째 버전을 완성했습니다.

즉시 업로드해서, 내가 실제로 원하는 기능인 블로그가 완성될 때까지 사이트가 비어 있지 않게 했습니다. 전체 과정(호스팅 설정 포함)은 한 시간 정도 걸렸으며, 예상보다 훨씬 빨랐습니다.

다음 날, 본격적으로 블로그 자체를 구축하기 위해 자리를 잡았습니다. 최신 도구를 사용하더라도 몇 저녁 정도는 걸릴 것이라고 예상했지만, AI가 얼마나 과정을 가속화할 수 있을지 궁금했습니다.

그리고 실제로 크게 가속화되었습니다.

깔끔한 사양, 작은 스토리, 그리고 빠른 진행

AI에게 프로젝트를 설명하면서 제약 조건, 색상, 기술 선택, 그리고 무엇보다도 원하지 않는 사항들을 이야기했습니다. AI에게 레포지토리 루트에 SPEC.md 파일을 만들게 해서, 개발이 진행되는 동안 사양을 다듬고 언제든지 참조할 수 있게 했습니다.

AI는 몇 가지 명확히 하는 질문을 했고, 몇 차례 주고받은 뒤 사양은 제가 만족할 수 있는 수준에 도달했습니다.

그 다음 새 채팅을 열어 사양을 작고 실행 가능한 스토리들로 나누도록 함께 작업했습니다. 그 스토리들도 함께 다듬었고, 프로젝트가 진행되면서 나중에 몇 개의 스토리를 추가하기도 했습니다.

스토리들이 준비되면 또 다른 채팅을 열어 AI에게 첫 번째 스토리를 구현하도록 요청했으며, 필요할 때마다 사양을 참고하도록 했습니다.

이때부터 제 머리가 녹기 시작했습니다.

엔터프라이즈 대비

직장에서 나는 대규모 시스템에 AI를 사용하는 데 익숙합니다. AI에게 컨텍스트를 제공하고, 스토리를 이해하도록 돕고, 구현 작업의 대부분을 맡기는 데 익숙합니다. 하지만 이것이 시간이 걸린다는 것도 익숙합니다. 응답을 받기 위해 몇 분을 기다리는 것이 드문 일이 아니며, 그 후에 AI가 만든 결과물을 검토하는 데 더 많은 시간을 소비합니다.

작업을 작게 유지하더라도, 레거시 시스템은 겉보기에 간단한 변경이라도 이해하기 위해 많은 컨텍스트를 요구하는 경우가 많습니다.

여기서는 그렇지 않았습니다.

1~2분 안에 AI는 첫 번째 스토리를 완료했으며—내가 확인한 바로는 모든 작업을 정확히 수행했습니다. 나는 변경 사항을 커밋하고 푸시하도록 했고, 새 채팅을 열어 다음 스토리를 구현해 달라고 요청했습니다.

그렇게 진행되었습니다.

각 스토리가 빠르고 완전하게 구현되었습니다. 그때 비로소 가능성들이 실감 나기 시작했습니다.

왜 단순 작업이 상품화되고 있는가

AI가 이렇게 빠르게 움직일 수 있다면, 누군가가 원하는 단순 프로젝트를 만드는 것을 막는 것이 무엇일까요? 많은 경우, 그것은 바로 그들의 동기부여입니다. 이는 사실상 단순 작업을 상품화하여, 외부 도움 없이 작은 시스템을 구축하려는 사람들의 진입 장벽을 낮춥니다.

하지만 저는 제 일상 업무에 대해 생각해 보았습니다.

제가 일하는 시스템은 방대합니다. 최신 모델이 얼마나 인상적이든, 전체 시스템을 컨텍스트 윈도우에 담을 현실적인 방법은 없습니다. 그럼에도 불구하고 AI는 그곳에서 부인할 수 없을 정도로 유용합니다; 다만 그 방식은 다르게 작동합니다.

이러한 대조는 중요한 질문을 제기합니다: 두 환경 모두에서 우리는 무엇을 배울 수 있을까요?

Lesson One: Context Is Everything

작은 시스템에서는 AI가 관련 코드 대부분을, 혹은 전체를 컨텍스트 윈도우에 담을 수 있습니다. 실제로 그렇게 하길 원하지는 않겠지만, 핵심은 시스템 자체가 더 단순하고 이해하기 쉬워진다는 점입니다.

새 페이지를 추가하고 싶나요? 요구 사항과 약간의 컨텍스트만 제공하면 몇 분 안에 꽤 견고한 구현을 얻을 수 있을 것입니다.

엔터프라이즈 시스템에서는 같은 변경이 가능하지만 훨씬 더 신중해야 합니다. 단순히 원하는 것을 설명하는 대신, AI가 부족한 아키텍처 컨텍스트를 제공해야 합니다:

• 어떤 라우터를 사용하고 있나요?
• 페이지에 대해 어떤 패턴이 정해져 있나요?
• 이 코드는 어디에 위치해야 하나요?
• 모델링할 수 있는 기존 페이지가 있나요?

이 정보를 제공하면 성공 확률이 크게 높아집니다. 개인 프로젝트보다 시간이 더 걸리지만, 이 정보를 제공하지 않으면 컨텍스트 윈도우가 채워지면서 모델 성능이 저하되고 오해를 바로잡는 데 시간을 낭비하게 됩니다.

레슨 2: 작은 조각은 리더십 스킬이다

맥락과 밀접하게 관련된 것은 작업을 작고 관리 가능한 조각으로 나누는 능력입니다. 제게 이것은 근본적으로 tech‑lead 스킬입니다.

Tech lead는 제품 관리자와 협력하여 사용자 요구를 기술 요구사항으로 변환합니다. 우리는 그 요구사항을 작고 실행 가능한 조각으로 정리하여 팀이 과부하에 빠지지 않고 빠르게 움직일 수 있게 합니다.

같은 스킬이 AI와 작업할 때도 매우 귀중합니다.

• 작업 항목이 작을수록 전체 맥락을 제공하기가 더 쉽습니다.
• 그 상호작용이 원활할수록 테스트하고 개선할 수 있는 작동 소프트웨어를 더 빨리 얻을 수 있습니다.
• 피드백 루프가 빨라지면 더 빨리 배포하고, 더 빨리 배우며, 더 빨리 조정할 수 있습니다.

이것은 스테로이드를 맞춘 애자일 소프트웨어 개발과 같습니다.

AI가 제약을 증폭시킨다

이 모든 것이 더 깊은 문제를 강조한다: AI가 제약을 증폭시킨다.

최근에 “AI가 이 회사를 망하게 한 것이 아니라, 나쁜 비즈니스 모델을 드러냈다” 혹은 “AI …”와 같은 의견이 많이 나오고 있다.

(원본 글이 여기서 끊겼으며, 의도된 결론은 AI가 기존 프로세스와 아키텍처상의 약점을 어떻게 드러내는지에 대해 확장될 가능성이 있다.)

> “didn’t cause these layoffs, it exposed poor performance.”  
> While I don’t fully agree with those claims, I do agree with the underlying idea: as systems become more efficient, their weaknesses become more visible.

As coding gets faster, bottlenecks shift elsewhere. If implementation takes minutes, what about:

- UX research?  
- Requirements gathering?  
- Testing?  
- Deployment?  
- Maintenance?  
- Architectural shifts?

This is why small personal projects can move at breakneck speed while large enterprise systems often feel slow—even with AI moving things along. It’s rarely the tools that are the problem; more often, it’s the surrounding process. That’s not a criticism of enterprise environments—it’s a reality of scale. The more customers, products, and revenue you have, the more those supporting processes matter.

**The real question** is how we improve those areas alongside our tooling.

시니어 엔지니어의 역할

나는 단일하고 확정적인 답이 있다고 생각하지 않지만, 그 중 일부는 소유권에 달려 있습니다:

• 가능한 한 제품 수명 주기의 많은 부분을 스스로 담당하세요.
• 담당할 수 없는 부분에서는 긍정적인 영향을 미치세요.

AI가 시니어 엔지니어링 기술을 없애는 것이 아니라, 오히려 보상합니다. 제약을 관리하고, 맥락을 제공하며, 작업을 분해하고, 시스템적으로 사고하는 능력은 AI‑지원 환경에서 더욱 가치 있게 됩니다.

이는 경험 많은 엔지니어에게 위협이 아니라 기회입니다.

토론 질문

• 작업 중에 비슷한 패턴을 발견한 적이 있나요?
• 작은 프로젝트와 대규모 코드베이스에서 AI 사용에 어떤 차이를 보셨나요?
• 다른 사람들에게 공유하고 싶은 교훈은 무엇인가요?