이게 직장에서 재미있는 프로그래밍 언어를 사용할 마지막 기회일까?

발행: 3일 전 (2026년 2월 16일 오전 04:44 GMT+9)

21 분 소요

원문: Dev.to

Source: Dev.to

갈등

다른 시각으로 보면 주류 vs. 틈새 프로그래밍 언어 관점에서 볼 수 있습니다.

특정 프로그래밍 언어에 집착한다면, 아마도 틈새이거나 난해한 언어에 집착하고 있는 것입니다.
집착하지 않는다면, 대체로 표준에 가까운, “Oracle을 선택해도 해고당한 사람은 없다”는 옛날 말처럼 흔히 쓰이는 것을 사용하고 있을 가능성이 높습니다.

두 경우가 완전히 같은 것은 아니지만, 잠시만 따라와 주세요. 저는 어느 쪽도 주장하는 것이 아니라, 갈등이 존재한다는 점을 확립하고 싶습니다:

팀, 회사, 혹은 더 넓은 산업 안에는 서로 다른 가치와 관심사를 가진 사람들이 존재합니다.

새롭게 떠오른 갈등 중 하나는 LLM(대규모 언어 모델)의 사용입니다. 다시 말해, 전적으로 옹호하는 사람도 있고, 사용을 거부하는 사람도 있으며, 그 사이 어딘가에 있는 사람도 많습니다.

이 차원들을 겹치면 충돌하는 사분면이 생깁니다. 이는 단순한 예시일 뿐이며, 갈등은 드물게 이차원적으로만 존재합니다.

갈등은 즐거운 것이 아닙니다. 물론 일부 사람들은 갈등을 사랑하고 그 안에서 성장하지만, 대부분에게 지속적인 갈등은 소모적입니다. 팀 내 대부분이 한 사분면에 있고 내가 다른 사분면에 있다면, 나는 다음과 같은 선택을 해야 합니다:

나의 필요를 억누른다,
논쟁한다,
회사를 옮긴다,
혹은 다른 방법을 찾는다.

가능한 해결책

직장에서 프로젝트를 살펴보던 중, 문득 떠올랐습니다: 우리는 케이크를 가지고 먹을 수도 있다 – 한 그룹은 특정 도구를 가질 수 있고, 다른 그룹은 다른 것을 사용할 수 있습니다. 우리는 여러 사분면에 걸쳐 성공적이고 갈등이 적은 팀을 운영할 수 있습니다.

아래는 그 작은 프로젝트의 이야기입니다. 어두운 격동의 시기에 여러분에게 희망이나 영감을 줄 수 있기를 바랍니다.

프로젝트: 내부 대시보드를 PureScript로 마이그레이션

배경

약 2년 전, 기존 내부 대시보드를 PureScript로 마이그레이션하고 싶었습니다.
그 대시보드는 아무도 건드리거나 확장하고 싶어 하지 않는 레거시 시스템의 일부였으며, 기준이 매우 낮았습니다.

목표

기본 기능을 빠르게 마이그레이션하여 나를 미치게 하던 대규모 레거시‑시스템 마이그레이션을 방해하지 않게 합니다.
가능한 최소한의 마찰로 구성 가능하고 확장 가능하게 만들기: 복사‑붙여넣기 가능한 컴포넌트와 TypeScript/JavaScript 컴포넌트의 쉬운 통합.
PureScript를 소개하고 사람들의 호기심을 자극하기 (스포일러: 결과는 없었습니다).

PureScript 사용을 확산시키는 것이 목표가 아니었습니다; 팀과 기술 리더십과의 합의는 몇 주간 시도해 본 뒤, TypeScript로 재작성할지 고려하거나 계획하는 것이었습니다.

나는 자투리 시간에 MVP(핵심 기능 마이그레이션 포함)를 만들었습니다. 업무 시간에는 이를 할 여유가 없었기 때문입니다. 추가로 PureScript + shadcn/ui에 관한 영상과 템플릿도 제작했습니다.

유지보수 불가능한 기술을 도입하지 말아야 하는 이유

