@teslamint@hackers.pub · 4 following · 8 followers
평범한 백엔드 개발자입니다.
GitHub"(가칭) 파일 하나로 시작하는 C#" 이라는 도서를 집필하고 있습니다.
이제까지 전통적인 C# 도서들은 모두 Visual Studio 20xx 시리즈, JetBrains Rider, 혹은 Unity를 중심으로 서술하고 있습니다. 그러나 도구 우선이 아닌 프로그래밍 언어의 본질에 집중하는 책이 항상 아쉬웠습니다.
그러던 중 작년 가을에 출시된 .NET 10부터 기본 제공되는 "파일 기반 앱" 덕분에 드디어 제가 원하는 스타일의 본격적인 프로그래밍 언어에 집중하는 책을 낼 수 있게 되어, Windows 없이, Visual Studio/Rider/Unity 없이 C#을 제대로 사용할 수 있는 방법을 다루는 입문서를 기획하게 되었습니다.
현재 원고 초안을 완료한 상태이며, 베타 리딩을 진행하고 있습니다. 베타 리더로 참여를 희망하시는 분께서는 저에게 DM을 보내주시면 별도 단톡방으로 초대 드리도록 하겠습니다. 이후 자가 출판이 끝나면 무료로 도서도 증정해드리도록 하겠습니다! :-D
LLM에서 마크다운이 널리 쓰이게 되면서 안 보고 싶어도 볼 수 밖에 없게 된 흔한 꼬라지로 그림에서 보는 것처럼 마크다운 강조 표시(**)가 그대로 노출되어 버리는 광경이 있다. 이 문제는 CommonMark의 고질적인 문제로, 한 10년 전쯤에 보고한 적도 있는데 지금까지 어떤 해결책도 제시되지 않은 채로 방치되어 있다.
문제의 상세는 이러하다. CommonMark는 마크다운을 표준화하는 과정에서 파싱의 복잡도를 제한하기 위해 연속된 구분자(delimiter run)라는 개념을 넣었는데, 연속된 구분자는 어느 방향에 있느냐에 따라서 왼편(left-flanking)과 오른편(right-flanking)이라는 속성을 가질 수 있다(왼편이자 오른편일 수도 있고, 둘 다 아닐 수도 있다). 이 규칙에 따르면 **는 왼편의 연속된 구분자로부터 시작해서 오른편의 연속된 구분자로 끝나야만 한다. 여기서 중요한 건 왼편인지 오른편인지를 판단하는 데 외부 맥락이 전혀 안 들어가고 주변의 몇 글자만 보고 바로 결정된다는 것인데, 이를테면 왼편의 연속된 구분자는 **<보통 글자> 꼴이거나 <공백>**<기호> 또는 <기호>**<기호> 꼴이어야 한다. ("보통 글자"란 공백이나 기호가 아닌 글자를 가리킨다.) 첫번째 꼴은 아무래도 **마크다운**은 같이 낱말 안에 끼어 들어가 있는 연속된 구분자를 허용하기 위한 것이고, 두번째/세번째 꼴은 이 **"마크다운"** 형식은 같이 기호 앞에 붙어 있는 연속된 구분자를 제한적으로 허용하기 위한 것이라 해석할 수 있겠다. 오른편도 방향만 다르고 똑같은 규칙을 가지는데, 이 규칙으로 **마크다운(Markdown)**은을 해석해 보면 뒷쪽 **의 앞에는 기호가 들어 있으므로 뒤에는 공백이나 기호가 나와야 하지만 보통 글자가 나왔으므로 오른편이 아니라고 해석되어 강조의 끝으로 처리되지 않는 것이다.
CommonMark 명세에서도 설명되어 있지만, 이 규칙의 원 의도는 **이런 **식으로** 중첩되어** 강조된 문법을 허용하기 위한 것이다. 강조를 한답시고 **이런 ** 식으로 공백을 강조 문법 안쪽에 끼워 넣는 일이 일반적으로는 없으므로, 이런 상황에서 공백에 인접한 강조 문법은 항상 특정 방향에만 올 수 있다고 선언하는 것으로 모호함을 해소하는 것이다. 허나 CJK 환경에서는 공백이 아예 없거나 공백이 있어도 한국어처럼 낱말 안에서 기호를 쓰는 경우가 드물지 않기 때문에, 이런 식으로 어느 연속된 구분자가 왼편인지 오른편인지 추론하는 데 한계가 있다는 것이다. 단순히 <보통 문자>**<기호>도 왼편으로 해석하는 식으로 해서 **마크다운(Markdown)**은 같은 걸 허용한다 하더라도, このような**[状況](...)**は 이런 상황은 어쩔 것인가? 내가 느끼기에는 중첩되어 강조된 문법의 효용은 제한적인 반면 이로 인해 생기는 CJK 환경에서의 불편함은 명확하다. 그리고 LLM은 CommonMark의 설계 의도 따위는 고려하지 않고 실제 사람들이 사용할 법한 식으로 마크다운을 쓰기 때문에, 사람들이 막연하게 가지고만 있던 이런 불편함이 그대로 표면화되어 버린 것이고 말이다.
![* 21. Ba5# - 백이 룩과 퀸을 희생한 후, 퀸 대신 **비숍(Ba5)**이 결정적인 체크메이트를 성공시킵니다. 흑 킹이 탈출할 곳이 없으며, 백의 기물로 막을 수도 없습니다. [강조 처리된 "비숍(Ba5)" 앞뒤에 마크다운의 강조 표시 "**"가 그대로 노출되어 있다.]](https://media.hackers.pub/note-media/17646c5d-3f9d-472b-9d56-dd34006ad291.webp)
산타 할아버지는 알고 계신대
누가 착한 앤지 sudoer에 없는지
오늘 밤에 보안 감사 다녀가신대
teslamint replied to the below article:
Jaeyeol Lee @kodingwarrior@hackers.pub
이 글은 NestJS를 사용하면서 마주할 수 있는 소프트웨어 설계의 복잡성을 SOLID 원칙을 통해 해결하고자 한다. SOLID 원칙은 단일 책임 원칙(SRP), 개방-폐쇄 원칙(OCP), 리스코프 치환 원칙(LSP), 인터페이스 분리 원칙(ISP), 의존 역전 원칙(DIP)으로 구성되어 있으며, NestJS의 Controller, Service, Repository 구조를 통해 SRP를 실현하고, Interceptor를 통해 OCP를, 인터페이스를 통한 LSP, Guard, Pipe 등을 통해 ISP를, DI 컨테이너를 통해 DIP를 구현하는 방법을 설명한다. 각 원칙 위반 사례와 개선 사례를 비교하여 코드의 응집도, 유지보수성, 확장성, 유연성을 높이는 방법을 제시하며, 다이어그램을 통해 각 원칙이 적용된 코드 구조를 시각적으로 보여준다. 이 글을 통해 독자는 NestJS를 사용한 개발에서 SOLID 원칙을 적용하여 더 나은 소프트웨어 설계를 할 수 있을 것이다.
Read more →@kodingwarriorJaeyeol Lee OCP에 대한 코드 예제가 이상하네요, 위반 사례를 개선하려면 NestJS에 포함된 Logger 클래스를 쓰면 됩니다.
발표자를 위한 교훈 하나: 프리젠테이션에 코드 예제를 보여줄 땐 좀 과하다 싶을 정도로 간단하게 한다. 안 그러면 발표 환경/청중의 위치에 따라 코드가 안보이는 불상사가 생길 수 있다. 😂
.NET Universe Unplugged 2025-08 온라인 세미나를 진행하려 합니다. 온라인으로 누구나 .NET에 관련된 주제라면 무엇이든 들고와서 발표할 수 있는 세미나로 만들어보고 싶어 기획했는데, 많이 알려주시고 참여해주시면 좋을 것 같아 소셜 피드에도 공유합니다. :-D
https://forum.dotnetdev.kr/t/net-universe-unplugged-2025-08/13457
해커스펍에 크게 "웨이브" 밀려올 수 있습니다. 7월 중순에 중간규모로 한번... 8월 중순쯤에 두세번.....
Hello Hackers' Pub!
