2년 전까지 직접 코드를 작성하던 시스템 엔지니어가 AI 시대에 가장 중요하다고 생각하는 것

여러분, 안녕하세요!

오늘은 기술적인 이야기에서 조금 벗어나서, AI가 당연하게 된 지금, 시스템 엔지니어로서 무엇을 중요하게 여기고 싶은지에 대해 제 경험을 바탕으로 써보겠습니다.

먼저 결론부터 말씀드리자면, 가장 중요한 것은 '품질'입니다.

사실 2년 전의 저는 AI에게 코드를 작성하도록 시키는, 이른바 vibe coding을 거의 사용하지 않았습니다. 코드는 거의 전부 제 손으로 직접 작성했습니다.

왜냐하면 생성된 코드를 확인하는 데 꽤 시간이 걸리거든요. 게다가 AI가 작성한 코드가 늘어날수록 프로젝트의 품질을 스스로 파악할 수 없게 될 것 같아, 그 점이 너무 두려웠습니다.

'확인하는 데 이렇게 시간이 걸린다면, 직접 쓰는 것이 빠르고 안전하지 않을까?'

당시에는 꽤 진지하게 그렇게 생각했습니다.

그런 생각이 바뀐 것은 한 업무 시스템 프로젝트를 진행하면서였습니다.

그 시스템은 주로 아침 8시부터 오후 5시까지 사용됩니다. Java의 Spring 프레임워크로 만들어졌고, Redis에는 커넥션 풀(connection pool)을 사용하여 연결하고 있었습니다.

발생했던 문제는 오랫동안 사용되지 않은 후 처음 접근할 때만 연결 오류가 발생한다는 현상이었습니다.

까다로운 점은 두 번째 접근에서는 아무 일도 없었던 것처럼 작동한다는 것입니다. '좋아, 조사해 보자' 하고 다시 조작하면 더 이상 재현되지 않습니다. 이런 건 정말 곤란하죠.

꽤 오랫동안 조사했지만 원인을 전혀 알 수 없었습니다.

더 이상 방법이 없어서, 만일의 경우로 AI에게 프로젝트 코드를 통째로 읽게 했습니다.

그러자 순식간에 원인을 찾아주었습니다. 솔직히 저는 깜짝 놀랐습니다.

세부적인 설정이나 대응 내용은 이미 기억나지 않기 때문에 대략적으로 말씀드리자면, 원인은 이런 흐름이었습니다.

밤 동안 Redis 접근이 전혀 없음
↓
풀의 커넥션이 모두 끊어짐
...

'아하, 이건 재현되지 않는구나.'

대응책으로는 먼저 프론트엔드의 HTTP 타임아웃을 늘려서 오류가 발생하지 않도록 했습니다. 최종적으로는 사용되지 않는 시간대에도 배치(batch)로 주기적으로 Redis에 접근하여 커넥션이 끊어지지 않게 하고 있습니다.

나중에 알았는데, Spring 프레임워크의 GitHub 리포지토리에는 몇 년 전에 같은 증상의 이슈가 올라와 있었습니다. AI는 그것을 알고 있었기 때문에 바로 찾아낼 수 있었던 것입니다.

인간이 거기에 도달하려면 먼저 '무엇으로 검색해야 할지' 깨닫는 것이 필요합니다. 하지만 AI는 코드와 방대한 과거의 정보를 한 번에 연결해 줍니다.

'찾고, 연결하는 능력은 AI가 인간보다 훨씬 뛰어나구나.'

그때 순수하게 그렇게 생각했습니다. 그 이후 조금씩 프로젝트에 AI를 참여시키기 시작했습니다.

지금은 AI를 상당히 많이 사용하고 있습니다. 설계 상담도, 구현도, 테스트 작성도 여러 상황에서 도움을 받고 있습니다.

다만 2년 전에 느꼈던 '품질을 파악할 수 없게 될지도 모른다'는 불안감이 사라진 것은 아닙니다. 불안이 사라졌다기보다는, 품질을 지키는 방법 자체가 바뀌었다고 느껴집니다.

AI가 코드를 점점 많이 작성하게 된 지금, 시스템 엔지니어가 노력해야 할 부분은 두 가지가 있다고 생각합니다.

첫째는, 품질을 지키기 위한 메커니즘입니다.

예를 들어, 테스트 코드는 AI에게 작성하도록 합니다. 하지만 그 테스트 코드가 정말 올바른지는 반드시 제가 직접 확인합니다. 테스트 자체가 틀렸다면 '테스트가 통과했다!'는 아무 의미가 없으니까요.

프론트엔드의 경우, 브라우저를 조작할 수 있는 Playwright MCP를 사용해서 사람이 브라우저로 만지는 것과 같은 흐름을 AI에게 시켜봅니다. 이때 '제대로 작동했다'는 증거도 남겨둡니다.

AI가 작성하게 하고, AI가 테스트하게 하며, 그 결과를 사람이 확인할 수 있는 형태로 남기는 것. 여기까지 해야 비로소 '품질을 지키고 있다'고 말할 수 있지 않을까 생각합니다.

또 하나는, AI 시대에서도 기술의 원리를 계속 학습하는 것입니다.

아까 Redis 건도 원인을 찾은 것은 AI였습니다. 하지만 '그것이 정말 원인인지', '어떻게 고치는 것이 좋은지'를 판단하려면 커넥션 풀이나 타임아웃 메커니즘을 제가 알고 있어야 합니다.

AI의 답변을 평가할 수 없다면, 잘못된 답변도 그대로 채택해 버립니다. 따라서 여러 기술에 대한 기본적인 지식이나 최적화에 대한 생각 같은 것은 앞으로도 제 머릿속에 제대로 넣어두고 싶습니다.

중요한 것이니 세 번 말합니다.

품질, 품질, 품질!

AI가 프로젝트에 참여하는 것은 이제 당연해져 왔습니다. 하지만 그것은 '프로젝트의 품질을 보장할 수 있다'는 것을 전제로 합니다. 아무리 빨리 작성하더라도, 품질를 파악할 수 없게 되면 의미가 없습니다.

2년 전의 저는, 품질이 걱정되어 AI를 사용하지 않았습니다. 지금의 저는, 품질을 지킬 수 있는 시스템을 구축한 후에 AI를 사용하고 있습니다. 그렇게 생각하니, 품질에 대한 고집은 2년 전부터 아무것도 변하지 않은 것일지도 모릅니다.

AI에게 맡기는 것이 늘어나도, 품질에 대한 책임만큼은 놓지 않겠습니다. 앞으로도, 그 점만은 잊지 않고 AI와 함께해 나가려고 합니다.