나는 아무도 유지보수할 수 없는 무언가를 도입하는 것이 가장 최악이고 비전문적인 행동 중 하나라고 믿습니다. 이는 해당 기술의 평판을 영원히 손상시킬 수 있습니다.

한 번은 Haskell으로 만든 프로젝트를 보았는데, 처음부터 관리가 형편없고 비현실적인 계획 때문에 실패가 확정되었습니다. 사람들이 떠났고 결국 아무도 유지보수하거나 원하지 않게 되었습니다. 몇 년 후, Haskell이 어떤 모습인지조차 몰랐던 사람들은 그 언어(그리고 개발 팀)를 모든 문제의 원인으로 탓했습니다.

Execution

첫 번째 버전을 배포한 뒤, 기여자는 우리 둘뿐이었습니다.

내 협력자는 PureScript 경험이 전혀 없었고 처음에는 툴링과 컴파일 오류 때문에 싫어했습니다.
그럼에도 불구하고 그는 내가 한 것보다 더 많은 코드와 기능을 기여했습니다.
몇 주 만에 프로젝트를 꽤 큰 규모까지 끌어올렸습니다. 비록 우리 팀의 우선순위에 없었지만, 저녁 시간과 다른 작업 사이에 작업했습니다.

The LLM‑Assisted Era

프로젝트가 순조롭게 성장하던 중, 우리는 LLM‑보조 코딩 시대에 들어섰습니다.

예전엔 수동으로 관리하던 많은 번거로운 일들이 이제는 깔끔한 UI 뒤에 숨겨졌습니다: 고객 지원 도구, 개발 도구, 제품 설정, 분석, 탐색 도구 등.
그 코드의 대부분은 인간이 작성한 것이 아닙니다. 결과는? 꽤 성공적입니다.

이렇게 잘 작동하고 확장되는 주요 이유 중 하나는 무상태 앱이기 때문입니다 (사용자의 다크/라이트 모드 선호도 저장을 제외하고). 또한 흐름이 단순합니다. LLM을 마음껏 활용했을 때, 우리는 이미 복사‑붙여넣기 가능한 스니펫들로 가득한 견고한 코드베이스를 가지고 있었습니다.

각 도구는 격리되어 있어 다른 부분에 영향을 주지 않습니다. 유일한 문제는 모든 것을 정리하고 UI를 어수선하게 만들지 않는 것이지만, 이는 실제 문제라기보다 재미있는 퍼즐에 가깝습니다. 이런 상황에서는 다른 도구에 영향을 줄 수 있는 잠재적으로 나쁘거나 느린 변경에 대해 두려워하지 않습니다—대규모 스모크 테스트나 QA 사이클이 필요하지 않으니까요.

A Real‑World Example

“한 사람이 새로운 사기 방지 도구를 추가하고 싶어했습니다. 그 사람은 우리 팀에 속하지 않았고 PureScript를 한 번도 다뤄본 적이 없습니다.”

우리는 5분 정도 대화를 나눈 뒤, 저장소를 공유하고 이렇게 말했습니다:

“보세요, 보안 엔드포인트만 있으면 정말 별다른 걱정은 없습니다.”

프로젝트의 README는 다음과 같습니다:

npm install
npm start

복잡한 설정이 없습니다. 기여자는 다음 날 풀 리퀘스트를 열었고, 코드는 깔끔하고 일관됐으며 UI는 친절했습니다.

Lessons Learned

Steep learning curves are no longer a show‑stopper.
좋은 문서, 복사‑붙여넣기 가능한 패턴, 그리고 LLM 지원 덕분에 기여 진입 장벽이 상당히 낮아졌다.
Don’t generalize.
모든 기여가 동등하다고 말하는 것이 아니며, 이 접근법이 깊은 기술 습득을 대체한다는 뜻도 아니다. 단지 시작 장벽을 낮출 뿐이다.
Stateless, isolated components는 실험하고 빠르게 반복하는 것을 안전하게 만든다.
LLMs can accelerate development는 유지보수를 희생하지 않으면서 개발을 가속화할 수 있다—단, 기반 아키텍처가 단순하고 잘 구조화되어 있을 때이다.

결론

언어 선택, 도구 체계, 그리고 LLM 도입에 대한 갈등은 불가피합니다. 하지만 그것이 파괴적일 필요는 없습니다. 다음과 같이 하면 됩니다:

낮은 마찰성과 조합 가능한 아키텍처 선택,
구성 요소를 격리하고 무상태(state‑less)로 유지,
보일러플레이트와 반복적인 코드를 위해 LLM 활용,

이를 통해 PureScript를 사랑하든, 싫어하든, 혹은 들어본 적이 없든 어느 쪽이든 기여자를 환영하는 시스템을 구축할 수 있습니다.

따라서 다음에 사용 중인 프로그래밍 언어에 대해 고민할 때, 프로세스와 환경이 언어 자체보다 훨씬 더 중요할 수 있다는 점을 기억하세요.

Open‑Source, LLMs, and Functional Code

작업 환경에서는 이제 좋은 인간 코드(나는 이것을 좋은 함수형 코드라고까지 말하고 싶다)를 가질 기회가 생기고, 다양한 기여자들의 문을 열 수 있습니다. LLM이 제공할 수 있는 수준보다 더 높은 기준이 있다면, 필요에 따라 언제든지 코드를 리팩터링하고 다듬을 수 있습니다.

보너스로, 유지보수성 및 버스 팩터에 대한 두려움을 낮출 수 있습니다. 마이크로소프트는 모든 것을 Rust로 다시 쓰기 위해 LLM을 사용할 것이라고 말하고 있는데, 누군가가 그런 주장을 할 만큼 용감하다면, 우리는 더 작은 규모에서 새로운 기술을 도입할 만큼 충분히 용감해질 수 있습니다.

누군가가 직장에서 당신의 Haskell 도구를 싫어한다면, 주말에 그것을 다시 쓰는 것을 무엇이 막을까요?
이제는 그 어느 때보다 쉬워졌습니다.

나는 Ruby, JavaScript, Python 코드를 함수형 언어로 마이그레이션한 경험만 있지만, 반대로도 잘 작동할 것이라고 확신합니다.

이것은 라이브러리를 만드는 경우에도 적용됩니다. 누군가가 다음과 같이 말한다면:

“아, 안돼! 새로 떠오르는 기술에 대한 Haskell SDK가 없어요!”

우리는 그들을 비웃으며 2025년으로 돌려보낼 수 있습니다! (죄송합니다, 이건 제가 가장 좋아하는 내부 농담 중 하나입니다.)

PureScript & FFI Generation

PureScript의 경우, 라이브러리를 다시 작성할 필요조차 없습니다 – 기존 JS/TS 라이브러리에 대한 FFI(PureScript 친화적인 바인딩)를 생성하면 됩니다. 또한 해당 라이브러리를 사용하는 TypeScript 코드를 생성하고, 그 코드에 대한 PureScript 바인딩을 생성할 수도 있습니다.

예시:
우리는 shadcn/ui를 사용하고 있으며 이미 몇 개의 그래프를 통합했지만, 모든 그래프가 다 포함된 것은 아닙니다. 몇 달 전, 데이터를 어느 정도 확인해 보고 싶었는데(캐시 개선 작업을 위해), 한 번만이라도 차트를 만들고 싶었습니다. LLM은 빠른 차트를 만드는 데 꽤 능숙합니다 – shadcn/ui 대신 Radix charts를 직접 사용하기를 선호합니다. 하지만 나는 이를 유지보수할 필요가 없으니, 누가 신경 쓰겠습니까?

(다음에 또 필요할 가능성이 있고, 아직 배우지 못했지만, 그건 별개의 문제입니다.)

Tooling & Errors

나는 불필요한 불만과 신화에 얽매이고 싶지 않으며, 마지막으로 언급하고 싶은 두 가지는 툴링과 오류입니다.

정확한 벤 다이어그램은 없지만, Haskell 툴링에 불만을 토로하던 많은 사람들이 이제는 채팅을 코드 인터페이스로 사용하고 있습니다. 그래서… 네… 스스로 결론을 내리세요.

컴파일 오류와 관련된 상황은 더욱 흥미롭습니다. Haskell, PureScript 등에서 발생하는 이러한 오류는 경험이 부족한 개발자와 숙련된 개발자 모두에게 큰 고통 포인트가 됩니다. 이 주제는 오래전부터 내 백로그에 있었습니다.

요약: 90 % 이상의 경우, 컴파일 오류는 실제로 매우 좋고 정확합니다. 문제는 오히려 너무 정확하다는 점입니다. 컴파일러는 문제를 정확히 알려 주지만, 당신이 이해하지 못하는 단어와 개념으로 설명합니다. 만약 이해했다면, 처음부터 실수를 하지 않았을 테니까요.

firstLetter :: String -> String
firstLetter xs = head xs

• Couldn't match type ‘Char’ with ‘[Char]’
  Expected: [String]
    Actual: String
• In the first argument of ‘head’, namely ‘xs’
  In the expression: head xs
  In an equation for ‘firstLetter’: firstLetter xs = head xs

0 || True

• No instance for ‘Num Bool’ arising from the literal ‘0’

덧붙여 말하자면, 나는 그 오류들을 변호하는 것이 아닙니다. 인간에게는 여전히 불편합니다. 하지만 뭐라고요? 머신에게는 정말 좋습니다. 그 불편한 오류들을 LLM에 입력하면 됩니다. 컴파일 오류를 두려워할 필요 전혀 없습니다.

A Real‑World LLM‑Generated Module

이 프로젝트에서는 LLM이 생성한 코드를 조심스럽게 다루었지만, 결국 Claudius만 읽고 수정하는 몇 개의 모듈이 생겼습니다. 한 번은 호기심이 생겨 우리가 만든 것을 확인해 보았습니다.

우리는 10개의 상태를 가지고 있었는데, 이는 비행 중 다양한 상황을 나타내는 일반적인 패턴이었습니다 – 하나의 동작이 진행 중일 때 다른 동작을 허용하지 않도록 하는 방식입니다. 각 동작/버튼마다 자체 플래그/상태가 있었고, 다른 모든 상태(9개)를 검사하여 비활성화 여부를 판단했습니다. 끔찍했습니다.

하나의 변경 사항이나 PR을 살펴보면…

ime, it’s fine – each one just adds a normal state, nothing special.

If you step back and look at the bigger picture – hell. It was a quick and easy fix to go from 10 states to 1.

Refactoring and dealing with tech debt are quite important, but can be scary. This is a point for languages with fearless refactoring, like PureScript. I can’t imagine how JavaScript developers, for instance, can survive this long‑term.

This is me, right now, on a specific project. It is not an argument for an FP‑only future.

당신에게 묻는 질문

사용하는 프로그래밍 언어에 신경을 쓰나요?
그에 대해 무엇을 하고 있나요?
LLM은 자신이 사용하는 프로그래밍 언어에 신경을 쓰나요?
언어 선택이 당신이 신경 쓰는 것들에 어떻게 영향을 미치나요?
그것이 미래에 어떻게 영향을 미칠까요?

현재는 2026년 2월입니다; 여러분의 의견이나 경험과 무관하게 새로운 추상화 수준 때문에 프로그래밍 언어의 중요성이 줄어들 가능성(0 %가 아닌 가능성)이 있습니다. 하지만 오히려 더 중요해질 수도 있습니다. 이것이 프로그래밍 언어를 선택하고 신경 쓸 수 있는 마지막 기회가 될까요?

다른 때에 더 길게 떠들고, 추측하고, 확장하고 싶지만, 아마도 다음에 할 겁니다.

사이드 퀘스트: PureScript 채택

그 프로젝트에서 제 사이드 퀘스트는 사람들을 PureScript에 흥미를 갖게 하고, 몇 명에게 가르쳐 주는 것이었습니다. 실패했습니다. 아무도 별로 원하지 않았고, 현재로서는 큰 동기가 없습니다.